Rubymotion – Myth, Magic, or The Future?(bostonrb.org)
bostonrb.org
Rubymotion – Myth, Magic, or The Future?
http://bostonrb.org/presentations/rubymotion-%E2%80%93-myth-magic-or-the-future
8 comments
I don't hate objective c / XCode nearly enough to pursue a solution like this even though I like and appreciate ruby. In my opinion the only way this would be the future is if apple started providing support for it.
I agree also. I primarily work in Ruby but was pleasantly surprised with the updates for iOS 5. ARC support and the addition of storyboards really helped with the parts I disliked working with.
The only issue is that I would prefer to work with another editor. XCode just doesn't have some of the editor features I am used to with other IDEs.
The only issue is that I would prefer to work with another editor. XCode just doesn't have some of the editor features I am used to with other IDEs.
Totally agree. That said, Rubymotion is pretty sweet as when I play around with it, I'm just reminded of why I love Ruby in general. I like Obj-c too, but I love Ruby.
Oddly, I didn't run away from Objective-C and Xcode screaming. But I have run screaming away from Ruby on Rails a number of times. I do acknowledge that this is likely a personal shortcoming though.
I haven't used RubyMotion, but Rails isn't really the best introduction to Ruby. Ruby gives you the ability to fairly easily create a lot of magic, but for just writing a Ruby program outside of Rails you can still certainly do things in a quite straightforward way where it's very clear what's doing what and why things are getting called. There's some really nice syntatic sugar and functional features that are, to my mind at least, much less "write only" than Perl's while giving you a bit more of that more-than-one-way-to-do-it flexibility than Python.
Ruby is cool. REPLs are cool. Objective-C is slightly weird. Interface builder is kind of nice. XCode is weird, but has some fairly great features for Objective-C/Cocoa.
But Cocoa is the thing you have to learn no matter what. To be honest, all things considered I would rather put up with Objective-C than lose Interface Builder and the niceties of XCode.
And I say that even though I have used and love PyQt. Cocoa is so deeply married with Objective-C and XCode, I can't really see the point of using RubyMotion.
But Cocoa is the thing you have to learn no matter what. To be honest, all things considered I would rather put up with Objective-C than lose Interface Builder and the niceties of XCode.
And I say that even though I have used and love PyQt. Cocoa is so deeply married with Objective-C and XCode, I can't really see the point of using RubyMotion.
[deleted]
You don't strictly have to lose interface builder to use RubyMotion, you can use XIBs with Motion, but [for now] addressing elements in the XIB requires a little bit of ugly manual mapping of the numerical XIB element ids to names you want to give them in Motion.
Disclaimer: I've not built anything extensive with Rubymotion/IB, but I have built a proof of concept. I don't know if it's really feasible on a large project.
Also, Obj-C and Ruby share many common concepts, using Cocoa from RubyMotion usually requires just a bit of syntax swapping, "vanilla" RubyMotion is not much of an abstraction.
Disclaimer: I've not built anything extensive with Rubymotion/IB, but I have built a proof of concept. I don't know if it's really feasible on a large project.
Also, Obj-C and Ruby share many common concepts, using Cocoa from RubyMotion usually requires just a bit of syntax swapping, "vanilla" RubyMotion is not much of an abstraction.
This fear of learning a new tool, language or API boggles my mind.
The insight alone from seeing a new corner of the programming world is worth biting the bullet and learning something new.
The insight alone from seeing a new corner of the programming world is worth biting the bullet and learning something new.
I think your comment is great, and equally applies to experienced Objective-C developers who could miss something interesting here :)
Good point, although, an experienced Objective-C developer can already write iOS apps - learning Ruby in the context of backend development would probably be more beneficial. It'd be like asking Michael Jordan to play basketball left-handed instead of playing baseball.
Former .Net/Java developers were already able to write backend apps before Rails started growing, yet there was a fairly large exodus at some point.
Similarly, I'm making the quick bet that we will see a interesting number of experienced Obj-C developers move to RubyMotion! (well, as someone who is on the RubyMotion list, I can tell some have already started).
Similarly, I'm making the quick bet that we will see a interesting number of experienced Obj-C developers move to RubyMotion! (well, as someone who is on the RubyMotion list, I can tell some have already started).
I think one of the most interesting points about the presentation is the BubbleWrap libraries. The greatest pain I've felt with iOS development are some of the terrible APIs. The amount of ceremony needed to Parse JSON from a web based API request or to access the camera is almost absurd.
Well, here are two short snippets on how to do that. It is incredibly easy. (Sorry, I couldn't find a better paste it host.)
http://paste.org/53022
http://paste.org/53022
Alternately, here's BubbleWrap on camera: https://github.com/rubymotion/BubbleWrap#camera
on JSON: https://github.com/rubymotion/BubbleWrap#json
on JSON: https://github.com/rubymotion/BubbleWrap#json
[deleted]
Try gist:
https://gist.github.com/3374114
Storyboards are just XML. I wonder if it'd be possible to write an HTML/JS-based Storyboard builder and viewer? I wonder if it'd be possible to somehow get the iOS emulator software working "in the cloud", similar to how maybe browserling.com does their VNC-ish stuff? Wish these two things in place, I don't think it'd be too outlandish to be able to replace xcode with a more Linux SSH-based workflow for iOS dev, in the same vein as cloud9 IDE or something. I personally know that I'd love to get back to working from my Windows machine and just editing my code with Eclipse over SFTP, with my code on my linux vps. I have not turned on my $2000 Windows gaming rig in like a month since I started getting into iphone dev. :(
This actually tracks w/ my experiences using MacRuby.
The REPL is kind of cool, but then he doesn't remember how to set the label text. There's no statement completion or help for him in the console, so he gives up. He's stuck. He'll spend way more time reading docs and figuring out Cocoa method sigs than just learning the XCode toolset and discovering methods in the editor.
That said, overall it's a good talk and I applaud his efforts at explaining the tool - I just think it's not clear RubyMotion is a net positive in terms of productivity.
The REPL is kind of cool, but then he doesn't remember how to set the label text. There's no statement completion or help for him in the console, so he gives up. He's stuck. He'll spend way more time reading docs and figuring out Cocoa method sigs than just learning the XCode toolset and discovering methods in the editor.
That said, overall it's a good talk and I applaud his efforts at explaining the tool - I just think it's not clear RubyMotion is a net positive in terms of productivity.
I refuse to hammer this nail with a hammer. I will use a screwdriver. I will go through great difficulties if need be, so that I can keep on using a screwdriver.
Are you saying use the right tool for the problem, or that there is only one tool per problem?
If you are saying the former, I agree entirely. If you are claiming the secondary, than I have to ask what do you think the purpose of a language like Lua is? Why do programmers like using Lua in combination with their c/c++ projects?
If you are saying the former, I agree entirely. If you are claiming the secondary, than I have to ask what do you think the purpose of a language like Lua is? Why do programmers like using Lua in combination with their c/c++ projects?
The challenge isn't Xcode or Objective-C but rather the Cocoa Touch API. At the end of the day you still need to contend with the API, no matter which framework you use.
This isn't about avoiding a challenge but about the comfort of using a modern language. Objective C still has you writing headers files for heaven's sake.