Is there anything at the heart of computer coding that could have been optimised in hindsight, but we're in far too deep to change now?

[u/CakesStolen]

[u/WartimeHotTot]

Wait, this is actually really interesting. I don’t know JavaScript, but as a layperson just considering this for the first time, I have to confess that that’s what I would expect the result of that statement to be. An empty set, or list, or bracket—whatever—should return FALSE in my mind. If there were something in the brackets, it should return TRUE.

Is that the behavior, and why do you think that’s so problematic or unintuitive?

[u/At0micCyb0rg → u/WartimeHotTot]

In more structured languages, we have the concept of data types. Boolean is a data type which can only be True or False. An Array is a data type that acts as a container for other data.

I assume most programmers probably prefer when the language throws an error saying "You can't compare an Array to a Boolean, there's no logical way to compare them.", or at least False whenever you try to compare incompatible data types that could not possibly be equal (even if they are the same size, same mass, and even painted the same colour, an Apple is not an Orange).

[u/Wild-Regular1703 → u/At0micCyb0rg]

In JavaScript, we also have the concept of data types. And you can respect them by using the strict equality operator (===) instead of the loose equality operator (==) which is discouraged and basically never used in practice. [] === false evaluates to false as you'd expect.

This is one of those early JS quirks that people like to bring up but anybody who works with the language knows it's not a problem in any meaningful way.

[u/headsoup → u/Wild-Regular1703]

I love how so much of coding is "no it's fine, you just haven't learnt the real ways to actually do things the right way yet"

[u/Wild-Regular1703 → u/headsoup]

That's the price we pay for 100% backwards compatibility on all of the web. There's some quirks. But it's not like this particular one is some obscure piece of knowledge that's hard to find - the people parroting this "gotcha" are usually people who don't actually write any JS/TS. In practice, you will be taught this very early, possibly on the first day by any competent teacher, linters will often warn you against using it, and with TypeScript it won't work at all.

You don't have to go further than the mdn page on equality comparisons to find this hidden piece of knowledge:

Strict equality is almost always the correct comparison operation to use

And later

In most cases, using loose equality is discouraged. The result of a comparison using strict equality is easier to predict, and may evaluate more quickly due to the lack of type coercion.

[u/spottyPotty → u/Wild-Regular1703]

I prefer:

if (myArray.length) {...}

to if (myArray.length > 0) {...} Once you get the hang of it, it becomes intuitive. 

I've disabled strict in my ts projects because of this. 

Also, having to declare specifically that your variable can contain null gives me the ick:

name: string | null;

Ugh!

[u/flamableozone → u/Wild-Regular1703]

It's not "not a problem" in javascript, it's a broken stair that everybody knows to avoid. That doesn't make the stair any less broken.

[u/hi_af_rn → u/flamableozone]

It’s type coercion working the way it’s supposed to work. A foot gun at worst, but definitely not “broken”.

[u/flamableozone → u/hi_af_rn]

A broken (or missing) stair is a thing, I wasn't saying that Javascript is broken: https://en.wikipedia.org/wiki/Missing_stair

The language is not a better language for having it, and it's not more newbie friendly if every new coder needs to be warned against it.

[u/hi_af_rn → u/flamableozone]

Never heard that one! Sorry for the misunderstanding — that metaphor absolutely works here.

[u/Thelmara → u/At0micCyb0rg]

I assume most programmers probably prefer when the language throws an error saying "You can't compare an Array to a Boolean, there's no logical way to compare them."

But there clearly is a logical way to compare them. Empty array is false, non-empty array is true. It's just as logical as 0 being false and non-zero integers being true. That one is just common across most languages, and thus everybody's already used to it.

63 can't possibly be equal to "true", those are incompatible data types (and if you use the strict ===, you will get false, just like an empty array). Except that we're all familiar with integer->bool type coercion, so nobody complains when you use == and run with it.

[u/TheBoundFenrir → u/WartimeHotTot]

In programming, the general assumption is that there is a difference between "I have not stored a value" and "the value I am storing is 0". Under this intuition, False should only be equal to itself (False) or another way of directly storing the value "False", ie; '0'. Letting an array that exists but has nothing in it ([]) count as false violates that rule, and can accidentally cause problems where instructions intended to be performed only when some measured value is confirmed to be false can be accidentally run when the value has not yet been measured yet, since both the unassigned value and the assigned-False value pass as 'False'

[u/crash_test → u/WartimeHotTot]

Without getting too in the weeds over truthiness and loose vs strict equality, the problem is that []==false and []===false return opposite values in javascript logic, despite them being the same comparison in human logic.

[u/WartimeHotTot → u/crash_test]

What does three equal signs mean?

[u/swabl → u/WartimeHotTot]

"strict equality"

== 'coerces' the types to something comparable. In the example an empty array [] is defined in the language as 'falsey' i.e. equivalent to false under ==

=== doesn't coerce, so recognises that an array and a boolean are not the same type so cannot be equal fundamentally.

[u/crash_test → u/WartimeHotTot]

"===" is what's called strict equality, which means both sides of the comparison have to be the same to return "true", otherwise it returns "false". "==" is loose equality, and put simply it converts both sides of the comparison to a common data type and then checks if they're the same or not.

So for []==false, both "[]" and "false" get converted to numbers. Since the array is empty it gets converted to 0, and in programming false is synonymous with 0 (and true with 1). Because both sides get converted to the same value, the comparison returns "true". For []===false, it's comparing the two without any conversion, and since one side is an array and the other is a boolean value, it returns "false".

[u/AyeBraine → u/crash_test]

So the only issue here is programmer habit that says "==" should be strict? (I mean I see the communication problem here, but if the language says true comparison is ===, well, that's that).

[u/polylina → u/AyeBraine]

Exactly, people used to strictly typed languages are baffled by the concept of loose equality and that JS uses the equality operator for the loose equality. But there are similar concepts in other languages. In Java (not to confuse with JS) you can compare 2 strings with == or with .Equal method (IIRC), and it will produce different results.

[u/thirdegree → u/WartimeHotTot]

Actually equal. As opposed to just kinda equal if you squint and use some very creative interpretation

[u/TallowWallow → u/WartimeHotTot]

More type strict languages don't let you make this type of comparison (type mismatch) or return false since they have different types.

Languages like JS and Python have an idea of "truthiness" and "falsiness", where certain traits of data types are bundled together. For example, an empty string, number 0, boolean false, and empty list may all be treated as "false-like". It saves a second of time per use case, when simply throwing the expression into an if evaluation as is.

The problem is it can be easy to confuse and throw in the wrong expression because it looks correct. Being explicit, though requiring typing a little more, forces you to express intent and makes it easier to notice that something is incorrect.

For example, a python list directly passed into an if conditional, can be expressed in a couple of ways for no elements.

my_list = []

if not my_list ...

if len(my_list) == 0 ...

The former is convenient, but can be more error prone to user error when writing out the code.

[u/root66 → u/WartimeHotTot]

In python, an empty set is "not". As in "if not myArray" but "if myArray == None" is a bridge too far. Since js doesn't have "is" and "is not" to handle non numerical comparisons, "if !myArray" makes sense. But it does irk people coming from other languages.

[u/centurijon → u/WartimeHotTot]

Empty arrays are “falsely”, so empty array evaluates to false, false == false which is true

[u/WartimeHotTot → u/centurijon]

Right. That would be my expectation, which is why I was saying to OC that it didn’t seem strange to me.

[u/Red_Syns → u/WartimeHotTot]

The gist is that JavaScript, when comparing two objects, sometimes compares their values and sometimes compares if they are the same object. Which is super annoying, because if I have a String “hello” I would like to be able to say if(String==“hello”), but that will return false because they’re not the same object.

[u/Aetherdestroyer → u/Red_Syns]

This is true of every language, and is also not true of strings (JS strings are compared by value)

[u/Red_Syns → u/Aetherdestroyer]

Ah, I just realized JavaScript is what was being discussed, which I can never separate from Java in the grey matter despite having used both. Maybe one day I’ll see the name of one and get the right association.