I particularly like the rationale given for the load/execute split over traditional eval; it makes distinguishing compilation errors from runtime errors much easier, and also helps make sandboxing easy, which they hint at talking about environments but don’t call out explicitly.
Although iterators present a new syntax
Interesting that they say that. I wonder how they define “syntax”, because I can’t think of a definition that makes that a true statement.
On a related note, I was looking at Lua implementations on the JVM the other day, and they all seem to completely miss the point of this paper. I looked at three different codebases, and none of them wrote Lua table classes in such a way as to implement the standard JVM collections interfaces which would allow seamless interop. It was very surprising to see them all make the same mistake. (luaj, kahlua, and rembulan)
Even though I am not a heavy Lua user at all I always enjoyed the fact that certain decisions about the syntax at least seem to be the opposites or completely different from what C or a compiled, statically typed language would use, making it more of an extension to C than most other scripting languages.
At least I think that’s what is throwing people off about Lua, when they come from C or a C style language (which in some regard most commonly used scripting languages outside of functional scripting languages are). I think this adds a lot of flexibility when adding it to any kind of project already using another language, making the benefits of adding a language to the stack bigger.
One for example notices that it’s not another system scripting language that is trying to get used instead of shell scripts for example, even though one could and such a project would probably be interesting, I think the lack of this while still being easy to integrate with C and therefor certainly being used by sysadmins in contexts like databases (Redis), web servers (nginx/openresty) speaks for a language and community that knows where the language’s strengths and goals/priorities lie. Personally I really enjoy projects that don’t aim for turning into a “jack of all traits” or yet another emacs so to speak.
That’s from someone who is mostly an outsider. I really wonder whether people using Lua a lot more have a similar view of this being a strong factor in the language design.
If you’re interested in this sort of thing, Tcl and its C API are pretty well done, and very readable code.
Fascinating article.
I particularly like the rationale given for the load/execute split over traditional
eval; it makes distinguishing compilation errors from runtime errors much easier, and also helps make sandboxing easy, which they hint at talking about environments but don’t call out explicitly.Interesting that they say that. I wonder how they define “syntax”, because I can’t think of a definition that makes that a true statement.
On a related note, I was looking at Lua implementations on the JVM the other day, and they all seem to completely miss the point of this paper. I looked at three different codebases, and none of them wrote Lua table classes in such a way as to implement the standard JVM collections interfaces which would allow seamless interop. It was very surprising to see them all make the same mistake. (luaj, kahlua, and rembulan)
Even though I am not a heavy Lua user at all I always enjoyed the fact that certain decisions about the syntax at least seem to be the opposites or completely different from what C or a compiled, statically typed language would use, making it more of an extension to C than most other scripting languages.
At least I think that’s what is throwing people off about Lua, when they come from C or a C style language (which in some regard most commonly used scripting languages outside of functional scripting languages are). I think this adds a lot of flexibility when adding it to any kind of project already using another language, making the benefits of adding a language to the stack bigger.
One for example notices that it’s not another system scripting language that is trying to get used instead of shell scripts for example, even though one could and such a project would probably be interesting, I think the lack of this while still being easy to integrate with C and therefor certainly being used by sysadmins in contexts like databases (Redis), web servers (nginx/openresty) speaks for a language and community that knows where the language’s strengths and goals/priorities lie. Personally I really enjoy projects that don’t aim for turning into a “jack of all traits” or yet another emacs so to speak.
That’s from someone who is mostly an outsider. I really wonder whether people using Lua a lot more have a similar view of this being a strong factor in the language design.