Re: Perl, Python, Ruby, PHP, C, C++, Lua, tcl, javascript and Java comparison

[Steve Litt <slitt@...>]

On Tue, 16 Jul 2013 23:49:15 -0600
Tim Mensch <tim-lua-l@bitgems.com> wrote:

> The complaint was that people, for better or worse, use the benchmark 
> game (which ranks very high in Google searches for many language 
> benchmarks) to choose between languages, and by removing it didn't
> show the full potential of Lua any more. If you've seen the LuaJIT 
> performance data on luajit.org, then you know that LuaJIT exists and 
> that it's really fast. But to someone unfamiliar with Lua, it doesn't 
> stand out as over-the-top awesome any more.
> 
> Tim

So true Tim. And besides that, if you're not doing a random number
generator or a hugely graphics heavy program, is runtime speed really
that important?

I just got done writing a LyX XHTML to ePub converter in Python (sorry
guys, Python's the official interpreter of the LyX community), and it
takes 1/5 second to process my 60K word book. If I'd taken 10 times
longer and written it in C, that runtime could have been cut by a
factor of five or ten. But does it really matter whether the computer
processes my request in the time of one keystroke or five?

Perhaps if my program did book after book all day it would matter, but
not in any sane situation.

How many times do we hear people discuss runtime speed on a program
whose bottleneck is the glacially slow pace of a 120 WPM typist? C,
LuaJit, Lua, Python, Visual Basic or DBASE III, they're all going to be
fast enough to keep up with the typist.

Totally forgotten in many language comparison discussions is the fact
that the programmer is human. Humans aren't perfect -- they forget to
initialize variables, they forget to free malloc()ed variables. They
can get so clever they confuse themselves, especially if the language
is so granular (like C) that they have to do everything themselves. Or
so crazy (C++) that their theoretically elegant design turns into a
snakepit. Or like Java, where the plethora of addons, some of which are
mildly defective, turn the program into a rickety Rube Goldberg machine.

You know why I think Lua is the best language? Tables. Numeric keys,
text keys, it's all the same to Lua tables. Just organize your data into
tables of tables of tables, and your algorithmic complexity departs the
scene. Additionally, Lua has first class functions, and it's sooooooo
nice to have a function as a data member of a table. You can do
callbacks in any language, but Lua's the one where callbacks are easy
and natural.

Thirdly, like many other languages, Lua has closures with upvalues. The
difference is, Lua has a much simpler syntax for them, so I actually
use them.

It's funny. After learning Lua, my programming style changed *in every
language*. I think more in tables, less in classes and objects. In the
Python LyXHTML to ePub converter, I have a dictionary called conf that
contains the contents of a YAML config file, plus a few other config
items, and a dictionary called arrays, that contains arrays containing
the contents of the input file, and the contents of several output
files. Those are the two things that get passed from function to
function. The only class in the whole thing is a special exception
class for when you walk off the end of an array (I didn't want to use
the standard one).

Here's my story, and I'm sticking to it: In many cases, the best
language for the human programmer has the fastest runtime. A simple
and intuitive language like Lua or Python saves me a lot of time, and I
use that time to design a better, simpler, and more bug-free algorithm,
thereby making the program run faster.

SteveT


Thanks,

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance