8 ways JavaScript is just... different.
Вставка
- Опубліковано 11 чер 2024
- To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/DreamsofCode/ . The first 200 of you will get 20% off Brilliant’s annual premium subscription.
JavaScript is the most popular language out there. Despite this fact however, it does a lot of things slightly different to other languages.
In this video, I take a look at 8 of those things that JavaScript has it's own original take on.
This video is sponsored by Brilliant.
Become a better developer in 4 minutes: bit.ly/45C7a29 👈
Support the channel by becoming a member:
/ @dreamsofcode
Join Discord: / discord
Join Twitter: / dreamsofcode_io
00:00:00 Intro
00:00:15 Equality
00:02:12 arithmetic
00:03:12 Sorting
00:05:08 Sponsor
00:06:20 Hoisting
00:07:13 Scoping
00:07:49 Nil values
00:08:53 NaN
00:10:40 this - Наука та технологія
To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/DreamsofCode/ . The first 200 of you will get 20% off Brilliant’s annual premium subscription.
I am convinced that JS is a language that was solely invented for the purpose of creating _those_ trick interview questions.
Its time for them to fire that fox!
It works just fine if you only use it on the client side, don't use var and refrain from validating data or making any calculations besides counting.
@@GeneraluStelaru It starts like this, and before you realise there are 100 other quirks you need to be aware of lol
Brendan Eich ruined interviewing.
NaN will not equal NaN in any language ( that follows the floating point standard ), even including floating point cpu instructions, which at least on x86 output a state called "unordered".
This has a very good reason.
It would be unreasonable to say that 0/0 == infinity - infinity, but both are NaN.
This is especially true in the programming context where precision can cause NaN where not expected.
NaN will not equal NaN in any reasonable language, but I think Rust is an example of how programming language should approach this problem. Instead of saying that Float is Eq but silently break its contract, Rust instead explicitly says that Float is not Eq, only PartialEq
@@xwtek3505 what exactly is that supposed to mean? I am not familiar with Rust terminology
@@U20E0 I think ordering is a better example: Rust has two traits (similar to an interface) for ordering: Ord and PartialOrd. The compare method in Ord returns an Ordering, i.e. less, equal or greater. But the compare method in PartialOrd returns Option, so for non-comparable inputs it can return None. So the type system helps you cover all possible cases.
However the case for Eq and PartialEq is weaker: They have the same methods with the same types, and both allow for the "==" and "!=" operators to be used on the respective type. So with Eq and PartialEq it's merely a type-system-level annotation of what behavior to expect.
I love PartialOrd, but I fail to see Rust's groundbreaking superiority regarding PartialEq. I guess it's better than nothing (i.e. what other languages do), but not by much.
Yeah you're right but how tf does that work?
[NaN].includes(NaN) -> true
@@dp.229NaN == NaN is false, like in every language. And variables a and b a.eq(b) is the same. So Rust is IMHO not smarter than other languages, concerning equality.
But if you look at ordering, you have a.partial_cmp(b) and it returns None instead of some arbitrary ordering. That’s cool. a.cmp(b) is just not defined for floating point types.
9:25 this is not specific to JavaScript -- the IEEE 754 standard specifies NaN as a value that never equates itself
Yeah, I don't know any language where NaN would equal to NaN.
but following IEEE standards IS specific to javascript, those guys are madmen. besides, I don't know any other language with NaN anyways
@@ayte1549 Please name a programming language without NaN (that's not for microcontrollers without a floating point unit at all)!
@@ayte1549it's fair to argue that most languages would prefer a hard error over producing a nan.
That said, if they have floating point numbers, they have NaN (e.g. in python, you have `math.nan` that is a NaN value and behaves as such)
@@ayte1549 It's absolutely NOT specific to JS. I dare you to name one even semi-modern language that does not follow IEEE
I thought the last example was going to be about how `this` in arrow functions refers to the global scope but in normal functions it refers to class scope so if you want arrow functions to work with classes you have to bind them in the constructor.
It reminds me of my favorite JS joke.
"Sometimes when writing JS I just wanna say f*ck this, but I don't know what this refers to"
Ehh???? Isn't it vice versa?
There is nothing as class scope in javascript, it does not even have classes and inheritance like you would expect. The class keyword is just syntactic sugar for javascripts good old prototype chain. Arrow functions just do not handle "this" and the default is global (upmost object in the prototype chain).
You can't bind anything to an arrow function
It's the opposite, arrow functions are sane and include `this` in their closures, making it lexically scoped, old functions are insane and resolve `this` when called, making it dynamically scoped unlike the rest of the goddamn language. Making them require binding and all.
lmao, did you know there's a trick to use arrow functions with classes without direct .bind calls?
You can declare a property that have a arrow function and boom, you have a bound arrow function
class Foo {
bar = (arg1, arg2) => {
console.log(this, arg1, arg2);
}
}
Great video but i think it is unfair to say NaN is handled strange in js because every language does same thing following IEEE 754.
On a side note
Hoisting does not put the variables to the top
Js runs in 2 phases
1 - The creation phase where all memory is allocated, thus causing the variables to be initialised
2 - the execution phase that runs the code
By the time it reaches the second phase starting from top to bottom, the variables on the bottom are already created from the previous phase.
Which is why functions as “const” does not hoist but functions with the “function” key word do.
Nan comparison weirdness is standardized in IEEE 754 and is thus present in all proper floating point arithmetic. Not exclusive to js.
Great! A 12 minute video on how broken JS is by design. 😆👍
Can you create a video on how all the prototype magic works in javascript?
I appreciate the Lost reference in the sorting section (4, 8, 15, 16, 23, 42).😉
That's what I always like to say, Javascript is a scripting language, it always has been. It's just v8 made it so fast it's feasible to be backend, but it really isn't meant to be used as a anything that couldn't afford downtimes.
Your videos are insanely well edited, narrated and thought out, love your style!
1:55: "Javascript also provides the strict inequality operator, which will return true if neither the type nor value match." I think you meant to say "will return true if the type and value don't both match". If the types match but the values don't, it returns true.
Neither nor are used in conjunction, it's like an and condition where both conditions has to be false when used with neither nor, it's not the direct opposite of the either or, where only one condition has to be true. English grammar can be weird too.
and in a number of cases a JSON responses from a server will omit JONS keys with values of undefined. Which is why you'll often see null in JSON data over undefined.
Yes. null and undefined behave almost the same. But not quite.
On sort algorithms, there isn't a standard one in JavaScript. The algos are entirely up to the engine/runtime to choose and apply as they want. They just have to behave the same.
`Object.is` has a quirk though, `+0` and `-0` are considered different (both === and == consider them equal).
Mostly caused by the f64 standard defining 2 distinct representations of the value 0.
(Don't worry, it could be worst: the decimal extension to the floating point spec from 2008 introduces d32 with 384 distinct representations of the value 0)
Also, there is an assumption which you make when comparing NaN which happens to be trus in js but might not be elsewhere: "there is only 1 NaN". It's wrong. There are a few millions different NaNs in f32 (and many, many more in f64). JavaScript does some "normalization" by converting them all into 1 variant.
There are some use in having different NaNs: it allow NaN boxing but that's getting off tracks.
JS isn't popular, it's enforced. People write in it because it's the only option for front-end, not because they want to. With wasm-based approaches maturing as we speak, there will soon come a time when that will no longer be the case and we'll look back at JS the same way we look back at IE6.
I love JS for everything it does and doesn't do "right".
In addition to undefined and null, at least NodeJS also has thing it calls an "empty", which happens when you use delete on an array's element. JS removes the element from the array, but does not put any value in its place.
You can then extract this out of an array using built-in functions and place it into an object, without it corresponding to a key.
This is technically not a value since it can't be assigned to anything, but the fact that Node can store in a random object the information that an element existed in an array that itself no longer exists is very interesting and sometimes annoying.
I think this is just how it's displayed/logged right? I think it's just because of the `Array.prototype.length` property, which is how it knows how long the array is. I think it's because JS arrays are just objects, or hashmaps if that's a more understandable term (seems like other languages use that).
@@offroaders123 . . .
I think you should delete those before they get reported for spam, and yes, YT has the buggiest UI ever
No, NodeJS clearly keeps the information about empty elements _and their position_ even when the object is not an array
The distinction between empty and undefined in arrays is in the former case, the index is not an owned property of the array. You can't tell them apart by using key access like `arr[0]` but `0 in arr` will be false if the entry is empty.
Holey arrays are really bad for performance, at least in V8, because once an array has a hole, it will never be promoted to a more efficient representation in memory. If you want to create an array of integers, it's a lot better to create an empty array then push values to it than to allocate an array with `new Array(n)`, which is immediately a holey array
@@seanthesheep That makes sense, but the bit really confusing me is how can the holes of an array end up in other objects
My favorite quote about JavaScript is “JavaScript was designed in a week and a half and it shows”
Really like your terminal. Can you pls make a video about your setup))
*the way you present the js features after telling how other languages do is very hilarious* 😂😂😂
I'm glad someone found my humor funny!
May I ask what plugin are you using for your status line?
Best of JS:
typeof null === "object"
In reality variables declared with var are either function scoped or global scoped, it means that it's not a "local" variable, it can bleed into surroundings scopes making things worse. Like if we declare a var inside a if, it will exist outside of it, and may cause confusion, bugs etc. I would recommend reading the article about variables in the javascript info website.
As a person who designs all of their apps and web-servers entirely in Python, JavaScript is one of those things I always dread writing. Only time I've ever thought maybe C would be easier.
I like your videos so much! How Do you create your videos? Is this all done with Linux?
Excellent explaining Thanks
1:58 correction : strict inequality returns true if either type or value mismatch.
How do you have all those fancy colors and icons in your terminal? like where it says what app your running and stuff
Powerlevel10k
At least that's that's part of it. It's what changes the prompt to be that arrow character and shows the path with a colored background.
thanks. do you know what part styles tmux's footer? that's the one part i can't seem to find.@@Spencer-wc6ew
thanks. do you know what part styles tmux's footer? that's the one part i can't seem to find.@@Spencer-wc6ew
What animator did you use for this video?
So, I started my adventure as a programmer with JS and I got used to it.
It has its quirks, but I don't see it as a problem when moving to other languages, most are really similar and don't change much between them.
Although personally JS makes a little more logical sense to me in some cases, it also has many useful mechanics (spread operator) that make working with objects much easier.
I'm not saying that JS is the only right language, everyone likes something different and everyone specializes in something different.
I think it is also worth mentioning the TS which is trying to at least partially correct some errors (while creating millions of others).
The key to understand most of the "weirdest" of JS comes from understanding that everything in javascript is an object, except for explicit primitives, every single thing is an object even functions are objects.
EDIT
once you understand that, every thing makes sense. Because, it's an object you know.
I ran into a bug in my school project's code a while ago, saying a value is "undefined", when I know for a fact it was not.
Say we have a Foo class and a Bar class, if inside a Foo's instance I try to initiate a Bar instance like `const bar = new Bar(this.value)`, the `this` will be Bar instead of Foo. It took me and my friend a whole night to figure out, and the simple work around is either pass in a ()=>this.value, or save the value in a const first and pass it in.
That last class issue can be completely avoided so it prints only the name its instantiated with no matter what its called with by defining the methods in the constructor as properties on the this keyword, but binding them to this: `this.method = function(){}.bind(this)`
That was an interesting video, i also didnt know the difference between "let" and "var"
Omg, I know what it is strange, but never thought how much. Thank you, now I am sure what I don't want to deal with js.
I'm disappointed you didn't talk about the object prototype model in Javascript (everything is an object, every object has an object prototype). You can do some weird things with that...
This is a great idea for another video however!
Perl tries to make == make a little bit more sense by having a version that coerces to numbers (==) or strings (eq).
@2:48 bwahaha never seen the adding array with a number thing before 🤣🤣🤣🤣
same
Great vid!
2:48 kill me, just end it, I refuse to live in a world where you can add an integer to an array and get a string.
Am I the only one that hates the two distinct keywords (null & undefined) for nil values instead of just a single "null"? From my personal experience, most of the time I don't really care about the subtle difference between null and undefined, as I just want to convey that a value can be nil.
Also because of that, I couldn't just use the `?:` operator in TypeScript to declare a property/argument is nullable. Since TypeScript's `?:` operator is a syntactic sugar for "union with undefined", I couldn't use it with I want a type to have union with null instead of undefined.
Languages like Lua only have one "nil" type, and it can be pretty annoying because there is no difference between a key that doesn't exist in the array and a key that exist in the array that has no value, IMO unless you have some kind of substitution (e.g. python uses its exceptions to raise a KeyError if you try and access uninitialised variables) its worth having undefined, and I would actually like it to be in lua
As a developer with a lot of Rust experience, I'm very annoyed that there's a null value at all. This is just a source of bugs, because you have to check for that everywhere. It's like a landmine.
@@anlumo1 I really love Rust's approach of using the "Option" enum to deal with nullable values
@@tauiinIn that case setting something to undefined should be the same as using delete on it.
@@U20E0oh yeah I agree, I'm not saying javascripts null/undefined stuff is perfect, just that I think its conceptually sound
Some one explain how he is running an instance of terminal side by side with nvim...is this a termux implementation? Or there is a better way to achieve this
I can't tell for sure but it looks like tmux.
Edit: Yeah its tmux, he did an entire video on the awesomeness that is tmux, so I doubt he's changed it up since then.
@@jeffreyhymas6803 thanks. I was also mixing up termux and tmux
I wanna a video about this on js
What a funny walkthrough ❤😂
You make the statement about how "this is javascript" where NaN is not equal to NaN. Thing is... this is part of the IEE-754 standard for floating point numbers and NaN:
en.wikipedia.org/wiki/NaN#Comparison_with_NaN
You are correct. That's my poor explanation.
I was attempting to reference the usage with parseInt and adding in that NaN != NaN is correct, but I did a poor job on this. I will do better next time!
I think if language allow you subtract and add number with text, it's pretty logical that adding will result string, but subtracting will result number. Never used java, and hear it first time, and don't see where is confusion. Tho it's probably because most of my programming experience based on Visual Basic, which is not very strict about such things too.
actually, NaN doesnt equal NaN, because it is a different value. NaN also holds information about what kind of operation caused the undefined behavior (0/0 and parsing error is not the same), as such it is a different error. Add to it the fact that Number in js can be int or float (two different primitive types), and u got urself a soup of potential undefined behaviors.
TLDR: the reason NaN doesnt always equal NaN is because they can be different errors
This is the reason, but not quite.
The content of NaN can be absolutely anything and is ignored in comparison. Two identical NaNs will still not equal eachother.
I believe many implementations of JS use NaN to store integers ( technically meaning they have 53-bit integers ). It's called NaN-boxing.
IEEE-754 64-bit floating point values are safe integers for values between `-(2**53)` and `2**53` ( both exclusive ). But they are not encoded in `NaN`s.
`Number` is always a 64-bit float, and every `NaN` is unequal.
( There is also an internal 32-bit signed integer, but that is not exposed to programs, it is mostly used with bitwise operators. And then there's `TypedArray`s .. )
@@JohanWilt I was partially correct. After some research, Number is in fact always a float, but some JS ( and this is not specific to JS, other interpreted languages to this too ) implementations do NaN-box all other types
String sorting is even more cursed. Why? Because "alphabetical order" can mean something entirely different between two languages. Take the list ["Aachen", "Berlin", "Aarhus", "Öerebro", "Zürich"]. Depending on where you live you can get either
* ["Aachen", "Berlin", "Aarhus", "Öerebro", "Zürich"]
* ["Aachen", "Berlin", "Aarhus", "Zürich", "Öerebro"]
* ["Berlin", "Zürich", "Öerebro", "Aachen", "Aarhus"]
as correct answers, as the "correct" answer depends on whether you're sorting by Latin1_General, Finnish_Swedish or Danish_Norwegian.
And that doesn't even go into non-Latin alphabets like Russian, or languages without an alphabet such as Chinese or Japanese.
This is not a problem that JS caused. It’s a political problem that the language has to deal with, as do all other languages that are running throughout the world. And this isn’t even confined to programming languages, it happens with ordered lists returned from a sql database.
@@nicholascopsey4807 I never said it's a problem that JS caused. However, as you said, it's a problem JS and every programming language has to deal with.
That said, JS is particularly bad at it because of JS' interpretation of array elements as strings.
> It’s a political problem that the language has to deal with
In other news: Water is wet.
@@Ruhrpottpatriot every language will sort it like that because of how the locals want the list sorted. It's not an issue of how JS orders lists, its how people think that words should be ordered. And there is no way to get around that. See lists returned from a sql database in ascending order with those language sets, and they will be in the exact same order. What does JS do that sql doesn't do, or that other languages don't do with this specific example.
now imagine writing server code in javascript
It seems like Chernobyl was written in it
😭
You're incorrect that null and undefined are loosely equal because they're both falsy. If that were true, they would also be loosely equal to false, which they're not. Null and undefined are a special case that are loosely equal to each other and nothing else. Of course they are still falsy, and will evaluate like false for the purposes of logical operations... Just not loose equality
I was thinking not not use js on backend for any reasons at all
now You gave me more clarity why I was thinking that
You can't love something that doesn't have flaws
YEah. I'd like a whole video about this in JS;
But can someone explain to me why JS couldn't call sayName() when he let sayName = person.sayName ???
Great!
Thanks
What a nice language, we should make the Web run on it.
The NaN thing seems reasonable though? How else would you implement it?
I agree. The way NaN works is correct! I did a poor job explaining my point. It's more regarding how NaN is used for the result of certain operations such as parseInt.
Sorry for the confusion!
You missed semicolon....
But great work as always !!! Keep going !!!
Indeed. Javascript syntax: In case of doubt, guess.
You don't need semicolons in JavaScript
@@seanthesheep That was beautifull theory but bite few guys in real life 😅
@@seanthesheep Because JS add the semicolon automatically if you don't add it manually.. though it's sometime buggy
I'm imagining javascrip will add a ==== operator at some point that's the same as === except "NaN ==== NaN" is true.
Wtf, really?!
javascript is like that one toy car that refuses to break.
missing tires? engine literally catch on fire? it'll still move.
hell give it wing and it'll probably start flying.
it's just that 90% it won't go into the right direction.
Javascript was made this way I think simply because they wanted more or less EVERYONE, even those with no programming experience whatsoever to be able to do web development cause the web was the new and hot thing now, and so instead of giving you an error message and refusing to run, JS is just : "Lets shoehorn everything together and somehow make it work anyways so that JS coders will not need to get confused and frustrated over errors!". Hence this big mess.
@@johnpekkala6941 yea i really doubt that's the case, python is even more beginner friendly and it isn't as messy as js.
it's because of it's short development time, the first version of it is developed in only 10 days.
and when some feature is broken, they can't just constantly update JS to fixed it because one wrong update and LOTS of website can break.
On one uses var keyword, it's like goto in other languages
Same is true for ==
Then you clearly haven't worked with legacy code. Things got so bad that they had to introduce let and const
Yea… js was never intended to be used for enterprise applications.
10:21 why not just if(value!==value){/*value is NaN*/}
I always think of Null as "There will never be/was anything here" and Undefined as "There currently isn't anything here, but something could be here eventually."
This is a great way to think of it!
in JS you can't add all numbers with all numbers. You can't add a BigInt to a Number for example.
That's because BigInt is not a number, it's a separate primitive type.
Also, typeof NaN is 'number'. 😊
Js outside browsers was a mistake.
3:27 I see what you did there... 😂
That's incredibly fitting:
A Lost reference for a video about one of the most clusterf*cked programming languages in history.
I reckon Javascript is not the most popular, just the most used as it's central to web development. WebAssembly lets you use other languages, but I don't think it's really taken off for general web dev as there are so many more mature Javascript libraries out there. I myself have never used WA directly, only compiled from Unity, so I'm not sure how feasible it it.
"The == followed ths ryle of other c like languages but it didnt act the same" it WAS the same until early users of javascript asked for what we have now
I mean ok 'this' is stupidly context based.. unless you just use .bind in the constructor or use arrow fns which implicitly does the same thing. Not that bad imo. Neglected to mention it in this vid ofc
I would almost think that javascript isn't the most popular but rather the only one logically available to use for web. I was going to skip learning javascript, but I wanted to be in web development and it seemed web assembly was my only other option.
JavaScript may not be great, but your videos are great 👍
ES 6 was a mistake. Adding in the "class" keyword was a huge mistake. There are no classes in javascript.
it's just a little bit cursed
I love javascript. I think I'm becoming very good with it.
I laughed at this all the way 😂
You forgot: it can't get you a job as a junior.
javascript is truly one of the programming languages of all time
there is a reason i use js to explain my feelings towards x86
“n ways WASM is just… different” !!!
Is JS reeeeally used that much of are people using frameworks of JS cause they dont actually want to use JS but there is no alternative?
TypeScript
Typescript solves nothing, and gives a false sense of security...
As soon as you get an object from the outside world all bets are off
And TS has no built in mechanism to check if a given object fits an interface at runtime
It's okay to criticize TS, it's not perfect. Saying it solves nothing is absurd.
Yeah, I didn't express myself correcly, it doesn't completely solve the things stated in the video
For me TS is useful in that it makes the IDE autocomplete work better, and it makes it easier to organize the code, but at the end of the day I am still writing JS with all the caveats
> As soon as you get an object from the outside world all bets are off
This is true in practically all programming languages. Most statically typed languages just don't allow to pass around invalid data, they will instead fail while parsing and give you a runtime error. In real world applications you must validate anything that comes from the outside world, tools like zod solve this problem completely. There are also tools like typia which can generate runtime validation schemas from type definitions.
This is a good video for beginner JS-haters to learn the talking points about hating JS without having to actually code in JS, so they can be one of the cool kids at the office lunch table once they find a job in Golang or Rust or whatever is cool these days. I guess not Golang. Fact is, it's entirely disingenuous to call JS a programming language in the first place. You shouldn't expect JS to behave like other programming languages. JS stands for, and I swear this is true, Java*Script*. As in, scripting language. As in bash, PHP, Perl. You know. SCRIPTING. The fact that it was turned into a general-purpose programming language meant that it needed a lot of baggage that it just didn't have by virtue of that kind of thing not being necessary. Hell, you showed an example of classes, and classes are *new* to JS! When I learned JS 5 ye -- I mean, 10 y -- is it really 2024 already, damn, 12 years then, 12 years ago. When I learned JS 12 years ago, there were no classes; you had to use prototypes. There was no let and const either; it was var this and var that. OK, not var this; this is a reserved keyword. I guess it was var self = this.
Point is, while JS definitely has its... quirks, they generally match its original purpose as a scripting language for web pages, and it's only after people started bringing it to new contexts that it somehow became weird for it to have, for example 5 == "5". Seriously, why should you have to do all these parsing steps to get from the string to the number? It's a website. There's a form on it. You type a 5. That's a string in the HTML text box element. You need it to be a number. So it is a number, end of story, done. No need to worry about converting between the 5 that the user clearly typed into the box and the number 5. That's kind of the point of JS; you don't want to have to worry about types because they just get in the way of making your 1990's-era webpage. And now it's used as an enterprise language so you need all this *stuff* to be able to use it, including Typescript transpilers to add types to your language with a deliberately minimalist type system. The weird behavior with adding and subtracting strings and whatnot is, really, completely expected if you understand what it's trying to do. It will generally do the thing you want it to do, and if it doesn't, you can easily coerce it with unary + to force a number or adding "" to force a string.
This raises the question: is JS "good enough" to be used as an enterprise language, then? That's kind of a dumb question. Lots of enterprises do use it. I can understand why people who aren't used to it would complain about it, because the features you get by using JS aren't necessarily comparable to the features you lose by not using whatever other language. In my job we use Java, and Java is great for when you don't want your teammates to use your code incorrectly. You can force people to use the right arguments to your method by labeling its types. I want to add an argument to some basic functionality everyone is already using; well, I add the argument and now doing things the old way gives a syntax error. No need to wait for users to email support to find out that it doesn't work! But that doesn't make JS invalid or even bad. Fact is, it requires a different way of thinking. If you're thinking in JS, you can write good JS code, yes, even in an enterprise. Features and tools have been added to the language over time to make this work. But it doesn't make sense to complain that JS doesn't do things like other general-purpose programming languages when it's always been and is meant to be a scripting language for the Web.
It's good to be aware of the quirks if coming from other languages!
So JS is the reason OOP is hated?
JavaScript literally made me hate oop but i guess i have to try it in a different language to really understand it
Watching this makes me really feel like I should move to Rust or something like that.
This is madness
8 more reason I never want to have to learn javascript.
Still my favourite language tho.
The production value is good, but please move on to more advanced topics
Javascript is very fun to play with, unless you know what you're doing.
I never understood how people working with JavaScript call Java shit. All Java is, is verbose or lengthy to write int. Unlike JS it doesn't just brainfucks with different shit and print parseInt(0.0000000005) as 5
Plus modern IDEs make Java simple to write. Most of the annoying boilerplate stuff is generated for you. Would never want to deal with even a moderately sized Java project without at least Eclipse.
@@jeffreyhymas6803 Forget about IDES, modern Java with the introduction of records, lambdas, method references, streams API, etc is quite concise than before in itself.
@@arandomzy I'm usually stuck writing Java 8 which can be a bit verbose.
Great explanation why it's a bad PL.
Since JavaScript was made for being run interpreted in the client, there is no compilation step to barf up warnings to the developer; any errors will appear when it runs in the client. And while you should of course test your code before pushing it; having it fail and write an error that nobody can see in a log on some users computer is not very useful, especially when it's possible to do _something_ useful. Also it might work perfectly and all types are correct in testing but since it runs interpreted in all sorts of weird browser with all sorts of poor internet connectivity; values that always are number in the 5 browsers you test on with a fully functional internet connection; might randomly become string in some other context. So the type coercion makes a lot of sense, if it's at all possible to do so it's in most cases better to do something a bit weird than completely crash for no apparent reason. For instance defaulting to string comparison for sorting is a good default because everything _can_ be meaningfully coerced to a string, and occasionally having a list be sorted "ascii-betical" is way better than having the website crash whenever a table contains a stray value. And for debugging it's much better to have some kind of sorting than no sorting at all. But if you supply your own comparison function you can choose how much error handling you want.
Some of these complaints smells a lot of a backend programmer used to strict strongly and explicitly typed languages complaining about a weakly typed language being weakly typed as if that's a bug when it's actually a feature. I personally hate strongly typed languages that complain about doing arithmetic operations on two types of number; since in 99% of the time of _course_ I wanted the result to be the one type that can contain the result most accurately. I think it probably should be either some compiler option and/or some decoration syntax in the language to indicate if I _do_ want it to complain about such issues and want all type casting to be explicit.
There are of course some genuine unfortunate choices, especially in the 28 year old first specification; but that's why we use linters to avoid these ugly parts that has to be there for backwards compatibility. E.g. overloading + to mean both arithmetic and concatenation was probably mostly a mistake, especially with it's arcane rules for how the operands is coerced; a more sensible default if you wanted to have this overloading would be that if any operand is not a number both sides are treated like strings. But that's why modern lint rules prefer string interpolation over concatenation.
If I gave the impression I was complaining, then I did a poor job on this video.
I have a very dry humor. I'm jovially talking about the quirks of JavaScript that developers should be considerate of.
I apologize if that didn't come across in the video and will do better next time.
Thanks God we use Typescript in 2024, and 5 is not equal “5”…
The worst thing about NaN in JavaScript, in my opinion, is that it's type is a number. `typeof NaN` returns 'number'. Not sure if this is standard behaviour across programming languages, I'd assume not, but it sure isn't intuitive.
NaN is indeed a standard IEEE 754 floating point number. All programming languages that follow the standard classify it as such (float, double, etc.).
JavaScript is fairly consistent in calling double precision floating point numbers "number." Other languages call it different names like double, float, or f64, but they'll still say that NaN is a (double precision floating point) number