Yeah, almost certainly the software only uses 4GB because it limits itself to what memory it has available.
I have seen this conversation pan out a few times already. It has always been because of that, and once expanded things work much better. (Personally I have never took party at one, I guess that’s luck.)
This was excellent, but conveniently left off any discussion that npm can “un-un-publish” a programmer’s code against their wishes, and apparently without repercussions?
Absolutely they can un-unpublish since the programmer has given everyone the rights to use his code wherever they want, with its open license. Npm can actually use the older version of the code and give it to everyone. Its actually a good thing
Thank fuck for that, cause if they didn't faker.js and node-ipc would have caused a lot of trouble, with the developers adding malware to a new version and later deleting the entire packages, breaking tons of projects. And those were everything but small packages.
All for the greater good, especially if it’s the choice between one guy’s desire to nuke their own code VS tens / hundreds of thousands of projects that depend on it.
sometimes i start my iterator with = -1. As I only +=1 it with a condition and I know that it will return true on the first cycle. I’ll chuck array[iterator] and need it to be 0 to start with ofc.
I just have no idea how to not do this, but it looks so bad, i need a i8 instead of a u8 at least because of this
I could tell you my recent cenario, but it wouldn’t get us anywhere. because I know that it’s avoidable, but it’d take for me to run a different logic for only first element of my array. which is doable, but it’d make the code like 5 extra lines longer, harder to read/follow. But I just simply choose to put -1 and boom it’s fixed, just works.
another solution would be (without context) is to add one more variable and one more check to my foreach, but that takes more memory and cpu, I usually choose the i = -1, it’s ugly but not as ugly as other solutions would be
So you can have a local, and a team config. So at time of commit the code rules your team has selected are enforced. So if I looked at my code, on GitHub, it would look as expected by the team.
I love such formatters and wish they were even more widespread. In many cases, I really want consistency above all and it’s so dang hard to achieve that without an opinionated formatter. If the formatters isn’t opinionated enough, it just leads to countless human enforced rules that waste time (and lead to an understandable chorus of “why can’t the formatter just do that for meeeee”).
Yeah but outside of that where the code is implemented or in a documentation, tabs are still easier to look through. And it does look pretty as long as there aren’t too many nested functions.
That’s really interesting. So does that mean the interpreter just checks whether the current line is more indented, less indented, or equal vs. the preceding, without caring by how much?
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.
Because Python uses indentation instead of curly brackets, which is why this meme exists. Also jetbrains ide s like pycharm and webstorm do all of this for you.
Not as good as jetbrains does, it automatically does things like realign when you paste things and lots of little things that improve the coding experience by a lot.
Me too, any day. I hate everything where indentation matters. Let me just throw my garbage there and YOU sort it out, you are the fucking computer, not me. You do the work.
Spaces? Tabs? Don’t care, works regardless.
Copied some code from somewhere else? No problem, 9/10 times it just works. Bonus: a smart IDE will let you quick-format the entire code to whatever style you configured at the click of a button even if it was a complete mess to begin with, as long as all the curly braces are correct.
Also, in any decent IDE you will very rarely need to actually count curly braces, it finds the pair for you, and even lets you easily navigate between them.
The inconsistent way that whitespace is handled across applications makes interacting with code outside your own code files incredibly finicky when your language cares so much about the layout.
There’s an argument to be made for the simplicity of python-style indentation and for its aesthetic merits, but IMO that’s outweighed by the practical inconvenience it brings.
Have you tried using an auto formatter? Let’s you write code however and fixes the structure automatically on save. It’s way easier for me to write curly braces then hit ctrl+s than have to select multiple lines manually and tab in and out. I feel the biggest gains I’ve made in productivity came after I learned to embrace tooling.
I used to write websites with Notepad. The upside is that you really had to learn HTML to do it; the downside is that it proves to the world that you’re a fucking lunatic.
@alphacyberranger
This is why I have my VSCodium set to highlight all indentation levels in my settings.json
To see the editor indent guides, set "editor.guides.indentation": true and "editor.guides.highlightActiveIndentation": true.
editorIndentGuide.background: Color of the editor indentation guides.
editorIndentGuide.activeBackground: Color of the active editor indentation guide.
This is due to the default sorter in JavaScript sorting by the string value. The reason for that is that this won’t create errors at runtime. Since JavaScript does not have types, this is the safest way of sorting.
This works:
<span style="color:#323232;">const unsorted = [1, 100000, 21, 30, 4]
</span><span style="color:#323232;">const sorted = unsorted.sort((a, b) => a - b)
</span>
Which is a fine decision if you have a programming language to do silly stuff on a personal geocities page, but a horrible one when you start using that language to handle serious data. Silently ignoring what’s probably a bug is dangerous.
ah yes, a reasonable solution to that problem that any human would think of
ah yes, a reasonable problem that any human would think of – “what if someone tries to sort a list containing some integers and some arrays, and our interpreter needs to keep chugging instead of telling the programmer they fucked up?”
I first started programming with TurboBasic which had the oh-so-amusing characteristic that you could have variable names of any length but the compiler only used the first two letters (and case-insensitive at that). So “DonutCount” and “DoobieCounter” actually referred to the same variable.
Really good times trying to debug that kind of shit.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.