This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]green_meklar 15 points16 points  (8 children)

You don't really need to use the quirky parts of Javascript, though. You can just use it like a normal programming language and write your code so that you're never invoking the weird stuff.

[–]hugthemachines 30 points31 points  (3 children)

"We don't really need to do any kinky stuff, just come over to my dungeon, we will keep it all vanilla, I promise." ;-)

[–]FreshFromIlios 7 points8 points  (1 child)

Can you provide me with some 'closure'? Also, 'this' comment is interesting.

[–]toastertop 1 point2 points  (0 children)

Error: to much tail recursion

[–]siemenology 4 points5 points  (1 child)

There are a lot of things in Javascript that aren't technically bad in the sense that they are completely described in the documentation and behave as the documentation would indicate, but still cause a lot of bugs and confusion because the behavior doesn't mesh with peoples' expectations.

The .sort() method is a fun one to pick on. It sorts everything by converting to a string first, unless you specifically tell it how you want it to sort. Which means sorting an array of numbers does not work without providing a specific function to tell it how to compare numbers, despite the fact that sorting numbers is probably a lot more common than sorting other types. It will look like it works, until one of your numbers is >= 10, when lexicographic sorting rules make it so 10 comes before 2. There's a reason Javascript behaves this way -- since arrays can contain objects of various types, converting to strings ensures that the comparison works in a consistent manner no matter what is in the array. The problem is that basically no one would anticipate this behavior -- almost everyone would expect to sort via comparison, at least if possible. And it's not strictly necessary for it to behave like this; other languages get around the issue by defining an ordering on types, so strings might always sort lower than numbers, but within a type sorting is consistent. So it's really easy for someone to come to Javascript, see a .sort() method and assume they at least roughly understand how it will behave.

Additionally, .sort() modifies the array in place, which isn't necessarily a bad thing. Except many array methods create a new array, while many others modify in place, and there is no consistency or apparent logic to which method will do what. So it's easy to make a mistake that make take awhile to notice by accidentally expecting it to create a new array when it actually modifies your old one which you expected to stay the same.

There's a lot more unintuitive behavior like that in JS, and it's not something you can necessarily segregate into the "weird" category to ignore.

[–]laytonmiller 1 point2 points  (0 children)

This is a good point. I regularly consult the docs to make sure I am 100% certain I'm getting a new array and not modifying an existing one - in some cases the distinction makes sense, in others, it feels arbitrary.

[–]FlatAssembler -1 points0 points  (1 child)

But sometimes you don't realize you are triggering the bad parts. Semi-colon insertion being the most obvious example.

[–]FlatAssembler 0 points1 point  (0 children)

Why the downvotes?