Re: Lua and other languages compared (pros and cons) [Was: LuaJIT without the JIT?]

[HyperHacker <hyperhacker@...>]

On Thu, Jun 23, 2011 at 21:55, Lorenzo Donati
<lorenzodonatibz@interfree.it> wrote:
>
> Well, we are really drifting away OT, so I think it is better to spawn a
> subthread :-)
>
>
> On 23/06/2011 23.38, Dimiter "malkia" Stanev wrote:
>>
>> Lua is very much suited for exploratory programming, live coding,
>> scripting, customizing, tweaking, even creating makefile system (premake
>> for example) at very fast pace without recompile, relink cycles. My plan
>> someday is to be able to use it from Autodesk products to write certain
>> plugins, without the need to recompile, and ability to tweak and fix the
>> things on the fly. Also any technical artist would prefer Lua much more
>> than C++.
>>
>
> I don't know if Lua is suited for very large applications. Those where
> traditional imperative languages are said to need strong compile-time checks
> to be robust (if someone has an experience to share, he/she is welcome!).
>
> I find Lua exceptional for (high-level) code generation and templating:
> together with lightwight OOP modeling and a DSL it can be hugely expressive.
> All in less than 1kLOC usually.
> For example, in this way I generated (using a modified version of the
> template engine of Rici Lake available on the WIKI) html pages and LaTeX
> sources, whose content is taken from a Lua data file written in a custom
> DSL. Sort of XSLT + XML approach, but waaaaay more readable and lightweight!
> :-)
>
> One of its merit in this respect is that, although it is not Unicode aware,
> its strings are 8-bit clean. Moreover, as Roberto replied to one of my
> questions, the lua interpreter (not the core - note) relies on the C runtime
> for reading a script. So, although it cannot be *guaranteed* (because C
> standard doesn't guarantee it either) that the interpreter can load UTF-8
> encoded scripts, I found that it works smoothly. This is very good for
> templates used to generate html or LaTeX (or whatever text file format which
> should support Unicode), since you can embed unicode chars directly in the
> template (or in Lua string literals).
>
>> Now take that, and in only 300kb executable code you have LuaJIT that
>> can bring the performance very close to "C" for a lot of things.
>>
>> I've seen only few other languages, systems close to that. One is Common
>> Lisp (and specific implementations), but no Common Lisp system comes
>> small, and all of them are statically compiled in dynamic environment -
>> unlike LuaJIT with trace compilation. For that reason the get fast code
>> in CL you have to specify where needed the types, and these serve as
>> promises to the compiler, which he would obey and make your code fast
>> (SBCL, LispWorks, Allegro, ClozureCL and others are doing pretty good
>> job at it).
>>
>> On 6/23/2011 2:07 PM, Francesco Abbate wrote:
>>>
>>> Lorenzo, Henning, all,
>>>
>>> thank you very much for the interesting discussion about Java and
>>> Erlang, you are certainly more knowledgeable than me about these
>>> programming languages and I think that I'm going to learn more about
>>> Erlang.
>>>
>>> Ultimately it seems that the idea that I had of Java is basically
>>> correct even if I was not aware of a lot of details. I have no
>>> experience of Java programming, my only knowledge came from my work
>>> where we have a lot of Java applications. Sometimes they throw stupid
>>> exceptions and became unusable and they are so terribly slow and
>>> memory hungry so I just hate them.
>>>
>>> For the other side my feeling is also that Lua really *lacks* the
>>> possibility of Java to detect errors before execution using a typing
>>> system or something similar. The fact that you have no types at all
>>> and no warnings of any kind even for a small typing error is terrible
>>> when you develop something even moderately complex. In addition you
>>> don't even have a debugger so it is even more painful. And yes I know
>>> that some home-made 'strict' packages and debugger exists but they are
>>> often incomplete and of little aid.
>>>
>>> When I work in C or C++ I'm glad that many trivial and not-so-trivial
>>> errors can be detected during compilation and, what a relief, I can
>>> throw the debugger and inspect all the variables step-by-step when I
>>> really don't understand.
>>>
>>> This is even more OT but it is strictly related to the Java
>>> discussion. Where Java is very strong Lua is terribly lacking :-) and
>>> please, no flames, I don't want to be polemic, I express just some
>>> reflections about a programming language, Lua, that I ultimately like
>>> and use (beside C, C++ and python).
>>>
>>> Francesco
>>>
>>>
>>
>>
>>
>>
> -- Lorenzo
>
>

I've written a bit of Java and I have to say, I do like it. It has a
bad rap for being bloated, and I do somewhat agree with that - it does
consume a fair bit of RAM (I suspect because there are so many
temporary objects being created and deleted all the time, that the GC
has a hard time keeping up), and especially some programs written in
Java seem to be severe memory hogs (NetBeans was using over 1.5GB of
RAM last time I used it), though that's probably more their own fault.
The pure-object-oriented approach actually works out pretty nicely. It
is very verbose, but IDEs help with that. I love that I can seamlessly
use my own objects just about anywhere by simply extending others
(e.g. if my Foo extends a JButton, then anything that expects a
JButton will accept a Foo just fine). Interfaces are also a great way
to implement duck typing, which I'm a fan of - you don't care what the
object is, as long as it has the methods described here. (I've often
wished Lua were a little better in this regard, having less emphasis
on what an object's type is and more on what methods it supports. It
is pretty good about this, but there's always room for improvement.)

Lua remains my favourite language though, due to its flexibility,
extensibility, and how impressively fast and capable it is for an
interpreted language whose only dependency is an executable of a few
hundred KB. (And that's before you even get LuaJIT involved!) I find
it just makes things so easy to do, largely because I can pretty much
do things however I like, and still load in other peoples' modules and
use them. It has a few quirks that bother me occasionally (break but
no continue, lack of binary operators, awkwardness with varargs and
nils, etc) but they're minor and easily worked around. It really is a
fantastic language and I'm always being impressed when I find myself
thinking "there's no easy way to do x" only to discover a line in the
manual I'd glossed over explaining "sure, just use this pattern"...

I've used a few other languages - VB6, C/C++, Javascript[1], PHP,
assembly, shell scripting (Windows and Bash), Python, and others I
can't recall offhand - but none I've found made OoP as nice as Java or
made complex tasks as easy (even enjoyable!) as Lua does. :) It really
does live up to its mantra, "doing more with less", where such simple
design features (e.g. f{} and f'' for function calls) create so many
possibilities. And as more and more modules are developed, it becomes
even more capable - with LuaGnome you can write GUI apps; with
LuaSocket you can write client/server stuff, and so on, entirely in
Lua.

I guess the point of this message is Lua is awesome and big thanks to
everyone who made it possible. :D

[1] Interesting trivia bit: how I first learned about Lua was when I
decided to write a scriptable PSP menu/shell program, and realized I'd
be much better off using an existing scripting language than trying to
roll my own. My first choice was Javascript, but in the process of
looking for a standalone Javascript interpreter library, I learned the
homebrew PSP SDK had Lua support already built in... (That project
never did get finished though!)

-- 
Sent from my toaster.