Live data from Hacker News

Why RubyMotion Is Better Than Objective-C

joshsymonds.com

11–20 of 70 posts

Re: Why RubyMotion Is Better Than Objective-C

#11
post #3

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 c…

[deleted]

Re: Why RubyMotion Is Better Than Objective-C

#12
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.

Re: Why RubyMotion Is Better Than Objective-C

#16
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.

Re: Why RubyMotion Is Better Than Objective-C

#17
post #3

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 c…

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.

Re: Why RubyMotion Is Better Than Objective-C

#18

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.

Re: Why RubyMotion Is Better Than Objective-C

#19
- Objective-C is Hard to Use

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.

Re: Why RubyMotion Is Better Than Objective-C

#20
> 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

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.

Post reply on HN