Lua is faster than Fortran???

[Luis M. González]

On Jul 4, 6:09 pm, Stephen Hansen <me+list/pyt... at ixokai.io> wrote:
> On 7/4/10 9:21 AM, sturlamolden wrote:
>
> > On 4 Jul, 14:29, David Cournapeau <courn... at gmail.com> wrote:
>
> >> Actually, I think the main reason why Lua is much faster than other
> >> dynamic languages is its size. The language is small. You don't list,
> >> dict, tuples, etc...
>
> > They have managed to combine list and dict into one type (table) that
> > does the job of both.
>
> You say "managed" as if it were some technical accomplishment, or that
> the result is able to actually do the job of both: neither of these
> assertions are true.
>
> Have you actually *used* Lua? I quite like the language in certain
> contexts where its appropriate, but if you've actually used it in real
> code and found tables to be at all a substitute for *either*
> dictionaries *or* lists, then I think somehow you've managed to actually
> miss using either data structure in Python to any real extent, somehow.
>
> Lua's tables are at very weak "dictionary-like" and "list-like" objects,
> which indeed have been folded into one. To the detriment of both, at
> least as far as they are an actual useful data structure.
>
> You can't even get the equivalent of len(dict) in it: you have to
> actually brute-force iterate the table and count manually. Even for a
> purely array-like table with onlyn umbered indexes, #table can be
> unreliable: its quite possible through normal list-like operations that
> you perform on it, it can end up with holes where #table will fail.
> Since it is *not* an list internally at *all*, but simply an associative
> array with numbered indexes.
>
> I could go on, and on, and on: but the fundamental *weakness* of Lua'
> data types as data-structures is irrefutable, from its tables to strings
> to numbers: they are incredibly weak on capabilities. You end up writing
> all kinds of "library" functions to just do the normal things that
> should be really easy to do.
>
> Now, of course, there's really good reason why Lua is so simple in these
> ways. Its entirely suitable for Lua as an embedded scripting language to
> keep things very light, so it can be simple and fast. Good for Lua to
> fill this niche superbly. But you can't start saying its simple
> alternatives are at all comparable to Python's extremely rich and
> capable data types.
>
> > And yes there are tuples.
>
> No, there isn't. There's ways to create a tuple-like-thing which kind of
> behaves like a braindead tuple, and functions have a positively bizarre
> capability of returning more then one value (and accepting variable
> values), so there's these points in the language where you have this
> sort of Immutable Sequence, but its opaque until you unwrap it -- and
> then it ceases to be.
>
> That's not the same thing as having an immutable sequence that you can
> store data in at your discretion, with a rich series of capabilities
> that you can leverage.
>
> > There are no classes, but there are closures and other building blocks
> > that can be used to create any object-oriented type system
>
> Not really.
>
> Above, I spoke of tables as data structures, things just storing data.
> But you're right, they are capable of more then that-- but you're
> over-selling just how far that capability goes, by a long shot (and
> underselling just how much work it takes to get it there).
>
> Yes, tables have a limited series of 'hooks' that you can tie into to
> alter their behavior, and through this you can simulate certain higher
> order type systems as defined in other languages. In fact, lots of
> people have done this: there's multiple "classy" libraries out there to
> bring some kind of Class-or-Object-Oriented-Programming to Lua.
>
> They work to varying degrees: but the hooks that Lua provides to tables
> is still significantly lacking to really replace Python's
> comprehensively dynamic object model, without a LOT of wasted cycles.
>
> For example, while you can use __newindex to 'catch' someone setting a
> new 'key' on a table, and and __index to replace or forward the actual
> lookup, you can't actually capture someone trying to set a value to a
> key which already exists. So, you end up having to do a full proxy
> approach, where your table never actually stores anything directly
> (except a reference to another hidden table), and so when someone goes
> to set something you have to set it on the proxied object instead.
> Because you can't let there ever be any real keys on the proxying /
> external table.
>
> So you're able to work around its lack a bit, to simulate something
> /like/ what it means to have __setattr__.
>
> But then you run into problems. There's no way now to iterate over the
> table now, because pairs() will only return your internal hidden keys
> that you're using to point to the proxied table (Although you can get
> around this with some more complexity by hiding said key into a
> closure-- but even then, you still can't iterate over the proxied
> table's keys instead).
>
> So what do you do? Well you go replace the global "pairs" function,
> that's what you do! So it learns your particular style of Classness, and
> interacts well. Hope you never use any third-party code which has even a
> vaguely different kind of Classness. Alternately, you can just decide to
> never use the standard idiom of iteration for your classes, and instead
> one must always "for x in my_table:iter()" -- so now you have one kind
> of code operating on 'real' tables, and a totally different kind
> operating on your 'classy tables'.
>
> And on and on. The point is, sure. Lua can sort of simulate different
> OOP approaches, and Lua-folk are very adept at tweaking, twisting,
> turning and ripping tables into all kinds of pseudo-data types that
> match other paradigms, but its all hacks on top of hacks on top of
> hacks. You end up with some *really* weird and/or messy code if you try.
>
> Better to do Lua in Lua, instead of Python in Lua, or Java in Lua.
>
> (just like
>
> > CLOS is defined by Lisp, not a part of the basic Lisp syntax). So I
> > imagine it would be possible to define an equivalent to the Python
> > type system in Lua, and compile Python to Lua. Lua can be compiled to
> > Lua byte code. Factoring Lua, out that means we should be able to
> > compile Python to Lua byte code.
>
> --
>
>    Stephen Hansen
>    ... Also: Ixokai
>    ... Mail: me+list/python (AT) ixokai (DOT) io
>    ... Blog:http://meh.ixokai.io/
>
>  signature.asc
> < 1KViewDownload

This is a very good explanation of what Lua is and how it differs from
python.
It all comes down to what you are looking for in a language.
Simplicity of use or simplicity of implementation?
Python gives you all the tools to code your algorithm right now with
the least delay an with minimal effort, at the expense of some
performance penalty.
Lua is lean and fast, but if you need to use classes, or list
comprehensions or some other cool features easily found in python, you
have to code them yourself before using them. Perhaps you don't need
them and you prefer a more spartan language in favor of speed and
performance, and that's ok. Actually, this is what Lua is for.

You may find that coding your own helper functions in Lua are not that
difficult, but you have to do it.
Basically, both languages are very similar, and their grammar is
almost identical in their simplest aspects.
But as soon as you start working with Lua, you wish you had all the
missing python features.

I see Lua as a some sort of minimal Python. It looks like a simplified
subset of python.
Being simpler, it's also easier to implement efficiently. Note that
Lua was created a simple language to be embedded into larger
applications written in c or c++. So it doesn't need a standard
library, since you would be using libraries built for the main
aplication, written in c or c++.

However it worth noting that, according to Mike Pall (the creator of
Luajit), there's no reason to believe Python could not be as fast a
Luajit. It has no show stoppers. It would simply require much more
work around its corner cases, being the main difficulties in python's
own environment, not in the core language.

This is all explained in the above mentioned thread on tracing jits...

Luis