Gonna guess you're a lisper ;)

Definitely it's biggest warts are around core data types - mainly the implicit-casting rules - but those are also impossible to change at this point. "Don't break the web" and all that.

More like wannabe lisper. Maybe someday I'll land that Clojure job.

And yeah, making [] false-y would probably do bad compatibility-breaking things. That's from the department of wishes more than good practical going-forward choices.

A couple of questions:

  “Make [] false-y”

Why?

  “Add macros”

Why? How?

  “Bring back `with`”

Why?

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.

A standard library, a proper date/time/timezone implementation, and robust number support (all sizes of integers and for the love of god Decimal). Every time I get excited about Deno and Typescript and all of that, I get so frustrated that 0.1 + 0.2 != 0.3 and that I need to find and vet a community Decimal library.

(I know BigInt is a thing and Temporal is coming.)

I agree a standard library for JS would be great, but .1 + .2 != .3 is the case in several languages and is not anything to do with JS.

This also is or can be the case in C, C++, Clojure, Python, and many other languages [1].

[1] https://0.30000000000000004.com

Yes... It's an artifact of floating points. My issue is that JS only has floating points and not Ints and Decimal.

There is a stage 1 proposal for BigDecimal.

https://github.com/tc39/proposal-decimal

JS has had integers since pretty much day 1 with bitwise operators. They just (from a user perspective) convert back afterward. If you were choosing just one though, floats would definitely be a better choice than integers.

It's also possible to make length 1 typed arrays of integers and operate on them if you really need. Then, as you mention there's BigInt numbers which are supported on the last few versions of every major browser except IE11.