Re: Idea. Removing nils from the language.

[Javier Guerra Giraldez <javier@...>]

On Sat, Jan 10, 2015 at 3:36 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2015-01-10 19:09 GMT+02:00 Enrique Arizón Benito
> <enrique.arizonbenito@gmail.com>:
>
>> Your example is really good to probe the "madness" of nil.
>
> Lua has lived with that madness for over 20 years.
> Though it be madness, yet there is method in it.


while i'm typicall a conservative in the common "change Lua" threads,
this one has a slightly different take, more like "imagine a language
with this uncommon trait... Lua seems a good platform to experiment".
In that light, the "we've always done things like this" argument isn't
so valid... maybe not even "i like it like it is".

unfortunately, the premise "imagine a nil-less Lua" is flawed on several points:

- the "NULL is a bug" rant is a very specific rant on a very specific
set of languages.  maybe not even full languages, more like the common
practices on those languages

- a big part of the "NULL problem" is that it's a value that can be
assigned to every pointer type, breaking type safety, or at least
making it harder to have strong types on static type systems.   but on
dynamic type systems, where the type is in the value and not in the
variable, there's no problem with nil (or None, or null), it's a
different type with a single value.  that's why some of the strongest
type systems are seen in dynamic type languages (or those with very
sophisticated type inference and automatic types).   in short: even if
NULL is a problem, it doesn't imply that nil is too.

- neither type statics nor type strength is a value on itself.

- the "removing nil would allow Lua to have static types!" argument
seems a non-sequitur, and a drawback if you happen to like dynamic
types.

- the original post ended in something like "i've done the easy part,
and i don't have time to do the rest", which is ok if somebody else
sees any value in the proposal... if not, then that should be the end
of it until the author finds time to either advance the code or to
draft a more consistent language design.


-- 
Javier