I strongly advise not to do that. As others pointed out, it really is just predicting the next word. It is worth learning about how to problem solve and to recognize that the only way to become a better program is with practice. It’s better to get programming advice from real people online and read the documentations for the functions and languages you are trying to use.
If the internet has succeeded in anything, it’s that the illusion of competence is worth more than the thing itself. Until someone calls you out, that is.
Y’all I dislike forced browser adoption as much as the next guy.
And I’ve been using Firefox for years and years and years now.
But, I’m forced to use edge for work. And, as a browser purely, none of the anti-trust baggage attached…
It’s really not too bad. A lot of things work just fine. And sometimes, if I’m having weird performance on a website on a personal device, loading the same URL in edge has resulted in improved/expected functionality of the website
I continue to use Firefox because I started using it a while ago and would rather not switch. I have to use Edge for school and it’s legitimately equal to Firefox in many ways. With Bing AI added, Edge blows Firefox out of the water.
The only reason Bing AI only works on Edge is because Bing AI specifically checks for edge. There was an extension that made it work on Firefox by simply lying about the browser, but Microsoft DMCA’d the developer.
Yes, when I have used Edge it’s been absolutely fine. Probably better than Chrome. I’d likely be quite happy to use it most of the time if it wasn’t for the fact that Microsoft are so intent on forcing me to do so.
I mostly use Vivaldi now which I think is by far the best of the Chromium-based browsers.
Yeah the problem with memes like this is (according to market share) that there are people that switch from Edge to Chrome and think they are actually using a better product
GitLab don’t have the monetary incentive to implement federation. Most of their revenue is coming from big companies which are mostly using private GitLab instance and won’t want their projects federated.
That being said, hope this changes can get merge as somebody already done the dirty work for them. The beauty of open source.
How can more instances not lead to more money? Look at the explosion of mastodon and other federated software. There’s a lot of good will in the community and being a viable competitor to Github is definitely not worth nothing. If Gitlab could offload the majority of users from their main instance, I bet it would actually save them money. And more users, probably also means more contributors since they’ll have experience hosting the instance and fixing issues they run into.
IMO, it’s short-term thinking to say “federation is of no value to us”.
This meme is really only true for things like Slack where the app is just the webpage in an app, and even then it's not quite true because Electron is a lot heavier than a webpage because it has to now run the webpage and the app - which I think is terrible.
But then also, Electron enables actual apps to be developed using web standards - which I think is great.
TLDR: Use Electron to make apps, not glorified webpages.
For Slack it does. Building an app via Electron means it’s cross-platform by default, so Slack doesn’t need to invest in separate platform teams to solve the same problem (Windows, macOS, Linux).
Electron also has better support for things like native notifications, video and voice calls, offline capabilities, and to other native APIs etc that are either unsupported or spottily supported via the browser.
It’s a much more lightweight option for building cross platfrom apps than Electron. Heck, even Tauri is better than Electron even though it also uses web technologies for UI.
It has all this support for native platforms yet it’s always a clunky memory hog that makes zero effort to respect the design language of the OS it’s running on.
I’m on macOS, I want the app to be a native macOS app. If I wanted it to look like a webpage, or Windows, or Linux GTK then I’d switch to one of those and expect it to match those paradigms.
It has all this support for native platforms yet it’s always a clunky memory hog
Maybe so but it has improved a lot over time. The app devs share some responsibility too so it’s not all on Electron.
zero effort to respect the design language of the OS it’s running on.
That’s the Dev’s design choice, not a limitation of Electron.
I’m on macOS, I want the app to be a native macOS app. If I wanted it to look like a webpage, or Windows, or Linux GTK then I’d switch to one of those and expect it to match those paradigms.
I don’t disagree but at the end of the day it doesn’t matter to enough people for it to become an issue. People are used to Slack and the way it works.
Moreover the cost of building the same app 2x or 3x simply doesn’t make business sense.
I’m a web developer but is there no concept of classes, libraries, etc in other programming languages?
What happened to writing the “core” of an app that doesn’t rely on UI then simply writing the front ends for each platform you want to support?
You keep saying Electron is used for better compatibility and listing out Linux, Windows, macOS but here’s the thing — most companies are only targeting those. That’s just three (if you don’t write for a million desktops on Linux).
Is it really so hard to support just three environments with only the UI being tailored for the OS it’s running on?
Honestly, it just feels like poor tooling and a poor excuse.
What happened to writing the “core” of an app that doesn’t rely on UI then simply writing the front ends for each platform you want to support?
What do you mean? I can’t speak for Slack but I’m sure some degree of business logic / client side logic separation exists.
By the way, what you just described is the essence of cross-platform development, rather than an argument for building apps natively.
simply writing the front ends for each platform you want to support?
But why would you rewrite the “front-end” for each platform if you have one you could just port over? Who is going to pay for those 2x developers and what would be the ROI on this effort?
That’s just three (if you don’t write for a million desktops on Linux).
Is it really so hard to support just three environments with only the UI being tailored for the OS it’s running on?
In Slack’s case I’d wager the answer to be a resounding YES. I don’t think you fully grasp the full scope Slack’s capabilities, and the amount of work involved to build native clients for not just one or two, but three different platforms - it’s definitely not just the “UI”.
Honestly, it just feels like poor tooling and a poor excuse.
Quite the opposite - frameworks like Electron let’s devs with your skillset build with the stack you already know, and abstracts away quite a bit of the cross-platform complexities, which strangely enough is what you are suggesting but also what you are arguing against
huh. what was the rationale for removing it in the first place? seems like a waste to throw away a whole codebase worth of perfectly good type annotations
You can have frameworks which fully generate the JS DOM code for you, allowing you to write complete single-page applications without writing a single line of JS.
Yep, that’s the framework, I’m using, too. But most frameworks in the Rust ecosystem can do DOM interop, as the heavy lifting for that is provided by the wasm-bindgen library.
Flash and AS3 was so much fun to work in. I completely understand why the industry moved away from it but even today we have yet to fully catch up to all the media animation and programmatic features it provided all in one. RIP.
Unpopular opinion: I hope it’s going to be a flop (apart from the few use cases where it does make sense). The limitation of having just JavaScript ensures level of interoperability which is IMHO one of the big advantages of web as an application platform. If WASM becomes successful, it will fragment the web.
Mypy is just okay. Haven’t used TS to know the dark corners there, but any type system that’s bolted on to the language is going to have dark corners in the best case.
It’s better than no type system, however. I remember when typed languages were “bad” because it “slowed you down” and “wasn’t necessary if you know what you’re doing”… how naive I was when I repeated those words so many years ago :)
I view it more like a powered exoskeleton around a blob fish. IMO static typing is way more valuable than strong typing and I’d take static typing only over strong typing any day if I can only choose one.
No. It always compares by converting to string. I actually think this is more consistent then having different behaviour if you have a string somewhere in your list.
Basically the default comparator is a.sort((a, b) => ${a}<${b} ? -1 : 1).
It also produces incorrect results in many languages other than English. You can pass it a compare function that uses localeCompare or Intl.Collator to get a correct alphabetical sort.
JavaScript is what’s called an “untyped” language, so here, it assumes that the numbers are words, and tries to sort them alphabetically. Specifically, it tries to sort them alphabetically as a dictionary would in a left-to-right language like English. In this case, just as “apple” would come before “asterisk”, 100000 would come before 21.
(Some would argue that it’s more of a “weakly typed” language, I know, but I’m trying not to be pedantic here.)
Sorting them as actual numbers would require some extra explicit instructions and guides. Most typed languages, like C, aren’t like this.
is there a good reason for javascript to work like that? python also isn’t typed like C and it sorts integer lists in the “normal” way, so it seems avoidable. (i don’t really know what im talking about here. i’ve never used javascript and i’m not familiar with how typing works under the hood.)
Mainly because JavaScript was designed to work along side HTTP in a browser. Most of its input will be text, so defaulting common behavior to strings makes some sense.
That’s misleading at best and most likely just false, and it’s worrying it’s so upvoted.
There’s no historical record explaining why this was designed this way, but we can infer some things. HTTP is very unlikely a factor, XHR / AJAX has been added years after the .sort() function. Additionally, it doesn’t make sense in the context that other comparisons are not string-wise (sort()/quicksort is basically a series of comparisons).
The trouble with JS arrays is that they can contain any values - e.g. [false, undefined, 1567, 10, “Hello world”, { x: 1 }]. How do you sort those? There must be one function to compare every combination of value, but how do you compare booleans and objects?
There’s no such function which would provide reasonable results. In that context, doing .toString() and then string-wise comparison/sorting doesn’t seem that crazy - every object has .toString(), it will compute something, and often it will work well enough.
There could be some additional smartness - if the array contains numbers only, it could choose to use a number-wise comparison function. But that would require a) extra implementation complexity (JS was famously designed in short time) and b) reduced performance - since JS runtime doesn’t know what type of values are present in the array, it would have to scan the whole array before starting the sort. But I guess the a) was the decisive factor in the beginning and backwards compatibility prevented improving the function later.
You are probably correct. I don’t know if it’s true, it’s probably more likely it was a way for it not to fail.
I said HTTP mainly because HTML is plaintext because of it. 1.0s main purpose was to manipulate the page. Of course Array objects weren’t added til 1.1, when netscape navigator 3.0 released, but it was still mostly 1.0 code. I felt like having everything be coercable to string made it easy for you to just assign it to the document. If you assigned the wrong thing it wouldn’t crash.
I originally thought there was a precursor to microsofts XMLHTTP in an earlier version due to the 1997 ECMAScript documentation specifically talking about using it both client and serverside to distribute computations, but it was far more static. So, I’m probably just wrong.
The hard part is sorting values of different types.
Python 2 had a order of built it types. Something like None < bool < numbers < strings. This means that you could sort anything like JavaScript and behaves fairly reasonably.
Python 3 takes the “safer” approach and comparisons of different types throw an exception. (You can override the comparison behavior for your own types and do something different).
JavaScript has conventionally been a very loosely typed language. So it almost certainly wouldn’t have chosen the exception throwing option. It does something similar to Python 2. But instead of just directly comparing the values of different types it converts them to strings first, then compares everything as a string. This is probably the most reasonable option. Otherwise you would have problems because 10 < “2” and “2” < 3 but 3 < 10. How can that work? You have no total ordering! So basically because the comparison operators convert to strings if either argument is a string the default sort comparator really doesn’t have a choice but to do convert to string. The other option would be to define a total order just for the sort function but that seems more confusing.
It’s also an incorrect alphabetical sort in many languages that use accented characters. For a correct sort you need to pass it something like the localeCompare function or Intl.Collator.
You can put any type of value in an array in JavaScript. You can have numbers, strings, booleans, arrays, and objects. So what should the default sort function sort by? Sorting by numbers makes sense, but what if it wanted to sort strings instead?
When you don’t know what value is in an array ahead of time you can’t assume how to sort it. When you’re controlling the program you can provide a sort function for the type of values you know will be in it, but when you’re writing the standard default sort function, there’s only one type that you can convert all the other types to safely and simply in the most predictable way, which is strings.
Think of digits like you would letters. You’re essentially sorting numbers alphabetically. It’s not the right way to do it, of course, but it’s the natural way to do it using a system like computers use that doesn’t necessarily differentiate between digits and letters unless you tell it to specifically.
I think the main shortcoming here is that there isnt a way to specify the type to sort as, instead you have to write the function to compare them as numbers yourself. If it’s such a simple implementation, why isn’t it officially implemented? Why isn’t there a sortAs() that takes two args, the input list, and a Type value? Check every element matches the type and then sort, otherwise return a Type Error.
I mean, there’s a sort() method that takes a comparator(a,b) such that if a comes first it returns 1, if b comes first it returns -1 and if they’re equivalent wrt sortinf it returns 0. If you absolutely need type safe number sorting you can use that to get it.
Right, but you have to make that comparator yourself, it’s not a built-in part of the language. The only built-in comparator converts values to strings and compares them in code units orders.
Also, that technically isnt type-safe, is it? If you threw a string or a NaN at that it would fail. As far as I knew, type safe means that a function can handle type errors itself, rather than throwing an exception. So in this case the function would automatically convert types if it was type-safe to prevent an unhandled exception.
Not every use case can be the built-in default. I wouldn’t have made JS weakly typed if I were designing it, but once the decision was made to use weak typing it made sense to either have no default sort method or to have a default sort method that assumes a type.
What I’ve outlined for you is the interface for a comparator, not the implementation. You can type check and convert and do anything else you want under the hood of the comparator you write.
It doesn’t have to be the default to be built in, tho. It could be an overloaded function, having the “default” be the typical convert-to-string sorting, and an overloaded function that allows to specify a type.
It’s just such a common thing, wanting to sort a list by different types, that I’m surprised there hasn’t been an official implementation added like this. I get that it a simple “fix” to make, but I just think that if it’s that simple yet kind of obscure (enough that people are still constantly asking about it) there should be an official implementation, rather than something you have build yourself.
Thats just JS for you. If you’re being generous, it’s a “quirky” language. If you’re being ungenerous, it’s a steaming pile of arbitrary decisions, gotchas, unexpected behaviors and problems that no one bothered to solve because there’s a workaround.
Yeah, JS always seemed like the red-headed stepchild of modern languages. I’d be curious to know if other ECMAScript languages like JScript are as, eh, “quirky”, suggesting that the ECMA spec is the source of the quirkiness, or if JavaScript itself is the one making silly decisions. Technically, I mostly work with Google’s AppScript when I use ECMAScript stuff, but I’m fairly certain AppsScript is based off of JavaScript instead of directly based on the ECMA spec, so I don’t think it’s separate enough for me to draw a conclusion there.
Because it turns everything into text first. Just in case you try to sort [1,“apple”,45.99,false,[true,3]] rather than an array of similar things like a normal person.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.