131–140 of 152 posts
Earlier quoted context omitted.
I'm aware that SQL has "bit" values that can be 1/0/null, but that's not exactly three valued logic. Does it really have conditional checks that can have three possible outcomes, or something similar?
Yes, a boolean value can be checked for the three possible values, TRUE, FALSE or NULL.
Earlier quoted context omitted.
Can you provide an example of when this would be useful? For example: if (foo.bar.length >= baz.buz) { ... } otherwise { // what am I supposed to do here? } How do I disambiguate if the "broken" type coercion was actually what I wanted? How do I tell what circumstances conspired to make this statement not-clearly-true?
You'll have to provide some more details. Why would you want this broken type coercion? What are you actually trying to do here? But in the absence of this information, my first guess would be: if (foo.bar.length >= baz.buz) { ... } otherwise { alert("Something unexpected happened. Either foo.bar.length or baz.buz is not a number.") }
Isn't what you're describing here basically equivalent to saying JS should throw on invalid comparisons, with
try {if (x) then A else B} catch C
if (x) then A else B otherwise C
?Not to defend JavaScript too much, but I think the three examples seem reasonable when viewed in the right way, and I think it's hard for JavaScript to do much better with its existing design philosophy (dynamic typing and coercion rather than runtime errors to deal with type mismatches). >= and > are numerical operations, so both sides are interpreted as a number, and null is 0 when treated as a number. That means `…
>I think the three examples seem reasonable when viewed in the right way These kinds of statements is why I think webdev is completely and thoroughly fucked. When obviously bad software or language design is widely accepted on the basis of convoluted technicalities you know that thing will not get better, only worse. >This type of issue isn't unique to JavaScript. In Java, if you have boxed Integers Boxed types in Ja…
Many smart people have been working on improving JavaScript for a while now, and many of the problems have been fixed either by language improvements or widely-available tools. The runtime behavior of basic operators can't be changed, though, so we'll likely be stuck with the type coercion rules for a long time, although it's worth noting that both TypeScript and Flow disallow `null >= 0`.
Earlier quoted context omitted.
> I've always wondered of what benefit weak typing actually brings It makes your code crash less, and I would argue that in many cases that's desirable. I think it's a bit sad that the default behavior for computers is often to completely give up on the sight of any error. If you're running code in development or need to worry about data integrity, it makes sense to fail quickly and loudly, but if the analytics syste…
> It makes your code crash less Wait, can you back this up? What makes you think strongly typed languages crash more than weakly typed languages? What's a scenario where a strongly typed language will crash at runtime, but a weakly typed language won't? I can see an argument that an interpreter of a weakly typed language will let you run a program with dangerous type conversions without complaining, while a strongly…
In JavaScript, `1 + {}` gives the string `1[object Object]`. In Python, `1 + {}` crashes. Neither language has a static type system, so neither language is able to disallow an expression like `a + b`; it needs to actually execute the code to find out that you're adding two things that don't make sense. I think most examples of "Python is stronger-typed than JavaScript" are of that form; Python crashes while JavaScript silently does something that may or may not make sense. Accessing a missing property, accessing an array out of bounds, and calling a function with the wrong number of arguments are also examples where Python crashes and JS doesn't.
So "crashing less" is pretty much inherent in my (simplified) definition of weak typing, and not meant to be anything controversial.
Earlier quoted context omitted.
> brilliant off-beat thinking Those words must have new meaning since he was citing as an example a language that's existed since the 70s. Ternary booleans are far from a unique or novel concept. The main difference is that for most languages, including Javascript, that third value exists at the variable binding or expression level, not the value level. Other languages that don't allow nulls encode that third value i…
> Adding a third value would mean that a boolean variable binding could now have 5 values, true, false, not_true_or_false, null or undefined. That's nonsensical and deserves to be called out. FWIW, I actually agree with this. There's no need to add a new value. It would be fine with me (within the context of Javascript's already horribly broken design) to use an existing value (null or undefined) as the third "boolea…
FWIW, I totally buy the former. If (null>0) returned null, then most things would still work as expected, and you could easily check the result of the comparison to catch unintended behavior. One can easily imagine a world where JS was defined this way from the start, and it'd be pretty much the same language.
The latter (three-way IF control structures) strikes me as waaaay more tenuous - much bigger change, more complexity on the programmer, and no benefits I can see that you wouldn't get from the former bit.
Earlier quoted context omitted.
> But the code using twisted features is hard to maintain afterward. let a = 0; for (const record of records) a += record.bool; What's so bad about this? (aside from mutable accumulator, but that can be restricted to one scope). The pattern is basically directly lifted from C, where there's thankfully no such thing as a boolean type. If anything, the solution is to fold Boolean and null into Number to begin with. > Y…
To be fair, let a = 0; for (const record of records) { if (record.bool){ a += 1; } } or ls.filter(x => x).length; aren't that much harder to read. The second one probably doesn't do deforestation and would end up stupidly slow, though.
Earlier quoted context omitted.
> It makes your code crash less Wait, can you back this up? What makes you think strongly typed languages crash more than weakly typed languages? What's a scenario where a strongly typed language will crash at runtime, but a weakly typed language won't? I can see an argument that an interpreter of a weakly typed language will let you run a program with dangerous type conversions without complaining, while a strongly…
To be clear, I'm talking about strong/weak typing and static/dynamic typing as distinct concepts. My comment mostly applies to dynamic-typed languages. In JavaScript, `1 + {}` gives the string `1[object Object]`. In Python, `1 + {}` crashes. Neither language has a static type system, so neither language is able to disallow an expression like `a + b`; it needs to actually execute the code to find out that you're addin…
Earlier quoted context omitted.
> If he is an authority on the subject, it should show through in his comments. The comment speculating on the "OTHERWISE" clause is the kind of brilliant off-beat thinking that challenges the level of understanding of the reader. The people scoffing at and downvoting it are, however smart and knowledgeable they may be, ignorant or foolish. If they thought it through they might learn something. It's a perfectly valid…
> brilliant off-beat thinking Those words must have new meaning since he was citing as an example a language that's existed since the 70s. Ternary booleans are far from a unique or novel concept. The main difference is that for most languages, including Javascript, that third value exists at the variable binding or expression level, not the value level. Other languages that don't allow nulls encode that third value i…
I still disagree about the argument from authority, but I think that's subjective.
Warm regards.
Earlier quoted context omitted.
You'll have to provide some more details. Why would you want this broken type coercion? What are you actually trying to do here? But in the absence of this information, my first guess would be: if (foo.bar.length >= baz.buz) { ... } otherwise { alert("Something unexpected happened. Either foo.bar.length or baz.buz is not a number.") }
This sounds like throwing an error with extra steps. Isn't what you're describing here basically equivalent to saying JS should throw on invalid comparisons, with try {if (x) then A else B} catch C rewritten as if (x) then A else B otherwise C ?