 |
lua-l archive |
|
|
||
|
Again, what I would say is that if you are worried about those sorts of bugs in your particular program, then you should invest in some abstractions and mechanisms to mitigate them. Maybe that's as simple as a metatable on a raw table. But maybe it requires a class, a module, a layered API. If the latter, then a simple language level checking feature might help you a bit, but it really won't solve the problem of missing fundamental abstractions in your program. You'll avoid some of the simple bugs, but miss the opportunity to protect against the more complicated bugs (e.g. by controlling access to multiple objects that must work together). Trust me, I am not a hobbyist, I do this for a living. :-) Sent from my new BlackBerry Z10
On Mar 20, 2013, at 10:43 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2013/3/20 Marc Lepage <mlepage@antimeta.com>: >> My general opinion is that, if you are suffering from these kinds of errors, >> you are "developing too fast." >> >> Which is to say, if you took time to ensure there were no typos, added >> asserts, metatable index guards where appropriate, etc. then the problems >> would basically just go away. Yes it would take some effort. And the amount >> of effort and appropriateness of these measures depends on the program and >> the programmer. E.g. whether you tend to make a lot of typos, or how much >> syntax highlighting support your editor gives you. >> >> So in general, my advice is to ensure you are taking time and measures to >> deal with these issues, if you are having them. Just that's more of a >> development workflow issue than a language environment issue. > > Cogently argued. The best precaution against typos is to avoid hasty, > shoddy programming habits. This seems to me like an acknowledgement that the current behavior slows people down. Many programming errors can be blamed on sloppiness, but at the same time, one function of computers is catch mistakes we make as flawed humans, and one can certainly make programming errors no matter how slowly and carefully they work. Ignoring this particular bug can snowslide into to further issues, such as accidental sparse arrays and incorrect length operator results, that can go undetected for an unpredictable length of time. Therefore, I can't help but view the behavior of the language as being unsafe rather than the programmer as being hasty. Additionally, the fact that external tools have been developed to catch this error, as well as homegrown solutions for protecting globals as well as individual tables, implies that this type of error is something of a universal occurrence that only increases in probability as larger and larger codebases are being developed in Lua. As long as humans are allowed to type programs, typos will occur. To give a more philosophical reply, one can view programming languages as user interfaces for programmers, and in that sense, something that is statistically error-prone is arguably a large target for improving accessibility. To take an example with current awareness, arguments that people should just get used to Windows 8 and learn to work around its interface would seem unconvincing to many users because it demands that they bend to accommodate aspects of the software that are uncomfortable for them. >> On Tue, Mar 19, 2013 at 4:23 PM, William Sumner <prestonsumner@me.com> >> wrote: >>> >>> Lua's behavior of silently returning nil for undefined variables can lead >>> to bugs that propagate undetected. Has thought been given to changing this >>> in a major version update, or are there reasons for retaining this behavior? >>> I'm aware of strict.lua, but it only provides safety for global/module >>> scope. > > That description of Lua's behaviour is based on a false analogy with > languages like C that have actual variables that can be defined or > undefined. > > There is no such thing as an undefined global variable in Lua. A Lua > variable is the association of a value with a name. That is to say, what > changes during an assignment statement is the association, not the value > or the name. By default, the value nil is associated with every name. > Literally every name, not only the ones for which the association has > explictly been stored. I find the concept presented by Lua that every possible key starts off with the value of nil to be a very elegant one. As I said before, I'm not sure that it's worth the tradeoff. Of course, there is some disagreement over how unsafe the current behavior really is. Due to its potential effects and the unpredictability in detecting the bug, I consider it something that should be reported to the user as an error, though I'm aware of the implications for the design of the language; that leads me to your next point. > Once you understand it, it becomes obvious that changing this would > result in a different language. It would no longer be Lua. I believe there is no static concept of what Lua should be, because this language has changed very much since its first release. It has adapted with each major update to address new problems, and it has a reputation for breaking backwards compatibility. This doesn't justify addressing every criticism made about it for the sake of continual change, but it does mean that dismissing criticism as being at odds with what Lua "is" in the philosophical sense is unconvincing, at least to me. After all, Lua is a piece of technology and is whatever its builders construct it to be. Even version 5.2 had its detractors, some of the criticism coming from well-known figures. It's admittedly presumptuous to drop in and suggest modifying a fundamental behavior with so many potential ramifications, but it's with the aforementioned reputation for change in mind that I brought up the topic, expecting pushback but also very much enjoying the technical discussion. I want the very best scripting language possible for my users, which is why Lua holds my interest in the first place. Preston | ||