[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: non random thoughts of a Lua n00b
- From: "Frank Bechmann" <fbechmann@...>
- Date: Tue, 28 Dec 2004 14:16:45 +0100
During my highly deserved x-mas holidays I took a deeper look into Lua, which I before used only infrequently when playing w/ the great SciTE editor. In these last days I tried to get a feeling what it means to develop a real app in Lua and I now want to share my thoughts w/ ppl forgiving me my funny english.
The main point that attracted me to Lua was the promise to create standalone apps in a scripting language. I love Python, but you can not create standalone apps w/ it (no, even py2exe doesn't help when it comes to creating one executable that can be started and run by itself), which is still a major issue if you want to spread a new language in a Windows environment (and business environments are still mainly Windows environments). Now I know that I can do this w/ Lua - some restrictions taken into account.
I read through your various discussions and found that the ubiquitary dilemma of any (scripting) language is also a major topic here: expand the language and its library (to come w/ batteries included) or to keep it simple and focused. Finding a path between these scylla and charybdis needs a clear vision and a rigid enforcement of appropriate separation, in case of Lua the Lua language core, the C library, and the Lua library (and/or LuaCheia). To achieve this, the most important points for me personally would be (mentioning these here does not mean that I didnt't find them brought up in the Lua community but that - as I said - they are important points for me personally):
- standard GUI support: part of Java's success was the possibility to create OS independent GUIs, slow/ugly or not, but it worked and became better over the years. AWT/Swing/SWT for Java or Tk/wxPython/... for Python prove that there is not the one and only approach, but that nevertheless there should be one minimal standard out of the box; broader options will always emerge and over the years a new standard might come up. After some fight I got IUP running and now I can create GUI apps w/ a scripting language (means w/o C/C++/Delphi) in just one executable which is something I was searching for for years. Make the build process more easy and add some bits here and there and you have a unique selling point for Lua. (btw.: wxLua might be the best bet for the "broader option", SWT integration would also really be cool, but this is a topic for a 1 godzillion character flame war, so I stop here.)
- adding functionality to Lua libs w/o ending up in an 5,000 file installation: I would prefer additional workload for the developer if it would still be possible to deliver a standalone app (a statically linked lua.exe w/ core and appropriate C-libs) w/ maybe one extra file (Lua-lib and app source in one "package"). One of the few things I liked w/ Java was the jar file packaging, a lot of functionality in just one file to be handled by the user. AFAIK a similar discussion comes up for Python from time to time, but some mechanism like that would be much more important for Lua.
- providing guidelines for development of Lua libs: this is what I hate most w/ Python, the standard library is far from being orthonal and even simple things like consistent naming standards are missing. I still hope there is some middle course between the anarchic way of Python and the bureaucracy of Java.
- hiding OS specifics in the Lua core and C library, even if this would mean non-ANSI C and OS specifics in the C backend: I personally wouldn't mind a few ifdef's here and there as long as my scripting language doesn't put all the differences of the various OSes on me - better maintained there once by the smart guys as many times by the language users. And I wouldn't bet that this can stay away from the Lua core if e.g. better filesystem support will be provided.
- other important features: for XML, database-like data handling, and data persistance I found one or more solutions. What I would really like is a build environment that - running a windows box - is not based on cygwin and *make (I used SCons for my IUP test and I think its really an option).
- finding and supporting a killer app: not business wise - as far as I see there is already much success e.g. in game development - but in the OSS comunity to attract supporters and users (means: developers). Maybe SciTE would be an option.
To not dissipate energy I would also put some functionalities on lower prio. For example I would not compete w/ Python, Perl, or PHP on Web-Server side: memory consumption and additional installation effort on server side are not really issues here, and I don't think that the headstart could be caught up.
Nearly the same is true for access to "real" SQL databases, I strongly believe in n-Tier architecture for database apps and I don't see Lua on the database server side, whereas I do see it on app server and GUI client side. A thin layer for database administration as part of Lua configuration tool approach would surely be cool but would also mean to split valuable resouces.
So, just my 5 cts, worst case scenario for answers would be that you - laughing - guide me to solutions for all the topics mentioned above and that's worth the price.
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201