Re: Suitability of Lua as a First Programming Language?

[David Given <dg@...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Kellett wrote:
[...]
> I think Python, although powerful, is not a good language to use, the
> number of times I've wasted time because of the whitespace indentation
> issues just make it a none-starter.

Many years ago I wrote my own mail client in Python. It was a pretty
chunky program, and I used it for a decent amount of time and even got
some users and another developer before I found something better.
(SQmaiL: http://sqmail.cvs.sourceforge.net/viewvc/sqmail/sqmail/src.
Its main claim to fame is that it stores all mail in a MySQL database,
so it can do blazing fast searches of everything.)

What I learnt from this is:

- - the whitespace issue is pretty much a non-starter. Basically, Python
requires you to format the code the way you would format the code
anyway. You *do* end up with issues when you need to move code from one
location to another, but any editor worth using will fix that for you
automatically. But multiline statements in Python have to be escaped
with \; and that's a pain in the arse. Also, the 'pass' keyword (used to
indicate an empty block) is a foul excrescence.

- - Python libraries *rock*. They are utterly awesome. There is a library
for *everything*. The application mainly consisted of glue to plug
libraries together. MIME message decoding? Yep, that's there. MySQL
interface? Uh-huh. POP3/SMTP abstraction? Sure. MBox parsers? Also
there. About the only bit of pure functionality I had to write was the
picon parser, and that's getting *really* exotic. Lua's libraries can't
match Python's, I'm afraid.

- - Python *scales* more nicely than Lua. Every time I write a big app in
Lua I find myself fighting the module system; but with Python, doing it
that way feels completely natural. Partly, of course, it's just that all
variables in Python are table lookups, so you don't feel guilty about
doing foo.bar.baz.boo(7), where a Lua programmer would want to cache
that heavily in locals.

- - . notation for methods. Yeah, yeah, I know... but it *does* feel
cleaner that Lua, where you'd need to say something like foo.bar.baz:boo(7).

- - Local-by-default. Aaargh. Please no. (Of course, Lua's
global-by-default is almost as bad, but in a different direction.)

- - Exceptions. Yes, Lua's got exceptions... but Python has the sugar to
make them useful in everyday programming, and the standards in place so
that everybody *uses* them. A try...catch in Lua is a bit of a mess,
unfortunately.

- - Keyword parameters: dead handy. Yes, Lua can do them with tables, but
Python's approach is cleaner.

- - Pickle. It's incredibly handy to be able to stash an arbitrary Python
structure into a string and pull it out again. Yes, it's easy to do in
Lua... but Python's pickles are already there, and are blazing fast.

- - Closures. Looking at this code, I cannot believe I managed to write it
without closures. These days I would never voluntarily write a GUI
program that did not have closures, they are just so awesome. There's
quite a lot of code I wrote for messily delegating callbacks from the
Glade UI description file to the classes responsible for doing the work
that would just vanish.

- - Threads. Python has threads (but no coroutines). Lua has coroutines
(but no threads). For some things you want one, for some you want the
other... and for this app, I wanted threads. Doing the same thing in
pure Lua would have hard; I'd have probably have gone with a third-party
Lua threading implementation such as Lanes.

I think I can summarise by saying that Python's killer feature is that
it provides the sugar to make common tasks convenient. It's slow, it's
big, it's unorthogonal and some things make me want to scream... but
it's undoubtedly hugely *effective*. Little things, like the % operator
for formatting strings, or try...catch, or the built in class system, or
a dozen other things that make life easier.

Alas for theoretical elegance, really.

If I wanted to write a complex app these days... what would I pick?
Well, I've already done WordGrinder, so I know it's possible... but I
did end up fighting the module system all the way, and I did end up
having to bolt stuff into a custom interpreter because the libraries I
wanted weren't available. So it's hard to say.

I suppose what would be really great is a kind of half-way house. I'm
still fascinated by the idea of producing a HLL that compiles into Lua.
Maybe I should revisit that idea...

- --
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "People who think they know everything really annoy those of us who
│ know we don't." --- Bjarne Stroustrup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKuTOPf9E0noFvlzgRAltdAKCOqMiYQ9WKh1/WHwCDj+puKTKzlwCZAUV/
EkTzdB/PSmueYQDkHvBWKrU=
=9q1G
-----END PGP SIGNATURE-----