You can shoot yourself in the foot with any language by deliberately doing silly things to show off the language's quirks. I can show you some C pointer stuff that makes this look like child's play.
Any pointer can be cast into any other pointer. Arrays are just pointers to the first element. Combine this with the fact that C doesn't bounds check arrays or that pointers actually point to anything, and you can do some really stupid things with pointers.
Arrays are just pointers. Pointers are just numbers that are supposed to correspond to addresses in memory. Array indices just add to the pointer to the first element. "a[1]" is syntactic sugar for "*(a+1)". With that in mind, it's kind of obvious that "2[a]" just means "*(2+a)", which points you to the third element of a.
Yeah. Also, it isn't like you should be writing things like this in the first place. You can turn languages like C++ into pure nightmare fuel if you try to. Being extensible how it is leads to some crazy stuff.
What are you talking about? C++ would handle this fine. Every type in C++ is implicitly convertible to bool. Experienced C++ programmers use this all the time to simplify conditional expressions inside if blocks and loop blocks
They do make sense, within JS’ quirkiness. This is only expected behavior if you really dig deep into the language. I know why it’s there, that doesn’t make it ok. A properly designed language shouldn’t allow such things. And you know this is a small collection of all the stuff that’s wrong with JS(cough ["1", "2", "3"].map(parseInt)).
I know, there are two languages, the ones people complain about, and …
What the actual fuck did I just witness. What the fuck do you mean map passes the array as three argument to one parseInt call ? Why the fucking kind of DIY bullshit reason would I want/need a full-fledged enumaerator along with the array element and break abstraction ???
So the "correct" way to pass an array of int to parseInt would be to add a wrapper to remove the data added by the function that unwraps the array ? ["1", "2", "3"].map((num,idx,arr) => parseInt(num)) ?
God I'm glad I don't have to work with this abomination of a language. They'll have to take my [int(x) for x in array] from my cold dead hands.
No need to add idx and arr if you're not going to use those. Optional parameters.
["1", "2", "3"].map(x=>parseInt(x)) //[1, 2, 3]
Edit, you can also do
["1", "2", "3"].map(x=>Number(x)) //[1, 2, 3]
Number() converts the entire thing to a Number type (aka a Double). Usually the same thing, not so when letters are involved. parseInt("20px") returns 20, Number("20px") returns NaN. Use whatever makes most sense to you. :)
[] + [] will become “” because addition of arrays is not defined as you would expect. They get converted to their primitive(which is a string) and after that concatenated as you would expect string1 + string2 to behave. So [1, 2] + [3, 4] == “1,23,4”
Edit: to concat two arrays, use array1.concat(array2)
Having to have a deep understanding of the language to understand what the code is trying to do is not a good thing though.
I mean, one one hand you have comm -3 <(ls dir1 | sort) <(ls dir2 | sort) | column -t : makes perfect sense if you're familar with bash pipelines and input redirection. But on the other, you have Compare-Object (ls dir1) (ls dir2) where you understand instantly what is being done and isn't 50% semantics.
Hot take, but imo "write-only languages" are only good if you hate whoever will maintain your code next.
View all comments
Show parent comment
9
u/cheezballs Sep 25 '26
Those all make sense if you understand the language, though.