I’ve never really found the type conversions that bizarre, unless you’re doing something weird like casting an array to a string or number. I don’t really use strange type casts, since I use TypeScript and avoid using the “==“ operator. What other things make it not good?
I started my career with Visual Basic (3!) and I appreciated the loose typing because it meant I could get going and actually have something running quickly as a newbie. A few years later I switched to C# and saw how an entire class of errors disappeared because of the strong typing. Both have their place, depending on the skill level of the coder and the needs of the application.
Yeah, I’ve seen a lot of those videos where they do things like {} + [], but why would anyone care what JS does in that case? Unless you’re a shit-ass programmer, you’re never going to be running code like that.
The idea behind that kind of type conversion was that JS was originally designed to be extremely lenient. If it ever crashed, the web page would freeze, so it lets you do things other languages just crash from, like divide by zero.
Yeah, I’ve seen a lot of those videos where they do things like {} + [], but why would anyone care what JS does in that case? Unless you’re a shit-ass programmer, you’re never going to be running code like that.
By this same logic, memory safety issues in C/C++ aren’t a problem either, right? Just don’t corrupt memory or dereference null pointers. Only “a shit-ass programmer” would write code that does something like that.
Real code has complexity. Variables are written to and read from all sorts of places and if you have to audit several functions deep to make sure that every variable won’t be set to some special value like that, then that’s a liability of the language that you will always have to work around carefully.
A language’s deficiencies are rarely obvious when everyone is writing it perfectly.
But a coherent type system gives the programmer confidence - for free. Do you know what [1] + [2] is in JavaScript? Do you know what type it is? JavaScript teaches you that it has operator overloading for built-in types but then it behaves in such a dumb way you can’t use it.
That’s explained by a desire to be extremely lenient, but it’s not justified by it. Programming langauges are generally not made by idiots, so every bad decision has an explanation.
I would assume [1] + [2] would give you either 0 or 2, but maybe "12". But why you ever write that? I’ve never bothered to memorize what happens there because I would never write that. The plus operator is not for arrays. It’s for numbers and strings. If you’re trying to concatenate arrays, there’s a function for that. Would you do that in Java or C? People trying to make JavaScript do silly things just because it refuses to crash when you do then calling the language bad for it is just silly to me.
Operator overloading is a perfectly reasonable feature in a language to make use of and to assume works. If it is not going to behave sensibly, it should be an error, not nonsense, because having it work for strings but not other sequence types is surprising, and surprising is bad.
As I said, the fact that you didn’t know the result means that JavaScript’s type system is opaque and hard to understand. You might have understood that there are some things you “shouldn’t do” but being hard to understand is a bad aspect of a language even if it doesn’t prevent you from writing correct, good code.
By way of analogy, thing of a language which, like JavaScript, doesn’t require semicolons, but they are accepted. Except, if you use a semicolon after the last statement in a block, that statement never gets executed. Your reply is like saying, “just don’t use semicolons - they’re not needed” instead of acknowledging that an element of the language which is prone to causing mistakes is bad design.
I mean how can you define a sensible way to subtract Infinity from an array, or add an object to a string? The way JavaScript defines it is predictable, easy to compute, and handles bad code gracefully, which is a good tradeoff between doing something like matrix arithmetic on a CPU and just straight up crashing. If you’re doing silly things like that, you should know how JavaScript coerces types, but I don’t do silly things like that, so I don’t really care how JavaScript would handle it. Every language will do silly things if you force it to. That doesn’t make it a bad language.
Do you feel the same about C because C lets you take pointers of pointers of pointers until you’re addressing random memory in an unpredictable way? No, because it’s silly to do that.
I’ve never really found the type conversions that bizarre, unless you’re doing something weird like casting an array to a string or number. I don’t really use strange type casts, since I use TypeScript and avoid using the “==“ operator. What other things make it not good?
I mean, just the fact that you’re using TS instead of plain JS (and that TS even exists) should tell you that the language has issues…
It’s just strict typing on top of plain JS. I like strict typing. Some people like loose typing.
I started my career with Visual Basic (3!) and I appreciated the loose typing because it meant I could get going and actually have something running quickly as a newbie. A few years later I switched to C# and saw how an entire class of errors disappeared because of the strong typing. Both have their place, depending on the skill level of the coder and the needs of the application.
If you use typescript you will obviously never see the weird type system of JavaScript
Considering TypeScript is a superset of JavaScript, you certainly can. But, that generally means you’re using TypeScript poorly.
Just look up the video entitled “wat” which is mainly about JavaScript
Yeah, I’ve seen a lot of those videos where they do things like
{} + [], but why would anyone care what JS does in that case? Unless you’re a shit-ass programmer, you’re never going to be running code like that.The idea behind that kind of type conversion was that JS was originally designed to be extremely lenient. If it ever crashed, the web page would freeze, so it lets you do things other languages just crash from, like divide by zero.
By this same logic, memory safety issues in C/C++ aren’t a problem either, right? Just don’t corrupt memory or dereference null pointers. Only “a shit-ass programmer” would write code that does something like that.
Real code has complexity. Variables are written to and read from all sorts of places and if you have to audit several functions deep to make sure that every variable won’t be set to some special value like that, then that’s a liability of the language that you will always have to work around carefully.
No.
By that same logic, memory safety issues in C/C++ don’t make them bad programming languages.
If you’re worried about it, like you’re accepting input from the user, sanitize it.
if (typeof userProvidedData !== "string") { throw new Error("Only works on strings."); }Better yet, put that in a function called
assertString.A language’s deficiencies are rarely obvious when everyone is writing it perfectly.
But a coherent type system gives the programmer confidence - for free. Do you know what
[1] + [2]is in JavaScript? Do you know what type it is? JavaScript teaches you that it has operator overloading for built-in types but then it behaves in such a dumb way you can’t use it.That’s explained by a desire to be extremely lenient, but it’s not justified by it. Programming langauges are generally not made by idiots, so every bad decision has an explanation.
I would assume
[1] + [2]would give you either0or2, but maybe"12". But why you ever write that? I’ve never bothered to memorize what happens there because I would never write that. The plus operator is not for arrays. It’s for numbers and strings. If you’re trying to concatenate arrays, there’s a function for that. Would you do that in Java or C? People trying to make JavaScript do silly things just because it refuses to crash when you do then calling the language bad for it is just silly to me.Operator overloading is a perfectly reasonable feature in a language to make use of and to assume works. If it is not going to behave sensibly, it should be an error, not nonsense, because having it work for strings but not other sequence types is surprising, and surprising is bad.
As I said, the fact that you didn’t know the result means that JavaScript’s type system is opaque and hard to understand. You might have understood that there are some things you “shouldn’t do” but being hard to understand is a bad aspect of a language even if it doesn’t prevent you from writing correct, good code.
By way of analogy, thing of a language which, like JavaScript, doesn’t require semicolons, but they are accepted. Except, if you use a semicolon after the last statement in a block, that statement never gets executed. Your reply is like saying, “just don’t use semicolons - they’re not needed” instead of acknowledging that an element of the language which is prone to causing mistakes is bad design.
I mean how can you define a sensible way to subtract Infinity from an array, or add an object to a string? The way JavaScript defines it is predictable, easy to compute, and handles bad code gracefully, which is a good tradeoff between doing something like matrix arithmetic on a CPU and just straight up crashing. If you’re doing silly things like that, you should know how JavaScript coerces types, but I don’t do silly things like that, so I don’t really care how JavaScript would handle it. Every language will do silly things if you force it to. That doesn’t make it a bad language.
Do you feel the same about C because C lets you take pointers of pointers of pointers until you’re addressing random memory in an unpredictable way? No, because it’s silly to do that.