Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Mruby and MobiRuby (aimonetti.net)
65 points by EzGraphs on April 20, 2012 | hide | past | favorite | 13 comments


If you want to learn how to develop iOS apps, then you should learn Objective C. I'm a Ruby developer and as much as I love the language, when I decided I also wanted to write iOS apps I bit the bullet and started learning Objective C. In the process I've found that learning Objective C is actually pretty easy - as the author of this post points out, it's CocoaTouch and the overall Xcode and iOS ecosystem and environment that takes time to learn.

This is fairly analogous to learning Ruby on Rails if you know neither Ruby nor Rails, although because I had experience with curly-brace/semicolon languages and pointers (a bit of C, plus PHP and Javascript) I found that learning Objective C was easier for me than learning Ruby. But just like Rails is a steep mountain to climb, so is CocoaTouch.

However, learning Objective C and CocoaTouch has been fun, enjoyable, enlightening, and well worth it. As the old saying goes, if something is worth doing, it is worth doing right. If you believe developing iOS apps is worth doing, then do it right with Objective C. You won't regret it, and by adding another language, framework, and way of doing things to your toolbelt, you'll become a better Ruby programmer too.


A quick look at the MobiRuby example code worries me. It looks like Objective-C, but awkwardly written using Ruby syntax. In other words, it looks more like an Objective-C wrapper, than a Ruby DSL for writing iPhone apps.

However, with plans to port the system to Android, perhaps a unified DSL could be built to target both platforms.


If you look at MacRuby, it actually takes a very similar approach. You need something like HotCocoa on top to make it more Ruby like.


There's a larger point in this post about using frameworks with the language they were designed for. Using another language to wrap a language you don't like to use a framework is often extremely limiting and awkward.

As a developer trying to get things done, I'm far more productive if I bite the bullet and learn the language the framework was designed for rather than bend the framework to fit my favorite language. I've found this to be true across mobile, web and pure backend server technologies.


What is the language that you write in that doesn't "wrap another language"? I always find it amazing that it's possible to get programmers to argue against not just some specific abstraction, but abstraction as a general principle. What do you think programming is exactly, if not layers and layers of abstractions?

[edit: that's not to say I think the MobiRuby syntax is looking very good at the moment, but don't toss the baby with the bathwater]


It's not the wrapping of the language that is the issue. Unless you're writing bytecode by hand, every programer deals with some abstraction.

The issue is wrapping a language with a higher level abstraction, but then proceeding to use your abstraction with a framework designed for the lower language. In the case of the post, the author mentions using MacRuby/mRuby to Objective-C, but then proceeding to use it with Cocoa, which is really designed specifically for Objective-C. Using it with Ruby just ends up being awkward and unwieldy.



As long as you can still reach the APIs you need 100% of the time, there's nothing wrong with the abstraction. Ruby is a huge timesaver over Objective-C... this is obvious in the syntax. The ability to create apps that run on anything but are 100% written in Ruby will be a huge step forward for the language. So that's why I think it is Matz working on this.


I see a great future for this - hopefully will get more users hacking on embedded devices with Ruby codes (ruby + Arduinio or even Routers - e.g. OpenWRT).

Quick glance in the Make file, sees runtime libraries for Win/gcc/iOS - should be able to build an arm exe easily.


Very interesting post. It hints are some serious architectural differences between MacRuby and MobiRuby. It'll be interesting to see if these differences limit the ability of MobiRuby to create a usable way to work with Cocoa in ruby.


All fair points that I agree with. Mruby is promising but it's still in its infancy. Whereas MobiRuby is interesting on its own, but lacking advantages over Obj-C for real development.


I'd be very interested to see what this "incremental garbage collection" Matz talks about does to battery life.

Also, what's up with all the underscore methods in MobiRuby?


I want to see redis with mruby scripting instead of or also with Lua scripting, one day.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: