[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua for large apps (was: Lua for GUI toolkit wrapping?)
- From: Alexander Gladysh <agladysh@...>
- Date: Wed, 30 Sep 2009 11:56:51 +0400
On Wed, Sep 30, 2009 at 10:25, Ivan Kolev <firstname.lastname@example.org> wrote:
> I'm not going to argue about the benefits of C++ vs Lua for large
> I have enough experience with C++ to realize how much its ideology is
> oriented to catching errors at compile time (though at the price of long
> compile times), and I've learned to use it. I've learned to design code so
> that it is hard to use incorrectly and easy to use correctly - C++ gives you
> tools for that.
> Maybe I'm not experienced enough with Lua to do the same.
Several years before, when I came to Lua, my professional programming
experience was almost all C++, without much of dynamic languages
experience. I agree, that, indeed, in C++, with careful design,
compile-time validation can give very good correctness guarantees.
At first it was quite hard to write code in Lua — without compile time
validation, without static types, it felt as if I try to stand on a
blob of wobbly jelly instead of a good solid rock.
The price of such validation is quite high. Not to mention longer
compile times. You need to spend much time on the design itself.
Sometimes much more time than you'd spend solving the problem that you
write code for. You need highly skilled and disciplined architector
paying constant attention to the each part of the project all the
time. You need highly-qualified programmers.
If you have a hammer, try to avoid looking on everything as a nail.
I quite understand if that amount of effort is spent on the low-level
"foundation" code in the system (application, library etc.). It is
usually written once, must be of high quality and work fast. But to
waste it on the business logic, that mutate every day to the whim of
the high command?
You want to be able write cheap business logic code. Okay, it should
be reliable enough and fast enough. But it is usually comes in huge
quantities, and you should be able to change it quick. You should not
need extra skilled programmers to write it — or your budget will bust.
Lua is perfect here — it is reliable, fast and easy to grasp.
Compile-time guarantees are not possible to achieve with pure Lua. As
we know, Lua compiler is dumb (and this is a good thing — since it is
also fast and simple).
I do hope that, in time, we would get Metalua-based static code
validation tool, powerful enough to do something like that. But now
there is no such tool now.
However, there is a simple solution — that you, of course, know. Write
tests. Any static analysis tool may only catch generic errors, that it
has heuristics for. Even C++ compile-time validation will catch only
so much of wrong logic — and the more it may catch, the greater the
price of the code.
As I said in this thread earlier, we have 160+ KLOC of Lua code. 80
KLOC of it are tests for our Lua and C++ code (we have 90+ KLOC of
C++). Most of our tests are declarative and consist of
table-structured input / expected output data, they are significantly
sparser than the usual code, so the price per LOC is lower.
Tests catch more (you may tune them exactly to the behaviour you
expect), they cost less (you may employ less sophisticated
programmers), they help refactoring at least as much as the static
If we compare Lua with "test-time" validation and C++ with its
compile-time checks, to me Lua is the winner (for the business logic