 |
lua-l archive |
|
|
||
|
On Thu, Feb 16, 2012 at 1:19 AM, Tim Hill <drtimhill@gmail.com> wrote:
> So first off let me say I'm on the side of "lean is better", which means
> keeping a really minimal runtime. But if the runtime *IS* to be extended,
> what should the criteria be for selecting the extensions? Let me throw out a
> straw-man list, others can critique it (or ignore it!) as they wish...
> 2. Non-Triviality. Routines that can be written in 5-10 lines of Lua code
> don't seem good candidates to me. The example earlier of a "set()" function
> to create a set from a table (migrate array values to keys) seems to me to
> fall into that category.
This criterion does not explain the contents of the existing Lua library (the one in linit.c) Eyeballing it, I see the following functions which could be expressed in Lua in 5-10 lines of code (with a * on the ones with caveats)
====
assert*, dofile, ipairs, loadfile*, loadstring, pairs, pcall, print
coroutine.wrap
module, require, most of package.* (except loadlib; see compat.lua for implementation).
string.gmatch, string.gsub*, string.len, string.match, string.rep*, string.reverse*, string.lower*, string.upper* [performance issues with concatenating interned strings, mostly; you'll write a stringbuilder once for them, or better, add the C version. corner cases in gsub probably take it over 10 lines]
table.concat*[same performance problems], table.insert, table.remove, table.sort[...well...not a sort you'd probably want to use in 10 lines.]
math.min, math.max--the rest seem like they have IEEE conformance traps.
io.close, io.flush, io.input, io.lines, io.output, io.read, io.write.
====
So clearly there are a bunch of trivial functions already in there. So why those?
The rhetorical clash is appeals to tradition and authority vs my appeal to adverse consequences at the end of the slippery slope.
> [If you go down this road you end up with
> developers really just stringing together dozens of calls to runtime
> functions, with the result that the code no longer looks like Lua
...discounting all the alien regexp code in anything which touches strings....
> and the
> underlying operation is all but lost in the mess.]
I would say that the problem has been solved with a higher layer of abstraction. Lua's metamechanisms seem *designed* to get about halfway to Lisp reader macros, so being uncomfortable with chaining together chunked operations...I dunno, I don't actually have an argument. (I've been mildly ill this week, which has really cut into my energy to go back and respond to dangling threads let alone implement the assert_utf8 stuff.)
So anyway, I've got a concrete example of obscuring the underlying operation, In soar without thinking about it: I called set(split(arg)). This creates an intermediate list instead of going directly from the split items into a table.
Is there really enough call for a setsplit() function? I doubt it. Will some cookbook coder cut&paste set(split()) into a context where n is large enough to make a difference? It's possible, but lazy/cookbook coders write O(n^2) string operations all the time anyway. I think there is a continuum between "mindlessly chaining together stuff from allfunctions.*" and "build everything from sticks and twine so you know how it works".
> 3. Performance. Some things are hard to code efficiently in Lua, and
> routines that handle heavy lifting in C do make some sense.
Yeah. I've been wondering if there are some core C types missing. I already wrote the stringbuilder in C a zillion years ago. With a size hint, I bet some of those string.* operations aren't so bad. It's a bit hypothetical.
> 4. Abstraction. Some operations are inherently platform-dependent in their
> implementation, even if they can be exposed through a standard interface.
I'm not sure how much of this is left after you switch to / as the directory separator on Windows (uh and just ignore the VC crt.) There's some dirty-as-hell code needed to quote argument lists for os.execute and popen....although I just realized on modern unix-y systems you could use "xargs -0" as a sort-of shell and have absolutely no quoting issues.
> [As an aside, imho adding lots of library routines can lead to AWFUL code.
Python does not have a reputation for a lot of awful code (that I know of), yet it has the biggest shipped standard library among the scripting languages.
> First off, inexperienced developers can get lost amongst a huge sea of
> library routines, fail to find the "ideal" routine and end up writing the
> code themselves anyway
I'm an experienced Lua programmer and I end up writing the same damn code over and over anyway! (There are both rational and irrational reasons why I don't just use a noplib for everything.)
> Second, inexperienced developers often treat library routines as "magic",
> particularly when it comes to performance, and end up writing slow code and
> then blaming the runtime library for not being instantaneous.
Therefore we should erect high barriers for inexperienced developers, so they have to write each function pattern once themselves? Like building your own lightsaber[1], or armor out of meteorite steel[2]?
I'm not sure what really can or should be done. Maybe just an arrogantly dismissive quip. I'll go with "Life's hard, but it's harder if you're stupid."[3] (As you can tell I've run out of seriousness.)
Much of why Java and .NET have a reputation for being vaster than empires and more slow[4] is that they've been money languages for a while, and have attracted the usual "enterprise" parasites too. Oh sure, it sounds like a staffing nightmare to build your project in Go, Scala, or that wacky language from Japan. But you're only going to get people who understand what's going on well enough to pick up a new language relatively quickly, and that filter is useful. I'm surprised Ruby has survived this long with the level of hype it has without sliding into the "no longer a filter" murk.
Lua survived *World of Warcraft* and Warhammer:AoR and now Rift. I think we'll do OK. At least until somebody builds a good UML round-trip engineering contraption. But if we don't let in a standard object system, nobody can do that, for better or worse.
Jay
[1]: I don't do non-canon SW. I wonder if Lucas will live long enough to do Episodes 1-3. Wait, Wikipedia suggests the term "lightsaber" came from Aleister Crowley!? Ooh, shiny.
[2]: There was a line about the _The Golden Compass_ movie. Something like "It has to be awesome--it has ARMORED BEARS." Well.
[3]: Not John Wayne, apparently. http://message.snopes.com/showthread.php?t=26553
[4]: I've been dying to use that line from "To His Coy Mistress" ever since I was shouted down suggesting it as a matter-of-fact description for LambdaMOO's condition while it was still at PARC.