> Rubyists get a lot of flak for the kind of DSLs and black magic method_missing tricks the above libraries use; but you know what, maybe that attitude is just what Objective-C has been missing.
I politely disagree. Objective-C hasn't been missing risky and error-prone approaches that merely attempt to save a few characters at the cost of correctness. Extensions like 'when' are vague, and could just as easily be co-opted for KVO as they could for UIControl event handling.
Also, the example is not accurate. In Objective-C, you'd control-drag from the button to your action method, using Interface Builder.
I think the value add of a `when` style isn't saving keystrokes but improving readability. What happens when the event fires is right there in-line with the button, not somewhere else on the page. Yeah there are editor tricks to command+click to it and such, but that's still some overhead.
TBH I think it really is a matter of preference at this point. There could be a killer, must-use RubyMotion framework in the future, but for now I simply feel more productive and flexible in Ruby.
In fact, the most impactful change of RubyMotion (and I somehow neglected this when I wrote it) is testing. It ships with a really powerful port of Bacon which is lightyears better than UIAutomation, KIF, and every other iOS testing framework I've tried. `rake spec` is a seamless, regular part of my workflow in a way that Xcode failed to achieve.
> I think the value add of a `when` style isn't saving keystrokes but improving readability. What happens when the event fires is right there in-line with the button, not somewhere else on the page. Yeah there are editor tricks to command+click to it and such, but that's still some overhead.
With Interface Builder, there is no "right there in-line with the button", because the button (and the entire remainder of the layout) is instantiated and fully laid out in a nice WYSIWYG editor.
That said, as the you noted, you can do this in Objective-C. However, due to the propensity for conflicts, it's bad form to insert un-prefixed category methods into system classes.
This is an appeal to emotion, but I must be honest: I'm concerned about the day that I'm asked to take over maintenance of a Ruby Motion project, especially if it's likely to diverge significantly and arbitrarily from our community's existing best practices.
Risky, error-prone and not correct? If you're going to throw out that kind of slander, you ought to back it up or it's just FUD. People used to say the same thing about Cocoa's "black magic" like the responder chain, undo support and Interface Builder. I didn't buy it from them then, and I don't buy this now.
" If you've tried projects in Ruby and just didn't like it, RubyMotion probably won't change your mind. But if you've ever wanted to make iOS or Mac apps but didn't want to get over the hump that is Objective-C, maybe this will get you going."
Can RubyMotion itself be used to create Mac apps in addition to iOS apps?
Sorry, should have specified! As jballanc said, I was referring to MacRuby (http://macruby.org/). I'll add a link there for clarification.
RM and MR are both by Laurent Sansonetti, and the experience developing for them is identical. The Ruby code is just as portable as Objective-C between iOS and OS X. I'm working on something right now which uses both technologies and it's been a great experience.
Of course it's a shame that Laurent needs to eat and of course this has everything to do about RM being able to build for Mac or not. Knowing him, I know he would prefer RM to be open source but it would be much harder for him to monetize his efforts.
I'm perfectly ok with paying a fee to get RM but I know that wouldn't pay for support (especially if the community handles it which is already the case).
Corporate sponsorship doesn't always works and often lacks security and stability for both the developer and the project as they are at the mercy of one entity.
There is still a lot that you can do to contribute back to the project. Much of the build system and various supporting libraries have been open-sourced. Furthermore, it is the stated goal of RubyMotion that development of higher-level abstraction libraries should be driven by the community.
I suspect that the number of people who would actually be interested in (or, indeed, even capable of) contributing back to the parts of RubyMotion that are closed source is rather small.
Probably true. But as an amateur developer, I'd like to try it out... yet I'm not in a spot where I can just drop $200 to see if I like something or not.
Besides the obvious difference of target platforms, the biggest difference you'll run into IMO is that MacRuby is a full Ruby 1.9 implementation on top of Objective-C, whereas RubyMotion is more of a dialect of Ruby. i.e. eval doesn't exist in RubyMotion, you can't require gems at runtime, can't use MiniTest or RSpec, etc.
He actually left Apple to launch RubyMotion -- a commercial product, by the way -- after creating MacRuby and developing/maintaining it for several years.
iOS development is not only objective-c and Cocoa Touch. XCode, interface builder, instruments are also big helpers and sometimes there can be memory problems that you can only trace with instrument.
Definitely. I know RubyMotion currently supports XIBs and Storyboards, but yeah there's no integrated solution with Xcode or Instruments right now. I personally like the Rake-based approach, its more lightweight than booting up an IDE, but I would bet that better Xcode support is possible since MacRuby already does it pretty well.
That's if you like using interface builder. I personally dislike it and prefer to lay things out programmatically, but this probably has to do with the fact that I came to iOS development from the web development world.
I also try to not use IB most of the time, but especially if you are building not so custom designs, IB really increase the productivity and keep the code clean.
It's because of a media query that responds to wider window sizes, strange that it didn't register in all your browsers (it does on my Safari when I fullscreen)
It's supposed to help readability while maximizing screen use in those cases (instead of either stretching out paragraphs to two lines or centering the body as to take up only a small percentage of the window). I'll change it to trigger on a wider dimension, sorry!
Aha, that would explain it. I almost never use Safari so its natural size is likely somewhat thinner than my day to day browser :-) I was just over your ~1300ish pixel width.
I politely disagree. Objective-C hasn't been missing risky and error-prone approaches that merely attempt to save a few characters at the cost of correctness. Extensions like 'when' are vague, and could just as easily be co-opted for KVO as they could for UIControl event handling.
Also, the example is not accurate. In Objective-C, you'd control-drag from the button to your action method, using Interface Builder.