lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


IMHO there is no problem with someone stepping up and doing some
"standard" library. I dont even see the problems with multiple
efforts, as long they dont .debug hack the metalibs of string or nil
or so. One applaudable effort is penlight. Personally I wonder if this
strong focus to Python-like is a good idea, but this is just a far
away general consideration, nothing I could now prove close up. The
Lua core team has not to worry much about it, or?

So what would you expect from a standard library?

On Sat, Jan 1, 2011 at 11:58 PM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Chris Babcock once stated:
>> On Sat, Jan 1, 2011 at 11:03 AM, kevin beckford <chiggsy@lazyweb.ca> wrote:
>> > You do not need standard libraries like Python, you need  a "Lua
>> > Cookbook" like Perl's  "Perl Cookbook", and even then "Programming in
>> > Lua"  is quite helpful with that sort of thing.
>> >
>> > "Do-it-yourself":  Good for learning, but automation and abstraction
>> > are always welcome.
>>
>> I've scripted an SMTP dialog before... There are some things you do
>> not want to learn. :)
>
>  I never fond SMTP to be that difficult myself (this from someone who has
> hacked sendmail.cf, so your milage may vary).
>
>> Something like a standard library is necessary for a cookbook. You
>> can't create a recipe for "How-to use Lua with Protocol X" without
>> either a recognized abstraction layer for Protocol X or so much domain
>> specific knowledge that the cookbook becomes a ten volume set.
>>
>> I honestly don't understand the resistance to a standard library.
>
>  Where do you stop?  At the minimal end, you have Lua (where we are now).
> At the other end you have Perl + all of CPAN (or maybe Java now that I think
> about it).  And what's useful *now* doesn't mean it's useful *later*---just
> look at Common Lisp.  Huge function set, but lacks a lot of functionality
> that's now considered *standard* like threads, sockets and XML/JSON support,
> but didn't even exist (or wasn't in widespread use) when the standard was
> created.
>
>> This
>> is a requirement for Lua to be competitive as a mainstream language,
>
>  Is Lua a mainstream language?  Do the creators consider Lua a mainstream
> language?  Is that even a goal for Lua?
>
>> Those who want a standard library are generally talking about
>> comparatively high level code that isn't going to have much impact on
>> those applications or even compete much with them for developer time.
>
>  The one syslog interface in Lua I found didn't offer the appropriate
> functionality I wanted (for instance, hard coded paramters to the C function
> openlog(); took only numeric constants for the levels instead of a string,
> etc).  The getopt functions I found were also lacking.  That's another issue
> with a "standard" library---they require *very* careful planning or they're
> annoying to use.
>
>> I think the problem is that the Lua maintainers are too successful at
>> maintaining the illusion that the feature set of Lua is responsive to
>> democratic process. There's an irrational fear that the 'ballot box'
>> will be stuffed with feature requests from former Pythonistas who,
>> like a plague of Calfornians, bring with them the causes of the taxes
>> they are fleeing. We need to get past that somehow.
>
>  Anybody that uses Microsoft Word on average uses only 20% of the features.
> The problem is---that 20% is different from person to person, and thus, you
> end up with a bloated application.
>
>  I like Lua *precicely* becuase it doesn't have a bloated standard library,
> and for features that are missing, I've been able to find bindings or create
> my own.
>
>  -spc
>
>
>