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…
Why RubyMotion Is Better Than Objective-C
11–20 of 70 posts
Re: Why RubyMotion Is Better Than Objective-C
#12Get some real iOS development under your belt before you make these broad assumptions.
Re: Why RubyMotion Is Better Than Objective-C
#13Re: Why RubyMotion Is Better Than Objective-C
#14Re: Why RubyMotion Is Better Than Objective-C
#15Re: Why RubyMotion Is Better Than Objective-C
#16- 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
#17Not 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…
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
#18Ramblings 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.
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
#19It 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
#20Uh, 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.