[samatman]

The 'soft, spongy' type system is nice to see. That kind of strong dynamism is a good choice for the application: it will do the wrong thing sometimes, but will throw fewer show-stopping errors, which are really disheartening for casuals.

I do regard casting not-numbers to 0 as a flaw. I've had plenty of bugs where I wished `nil` would automatically cast to to `""` in string position, or the empty list/dict: but I have never, once, wanted a missing number to cast to 0.

The number zero doesn't have the "semantics of emptiness" in programming. It shouldn't be treated as false, either, unless we're dealing with a "raw" language, in which case, one should have to at least cast to boolean to get the truthiness of anything.

Personally, I would promote this to an error, because the other option, 'NaN', is itself a source of confusion. But at least NaN-poisoning the calculation will eventually inform the user that "htree" isn't a number.

[nerdponx]

This is really task/domain-dependent. It's convenient in shell scripts and AWK, but in bigger programs it really isn't good.

One of the things I love about Python is that its type system is actually quite strong, in that implicit conversion is very rare in the standard library and somewhat frowned upon in general. Having "falsy" and "truthy" values that are not actually `bool` instances is maybe the only big exception.

[samatman]

Lua hits my personal sweet spot for robustness vs. precision, Python is good enough to be worth criticizing, but hey, pleasant enough.

Lisps are a good example of using emptiness well, I wouldn't want an empty Lua table to be false, but you can't do classic Lisp programming without a falsy empty list, I wouldn't have it any other way. Large Lisp programs have their problems but it isn't the empty list causing those.

I wouldn't want to use Lil for the things I use Lua for. I think it's a great match for what Decker is doing here.

[hmry]

Definitely. I would argue even in shell scripts it's not always great. Just thinking about all those times rm -rf "~/${configdir}" accidentally wiped someone's home directory because that unset variable was implicitly turned into an empty string, etc.

I would not want to use a language with a spongy type system for any code I'm distributing to other people But for quick one-off scripts that only I will use, it is quite convenient.

[1vuio0pswjnm7]

   test ! "${configdir}"||rm -rf "~/${configdir}"

   [ "${configdir}" ]&&rm -rf "~/${configdir}"

   test x"${configdir}" = x""||rm -rf "~/${configdir}"

   [ x"${configdir}" != x"" ]&&rm -rf "~/${configdir}"

This assumes NetBSD ash or Debian ash which is what I use. I write scripts for me, not for others and often end up using "quick one-off" scripts for years. After decades of using UNIX, I have never wiped a root directory accidentally (but there is still time). YMMV.

[nerdponx]

Sure, and in Zsh you can do `(( $+configdir ))` if you want to differentiate "unset" from "empty". But the fact that you need this check at all demonstrates the existence of a problem.

You can also set the "-u" option (in Zsh, `setopt no_unset`) which at least will cause your script to crash with an error if you happen to forget this check. But then you have to remember to set that option as well!

Lua has a similar-ish problem with undefined variables being `nil`, but for the most part Lua is also rather strictly typed, and that will typically end up causing some kind of error deep inside a function call, rather than doing something dangerous silently.

[samatman]

While what you say about Lua is true, undefined variables can be promoted to errors. An `__index` function can throw an error if a slot looked up on a table is nil, and the environment is just a table.

That's Lua for you. The semantic model is dead simple and easy to understand, and even though roughly no one wants typos to become variables, the semantics would have to be less minimal to accomplish this.

So instead, there's a mechanism, a more than adequate one, but one does have to use it.

[1vuio0pswjnm7]

Also

  test "${#configdir}" -lt 1||rm -rf "~/${configdir}"

  [ "${#configdir}" -gt 0 ]&&rm -rf "~/${configdir}"