Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

LuaJIT

Name: LuaJIT 2012-02-25 0:48

LuaJIT

Name: Anonymous 2012-02-26 2:53

>>31

>- Lua Tables are mutable and encourage modification, instead of creation, meaning there is no easy way to do functional programming with Lua.

Be creative. You are welcome to make shallow copy and comparison functions, or implement a balanced immutable red black tree. lua has closures and tail call optimization, making it much better for functional programming than most other popular languages.

>- `t={[{1,2,3}]="abc"}; print(t[{1,2,3}])` wont print "abc", meaning that `{1,2,3} != {1,2,3}`. In general, Lua's logic seems odd: "nil+1" results in error, while "(not nil)+1" eval to 2.

Yeah, you can't use table keys with deep equality in lua. There is an issue with mutable keys. This is solved nicely in python by providing immutable tupples that can be used as keys. One work around is to stringify the keys, although you have to make the stringification function one to one.

>- Lua uses floating point values instead of integers and 1234567890123456789 would result into 1.234567890123457e+18

Well that's interesting. I wasn't aware of that myself. They don't require it though:

http://www.lua.org/manual/5.1/manual.html#2.2
Number represents real (double-precision floating-point) numbers. (It is easy to build Lua interpreters that use other internal representations for numbers, such as single-precision float or long integers; see file luaconf.h.

>- Lua is unstable: API changes frequently, functions are being added and deleted continuously, `table.foreach` being a good example of to be deleted function, and then there is `table.unpack`, which present only in some versions of Lua.

Yeah they've made changes. But the API is very small and simple. Most of the changes are additions of new features, like variable argument functions and unpack. and table.foreach is trivial to replace, which is likely why it was removed.

>- Lua is inconsistent: `t = {"a","b","c"}; print(t[2])` works, but `print({"a","b","c"}[2])` fails.

The parser can be finiky. But that is completely possible to do with some parens:

Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
print(({"a", "b", "c"})[2])
b


- Hash-Table as a primary data structure has some issues. There is no simple and safe way to implement FIRST and REST function from Lisp: either you have to copy whole Table or modify it, and sequential access is somewhat slow. There is no easy way to remove an element from a list. Even worse, the size of a list may not be what you expect: "b={};b[666]="a";print(#b)" will print 1. Lua Tables also don't provide advantages of catenable double-ended queues -- a silver bullet data strucure, you'll find in modern Lisps and Haskell.

Not every algorithm must traverse a data structure using first rest style. Plain iteration works just as well, and can be expressed recursively if you want to go there.

A doubly linked list is not that difficult to implement. And lua has pretty nice support for iterators. I actually concatenate iterators.

- Lua's REPL wont pretty-print tables, instead it'll print something like "table: 0x807e978"


Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
t = {action = "learn lua before finding fault with it"}
setmetatable(t, {__tostring = function(instructions) return "You should really " .. instructions.action end})
print(t)
You should really learn lua before finding fault with it



>- Hashtables hold much of Lua's data, and even simple variable access goes through table system, producing several L2 cache misses in process just to get to value. That makes Lua slower than comparable alternatives, like Lisp.

Have you confirmed this with profiling? A hash table that doesn't use chaining is usually kept at a length that is twice the number of elements stored. Your beef is with hash tables being used for structures? Most sane structures will have maybe 8 to 10 entries in it, so a hash table of length 20. Assuming each pointer is between 4 to 8 bytes long, the array will be 80 - 160 bytes long? That ought to fit in a cache.

If you want to avoid cache misses though, you should use a langauge like C or seeples. Something that lets you explicity control where your objects are allocated. Using a language where objects can only contain references to other objects will cause a lot of jumping around in memory.

- Table indexing starts from 1, instead of 0, like everything in computing. That acts as a source of errors and confusion, when interfacing with external APIs or converting algorithm from Lua to C/C++, while 0 still acts as a dangling pointer.

You can still use A[0] if you want to. zero is a valid key. And if you want the ipairs function to iterate from zero up to #A, you can make one yourself. And indecies starting at zero is not always ideal. Check the formula for a d-way heap (the priority queue implementation) and you'll see what I mean.

- Lua's GC is a naive mark-and-sweep implementation, which stores the mark bit directly inside objects, a GC cycle will thus result in all objects being written to, making their memory pages `dirty` and Lua's speed proportional to the number of allocated objects. Lua simply was not designed to support hundred thousand objects allocation per second.

If you'd like to change this by having an ID array, it would not be very difficult to implement. You can download the source and make your change and release it as Clean Page Lua 1.0.
http://www.lua.org/ftp/

- Quirky syntax with underscores for special variables and cryptic symbols for simple functions, like `#xs` for `length(xs)` and `x = start,end,step` instead of range(start,end,step), while logical connectives (`and`, `or` in place of `&&`, `||`) are hard to notice between other symbols. do/then/end everywhere could be annoying.

You criticize #A instead of length(A), but support A && B instead of A and B?

- Lua was built as a glue language, and it shows. Much of Lua hype comes from it's usage as a simple integrated scripting language in video games industry. That makes typical Lua user a teenage gamer with little expectations or taste for computation features and productivity.

True. Some people that begin that way get past that stage, and some don't. I started using lua for its simplicity, support for functional style, readability, flexibility, and performance. As for it's presence in the gaming industry, lua wouldn't be used if it didn't fill a niche.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List