lua-users home
lua-l archive

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

On 2002/11/14 12:35:04, "Andy Stark" <astark@blackpoolsixth.ac.uk>
wrote: 

> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <html><head></head><body bgcolor="#FFFFFF">
> <div
> style="margin-left:10px;margin-right:10px;text-indent:0px;padding-left:
> 0px;padding-right:0px;margin-top:0px;"><font face="Geneva" size="+0"
> color="#000000" style="font-size:10pt;color:#000000;">Just another
> humble opinion from someone who hasn't even used Lua for<br>anything
> serious yet:-<br><br>All the ideas expressed so far about getting some
> commercial input into<br>Lua seem to have one major flaw: they are all
> about making Lua resemble<br>the languages that are already
> established (&quot;Lua could compete with<br>Rebol&quot;, &quot;Lua
> should have a large standard library like Python
> does&quot;,<br>&quot;needs a graphical GUI, IDE&quot;, etc).<br><br>I
> think Lua's very strength lies in the fact that it DOESN'T have
> these<br>features. The philosophy behind Lua is that it should be very
> easy to<br>embed and I think this requires it to be minimal but
> effective<br>nevertheless.<br><br>We have observed that, say, Python
> CAN be stripped down to a minimal<br>implementation which can be
> embedded. But embeddability is not exactly<br>Python's forte and is a
> relatively minor design issue in the language.<br>For example, I doubt
> that Python could boast that it is &quot;written in<br>ANSI&#160;C,
> and compiles unmodified in all known platforms&quot;. You can't
> just<br>pick Python up and drop it into your app.<br><br>Lua, on the
> other hand IS specifically designed to be embeddable. I<br>think this
> is what the authors intended it to be all along and this<br>strength
> is what should be developed in the future. There is no point
> in<br>adding features that are common in other languages (at least
> we<br>shouldn't treat this as high priority) because we will simply
> end up<br>re-inventing Python or Perl or Rebol. As programmers, we are
> all<br>concer ned about avoiding unnecessary code duplication, and
> this is code<br>duplication of the worst kind: open source projects
> competing for the<br>same niche!<br><br>It will take considerable
> creative effort to preserve Lua's fresh and<br>distinctive spirit
> because (I think) it is the first language whose<br>syntax and
> implementation are specifically designed for
> &quot;extreme&quot;<br>embeddability above all else. But if we put
> respectability above<br>embeddability, then we will end up with
> another Python. Don't get me<br>wrong, Python is great, but we don't
> need two of them!<br><br>&amp;.<br> </font></div></body></html>

Wow, hard to read!
This has been discuted already, between those using Lua as an extension 
language, and those using it as a scripting language.

I mainly use it as a scripting language, because it fits most of my needs 
and I like the syntax. And since my needs are small, I have (currently) no 
time to learn Python or improve my Perl.

But I also plan to use it as extension language (to SciTE, to other future 
applications...) so I am concerned by both aspects of the language.

Even in a world of gigahertz and gigabytes, I still care for small and 
fast applications, so I don't want Lua to become bloated.
You can perhaps strip down Python to a small core, but at least for 
Windows, unless using a independent, perhaps outdated distribution, you 
have to download a 8~9MB file and install it before stripping out... If 
all you want is to run a small script found elsewhere, it is overkill.

Yes, Lua must still be available as Ansi C source code and small binaries.
We should never have to strip down Lua to get small binary, but instead be 
able to download various extensions, perhaps as a whole package if needed.
If someday we devise a standard way to extend Lua as scripting language, 
using external modules, it would be a great improvement.

Such use is much more popular, and as such, it can introduce Lua to a 
wider range of people, which may be pleased to be able to embed it later, 
using an already familiar language.

Last note: Lua is a living language, and authors are open to suggestions 
to improvement, while still keeping in mind their initial goals. That's a 
very good thing, even if compatibility with previous versions is sometime 
broken. That's good, we don't want to carry obsolete functionality just 
for the sake of backward compatibility. As the main purpose of Lua is to 
be embedded/integrated, authors can choose to keep an old version or 
[re]design for the newest, greatest version.

The drawback is that if there are many modules/add-ons, they must all be 
updated to the latest version. That's already the case with some current 
libraries, and this probably won't dissapear with external modules. And I 
don't want this "problem" to slow down innovation. So we have to live with 
this.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/