

Objective-C vs Lua - tudorizer
http://od-eon.com/blogs/tudor/lua-vs-obj-c/

======
billjings
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
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.

------
Zev
\- 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).

~~~
chc
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
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
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.

~~~
st3fan
"""And then we get onto secondary claims, e.g. benefits of garbage collection.
(See the pretty graph)"""

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.

~~~
rbarooah
Yes - it's pretty obvious that that CPU graph is not accurate.

------
delackner
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
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.

------
rbarooah
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.

~~~
cageface
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
Right - also there doesn't seem to be a story for closures and GCD.

------
Flow
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.

------
defroost
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
Sounds like Cycript (<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.

