[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Ruby philosophy vs Lua philosophy
- From: Andrew Starks <andrew.starks@...>
- Date: Thu, 28 Feb 2013 03:43:59 -0600
On Feb 28, 2013, at 0:39, Ross Bencina <firstname.lastname@example.org> wrote:
> 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?
Yes, this is all reasonable. My intent was not to suggest that the Lua
team should be involved. It was only that a team, with some form of
structure, would be what was needed.
I like the idea that this may be accomplished from projects such as
Luvit. I had not thought of that, although those kinds of projects
haven't played with external package management... easily... yet.