Comments on: 5 awkward and 5 awesome things about lua …

By: phil hassey

phil hassey — Mon, 08 Feb 2010 20:12:27 +0000

@Denilson: “Tender lovin’ care.”

By: Devon Strawn

Devon Strawn — Mon, 08 Feb 2010 08:16:09 +0000

Mulling this over a bit more, I’d advise you to double down on improving TinyPy rather than move your investment to Lua. Lua doesn’t seem to be getting much traction outside of the game development community, whereas Python is widely adopted. And the momentum behind Python will continue to grow now that Google’s putting resources into the language (Guido works there, and Google’s built several products on Python).

Here’s some real data on usage of various dynamic languages: http://www.ohloh.net/languages/compare?measure=commits&percent=&l0=csharp&l1=javascript&l2=lua&l3=python&l4=ruby&l5=lisp&l6=-1&commit=Update
Lua rides the bottom of the graph, and Python beats out even JavaScript and C#. Lua’s great for embedding, but it’s an idiosyncratic also-ran language.

Perhaps you could modify LuaJit (or LLVM-Lua) to work with TinyPy bytecode to improve perf?

By: Denilson

Denilson — Sun, 07 Feb 2010 13:15:07 +0000

Just one question: WTF is TLC?

By: philhassey

philhassey — Thu, 04 Feb 2010 16:54:08 +0000

@brm – I don’t use -lgc, I use a hand rolled incremental collector, which could also use some work.

Thanks for the thoughts!

By: brm

brm — Thu, 04 Feb 2010 10:34:29 +0000

first, try to avoid on hacking bare lua parser, i did that, got my hands burnt. it’s easy but all you’ll end up is no-lua anymore with all the bad strings attached (unknown to users). this can be solved nicely by using http://metalua.luaforge.net so you use whatever syntax you’re comfortable with, while the users are left with a choice whether to use plain lua or your mod (the index 1 tables are still a neccesity for common co-op though).

second, why is tinypy slower? from superficial look at the code it seems to it’s rather luasqe (internalized strings, ssa-like register vm, tuples are pretty much heavier than lua’s stack arg passing, consts are inline though..), save for bloated -lgc which is probably a real performance hit. imho hacking tinypy to be more like luavm would be the way to go (also, having OO implemented on top of syntax/codegen, rather than vm would probably help) i suppose you’re familiar with the http://www.lua.org/doc/jucs05.pdf

By: Devon Strawn

Devon Strawn — Tue, 02 Feb 2010 06:20:51 +0000

Lua’s awkward bits make it annoying for real-world use. Python’s not perfect, but it’s *more perfect* than Lua by far.

Your time might be better spent optimizing TinyPy than forking Lua.

By: Alex

Alex — Sun, 31 Jan 2010 23:09:11 +0000

You might get more people helping with tinypy if you made a busybox module for it.

By: Niki

Niki — Sun, 31 Jan 2010 17:35:04 +0000

point 1 is very important. After years of using 1 based indexing in Pascal and fighting with extra +1 and -1 on many places i am confident that 0 based indexing is the only save way.

By: Adam H

Adam H — Sat, 30 Jan 2010 19:12:33 +0000

One quick note: Lua uses identical syntax for arrays and dictionary, but if you use a table as if it were an array, internally it stores it as an array. I worked this out when I got curious and dug into their handling code a little bit. So if your discomfort is caused by “storing arrays as hash tables is inefficient,” then be aware that Lua does NOT store arrays as hash tables. It just uses the same syntax for both, and does not make a type distinction between the two.

Note also that there is another difference — arrays have a magic member named “n” which gives the size of the array, but it only works on true arrays. Hash tables don’t keep count of their contents, so you either have to do that yourself (update ‘n’ on your own) or do without it.

If you start using an array as a hash table, of course, it converts it into a hash table.

By: phil hassey

phil hassey — Sat, 30 Jan 2010 17:22:55 +0000

@sopyer – I’ll check out squirrel!

@Eli – yeah, tinypy is pretty slow, doesn’t handle exceptions well, and a few other things. Maybe I should put more work into it. At any rate, I’m considering my options.

@carl – A few brief tests. It’s not enormously faster than python, so it’s not a major thing.

@tonic – I’ll check that language out too.