Objective-C vs Lua
od-eon.com
od-eon.com
First question I asked myself: What does programming the Smalltalk-style message sending interface look like? What does [dict setObject:x forKey:y]; look like?
It looks like this:
dict:setObject_forKey(x, y);
Well.. okay. I know some people dislike the message sending syntax, but the API is written for that syntax. This is verbose, but readable (if you're familiar with Cocoa):
- (NSIndexPath )tableView:(UITableView )tableView targetIndexPathForMoveFromRowAtIndexPath:(NSIndexPath )sourceIndexPath toProposedIndexPath:(NSIndexPath )proposedIndexPath;
This, on other hand...
function tableView_targetIndexPathForMoveFromRowAtIndexPath_toProposedIndexPath(tableView, sourceIndexPath, proposedIndexPath);
...is... not winning the fight, let's say.
Second: what on earth is this:
function crunchCookie(self, sender)
self.button = self:view():viewWithTag(1)
self.button:setImage_forState(UIImage:imageNamed('cookie-crunched.png'), UIControlStateNormal)
self.label = self:view():viewWithTag(2)
self.label:setHidden(false)
end
Anyway, this still looks pretty cool. Hooking up a garbage collected scripting language on top of Obj-C with minimal memory overhead is awesome.
- Can Lua/Wax not use IB? The Objective-C version uses IB to lay the views out, while the Lua version seems to lay it out manually? It does for the main UIWindow, at least.
- The Objective-C and Lua code don't behave the same way. This isn't a 1:1 comparison.
1. Less, if you turn your AppDelegate into a UIApplication subclass (so it is a singleton, and you can not worry about dealloc in there because the app will be gone by the time dealloc is reached).
It is really not fair to compare a verbose standard project template from Xcode with a a condensed Lua version.
If you were really keen, you might consider which of the lines were authored by the programmer, and which were inserted by the tool 'auto-magically'.
In that case, Objective-C may actually come out ahead in this example!
Of course, I don't know how much of the Lua code was boilerplate supplied by the toolchain, all that stuff about twiddling the bounds and the frame might be boilerplate. In _that_ case, the actual amount of code written by both would be almost exactly the same.
And then we get onto secondary claims, e.g. benefits of garbage collection. (See the pretty graph)
Lastly we could compare them on 'prettiness' of code. Objective-C is quite ugly, but 'underscorising' the function names doesn't improve it much if at all.
-----
So overall everything is equal apart from the garbage collection/memory usage thing which tips the scales in Lua's favour.
Now, on iOS the speed can be a big issue, so knowing if there is a performance penalty that comes with that is a big deal, which I don't see covered in the article.
The pretty graphs are actually very misleading.
The graphs that drop down in the Lua version actually show the system load and not memory usage. So it shows nothing about garbage collection.
If you look at the process list in for the Objective-C version you can see that some other process, 'installd', is hogging most of the CPU.
I bet the author was syncing with iTunes or installing some software while running these tests.
What you can see in the Instruments screenshots is that the Lua version uses about 200KB more memory for the 'same' application.
Call me naive, then. Source code, even automatically generated, will be read, and may be modified. It does count. XCode template (unlike Yacc output) is source code.
> And then we get onto secondary claims, e.g. benefits of garbage collection. (See the pretty graph)
If I got it right, the little graph is about some aspects of runtime performance, which is secondary. But you sound like you don't acknowledge the primary claim of garbage collection: that it simplifies programs.
If you can control when collection happens and memory management is simple, then it's probably some kind of RAII. That makes sharing (shallow copies) unsafe, and ultimately encourages mutable state, which is bad[1].
If there's some reference counting going on, then GC pauses will occur whenever some giant data structure goes out of scope (and its destructor is called). That's predictable, but not obvious. Plus, a proper GC (generational and incremental) will not pause often nor long, if at all. Even then, many languages give you some control over the GC, giving you most predictability back. I don't know if Lua offers that, but I'd be surprised if it doesn't: it's used for games.
http://stackoverflow.com/questions/4064451/luas-gc-and-realt...
tldr; LUA's GC isn't magic and for games you need to control it carefully. Even then a reference counting system is often better.
Answer excerpted:
As for the garbage collector. Use it as is first. If later you find performance issues use lua_gc to fine tune its behavior.
Some examples:
Disable the garbage collector during those times when the slow down would be a problem.
Leave the garbage collector disabled and only step it when game logic says you've got some head room on your FPS count. You could pre-tune the step size, or discover the optimal step size at runtime.
Disable the collector and perform full collection at stopping points, ie a load screen or cut scene or at turn change in a hot seat game.
You might also consider an alternative scripting language. Squirrel tries very hard to be a second generation Lua. It tries to keep all of Lua's good features, while ditching any of its design mistakes. One of the big differences between the two is squirrel uses reference counting instead of garbage collection. It turns out that reference counting can be a bit slower than garbage collection but it is very deterministic(AKA realtime).
Otherwise, it would sound perfectly reasonable if I were to tell you, "OK, I'm going to give you a 500k LOC program to debug without tool support while I debug a 50 LOC one. First one to finish buys the other a car." You'd be naive to take that bet.
Sure but the author does actually compare a poorly written Objective-C version to an optimized (and different!) implementation in Lua and then goes on to say, hey look how much more pretty the Lua version is.
If I can accomplish something in 1 line of code that takes me 100 lines of code in another language, that matters. It also probably indicates that the more succinct language has a higher level of abstraction.
I completely agree. Do you have some good suggestions on how to test this?
foo (a, b, c, d) memorable? You have to remember the order of parameters, and the function name rarely makes this obvious, so unless you use this func all the time, you end up reading the docs.
fooWithBarAndBlatAndFazAndFooz(a,b,c,d) makes the parameter ordering obvious, but is to me less readable than:
fooWithbar: a blat: b faz: c fooz: d
Which is just about as concise as you can get. Of course it would be "nice" if objective-c allowed for parameter order to not be meaningful, but that would require dictionaries of parameters, instead of what really happens, translation to a function with a fixed parameter list, which is pretty efficient.
Message passing syntax looking initially complex is a lazy reason to dump an entire system when the alternative has much worse integration and support.
"Which is just about as concise as you can get. Of course it would be "nice" if objective-c allowed for parameter order to not be meaningful, but that would require dictionaries of parameters, instead of what really happens"
It's pretty easy for the compiler to look at the param name at the call site and compare it to what was declared. No dictionaries needed at run-time.
1. Obj-c may be verbose but XCode 4 does a lot of the heavy lifting with templates, snippets, and auto-completion, not to mention the continuous feedback on errors. It doesn't feel anywhere near as heavy as it looks. How much of that is available in LUA?
2. What does the picture look like when you want to access C api's and not just send messages? One of the most positive aspects of Obj-C is that you can use C libraries directly without either performance or code overhead - e.g. OpenGL, CoreGraphics, not to mention all manner of OSS C-libraries.
There's another modern variant of Lua bindings for ObjC (aimed mostly at Mac instead of iOS) -- http://playcontrol.net/opensource/LuaCocoa/
It uses BridgeSupport and libffi.
That's exactly what was said about Java or MFC. Instead of staring at your own verbose code you're now staring at the auto-generated verbose code.
Personally a slightly simpler syntax for the message sending layer in Objective-C just doesn't seem to give that much leverage. I'd much rather see a functional language properly integrated à la F#.
http://probablyinteractive.com/2010/8/20/ios-interactive-con...
I'm planning on trying it out whenever I get time.
And also, the whole discussion turned into a discussion about exactly how dynamically typed something is, and that feels quite irrelevant to what he tried to show.