Looking back I find it a bit amusing how "write once, run/debug anywhere" was the motto for Java, and Oracle used to make a big stink about how Java wasn't JavaScript, and yet it was JavaScript where that promise actually won out in the long run
8:15 if it's on paper, the classic sign for a space is a lowercase "b" woth a slash through it. On electronic media, it's often represented by a middle dot. Both can be easily used without causing (much) confusion with the rest of the ASCII character set.
harkens back to the IOCCC. Love it[0]. :) Bonus assignment: capitalize the b and the j with as few changes as possible. :) [0] as a fun exercise, not to be used (as you say) in production code, or even anything resembling that.
@@rafal06 It does and doesn't, actually. If you just evaluate it on its own in the console, it returns 0. If you use it as the right-hand sign of an assignment expression, e.g let a={}=[]; console.log(typeof a, a), it will print "string [object Object]" - it only shows 0 when it's there as a naked expression in the console. The same applies in Chromium-based browsers and Safari. In NodeJS, this changed somewhere in the 13.x release cycle. The safe way to get 0 is {}|[]
{}+[] (and {}+"", which I talk about briefly in the video) are misleading, because they return something different depending whether you evaluate them as an expression or run them as a program. As a program, they're both an empty block {} and then, separately, an expression with a unary plus operator + and an empty array/string, which is zero. If you wrap them in parentheses - or run them in nodeJS, which I assume interprets them as a single expression for some reason - the {} becomes an empty object, it tries to add that to whatever's on the right hand side and the only way to make that not explode is to make them both strings, so you get "[Object object]" plus the empty string. I ❤ JavaScript.
A small edge-case you missed about falsey-ness: - If you run [] == false, you get true. - If you run !![], you also get true. In short, an empty array is truthy and falsey depending on how you check it.
Could it be that this notion of truthiness was pioneered in Perl? Perl 5 came in 1994, Javascript appeared in 1995 (according to Wikipedia). But, I see that Javascript could have it's own industrial-grade obfuscated programming contests 😀
For me as a former C/C++ developer they are obviously truthy because they are not nulls. For the same reason type of null is obviously an object because of type of "Object *obj" is still an object pointer even if it's value is null.
@@househall what's null if not null pointer? and null pointer is just 0 casted to a pointer. It points to nothing, there is no Object. Also, 0 is equivalent to false. and what is an empty array? you can't malloc(0)
Aww, my prediction was wrong. I _almost_ correctly interpreted ({}+"")[!""+!""] as indexing 2 from the string "Object Object" (forgetting the square brackets), which would've been 'j', and predicted the entire expression would evaluate to "javascript"
I'm sorry, but JavaScript is in no sense elegant. Elegance of a system is a measure of how well it suits the problem it's trying to solve. Elegant languages have low impedance for use. JavaScript is for sure a simple language, but it was designed in a few weeks by essentially one person. You cannot expect elegance from that.
JavaScript is not a good language, it's a necessary and at this point pretty much irreplaceable language. The idea of just running code without needing to compile, in a way that can just be interpreted by all browsers is obviously grand. Just the design of the language itself is unfortunately pretty mediocre.
And would that "mediocre design" by any chance have anything to do with not requiring declared types or class definitions, and having automatic coercion? As seems to be the standard complaints about the "garbage JavaScript language" that seem to flow from every other "internet coder" out there, who dont' care to read specifications, and declare any language behaving other than whatever they learned first, as "bad". Or are there any actual design problems in the language that prevents it from being "good"? I'm honestly curious, because I've only ever heard whining about the way it handles types.
Is that critique really fair? Having a messy origin story and heroically standing by the past by ensuring backwards comparability isn't automatically disqualifying in my book. The latest version of ECMA script has cleaned up quite a bit as I understand it. What is the verdict if you follow best modern practice?
@@peterlinddk These are all valid complaints yes. All of these things (well besides classes) can pretty effectively be avoided by using TypeScript (or jsdoc if you don't want to compile an interpreted language), though. The thing about js is that it's pretty bad in doing what it's made for, making a webpage interactable. You basically need some sort of framework if you want to have any kind of complex data rendered on a webpage in a maintainable way. I really dislike the size and overhead of these frameworks, which is unfortunately not avoidable without native support by the language. The way it handles types natively is a pretty good indication of the mindset this language was created with though, and the kind of legacy it holds. It's not possible to get rid of this legacy though. In general, I personally prefer static typing, and more hardware close languages. I recently started learning Rust, which I really enjoy. I dislike a lot of the design choices you have to deal with as a web dev.
Javascript is bad, Python is slow. The funny thing is… “There are only two kinds of languages: the ones people complain about and the ones nobody uses” (c) Bjarne Stroustrup It’s easy to be that categorical when your knowledge of something is mediocre (or worse) 🤷🏻♂
Looking back I find it a bit amusing how "write once, run/debug anywhere" was the motto for Java, and Oracle used to make a big stink about how Java wasn't JavaScript, and yet it was JavaScript where that promise actually won out in the long run
either way we are f*cked, and that poor island in Indonesia has it worst
Oracle owns the JavaScript name anyway, so 🤷
2:00 I can't be the only person who saw that and thought of Brainfuck.
These videod are just sooo good
Please don't stop making them 🙏
Oh, I thought this would be about WASM-WAT (WAsm Text format).
you can take this to an extreme and obfuscate *any javascript program* into only using the characters []()!+
i love javascript, masochistically
it's called JSFuck
8:15 if it's on paper, the classic sign for a space is a lowercase "b" woth a slash through it. On electronic media, it's often represented by a middle dot. Both can be easily used without causing (much) confusion with the rest of the ASCII character set.
harkens back to the IOCCC. Love it[0]. :)
Bonus assignment: capitalize the b and the j with as few changes as possible. :)
[0] as a fun exercise, not to be used (as you say) in production code, or even anything resembling that.
Zero-based footnote indexing, love it.
@@raffriff42 but of course!
(Thanks! 😊)
JavaScript: The Ugly Parts
...aka the parts that make you go "WAT???!!!!"
Dunno when, but from the WAT talk, things have changed.. {}+[] and []+{} now both return '[object Object]' in NodeJS
the first one returns 0 in firefox
@@rafal06 It does and doesn't, actually. If you just evaluate it on its own in the console, it returns 0. If you use it as the right-hand sign of an assignment expression, e.g let a={}=[]; console.log(typeof a, a), it will print "string [object Object]" - it only shows 0 when it's there as a naked expression in the console. The same applies in Chromium-based browsers and Safari. In NodeJS, this changed somewhere in the 13.x release cycle. The safe way to get 0 is {}|[]
{}+[] (and {}+"", which I talk about briefly in the video) are misleading, because they return something different depending whether you evaluate them as an expression or run them as a program. As a program, they're both an empty block {} and then, separately, an expression with a unary plus operator + and an empty array/string, which is zero. If you wrap them in parentheses - or run them in nodeJS, which I assume interprets them as a single expression for some reason - the {} becomes an empty object, it tries to add that to whatever's on the right hand side and the only way to make that not explode is to make them both strings, so you get "[Object object]" plus the empty string.
I ❤ JavaScript.
For some reason I feel like starting a fire.
A small edge-case you missed about falsey-ness:
- If you run [] == false, you get true.
- If you run !![], you also get true.
In short, an empty array is truthy and falsey depending on how you check it.
🤣 That's brilliantly ridiculous! And what I'm hearing is that this process could generate working Rockstar code?
Oh, no, Rockstar takes things a step further. In Rockstar 2.0 you can add, subtract, multiply and divide strings. No NaNs to worry about.
Oh no, it’s ridiculously brilliant… What looks like a complete silliness actually teaches you JS syntax!!!
Could it be that this notion of truthiness was pioneered in Perl? Perl 5 came in 1994, Javascript appeared in 1995 (according to Wikipedia).
But, I see that Javascript could have it's own industrial-grade obfuscated programming contests 😀
Truthiness goes back at least to C, as in *if (c = getchar()) {* _/* assign to c, check if assigned 0 */_
idea for javaScript update: !Nan = "number"; !"number" = String; String*String = "crossword"...
I hate that empty arrays are truthy in JS. They are falsey in Python and that seems reasonable.
For me as a former C/C++ developer they are obviously truthy because they are not nulls. For the same reason type of null is obviously an object because of type of "Object *obj" is still an object pointer even if it's value is null.
@@househall what's null if not null pointer? and null pointer is just 0 casted to a pointer. It points to nothing, there is no Object. Also, 0 is equivalent to false.
and what is an empty array? you can't malloc(0)
The hole concept of truthyness for anything other than booleans is heresy
@@woosix7735 tell that to the C programmers. They don't even have an actual boolean type.
@@woosix7735 I agree
classic jsfuck
actually not even true jsfuck
@@minigamer4262 so... truthy jsfuck, I guess?
This is like the opposite of Hacker's Delight. Hacker's Horror?
Aww, my prediction was wrong. I _almost_ correctly interpreted ({}+"")[!""+!""] as indexing 2 from the string "Object Object" (forgetting the square brackets), which would've been 'j', and predicted the entire expression would evaluate to "javascript"
NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN
the automatic translation by google to 'Yes' is extra funny, NaN should not be truthy
I was like, wat? Wat is awesome? Yes.
I detect a reference to KOHUEPT.
Madness 😂
Hahaha! Excellent! 👌
Yea.... the logic of JavaScript ist totaly intuitiv and clean with basic abstract rules, where everything else you can adapt from.....🙄
What did I just watch? I looked like a pile of loose sand shifting ...
😂😂😂😂
Just as Brendan Eich saw it
I'm sorry, but JavaScript is in no sense elegant. Elegance of a system is a measure of how well it suits the problem it's trying to solve. Elegant languages have low impedance for use. JavaScript is for sure a simple language, but it was designed in a few weeks by essentially one person. You cannot expect elegance from that.
It can be elegant, if you avoid the root of all of these problems: type coercion.
JavaScript is not a good language, it's a necessary and at this point pretty much irreplaceable language.
The idea of just running code without needing to compile, in a way that can just be interpreted by all browsers is obviously grand.
Just the design of the language itself is unfortunately pretty mediocre.
PHP: hold my beer! (I know, different beast but also something that became somewhat relevant despite its questionable design..)
And would that "mediocre design" by any chance have anything to do with not requiring declared types or class definitions, and having automatic coercion? As seems to be the standard complaints about the "garbage JavaScript language" that seem to flow from every other "internet coder" out there, who dont' care to read specifications, and declare any language behaving other than whatever they learned first, as "bad".
Or are there any actual design problems in the language that prevents it from being "good"?
I'm honestly curious, because I've only ever heard whining about the way it handles types.
Is that critique really fair?
Having a messy origin story and heroically standing by the past by ensuring backwards comparability isn't automatically disqualifying in my book.
The latest version of ECMA script has cleaned up quite a bit as I understand it.
What is the verdict if you follow best modern practice?
@@peterlinddk These are all valid complaints yes. All of these things (well besides classes) can pretty effectively be avoided by using TypeScript (or jsdoc if you don't want to compile an interpreted language), though.
The thing about js is that it's pretty bad in doing what it's made for, making a webpage interactable. You basically need some sort of framework if you want to have any kind of complex data rendered on a webpage in a maintainable way. I really dislike the size and overhead of these frameworks, which is unfortunately not avoidable without native support by the language.
The way it handles types natively is a pretty good indication of the mindset this language was created with though, and the kind of legacy it holds. It's not possible to get rid of this legacy though.
In general, I personally prefer static typing, and more hardware close languages. I recently started learning Rust, which I really enjoy. I dislike a lot of the design choices you have to deal with as a web dev.
Javascript is bad, Python is slow. The funny thing is… “There are only two kinds of languages: the ones people complain about and the ones nobody uses” (c) Bjarne Stroustrup
It’s easy to be that categorical when your knowledge of something is mediocre (or worse) 🤷🏻♂