[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Philosophy ;-)
- From: "Philippe Lhoste" <PhiLho@...>
- Date: Thu, 8 Feb 2001 19:08:44 +0100
First, thanks to Luiz for saying to me to subscribe to the TecGraf mailing
list, not the YahooGroups one. Receiving daily summaries is OK in lurk mode,
but to very suitable in interactive mode.
I have two points on licence issue I would like to talk. It is mostly
curiosity from me, in a quite theoritical level, as I don't intend to do
what I am asking (lack of time, and probably of skill).
1. Does your licence allows to use part of your code? I briefly though about
using your expression parser in another project, but I doubt it can be done
easily, as it must be deeply dependent of the whole project (ie. difficult
2. I like the philosophy of Lua: you have the source and you can make
proprietary changes, but if you change the syntax or behavior of the
language, don't call it Lua.
This is flexible and wise, as it avoid to have a lot of Lua dialects,
incompatibles. You can make a Lua dialect, but it is no longer Lua.
But does it work the other way around? I mean, if I write another Lua
interpreter (again, I don't have the skill to do it, and even less the
time!), which mimic exactly the Lua syntax and behavior, can I call it a Lua
After all, we may want to make a non-portable Lua interpreter, making
optimized system calls instead of using the C standard library, which can be
slower. Or even an assembly language interpreter! Or just rewrite it in C or
C++ for the fun of it...
Or write it in Java to allow running Lua program on browsers (hello Yindo
Or write it in Perl (!) to allow using Lua CGI scripts on servers like
ProHosting which allows only Perl scripts.
You get the idea.
There are many C compilers, from different sources. Interpreted languages
(Perl, Tcl, Python) have more monolithic sources. Just wondering why.
Probably because most of them (except Rebol) are open source, so they can be
improved without the need to make entirely new code.
A word about the (moderated) criticisms I saw here. I think the authors are
injustely accused of not being reactive about change suggestions. I believe
they don't work on Lua on full time, probably working on other projects. So
they may have not so much time. And time spent on heated discussions on this
mailing list is time not spent on Lua code...
And actually, they are quite helpfull on practical issues, so thank you very
much for your time and for this wonderful language.
Lua is managed in a satisfying manner. Authors do ear their users, and
doesn't hesitate to break compatibility (at least on the API level) to
improve the language, not hindered by legacy problems. Old programs can
still run on old interpreter, anyway. Still, they don't jump at all the
suggestions, otherwise the language would grow uncontrolled and would become
bloated. (My English isn't very good, I have some trouble expressing my
A thin path, indeed.
BTW, Roberto, I am reading your book draft, and it is excellent. It is
exactly the tutorial I was looking for! Even my thick brain (I had to read
twice the chapter on upvalues and closures...) finishes to understand the
exposed concepts. I am waiting eagerly for the final version.
Your English is excellent, I have just found a typo, a '$Ta' instead of a
'a'. You probably already have corrected it.
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist