The lack of IB support makes the otherwise "Ruby that Looks Too Much Like Objective C" a bit of a net loss. You lose IB, and the ability to easily integrate the approaches all the thousands of examples and questions do.
I'm very interested to see where this ends up however. I'd love to do iPhone programming (with IB support) in python or ruby. Just not with this tool, just yet.
Not that it's an invalid position, but when Apple-centric developers proclaim 'ObjC > C++' in such a matter-of-fact way, I always wonder how much that is based on actual real-world experience.
Well see part of the problem is that it takes more experience to know your way around C++; it's just bigger than Objective-C, even if you only talk about the "commonly used" parts. If you know C and are reasonably familiar with OO, you can easily learn all of the important differences between C and Objective-C in a week or so. And since it's a true superset, everything you know from C carries over. C++ is just more complicated to learn the ropes of.
So I guess what I'm saying is that a lot of people criticizing C++ probably don't have much experience with it, but that's kind of the point.
Exactly. C++ is simply way more complicated than Obj-C.
Also, the Obj-C object system is pretty high level and dynamic (message passing, late binding, dynamic dispatch). This makes it somewhat slower at method calling, but at the same time a lot easier to work with.
The downside of being slow is usually mitigated by simply being able to drop back to plain old C if need be.
Of course, C++ can emulate all that, and without performance compromises, but at the expense of readability.
For the longest time, I would hands down prefer Obj-C to C++ just because it was simpler. The more experienced I become with C++, the more I am able to appreciate its power and no-compromise attitude, though.
having dabbled in a bit of Ruby metaprogramming, I can't say that it is particularly simple. Still, simple Ruby is simpler than simple Obj-C and certainly simpler than simple C++ (if indeed there is such a thing as simple C++).
Do you mean that Ruby code tends to be simpler than Objective-C code, or that the language itself is actually simpler. Because, while I haven't done a formal comparison or anything, I would find the latter to be pretty unlikely. Most of Objective-C can really be boiled down to little more than few teaspoons of syntax sugar on top of C (although that is less true today than it once was), and C is definitely a simpler language than Ruby.
Not case closed. Given that you lose a lot of useful tools (Interface Builder, Storyboards and such) and that Objective-C can be pretty quick to code with Xcode I would contend that given expertise in both a complex application would take less time to code in Xcode/Objective C.
While RubyMotion is by far, the best alternative to Objective-C but it is hard to tell 48 hours after its release what people will do with it.
What about MonoTouch? To be honest I think I'd look at that first if I wanted something other than Obj-C. At least I could take my non-UI code and run it on Android.
I would have killed for this about 2 years ago, but now that I learned Objective C, I'm comfortable enough with its quirks that I can just use it to get stuff done..
Having to learn the nuances of RubyMotion in order to do stuff I already know how to do, is probably very very low on my priority list.
As someone who has developed and released iOs apps in Titanium before (write JS / coffee, compile to native app), I am curious about RubyMotion's performance. One of Titanium's weaknesses is that it is extremely inefficient in certain views (e.g. tableViewsRows) to the point where if you are loading/sorting any appreciable amount of data you can only display a few labels within the view without the app grinding to a halt -- on average iPhones.
I am not sure if the RubyMotion approach is different than Titanium -- does anyone know whether it is faster and why?
Ramblings like this are a premier example of what is wrong with engineers today. If you are afraid to learn or use tools outside of ruby, you are not a true engineer. The world does not revolve around ruby.
Get some real iOS development under your belt before you make these broad assumptions.
Agreed. I'm sure obj-c is horrible if you keep expecting it to be like Ruby... people need to embrace the idioms and syntax of the language they're actually using.
After using it for almost a year, I find obj-c really nice now. But that was only after I got out of the C/C++ mindset and more into obj-c mindset.
The REPL/debugging looks "better" than iOS obj-c, but I'm not seeing any other "better" here. Ruby syntax is not "better" than obj-c syntax, it's just different.
Xcode may be unstable, but you can write Objective-C in any text editor. And since Xcode shells out to regular command line tools, you can do the same under any environment you wish.
I agree that for some people, RubyMotion may be better than ObjC. I'm not one of them. Regardless, I think your Ruby code examples could have been better chosen:
- I'm a huge fan of Ruby's || operator, but probably wouldn't use it to dequeue or create a table cell, because the line is way too long. Perhaps this is fixable with a return after the ||
- creating labels programmatically seems like a poor example because I'd do that in my storyboard, and it would take zero lines of code. Or 6 lines of XML for 6 labels, if I'm being pedantic.
It has a much steeper learning curve than Ruby for sure, but once you're proficient it's no harder to use. Indeed there's benefits to both languages.
- Xcode is Unstable
It's gone through periods of instability. But in the current version you may encounter the odd crash (perhaps once a week in full time use for me). Really not an issue given it's a cutting edge tool that's rapidly evolving.
- Xcode Hides Important Information
It has a learning curve. Some things take time to learn but once you do you're more productive.
- Objective-C Is Tedious
Matter of opinion. One person's tedium is another being explicit and reaping the benefits during refactoring, code completion and compilation speed.
- RubyMotion is Easy to Use
For sure easier than Objective-C. But so what? Can it build complex apps more quickly than Objective-C when someone becomes proficient? Probably not.
- RubyMotion is Ruby
That's great. Ruby is a great, easy to use and powerful language. I love Ruby. However given all the other things you sacrifice to get Ruby it's really not worth it.
- RubyMotion Makes Debugging Easy
Really? It sure doesn't look like it does. Xcode and LLVM save me a hell of a lot of time writing my apps because I don't need to actually run them and see the exceptions. And what about the static analyzer?
- RubyMotion Isn’t Perfect
Indeed.
- Better Than Objective-C
For trivial apps yes. For apps you'll be paid to write, in my opinion probably not.
I have yet to write an iOS app where I didn't at least once dip down into raw C for speed and/or control. On resource constrained platforms Obj-C's ability to go from high to low in a line of code is a big competitive advantage. I don't give that up lightly.
If RubyMotion offered a truly higher level abstraction over Cocoa Touch or offered cross-platform portability I might be interested but an arguably better syntax over the same API just isn't enough of a win.
Score one for ObjC's use of reference counting instead of a garbage collector on iOS, too.
Now don't get me wrong, I'm normally of the opinion that anything that whiffs of manual memory management is for chumps. But by day I write apps that target workstations that have enough RAM that I can get away with pretending that memory is an unlimited resource.
On a memory-constrained platform like iOS, though, being able to tightly control how much memory you're using becomes much more valuable. If not critical. And the one place where garbage collection simply can't beat manual memory management is total memory consumed. All those dead objects that are waiting around to be scooped up by the collector do take up space. Sometimes a whole lot of it.
It's not all rainbows and butterflies. From the RubyMotion documentation: "Object cycles, when two or more objects refer to each other, are currently not handled by the runtime, but will be in future releases."
- RubyMotion is Ruby
That's great. Ruby is a great, easy to use and powerful language. I love Ruby. However given all the other things you sacrifice to get Ruby it's really not worth it.
What do you sacrifice to get to use Ruby? I've avoided learning to program iOS because I really dislike Obj-C. If Ruby were good enough for 60% of the apps on the App Store I'd join in a heartbeat.
- No Interface builder. Really a big loss given the power of Storyboards/segues, layout of objects, complex flows.
- No syntax/error checking as you type
- No static analyzer
- No code completion (perhaps you could find a 3rd party module to do this eventually)
- No refactoring support (very important in larger projects)
- Probably longer compilations (in Xcode/ObjC the compiler will know which files are modified by looking at the included headers and only recompile what is needed, in Ruby I would expect it's gotta do them all but could be wrong).
>> - Objective-C Is Tedious
>
> Matter of opinion. One person's tedium is another being explicit and reaping the
> benefits during refactoring, code completion and compilation speed.
Objective-C's "explicitness" provides no advantage to the programmer here whatsoever.
I write code all day every day in Objective-C. It is an extremely tedious language that requires large amounts of boilerplate to perform even simple tasks. (Yes, I know about the new literal syntax available in Mountain Lion, but that doesn't change the broader point.)
Your programming language is the most powerful tool in your toolbox. Ruby is clearly more powerful than Objective-C in terms of how much code one has to write to accomplish a given task.
> Why do I have to have huge statements like this?
Uh, because you're declaring six static color variables. Also, they could be collapsed into one line.
> Introspection is unavailable at runtime
Not sure what this means. Everything is introspectable in Objective-C. #import <objc/runtime.h>
The cell dequeueing comparison uses a one liner for Ruby and an if statement for Obj-C. That's not a fair comparison. "dequeue ?: allocate" would be fair.
> dequeueReusableCellWithIdentifier, ugh.
What is wrong with this?
• I am dequeueing something from the receiver.
• It is a reusable cell.
• The first (and only) argument is the identifier for the cell.
What would be a better name, without losing the descriptiveness?
> Without tab completion, you do a lot of copying and pasting from the documentation when you find a method name you like, just to ensure you don’t accidentally typo it.
This is a huge problem, not a minor thing! The whole point of those "long" message (not method, btw, but that's minor) names is that you don't have to read documentation. If you want to append a format to a string, but don't know the name, just start typing "stringby" and the names are the documentation.
> dequeueReusableCellWithIdentifier, ugh.
What is wrong with this?
• I am dequeueing something from the receiver.
• It is a reusable cell.
• The first (and only) argument is the identifier for the cell.
What would be a better name, without losing the descriptiveness?
I don't think he's complaining about the name of the method, he's complaining about the fact that he has to type it all out now instead of Xcode completing it for him, which is a gripe against RubyMotion, not Objective-C or the cocoa API.
Xcode does complete it for you. So does JetBrains AppCode. I bet RubyMine would too with RubyMotion.
IMHO, the name sucks because it includes information in the name that is also in the signature. At least it would be in languages that support overloading.
Text editors don't display method signatures (some IDEs do, but usually only in tooltips or autocomplete). When writing code in Java or C I often find myself looking up the method/function definition to be certain which argument is which.
This project is really interesting to me, but my biggest issue is the code completion issue. I can deal with writing UI code manually, but Cocoa's APIs are complicated and I find it difficult to remember the method names, argument names, etc. Ruby's nicer array and dictionary syntax may make that easier though (alleviating the need for [NSArray arrayWithObjects:...], [NSDictionary dictionaryWithBlahblah] and replacing it with simply [] and {} to remove complexity.)
Objective C's collection syntax is terrible and is easily the worst thing in the language. Apple fixed it with collection literals in OS X 10.8 though and those enhancements are almost certainly coming to iOS soon.
As far as I understand they required patches to LLVM so it may be that the resulting code would also work on older releases and don't need runtime support. But the version of Xcode that supports them is only available for Mac devs, as far as I can tell.
I've written more code in Ruby than in any other language over the last ten years and I intend to continue using it where it's appropriate. But I have to agree with a lot of other posters that this just seems like a case of people being too lazy to learn something new. If we were talking about the old Obj-C without blocks, ARC and collection literals, I might be more sympathetic. But this just doesn't seem like enough of an improvement to throw out static typing, a decent visual debugger, and first-class, unmediated access to the native APIs without a clumsy pseudo-selector syntax.
It's true that Xcode is bad, but the solution to that is to use AppCode, not to throw out the language.
There is a recurring problem in which languages outgrow their original syntax when applied to new programming paradigms.
For example, accessing an array in C uses simple syntax: arr[5] = 10;
But with NSArrays, etc., we have to add lots of explicit method calls with lots of named arguments, destroying the clear and simple syntax meant to express use of an array in C.
The nice thing about C++ is that you can fix that by overloading operators so that a vector can use the same simple syntax most of the time. You can do this for any objects for which it makes sense... And it vastly improves the ease of coding and reading code.
In objective c, you simply can't improve it. Tons of operations with containers and objects are unnecessarily syntactically unwieldy. Higher level languages like Ruby do this as well, but C++ is fast and explicit. If you want to know what the operator is doing, you can step into it. You can read the code...
The frameworks themselves sometimes impose verbosity, changing syntax used to work with them isn't going to do anything about that.
I've seen quite a few examples since yesterday where the code given was not fewer in line count or even easier to read (partly subjective), but was simply more approachable and familiar to people who are already set on writing Ruby instead of ObjC.
If you know ruby very well you may get a head start here without having to learn ObjC (yet, i'll be shocked if you dont hit walls with this plan), but the mountain of work for you is learning the frameworks, and learning them without the benefit of 90% of the examples and help available specifically for ObjC.
And what of working with the parts of Apple's platforms that aren't Objective-C in the first place, like all the CoreFoundation stuff which is C. At some point you're going to hit walls that could be easily solved by dashing your code with a few lines of C or dropping in an example you found on stackoverflow, but now you've got to come up with the Ruby equivalent and you're actually juggling a new set of issues whether it seems that way or not. Maybe the time you save writing most of an App in ruby makes up for it, but I'd be surprised if thats the case in practice.
Great, so someone who doesn't know how to use arrays is criticizing Objective-C as a language.
To everyone claiming that Objective-C's syntax is unintuitive/unwieldly/etc: remember that familiar != intuitive.
My two darling languages are Python and Haskell and I learned programming in C/assembly, and I find Objective C + Cocoa Touch quite nice, especially since ARC was introduced. Yes, there are things that can be slightly bothering, but once you pass the initial "wow this syntax is weird" hurdle, you're good to go.
It's great to have Ruby as an alternative, but all that Objective-C hating is silly and quite unproductive. Yes, there are limitations in the iOS dev stack (mostly with XCode— but hey, it's not that bad, people have gotten good things done with Eclipse and it doesn't exactly have a perfect track record either). But if the only thing that's getting in your way of developing a great application is the fact that Objective C's syntax makes you uneasy, then you should probably reconsider your abilities as an engineer.
As usual, the ones doing great things done probably won't be the ones tweeting & blogging about how Objective-C is lame and that if only $(arbitrary language) could be used for iPhone dev, then they would change the world.
In addition to your points; I'm not a fan of sensationalist blog posts that start off with whining about how something is hard even though the 'about me' section states how awesome they are at writing code. This seriously just screams hey come read my blog!
I am a fairly proficient ruby coder and I tried learning obj-c multiple times but just did not find my way around it. I wasn't thrown off by the syntax but more about the way the MVC model is built in obj-c. I was really confused by delegates and did not for some reason find obj-c intuitive. I was baffled in a few areas even with tutorials since I did not grasp some of the fundamentals. I think most people are not referring to the obj-c syntax as hard but to the overall framework. Again, I did not spend as much time/effort learning ruby/rails and felt comfortable the first week. My background is primarily Java/J2EE stuff before rails.
>Great, so someone who doesn't know how to use arrays is criticizing Objective-C as a language.
I think the author has a valid point though, even though that example doesn't illustrate it well. He should have used variable names that didn't immediately cry out for arrayification, but there is a boilerplate problem in Objective C.
The thing is, a lot of the verbosity of Objective C is actually a win. Take the messaging syntax: beautiful and readable. And the lack of first-class syntax for almost anything? Usually pretty nice and elegant. Nothing feels magic.
But you don't get a choice about these ideals. Need optional arguments? Too bad. Use a config dictionary. And there's no literal syntax for dictionaries, so every time somebody calls your method, it's going to be a big pile of boilerplate.
I don't even think Objective-C should compromise on all of these ideals, but it should compromise on some, and I think that kind of basic functionality would have been a better point of focus than foreach loops and dot-notation.
Since they don't, people are tempted to use CPP macros to work around these shortcomings. You may remember CPP macros from every GDB nightmare you've ever had.
In my opinion lot of these threads completely miss the point of a tool like RubyMotion. It isn't about which solution is "better"...it is about ease of use for the large number of people that already know Ruby, and want to leverage that knowledge into exploring IOS development. Not everyone has the time or inclination to learn Objective-C right now, even though we can all agree that learning other languages is a good thing. This clearly scratches a market itch, will be supported by a great community that will layer tons of syntactic sugar and cleaverness over any verbosity/UI tool problems, and will likely grow into something truly great for the market it seeks to serve. I think it makes for one hell of a 1.0 MVP release.
As many other posters have noted, learning Obj-C is about 5% of the battle. Getting to grips with the APIs is the hard part and you have to learn them whether you decide to use Obj-C, RubyMotion or MonoTouch.
So if you think that Ruby is providing you with a significant shortcut here you're in for some disappointment.
I completely understand and agree with your comment re: the importance of the APIs, but I think the big win is going to be the Ruby DSLs built on top of the tool kit to make the APIs easier to use - for RubyMotion's intended audience (existing Ruby/Rails Devs). This is just the first step.....look six to twelve months out with an active developer community and think where this project could be.
actually, i have found that without the code completion rubymotion is forcing me to learn the obj-c framework and method names a bit more. i guess I could have just turned off code completion for that.
On top of this, when Apple releases new frameworks, the Obj-C users get to use them immediately. People using weird bridges are giving their competition a huge time boost by voluntarily delaying their own access to the new stuff.
I worked for a company doing Mac apps in REALbasic for several years, and this was a constant hassle. Additionally, RB chose the wrong backend for their compiler (Carbon instead of Cocoa) and there were multiple years of setbacks due to Apple hemming and hawing about whether they were going to deprecate Carbon altogether and RB porting their entire framework to Cocoa. During that process, everybody who emigrated to Objective-C got their stuff to market sooner, and with access to newer libraries to boot.
Ruby's a neat thing, but the way some Ruby programmers come off like they can only think in Ruby and want everything to be Ruby is a little off-putting.
I've been programming a 3D application in Objective-C for a few months. There are things I like, dislike and find really confusing about the language. The thing is, you have to learn and understand it before making assumptions based on "hello world"-like pieces of code. The best "feature" I found so far is not even a feature. It is the way the language is designed simultaneously with the framework/os. It feels more compact and makes reasoning about programs easier.
The second is the way in which complex applications are built. Some programming languages are known for having many design patterns around them, which often feel artificial. Objective-C and the Cocoa libraries use only a handful of them, but they come very natural.
This is the power of Ruby + Objective-C: you get Ruby’s powerful and expressive enumerators, metaprogramming, and reflection, but Objective-C’s APIs and libraries. It’s like chocolate and peanut butter, they just go together so well.
Not the best researched sentence. Much of this is possible in RubyMotion because of Objective-C's metaprogramming and reflection and other powerful features. This makes me suspect the author's depth of knowledge of Objective-C. That said, he's right that Objective-C has a lot more syntactic noise than more recent languages like Ruby and Python.
69 comments
[ 4.0 ms ] story [ 63.5 ms ] threadI'm very interested to see where this ends up however. I'd love to do iPhone programming (with IB support) in python or ruby. Just not with this tool, just yet.
So I guess what I'm saying is that a lot of people criticizing C++ probably don't have much experience with it, but that's kind of the point.
Also, the Obj-C object system is pretty high level and dynamic (message passing, late binding, dynamic dispatch). This makes it somewhat slower at method calling, but at the same time a lot easier to work with. The downside of being slow is usually mitigated by simply being able to drop back to plain old C if need be.
Of course, C++ can emulate all that, and without performance compromises, but at the expense of readability.
For the longest time, I would hands down prefer Obj-C to C++ just because it was simpler. The more experienced I become with C++, the more I am able to appreciate its power and no-compromise attitude, though.
"I like X. I'm not interested in Y."
and not
"X is better than Y."
That's my point. I think it's a worthwhile distinction for developers.
Also, Obj-C is somewhat more complicated than Ruby, though there is a lot of Ruby if you go looking. Obj-C is also more syntactically noisy than Ruby.
It's a higher level language, which allows you to get more work done faster. Case closed.
What about MonoTouch? To be honest I think I'd look at that first if I wanted something other than Obj-C. At least I could take my non-UI code and run it on Android.
I am not sure if the RubyMotion approach is different than Titanium -- does anyone know whether it is faster and why?
Get some real iOS development under your belt before you make these broad assumptions.
After using it for almost a year, I find obj-c really nice now. But that was only after I got out of the C/C++ mindset and more into obj-c mindset.
If using Ruby for a developer to produce the same result is more productive, then not using Ruby Motion would be a crime against "true" engineering.
- I'm a huge fan of Ruby's || operator, but probably wouldn't use it to dequeue or create a table cell, because the line is way too long. Perhaps this is fixable with a return after the ||
- creating labels programmatically seems like a poor example because I'd do that in my storyboard, and it would take zero lines of code. Or 6 lines of XML for 6 labels, if I'm being pedantic.
It has a much steeper learning curve than Ruby for sure, but once you're proficient it's no harder to use. Indeed there's benefits to both languages.
- Xcode is Unstable
It's gone through periods of instability. But in the current version you may encounter the odd crash (perhaps once a week in full time use for me). Really not an issue given it's a cutting edge tool that's rapidly evolving.
- Xcode Hides Important Information
It has a learning curve. Some things take time to learn but once you do you're more productive.
- Objective-C Is Tedious
Matter of opinion. One person's tedium is another being explicit and reaping the benefits during refactoring, code completion and compilation speed.
- RubyMotion is Easy to Use
For sure easier than Objective-C. But so what? Can it build complex apps more quickly than Objective-C when someone becomes proficient? Probably not.
- RubyMotion is Ruby
That's great. Ruby is a great, easy to use and powerful language. I love Ruby. However given all the other things you sacrifice to get Ruby it's really not worth it.
- RubyMotion Makes Debugging Easy
Really? It sure doesn't look like it does. Xcode and LLVM save me a hell of a lot of time writing my apps because I don't need to actually run them and see the exceptions. And what about the static analyzer?
- RubyMotion Isn’t Perfect
Indeed.
- Better Than Objective-C
For trivial apps yes. For apps you'll be paid to write, in my opinion probably not.
If RubyMotion offered a truly higher level abstraction over Cocoa Touch or offered cross-platform portability I might be interested but an arguably better syntax over the same API just isn't enough of a win.
Now don't get me wrong, I'm normally of the opinion that anything that whiffs of manual memory management is for chumps. But by day I write apps that target workstations that have enough RAM that I can get away with pretending that memory is an unlimited resource.
On a memory-constrained platform like iOS, though, being able to tightly control how much memory you're using becomes much more valuable. If not critical. And the one place where garbage collection simply can't beat manual memory management is total memory consumed. All those dead objects that are waiting around to be scooped up by the collector do take up space. Sometimes a whole lot of it.
- No syntax/error checking as you type
- No static analyzer
- No code completion (perhaps you could find a 3rd party module to do this eventually)
- No refactoring support (very important in larger projects)
- Probably longer compilations (in Xcode/ObjC the compiler will know which files are modified by looking at the included headers and only recompile what is needed, in Ruby I would expect it's gotta do them all but could be wrong).
Objective-C:
NSDictionary *d = [NSDictionary dictionaryWithObjectsAndKeys:[NSNumber numberWithInteger:1], @"foo", [NSNumber numberWithBool:YES], @"bar", nil];
Ruby:
d = {foo: 1, bar: true}
Objective-C's "explicitness" provides no advantage to the programmer here whatsoever.
I write code all day every day in Objective-C. It is an extremely tedious language that requires large amounts of boilerplate to perform even simple tasks. (Yes, I know about the new literal syntax available in Mountain Lion, but that doesn't change the broader point.)
Your programming language is the most powerful tool in your toolbox. Ruby is clearly more powerful than Objective-C in terms of how much code one has to write to accomplish a given task.
Uh, because you're declaring six static color variables. Also, they could be collapsed into one line.
> Introspection is unavailable at runtime
Not sure what this means. Everything is introspectable in Objective-C. #import <objc/runtime.h>
The cell dequeueing comparison uses a one liner for Ruby and an if statement for Obj-C. That's not a fair comparison. "dequeue ?: allocate" would be fair.
> dequeueReusableCellWithIdentifier, ugh.
What is wrong with this?
• I am dequeueing something from the receiver.
• It is a reusable cell.
• The first (and only) argument is the identifier for the cell.
What would be a better name, without losing the descriptiveness?
> Without tab completion, you do a lot of copying and pasting from the documentation when you find a method name you like, just to ensure you don’t accidentally typo it.
This is a huge problem, not a minor thing! The whole point of those "long" message (not method, btw, but that's minor) names is that you don't have to read documentation. If you want to append a format to a string, but don't know the name, just start typing "stringby" and the names are the documentation.
IMHO, the name sucks because it includes information in the name that is also in the signature. At least it would be in languages that support overloading.
It's true that Xcode is bad, but the solution to that is to use AppCode, not to throw out the language.
Objective-C better than C++? Wow, has this person ever used Objective-C and C++?
There is a recurring problem in which languages outgrow their original syntax when applied to new programming paradigms.
For example, accessing an array in C uses simple syntax: arr[5] = 10;
But with NSArrays, etc., we have to add lots of explicit method calls with lots of named arguments, destroying the clear and simple syntax meant to express use of an array in C.
The nice thing about C++ is that you can fix that by overloading operators so that a vector can use the same simple syntax most of the time. You can do this for any objects for which it makes sense... And it vastly improves the ease of coding and reading code.
In objective c, you simply can't improve it. Tons of operations with containers and objects are unnecessarily syntactically unwieldy. Higher level languages like Ruby do this as well, but C++ is fast and explicit. If you want to know what the operator is doing, you can step into it. You can read the code...
I've seen quite a few examples since yesterday where the code given was not fewer in line count or even easier to read (partly subjective), but was simply more approachable and familiar to people who are already set on writing Ruby instead of ObjC.
If you know ruby very well you may get a head start here without having to learn ObjC (yet, i'll be shocked if you dont hit walls with this plan), but the mountain of work for you is learning the frameworks, and learning them without the benefit of 90% of the examples and help available specifically for ObjC.
And what of working with the parts of Apple's platforms that aren't Objective-C in the first place, like all the CoreFoundation stuff which is C. At some point you're going to hit walls that could be easily solved by dashing your code with a few lines of C or dropping in an example you found on stackoverflow, but now you've got to come up with the Ruby equivalent and you're actually juggling a new set of issues whether it seems that way or not. Maybe the time you save writing most of an App in ruby makes up for it, but I'd be surprised if thats the case in practice.
"Why do I have to have huge statements like this?
static UIColor firstColor = nil;
static UIColor secondColor = nil;
static UIColor thirdColor = nil;
static UIColor fourthColor = nil;
static UIColor fifthColor = nil;
static UIColor sixthColor = nil; "
Great, so someone who doesn't know how to use arrays is criticizing Objective-C as a language.
To everyone claiming that Objective-C's syntax is unintuitive/unwieldly/etc: remember that familiar != intuitive.
My two darling languages are Python and Haskell and I learned programming in C/assembly, and I find Objective C + Cocoa Touch quite nice, especially since ARC was introduced. Yes, there are things that can be slightly bothering, but once you pass the initial "wow this syntax is weird" hurdle, you're good to go.
It's great to have Ruby as an alternative, but all that Objective-C hating is silly and quite unproductive. Yes, there are limitations in the iOS dev stack (mostly with XCode— but hey, it's not that bad, people have gotten good things done with Eclipse and it doesn't exactly have a perfect track record either). But if the only thing that's getting in your way of developing a great application is the fact that Objective C's syntax makes you uneasy, then you should probably reconsider your abilities as an engineer.
As usual, the ones doing great things done probably won't be the ones tweeting & blogging about how Objective-C is lame and that if only $(arbitrary language) could be used for iPhone dev, then they would change the world.
I think the author has a valid point though, even though that example doesn't illustrate it well. He should have used variable names that didn't immediately cry out for arrayification, but there is a boilerplate problem in Objective C.
The thing is, a lot of the verbosity of Objective C is actually a win. Take the messaging syntax: beautiful and readable. And the lack of first-class syntax for almost anything? Usually pretty nice and elegant. Nothing feels magic.
But you don't get a choice about these ideals. Need optional arguments? Too bad. Use a config dictionary. And there's no literal syntax for dictionaries, so every time somebody calls your method, it's going to be a big pile of boilerplate.
I don't even think Objective-C should compromise on all of these ideals, but it should compromise on some, and I think that kind of basic functionality would have been a better point of focus than foreach loops and dot-notation.
Since they don't, people are tempted to use CPP macros to work around these shortcomings. You may remember CPP macros from every GDB nightmare you've ever had.
So if you think that Ruby is providing you with a significant shortcut here you're in for some disappointment.
I worked for a company doing Mac apps in REALbasic for several years, and this was a constant hassle. Additionally, RB chose the wrong backend for their compiler (Carbon instead of Cocoa) and there were multiple years of setbacks due to Apple hemming and hawing about whether they were going to deprecate Carbon altogether and RB porting their entire framework to Cocoa. During that process, everybody who emigrated to Objective-C got their stuff to market sooner, and with access to newer libraries to boot.
In the same vein that allowing Flash and C# toolkits above Cocoa Touch would slow the adoption new features (http://daringfireball.net/2010/04/why_apple_changed_section_...).
The second is the way in which complex applications are built. Some programming languages are known for having many design patterns around them, which often feel artificial. Objective-C and the Cocoa libraries use only a handful of them, but they come very natural.
Not the best researched sentence. Much of this is possible in RubyMotion because of Objective-C's metaprogramming and reflection and other powerful features. This makes me suspect the author's depth of knowledge of Objective-C. That said, he's right that Objective-C has a lot more syntactic noise than more recent languages like Ruby and Python.