nice, but where is the advantage over just using objc? the hard part of coding for iOS isn't objc, it's learning how to use all the API's.
I agree, but many young developers have C phobia and somehow seem not to be able to grasp C based languages.
RubyMotion - Ruby for iOS
31–40 of 250 posts
Re: RubyMotion - Ruby for iOS
#32The problem with Rubyists (being one for the past 6 years I feel qualified to say this) is in general they want to use Ruby for everything. It's not always the best tool for the job.
Re: RubyMotion - Ruby for iOS
#33I've played around with what seems like ever alternative framework under the sun (Titanium, Rhodes, PhoneGap, MonoTouch, Corona) and have been pretty frustrated with how clunky they usually feel. However with everything its claiming and the decent price point I'm toying with purchasing site unseen...just wish I could try it for a few hours first.
1) http://arstechnica.com/business/news/2012/05/exclusive-build... (Review with code)
2) http://pragmaticstudio.com/screencasts/rubymotion (Screencast)
Re: RubyMotion - Ruby for iOS
#34Earlier quoted context omitted.
I agree, but many young developers have C phobia and somehow seem not to be able to grasp C based languages.
Or they've been spoiled by certain language features and it seems unbearable to go backwards.
I hope for the day when we have better and more type safe languages for system programming.
Most attempts so far, Modula-* family, Ada, Oberon and so on, failed to catch on, to my dismay.
Still it does not hurt to know some C.
Re: RubyMotion - Ruby for iOS
#35I could see this really taking off. My worry is that it would take off so well that the ruby gem community could get fragmented into libraries for RubyMotion and libraries for regular ruby projects.
I'm supposing that they will probably implement it as another platform option like you can do right now for JRuby/Windows/etc. It shouldn't affect much. I haven't looked at the documentation, though, so I can't say for sure.
Re: RubyMotion - Ruby for iOS
#36Re: RubyMotion - Ruby for iOS
#37Will apps created using this have any problems getting approved with App Store?
No. From the FAQ ( http://www.rubymotion.com/support/#faq ): "Applications submitted to the App Store must conform to the Review Guidelines dictated by Apple. RubyMotion implements a dialect of Ruby that conforms to those rules. RubyMotion apps are fully compiled, do not download or interpret code and are using public iOS APIs through the exact same machinery as regular Objective-C apps."
Re: RubyMotion - Ruby for iOS
#38Earlier quoted context omitted.
I agree, but many young developers have C phobia and somehow seem not to be able to grasp C based languages.
I like C but have Obj-C-aversion because "high level" languages that still need header files all over the place just ain't right.
Header files are so 70's.
Re: RubyMotion - Ruby for iOS
#39Earlier quoted context omitted.
The call syntax is still painful compared to straight Objective-C as it actually uses more characters and is not as clean. I really wish he had come up with something that resembled Objective-C better.
I may have missed something but API calls looks like a regular Ruby call with a hash and since all [] are dropped it's systematically shorter (not even counting the fact that you don't have .h/.m, declaration/implementation, it's not just a matter of API calls). i.e. [obj method: param second: param2]; vs obj.method(param, second: param2) which is exactly two characters shorter in ruby. And what would be the point of…
UIColor.colorWithRed(red/100.0, green:green/100.0, blue:blue/100.0, alpha:1.0)
vs [UIColor colorWithRed:red/100.0 green:green/100.0 blue:blue/100.0 alpha:1.0];
>And what would be the point of having something that looks like Objective-C?Because the name of the function is not colorWithRed(), it is colorWithRed:blue:green:alpha:.
Re: RubyMotion - Ruby for iOS
#40This looks promising but at the same time I really wish the backend compiler was open sourced and worked on Mac and not just iOS.