 |
lua-l archive |
|
|
||
|
Hi Andrew, On 28/02/2013 8:58 AM, Andrew Starks wrote:
The point is this: accessibility in the realm of "general scripting language to use on its own and not embed into a big project" lags behind the rest of the eco-system. This is neither bad nor good, in my mind. Other tools work, does Lua need to cover their ground, as well as its own? Probably not. But let's face it. On the day that Lua 5.2 was announced, there was no standard TCP/IP library that worked on major computing, without hacking the source or finding some random guy's github repository (is this still the case???). That sucks. Hard. For those that feel a connection with this community, or language, or whatever one associates with their need to evangelize for the language, we should be ashamed. Lua as a language is a garden well-tended. The front yard has a rusted, bullet hole-ridden Camaro on blocks, a busted toilet and a washer-machine.
This really depends on whether you think that's the front yard, or the vacant block next door that the gypsies are camping in.
As you note above, Lua's primary domain is not "general scripting language to use on its own." Like all general purpose languages, it's a building block.
Lua's leadership are focused on the language core, and for this, I for one, am extremely grateful.
In the early days of Python, Python held out great hope as an embeddable scripting language (it was, after all, invented as a better TCL). Then the "lets use it as a general language with a massive runtime library" folks took over and the possibility of using Python as a light-weight embeded language because a de-bundling nightmare. Thankfully Lua looks unlikely to meet the same terrible fate.
My two cents is that what you're looking for, is (and should) be covered by satellite project (like luvit to pick one example). This is analogous to a Linux distro. Distros aggregate and package libraries, the core kernel team just do kernels.
No one bitches that the Linux kernel doesn't contain a web browser or that kernel.org doesn't oversee package management. No one bitches that ANSI C doesn't have a built-in JSON parser. No one complained that C++11 didn't have a working implementation on release-day.
Sure it's not the way Rubyists think about their language, but that's the point isn't it?
Ross.