Adventures in RubyMotion, Part 2

Another couple of days have passed since I finally got around to trying RubyMotion. I’m still excited – even more than I was three days ago, actually. This is clearly a love affair, much to the surprise of some of my peers (“It’s just Ruby instead of ObjC, what’s the big deal?”) and, naturally, my own, since I haven’t been this excited about a piece of technology since good old Rails clicked with me back in the days.

Something you should know about Ruby, and Rubyists

When I introduce myself to a new group of students, I always mention that I haven’t really done much else besides Ruby (and Rails) development since late 2005, and I never forget to include a hint of sarcasm in there, since it also means I more or less missed most of what was happening outside of Ruby for the last 7-8 years – which is really kind of sad. Even though I used to do heaps of non-Ruby development, I know practically nothing about how Java, .NET, Python or PHP work in 2013, let alone ObjectiveC and iOS development.

On the other hand, focusing on this one technology, Ruby, allowed me to gain a satisfyingly deep understanding of it, as following its developments over so many years also helped me understand why things are the way they are. Ruby, obviously, is not “the perfect language”, if such a thing even exists. It is, however, a beautiful language; not because it has a beautiful syntax – I believe it has, but that’s not the point – but because it encourages the developer to write beautiful code. Granted, beauty is a very vague attribute for something as technical as a programming language, not least since it probably means something else to different people. Here’s my attempt at a definition: beautiful code is code that you enjoy changing.¹

Have you ever had one of those “ugh, I never want to spend any time in this piece of code again” moments? Ruby goes a long to help you prevent those. Its weapons of choice mostly consist of metaprogramming features that allow you to build Domain Specific Languages; pieces of syntax that allow you to solve a specific problem in a concise and simple fashion, wrapping around the more complex implementational details. (This, of course, is one of the reasons why Rails is so popular, in case you’ve been wondering.)

You’d be absolutely correct to argue that this is also possible to do in other languages, sometimes more, sometimes less so, including ObjectiveC, so let me talk about Ruby’s most important feature: its community. Rubyists, for better or worse, are different from Java, PHP, Perl or ObjectiveC developers. Feel free to be snide and call them hipsters, accuse them of ignoring decades of computer science, or ridicule them for favoring such vague entities as “beauty” or “happiness” over attributes like performance or stability; that’s perfectly alright. In the end, for true Rubyists, choosing this language is merely a consequence of making a particular set of lifestyle, not technological choices, and one of them is to simply be okay with having to catch a lot of flak, sacrificing a bit of performance in favor of easier to maintain code, or waking up to disasters (right?) like the recently discovered YAML deserialization vulnerability. It may not be your cup of tea, but that’s okay – it’s still a tasty fucking tea.

What does all this mean for RubyMotion? At first glance, RubyMotion’s core proposition is to simply replace the supposedly ugly ObjectiveC with the supposedly beautiful Ruby.

But it goes so much deeper than that. RubyMotion opens up iOS development to Rubyists, a lot of whom so far had trouble thinking their way into the world of ObjectiveC and Cocoa Touch, not because of ObjectiveC itself, but because of they way people would work with it. RubyMotion isn’t even a year old, and the effect of bringing Ruby thinking into the world of iOS already shows in the type of RubyMotion specific gems available; just check out Formotion as an example.

And this is why I’m so excited about RubyMotion. I don’t mind ObjectiveC; but I simply love using (and more so, building) Ruby DSLs. I love seeing what kind of abstractions other people come up with. I love improving on them, or coming up with my own.

I love it when things are easy, and I love being able to make them so.

A couple of bumps in the road

This ride is a fun, but not perfectly smooth one. There’s a couple of observations I’ve made regarding RubyMotion that took me by surprise. Nothing major, just stuff that I’m sure can be improved on over the next couple of months (or years).

First of all, RubyMotion buzz within the Ruby community appears to be pretty low. This is probably the biggest surprise of them all, and I can’t really think of another reason than RubyMotion not being available as a free trial (let alone being open-source). I’ve been perfectly happy about the $199 purchase just for the learning experience alone, but I can perfectly understand anyone who’s not willing to shell out that kind of money just to give RubyMotion a try. I firmly believe there needs to be a free version at some point.

A lot of the people working with RubyMotion today don’t seem to come from a strong Ruby background, as a lot of the code I’ve seen (both in sample projects as well as in the gems available) simply isn’t very idiomatic Ruby. Please don’t misunderstand that as a diss of some sort; I love most of what I’ve seen, and there’s nothing inherently wrong with any of it per se – I was merely expecting the RubyMotion community to consist primarily of hardcore Rubyists, which doesn’t appear to be the case. In the end, diversity is great, and it’s just one big learning experience for everyone involved anyway, so all is good.

Still, the RubyMotion community badly needs to embrace some of the more fundamental things we’ve learned in Ruby land over the last couple of years. There seems to be a slightly awkward focus on general-purpose, kitchen-sink libraries like BubbleWrap; what BubbleWrap does is great, but I wouldn’t be the first or only developer to prefer a selection of smaller gems focused on individual pieces of functionality. Also, a lot of the gems available don’t include tests, which is a surprise since RubyMotion not only allows for, but actively encourages testing (using an RSpec-style dialect). Finally, there appears to be a lingering dislike for Bundler. With all those RubyMotion gems popping up, correct dependency management is important; Bundler takes care of this beautifully, and if you’re working with RubyMotion, you should use it. To my surprise, an earlier version of RubyMotion actually generated new apps with Bundler support included, resulting in some sort of community outcry followed by a quick removal of the feature in the following version. Hm.

Haters gonna hate

Another thing that I’ve observed is how large parts of the supposedly “true” Apple development community appear to feel a significant amount of hate for RubyMotion, claiming it will “bring those Rails people” to iOS and similar cute little disses; just read the discussions in any HackerNews story on RubyMotion to see what I mean.

Obviously, someone who’s been creating software for a bunch of decades, having spent years on refining their skills, will watch a technology that “makes things easier” with caution (or worse); the same thing happened with Rails (and J2EE) back in 2005-2007, and it wasn’t a whole lot of fun.

Admittedly, they wouldn’t even be wrong to do so; technologies like Rails (and possibly RubyMotion, too) are prone to make or encourage certain shortcuts that, for a lot of people, will lead to leaky abstractions, in code, knowledge, or both. Someone who knows how things are working under the hood will always be the better developer than someone who doesn’t.

However, the important question is: how deep does your knowledge have to be in order to write certain applications? If you can build a compiler, you’re probably a better developer than someone who doesn’t. But look at Rails; do you need to be able to build a compiler in order to build web applications? Probably not. Granted, building an iOS application is significantly more complex than building a web application, but you’d be wrong to claim that everybody should be a computer scientist to at least have a shot at it.

The bottom line here is: there’s always someone smarter than you, which shouldn’t stop you from building what you want to build. Even if things go horribly wrong and your code makes your iPhone catch fire, it will at least work as a learning experience. Chances are things aren’t going to go that bad, anyway.

Moving forward

While experimenting with RubyMotion, I ended up creating two apps, one being a test bed for all things Cocoa Touch, allowing me to try the various RubyMotion gems available; the other one bypasses most of Cocoa Touch in favor of Cocos2D. I haven’t found any noteworthy RubyMotion gems wrapping around Cocos2D yet, so maybe I’ll whip one up, just as an exercise. I’ll keep you posted.

What can I say? This is fun. :)