11 ms·

Objective-C vs Lua

73 points by tudorizer 16y ago

rbarooah 16y ago
Looks very nice, and god knows it would be nice to have a next generation replacement for obj-c, but... 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.
- dchest 16y ago
  2. AFAIK, Wax requires wrappers for C functions. There's another modern variant of Lua bindings for ObjC (aimed mostly at Mac instead of iOS) -- http://playcontrol.net/opensource/LuaCocoa/ http://playcontrol.net/opensource/LuaCocoa/ It uses BridgeSupport and libffi.
- rbarooah 16y ago
  And another thing - what about debugging. Are we back to just logging? 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#.
  - koko775 16y ago
    Try an interactive shell! http://probablyinteractive.com/2010/8/20/ios-interactive-console.html http://probablyinteractive.com/2010/8/20/ios-interactive-con... I'm planning on trying it out whenever I get time.
- cageface 16y ago
  I share your reservations about the loss of XCode functionality. The verbosity of Obj-C and the Cocoa APIs is mitigated to a large degree by code completion and integrated documentation. Losing that, the visual debugger, and, presumably, the tight integration with Instruments would be a big productivity loss.
  - rbarooah 16y ago
    Right - also there doesn't seem to be a story for closures and GCD.
- blub 16y ago
  "Obj-c may be verbose but XCode 4 does a lot of the heavy lifting with templates, snippets, and auto-completion," 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.
Zev 16y ago
- If you remove the boilerplate, you can likely get the Objective-C version down to about 40 lines.[1] - 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).
- richcollins 16y ago
  Both projects use the same .xib created in Interface Builder, per the tutorial.
  - Zev 16y ago
    In that case, it is very weird that one sample (Lua) specifies the bounds of the UIWindow while the other is closer to the default setup and does not specify the bounds (Objective-C).
- chc 16y ago
  I was going to disagree with you about the boilerplate until I actually looked at the article, and you're right, it's just silly that the the Objective-C version gets about 10 additional methods that serve no real purpose.
  - st3fan 16y ago
    The author must not be very experienced with iOS development because you can simply ignore all those extra empty methods if you do not wish to implement them. It is really not fair to compare a verbose standard project template from Xcode with a a condensed Lua version.
    - Stormbringer 16y ago
      It is only 'not fair' if the number of lines of code is important. Only the most naive programmers think that LOC actually means anything. 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.
ajl2011 16y ago
The limitations people will impose on themselves just so they don't have to spend time learning something will never ceases to amaze me.
billjings 16y ago
Kneejerk criticism first. 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 Is this Android programming now? Do I have to fish my widgets out by hand? Anyway, this still looks pretty cool. Hooking up a garbage collected scripting language on top of Obj-C with minimal memory overhead is awesome.
- protomyth 16y ago
  I know it is a personal thing, but I actually like the Smalltalk-style message system. I don't spend as much time look things up. It is interesting now that iOS gains enough popularity to attract enough people who prefer C/C++ style message syntax. Apple did the property thing to help, but It still feels a little weird.
defroost 16y ago
With the underscores, Wax looks a bit like PyObjC or RubyCocoa. Lua is a fun language, so I will certainly give it a try. I would love to see a Framework in MacRuby, as I think Ruby, as a true Object Oriented language, may be better suited to Cocoa/IOS development. But this is certainly a project to watch.
comex 16y ago
Sounds like Cycript (http://cycript.org http://cycript.org), but Cycript allows messages to be written in Objective-C syntax rather than underscore-ized, which makes using Cocoa not so painful.
delackner 16y ago
People often complain about the verbosity of objective-c, but if you have a method that takes several parameters, how is 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.
- blub 16y ago
  You can't create an "easy to use" function if you name it foo and you name your variables a, b, c and d or blat or faz or whatever. "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.
Flow 16y ago
I must say I didn't like the authors cocksure attitude that "Most of the people dislike the syntax of Obj-C and it does slow down development". 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.

73 points by tudorizer 16y ago

Looks very nice, and god knows it would be nice to have a next generation replacement for obj-c, but... 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.

dchest 16y ago
2. AFAIK, Wax requires wrappers for C functions. There's another modern variant of Lua bindings for ObjC (aimed mostly at Mac instead of iOS) -- http://playcontrol.net/opensource/LuaCocoa/ http://playcontrol.net/opensource/LuaCocoa/ It uses BridgeSupport and libffi.
rbarooah 16y ago
And another thing - what about debugging. Are we back to just logging? 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#.
- koko775 16y ago
  Try an interactive shell! http://probablyinteractive.com/2010/8/20/ios-interactive-console.html http://probablyinteractive.com/2010/8/20/ios-interactive-con... I'm planning on trying it out whenever I get time.
cageface 16y ago
I share your reservations about the loss of XCode functionality. The verbosity of Obj-C and the Cocoa APIs is mitigated to a large degree by code completion and integrated documentation. Losing that, the visual debugger, and, presumably, the tight integration with Instruments would be a big productivity loss.
- rbarooah 16y ago
  Right - also there doesn't seem to be a story for closures and GCD.
blub 16y ago
"Obj-c may be verbose but XCode 4 does a lot of the heavy lifting with templates, snippets, and auto-completion," 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.

Zev 16y ago

- If you remove the boilerplate, you can likely get the Objective-C version down to about 40 lines.[1] - 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).

richcollins 16y ago
Both projects use the same .xib created in Interface Builder, per the tutorial.
- Zev 16y ago
  In that case, it is very weird that one sample (Lua) specifies the bounds of the UIWindow while the other is closer to the default setup and does not specify the bounds (Objective-C).
chc 16y ago
I was going to disagree with you about the boilerplate until I actually looked at the article, and you're right, it's just silly that the the Objective-C version gets about 10 additional methods that serve no real purpose.
- st3fan 16y ago
  The author must not be very experienced with iOS development because you can simply ignore all those extra empty methods if you do not wish to implement them. It is really not fair to compare a verbose standard project template from Xcode with a a condensed Lua version.
  - Stormbringer 16y ago
    It is only 'not fair' if the number of lines of code is important. Only the most naive programmers think that LOC actually means anything. 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.

ajl2011 16y ago

The limitations people will impose on themselves just so they don't have to spend time learning something will never ceases to amaze me.

billjings 16y ago

Kneejerk criticism first. 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 Is this Android programming now? Do I have to fish my widgets out by hand? Anyway, this still looks pretty cool. Hooking up a garbage collected scripting language on top of Obj-C with minimal memory overhead is awesome.

protomyth 16y ago
I know it is a personal thing, but I actually like the Smalltalk-style message system. I don't spend as much time look things up. It is interesting now that iOS gains enough popularity to attract enough people who prefer C/C++ style message syntax. Apple did the property thing to help, but It still feels a little weird.

defroost 16y ago

With the underscores, Wax looks a bit like PyObjC or RubyCocoa. Lua is a fun language, so I will certainly give it a try. I would love to see a Framework in MacRuby, as I think Ruby, as a true Object Oriented language, may be better suited to Cocoa/IOS development. But this is certainly a project to watch.

comex 16y ago

Sounds like Cycript (http://cycript.org http://cycript.org), but Cycript allows messages to be written in Objective-C syntax rather than underscore-ized, which makes using Cocoa not so painful.

delackner 16y ago

People often complain about the verbosity of objective-c, but if you have a method that takes several parameters, how is 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.

blub 16y ago
You can't create an "easy to use" function if you name it foo and you name your variables a, b, c and d or blat or faz or whatever. "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.

Flow 16y ago

I must say I didn't like the authors cocksure attitude that "Most of the people dislike the syntax of Obj-C and it does slow down development". 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.