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
11–20 of 250 posts
Re: RubyMotion - Ruby for iOS
#12I 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.
There are already exclusive libraries for MRI/JRuby, so adding a third platform doesn't seem like it would break the world. Tools like Bundler do a great job of keeping things moving smoothly.
Re: RubyMotion - Ruby for iOS
#13nice, 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 write code in both Ruby and Objective C pretty regularly, but man oh man is my Ruby code SO MUCH shorter and cleaner in a lot of respects. A lot of the Objective-C API's are just terribly terribly verbose. My favorite one to whine about is NSTask; it shouldn't take me 10 lines of code to spawn a simple external process. :P
For me, I prefer working in Ruby. Some people don't. But I think this will probably spurn me to get more serious about writing more iPhone apps, and it should open the door for a few more people who work on Ruby-based apps to write their own simple iPhone apps rather than paying a consultant to do it for them.
Re: RubyMotion - Ruby for iOS
#14nice, 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.
Having been part of the private beta I can tell you that it's a huge time saver. Objective-C is nice be ruby is much more expressive, you can use the same API with much less code, you can skip XCode altogether and use your favorite editor, ... I can't express properly how awesome it is, really.
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.
Re: RubyMotion - Ruby for iOS
#15Cool free 50 min video on RubyMotion -
Re: RubyMotion - Ruby for iOS
#16missing trial period so i'd rather wait for mobiruby
Re: RubyMotion - Ruby for iOS
#17This is huge from a programmer productivity perspective.
Re: RubyMotion - Ruby for iOS
#18I 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
#19Will apps created using this have any problems getting approved with App Store?
Re: RubyMotion - Ruby for iOS
#20Earlier quoted context omitted.
Having been part of the private beta I can tell you that it's a huge time saver. Objective-C is nice be ruby is much more expressive, you can use the same API with much less code, you can skip XCode altogether and use your favorite editor, ... I can't express properly how awesome it is, really.
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 having something that looks like Objective-C?