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.)
Why RubyMotion Is Better Than Objective-C
21–30 of 70 posts
Re: Why RubyMotion Is Better Than Objective-C
#22I'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.
Re: Why RubyMotion Is Better Than Objective-C
#23>>>Don’t get me wrong, Objective-C is better than C or C++, but I don’t think that’s saying a whole lot.
Objective-C better than C++? Wow, has this person ever used Objective-C and C++?
Re: Why RubyMotion Is Better Than Objective-C
#24The 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.
Re: Why RubyMotion Is Better Than Objective-C
#25This 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 replacin…
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.
Re: Why RubyMotion Is Better Than Objective-C
#26Get back to us when you've written a significant application in either Objective C, or RubyMotion.
Re: Why RubyMotion Is Better Than Objective-C
#27- 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 evolvin…
All of these points are subjective, why are you trying to argue against them?..
Re: Why RubyMotion Is Better Than Objective-C
#28> 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…
> 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?
Re: Why RubyMotion Is Better Than Objective-C
#29This 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 replacin…
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.
Is it true that those are only available in 10.8? It thought they just compiled to +[NSArray arrayWithObjects:count] calls, which would work anywhere.
Re: Why RubyMotion Is Better Than Objective-C
#30Earlier quoted context omitted.
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 wit…
To me, Y appearing repellently complicated means:
"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.