lua-users home
lua-l archive

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

On Oct 18, 2011, at 9:16 PM, Patrick Mc(avery wrote:

> [snip]
>> Please don't take any of this as black and white, because I really
>> have never looked at the PHP code myself (except via stories like[1]).
>> However, from what I can tell there is basically no clean separation
>> between parser and interpreter/VM in PHP like there is in Lua. Don't
>> forget that PHP stands for Hypertext *Preprocessor*... it's amazing
>> (though I guess actually not) in this light that we ever got to the
>> point where people are writing daemons in PHP.
>> Regards,
>> Matthew
>> [1]:
> Thanks Matthew
> Maybe this is just the price one pays for a small fast scripting language. If Lua has to be fat and slow to offer what I have been asking for then there isn't much point to it.
> I think the Lua team must have a difficult job weighing the different threats and opportunities in the language business. They need a user friendly API to compete with the fat languages but don't have the libraries to make Lua a fat language itself.
> -Patrick

Why does Lua needs to compete with the fat language?  There are plenty to choose from: PHP, Perl, Ruby, Python, etc.  

I view Lua a very nice little language that can be easily embedded in other software systems.  Or something small enough that you can put it on tiny hardware (e.g., eLua).  There are plenty of large "fat" languages that are feature rich, have bazillions of packages and much "power", whatever someone might think that is.  But there are very few small, compact language implementations in the space that Lua is in.  The closest is probably Tcl which is pretty old at this point, and I think Lua is a wonderful, "modern" replacement for the space that Tcl was popular in.  Perhaps ficl is another, somewhat less well known example.