What about not making [] any kind of boolean? Let's be explicit and use [].empty() or something, implicit conversions are confusing.

> implicit conversions are confusing.

Are they? All of them? 0:1 <≠> F:T? Boolean and binary are and should be distinct, and never the twain shall meet? A bold thesis in the world of computing.

Context-sensitive meaning is something people navigate all the time. You probably do it in some software contexts w/o even realizing it (and we all do it with human language and relationships w/o thinking consciously about it).

It's most likely to be confusing if you're unfamiliar with the context, or if the context-specific rules turn out to be convoluted.

0:1 maps on to F:T or even nothing:something or empty:non-empty pretty effortlessly. Even rigorously, with the right level of attention.

Implicit can mean subtle. Whether that means confusing (or whether there's some other cognitive load imposed by some forms of subtlety) is a separate question. And probably subjective.

Explicit can be a virtue. Concision can also be a virtue, and sometimes context-sensitivity promotes that.

Not GP, but I really like [] being false in ruby and python because I often want to ask "is this variable that should hold a collection holding a collection of things, or is it empty/false?"

Why an array with zero element should be false? It doesn't make a lot of sense. And writing if (array.length > 0) is more explicit than writing if (array) anyway. Even in python, I prefer to be explicit and say if len(array) > 0 than to rely on implicit conversion rules.

It would be better if Javascript had Array.empty() instead of comparing array length. It would make things even more explicit and more convenient.

Personally, I don't like if even accepting things that are not boolean. But an empty array being false makes exactly as much sense as an empty string being false, and both should have always the same behavior.

If you want objects to behave like dictionaries, an empty object should also behave the same, by the way.

I'd argue that `if empty_list` is already explicit in Python.

[] is truthy in Ruby but there is #empty? on collection types. Rails also has #blank? which additionally works on false and nil.

[] is truthy in Ruby. Only false and nil are falsy.

Yeah, sadly zero is not falsy in Ruby.

I always found it strange that in Python, stuff doesn't get implicitly cast to string (even Java does that!), but for whatever reason the idiomatic way to check if a collection is empty is to do "if collection:", implicitly casting to bool.

Nothing gets casted to a bool in Python if statements.

Luckily, most languages have a `.empty()` method! You should use that instead for readability purposes.

And in that vein, JS has some().

You are thinking about `[].present?` I think

[] should be falsey so it can be used in an if().

I'm not sure about macros.

I kind of want to see `with` back also. The problem with it was ambiguity. The syntax could be adjusted to avoid the ambiguity. .e.g `.prop = val;` could be legal inside the block. But "why though" you ask. A `with` block makes it visually obvious that a block of code is specifically relating to getters/setters on a particular object instance.

I'd argue truthiness implicated by the presence of an object is more logical than having an arbitrary definition of truthiness depending on the data type.

If I have a cup that's empty, there's still a cup there. It's presumptuous to assume I care about the contents.

There's a presumption either way. You can make the presumption JS did for [] (and there's probably no turning back), you can even argue explicit is better than implicit (vs the value of context-sensitive concision).

But it's also not consistent with the ways that other empty but typed cups are treated ("" for the empty string, 0 for empty count / quantity, both of which are false-y). Different presumptions for different types of cups carries its own implicit hazards from context sensitivity.

In that case "" should be truthy. And 0 should be truthy too probably.

They should be, to have consistency in design. Note that if the language operated this way, checks on these types would be more explicit (though more verbose too).

Checking for presence of a number with a truthy check is a common source of errors, if 0 is a valid number.

I just don't agree at all that Python's interpretation of truthiness (or equality, for that matter) is inherently the "right" one. If I clone somebody are they equal because they have the same genetic makeup? No. Though a pretty contrived example that requires common understanding of equality.

At least from a programming perspective, I usually care more about instance equality rather than structural equality. Of course Python supports that too via the `is` keyword

Yes and yes. Ruby got it right, no question :)

Macros with a standard library would have saved us from many compatibility and bloat issues when they would have arrived before things like the class keyword.

Macros doesn't have that utility in a language with high-order functions.