Re: A very basic thing I don't get

[Lorenzo Donati <lorenzodonatibz@...>]

On 05/10/2011 16.36, Mark Hamburg wrote:

> Which leads to the argument that the "problem" is that Lua
> tables are too powerful. So often they are powerful enough
> that they just solve the problem. Much of the rest of the
> time, they seem powerful enough until you realize that they
> aren't quite. And then you come and complain to the list
> about tables being broken and about how Lua has to change.

I couldn't have expressed the idea in a better way!

> Maybe the change is that tables should be less powerful and
> people should be forced to roll their own data structures.
>
> Not that I buy that argument.

Neither do I. I think Lua tables are good this way.

FWIW I'd like some more enhancements on the "virtualization" side, that 
is some nice idea to make it a bit easier to do OOP, but I realize that 
it is hard to add good orthogonal features in that area without imposing 
some OOP paradigm on the user or cluttering Lua.

> Still, it does point to perhaps a getting started FAQ that
> would disabuse people of notions that will get them in
> trouble -- "You can do a lot with tables, but understand
> their limits and build data structures as you approach those
> limits."; "Metamethods are fallbacks not overrides and though
> they may seem like methods in an OOP language, they don't
> always behave that way."; etc.

Well said! Probably the hardest part of learning Lua for me was to 
"attune" to Lua's spirit. I must confess that at first sight it seems 
*really weird* (especially for people having strong imperative, 
statically typed, languages background). It takes some time and some 
effort to understand that it is not so weird and there's a strong 
rationale beneath all that stuff.

Not that some aspects are not debatable, but as Roberto sometimes 
pointed out, some design decisions were well-thought tradeoffs.

Probably many recurring topics on this lists could be avoided if there 
were a sort of "Rationale FAQ", explaining *why* (*not* how) something 
is the way it is, maybe with a nice introductory essay on the general 
philosophy of Lua (I mean, more extended than the introductions in the 
refman or PiL - more focused on a Lua newbie's perspective). The cherry 
on top would be also comments about the current status of the feature, 
i.e. if it is a state-of-the-art feature (unlikely to be changed), or it 
is the result of a tradeoff (and what were the factors influencing the 
decision), or if it is something that Lua team regretted to have done 
("module" function comes to my mind). A section on what new features Lua 
team would like to add in the future could improve the quality of the 
discussions (adding perspective).

I understand that it is a somewhat a daunting task, but if it were ever 
done curious and/or enthusiast people would have an easier path for 
learning what is worth arguing about. In other words, if more people 
concentrated on aspects that also Lua team would like to improve, there 
could be better chances that a good idea would pop up from the 
discussion, instead of wasting time arguing about the sanity of holes in 
tables.

Caveat: no flamebait inteded here. I too fell victim of the "why not do 
this and this" disease, and sometimes I could have avoided to jump into 
the discussion if I had had a clearer view of the rationale behind the 
features.

Often the rationale has indeed been discussed somewhere, but this kind 
of information is usually scattered in the WIKI or, more often, in some 
remote thread in the list archive. You may say one has to do his 
homework better, but it's much harder IMO to search for "whys" instead 
of searching for "how-tos".

> Then the real trick is to
> write this all without it turning into something like
> JavaScript: The Good Parts which contains a lot of warnings
> about the "bad" parts where JavaScript is just bizarre.
>
> Mark

Cheers.
-- Lorenzo