Re: Project lead nominations for standard libraries?

[Chris Babcock <cbabcock@...>]

On Fri, Dec 31, 2010 at 11:05 AM, Mark Hamburg <mark@grubmah.com> wrote:
> I think this rapidly gets to be much larger than I would expect in a
> standard library for Lua. Certainly in any sort of initial distribution.
> While it would be good to have a larger set of community accepted batteries,
> I really think it would be better to focus first on whether there are
> recurring "issues" that could be mitigated with some targeted code.

Lua would be a great, not merely good, language for web deployment and
rapid prototyping if there was a systematic effort to identify and
maintain code to fill the majority of the needs identified in other
programming languages as standard libraries. These aren't the standard
application areas for Lua, nor should they be, so perhaps "standard
library" is the wrong term for this community. Something like
"application library" might better communicate the fact that we don't
operate under the assumption that these tools will be available in all
places where Lua is installed.

You can't push a string. That's another way of saying volunteer
projects are led by example no matter how much planning you do. It's
pretty useless to set agendas for anyone other than yourself in most
situations. I'm not sure what "issues" are meant here (#t?), but are
they really in contention for the time of the type of programmer who
is interested in application support?

I suspect that there is the mistaken impression that supporting these
heavier applications will create a group of stakeholders who gradually
increase pressure on the core to make the language itself heavier. I
think, however, that we need to give the core team and the technology
itself more credit for having the ability to promote a modular design
and prevent scope creep in the core language.

My personal opinion is that Lua has the potential to be the kind
language that Python has often promised to be - agile, rapid
prototyping, easy integration with C - and will do so all the better
if it doesn't lose its soul on the way. Towards that end, I think it
is counter-productive to split into "camps" over this issue. A great
many Lua users will not see the point of an initiative to standardize
a set of application libraries. There's no reason for them to feel
marginalized by such an initiative, however. The functionality
required by the embedding and scripting applications supported by the
Lua community is still important to the qualities of the language that
make it desirable for other applications... and we recognize that
more, not less, as a consequence of seeing other languages bloat over
the years.

Chris
--
51st century guy