Mar

29

Why MacRuby Matters (Present & Future)

Filed Under Cocoa and Objective-C, Mac, Ruby | 44 Comments

HotCocoa::Graphics example Over the years the inadequacy of Ruby’s main implementation has led to the creation of several alternatives. The greatest common divisor between these is an attempt to improve the performance of Ruby, both in terms of time and space. But every Ruby implementation has another, deeper reason for being. For example, Ruby 1.9.1 is a refactoring of the language that provides the chance to incorporate several much needed features into a relatively fast virtual machine, whereas JRuby’s truest value lies in its ability to interact with the Java ecosystem. Likewise IronRuby (which is admittedly at an earlier stage in its development) is attempting to plug a dynamic language like Ruby into the .NET world (as per its predecessor IronPython).

While MacRuby is a younger, lesser known implementation, it has the potential to become a game changer - at least for Mac developers. Based on Ruby 1.9, MacRuby’s main aim is to provide programmers with the ability to write Mac OS X applications in Ruby, making Ruby a first class Cocoa programming language. In what may sound like an utopistic effort, MacRuby strives to provide the high level abstractions, power and syntax sugar of Ruby, without the characteristic performance hit of its main implementation.

Rather than relying on a mix of Objective-C and Ruby (through a bridge like RubyCocoa), developers can use MacRuby which integrates with Mac OS X core technologies and acts as an alternative language to Objective-C. To be exact, Objective-C’s runtime and generational garbage collector are at the heart of MacRuby, but from an API standpoint, programmers can write code in Ruby, instead of in the more verbose and low level Objective-C. MacRuby maintains the ability to integrate with Objective-C code, but doing so is often unnecessary thanks to a framework known as HotCocoa, which is a Ruby wrapper around the Cocoa API.

MacRuby applications end up being succinct, easy to write and straightforward to maintain. Their look and feel is exactly the same as those of applications written in Objective-C, because they are actually native Cocoa applications. In fact, MacRuby objects are Objective-C objects which use Core Foundation data types and services. The current version, MacRuby 0.4, even allows you to package applications as self-contained .app, without having to redistribute MacRuby itself.

Sponsored and developed by Apple, MacRuby 0.4 is a stable release that can be - and already is - used to write desktop applications. But MacRuby’s real promise lies in its experimental branch. This rewrite will become MacRuby 0.5, as announced by the MacRuby team earlier today (along with a new, nice looking site). This future version of MacRuby is freakishly fast and uses the LLVM to generate code for the Objective-C runtime. The layer composed of LLVM, ObjC Runtime, Generational Garbage Collector and Core Foundation make this specific Mac OS X release possible. To this layer, add in Ruby 1.9’s AST parser and Standard Library, and you get MacRuby 0.5 as it stands today. In the future it’s likely that applications built with MacRuby will be compiled into binary code, like Objective-C ones, thus removing the issue of protecting one’s source code in commercial applications.

To really understand the value of MacRuby, consider the following Hello World program that uses RubyCocoa:

require 'osx/cocoa'; include OSX

app = NSApplication.sharedApplication

win = NSWindow.alloc.initWithContentRect_styleMask_backing_defer(
    [0, 0, 200, 60],
    NSTitledWindowMask|NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask,
    NSBackingStoreBuffered, false)
win.title = 'Hello World'

button = NSButton.alloc.initWithFrame(NSZeroRect)
win.contentView.addSubview(button)
button.bezelStyle = NSRoundedBezelStyle
button.title = 'Hello!'
button.sizeToFit
button.frameOrigin = NSMakePoint((win.contentView.frameSize.width / 2.0) - (button.frameSize.width / 2.0),
                                 (win.contentView.frameSize.height / 2.0) - (button.frameSize.height / 2.0))

button_controller = Object.new

def button_controller.sayHello(sender)
 puts "Hello World!"
end

button.target = button_controller
button.action = 'sayHello:'

win.display
win.orderFrontRegardless

app.run

And compared to the equivalent MacRuby and HotCocoa program:

require 'hotcocoa'
include HotCocoa

application do |app|
 win = window :size => [100,50]
 b = button :title => 'Hello'
 b.on_action { puts 'World!' }
 win << b
end

The first approach reminds me of Objective-C, the second is a pure Ruby DSL.

Benchmarking the experimental branch

The question on many readers minds is probably, how fast is it? To begin with, the start-up time is negligible which is a good quality for desktop applications to have. Using the YARV tests that ship with the experimental branch, let me show you the numbers I obtained on a Mac Pro with two Quad-core Intel Xeon 2.8 GhZ and 18 GB of RAM. The tests were also run on much less “beefier” hardware with analogous results.

All the usual disclaimers apply here. These are just a few very basic micro-benchmarks that should give you a “feel” for how two VMs stack up against each other; but don’t read too much into this and don’t expect it to be a scientific report on the performance of the implementations that were tested. Also keep in mind that MacRuby 0.5 is currently an experimental release, and while it’s able to pass RubySpec’s language specifications, it is not a complete implementation so far. The team is taking incompatibility issues seriously though and will make sure MacRuby will be able to run any Ruby code.

The following table summarizes the results of these benchmarks for Ruby 1.8.6, Ruby 1.9.1 and MacRuby 0.5:

This table shows the ratios between Ruby 1.9.1 and MacRuby 0.5, respectively, against the Ruby 1.8.6 baseline. When you see a number 4, for example, that means that the given implementation was four times faster than Ruby 1.8.6.

And here is a direct comparison between Ruby 1.9.1 and MacRuby 0.5. In this case, a number 4 (for example) would mean that MacRuby was four times faster than Ruby 1.9.1 for the given test:

The following chart should help you better visualize the results shown in the first table (click on it to enlarge the picture):

Even when you consider the disclaimer above and the trivial nature of the benchmarks themselves, it’s clear that at this stage of the game, MacRuby 0.5 is built for speed. ~~the fastest Ruby implementation around~~. MacRuby literally dominates Ruby 1.9.1. On “average”, according to these limited tests the experimental branch of MacRuby appears to be roughly 3 times faster than Ruby 1.9.1 (YARV), and in some cases even faster than that. You should definitely find this impressive.

For full disclosure, I’d like to explain the most likely reasons behind the four tests in which MacRuby is slower than Ruby 1.9.1:

bm_app_raise: MacRuby opts for cost free IA64 exceptions. What this means is that begin/rescue clauses don’t require a setjmp() like YARV does, but in case of exceptions at runtime, raising an error is more expensive. Of course, exceptions are… well, exceptional, so this has a trivial impact on real world programs.
bm_app_mergesort: Array operations are currently suboptimal. Slight improvements are expected.
bm_so_object: MacRuby’s object allocation tends to be relatively expensive. If you are allocating a zillion objects in a test, MacRuby will pay a hefty price for it.
bm_so_random: The performance of Fixnum has been optimized in this early release, but both Bignum and floating point operations are still suboptimal. Work is in progress and major improvements are expected to occur in future versions. In the case of Bignum, vectorization will do the trick.

The take home lesson

MacRuby is a serious project that fits in, and serves the flourishing market of Cocoa applications well. Its experimental branch is a major rewrite that, ~~grants this implementation the title of fastest Ruby in the West~~ that, much like Unladen Swallow for CPython, could become a very fast alternative to Ruby 1.9.x and JRuby. It’s mainly aimed at the desktop world, and as such the question of when it will work with Rails, is less pressing than it was in other early Ruby implementations. What’s certain is that Ruby is going to become a first class “scripting” language and a common choice for desktop applications on Mac. And should the difference in performance still remain in future, stable versions, it’s not hard to imagine that Apple’s server segment could also benefit from this, when Rails support becomes available.

Update (2009-04-04): I’ve modified a controversial statement since, technically speaking, while it is true that a very fast, incomplete implementation is promising and worth getting excited about, it cannot be considered the fastest Ruby implementation until a great degree of compatibility has been reached. This doesn’t diminish the value of MacRuby in any way, but rather draws a more accurate conclusion about the data that’s available today. It’s also worth noting that the few benchmarks that have been mentioned here are only part of the story. Speed aside, MacRuby’s aim and potential for Mac development still stand.

The image at the top of the post was generated by James Reynolds with HotCocoa::Graphics, a Processing-like library that uses Mac OS X’s graphics capabilities and makes them available to MacRuby.

Social Bookmarks

Sep

25

Don’t alienate developers

Filed Under Cocoa and Objective-C, General, Mac | 35 Comments

Remember Ballmer shouting ad nauseam “Developers, developers, developers”? I’m sure you’ve seen the original video and even a few techno remixes. Whether he truly meant it or not, his message was correct: it’s all about developers. Any platform that doesn’t attract developers is bound to fail.

Microsoft is trying to make an effort to please developers by shifting to a more open attitude towards the development community. Their record is far from pristine, but at least they are making a concrete attempt not to piss off programmers who chose to develop for any of their platforms – efforts which are rarely acknowledged.

Apple, a company that is generally considered far from “sinister” or “evil”, on the other hand, is trying their best to alienate developers. This is a crucial and costly mistake, even if they are a hardware company whose interest is mostly centered around their phones at this stage.

Their first idiotic move was to place an NDA on a finished product like the iPhone SDK (including the final version). For the ecosystem surrounding a platform to flourish, it’s fundamental that developers are able to freely share their knowledge. This move has many repercussions including the inability to publish books on the subject, something that is clearly a stepping-stone when it comes to being able to reach a broad audience of programmers.

Apple then decided that it was a good idea to charge people for the privilege to develop for the iPhone: $99 (that’s a hundred bucks, we are not idiots and this is not a grocery store). Thousands of other developers would have likely given it a shot and tried to tap into this new platform (and market opportunity), or simply experimented with it to satisfy their intellectual curiosity. But putting a $99 price tag on the Standard Program will push away the silent majority of potential developers and surely most freeware authors. Why would Apple do this? For a few extra bucks? That is nothing short of nearsighted thinking which only benefits a company in the short term and does serious harm in the long run.

These were two blatant mistakes, but, if you can believe it, Apple managed to alienate developers further still. A few thousand people put up with the NDA on the SDK, with the cost of the Standard Program, and with the lengthy and bureaucratic process it takes to access the only viable distribution channel, the iPhone App Store. Some of them spent months trying to create excellent, innovative applications for the iPhone, only to see their work rejected for no good reason other than that it competed with Apple’s own products (e.g. Podcaster) or was inconvenient for their business partner AT&T (e.g. NetShare). How shortsighted is that? It’s almost as stupid as the RIAA, which has a habit of suing its own customers.

Following the uproar of complaints about this, Apple decided that the best way to deal with developers’ malcontent was to legally bind them to shut up. So now the rejection letters many developers are receiving are covered by an NDA as well.

How low will Apple go? I understand that a few developers are making a good deal of money from some popular applications, and that the iPhone is a hot product which may change the mobile world. I can even grasp that programming in Objective-C is fun. But how many developers is Apple alienating, how many great applications will never be written because programmers object in principle to developing for Apple’s platform?

I fail to see Apple’s usual business insight and only see blind greed, the kind that acts as a highly effective cautionary tale against developing for Apple’s platforms. This all comes at a time when Google is promoting a truly open platform, Android, which poses a few challenges due to the heterogeneous nature of the devices it will be deployed on, but is equally interesting from a technical standpoint. Google even went so far as to award ten million dollars in prize money through a contest that they held, to attract new developers and applications. Android is definitely welcoming new developers and it’s doing so free from glaring restrictions and limitations.

I suspect that many will put up with Java, to get a cup of freedom.

Social Bookmarks

Nov

27

Ruby, Python, Haskell and Objective-C Feed Survey

Filed Under Cocoa and Objective-C, Django, Haskell, Ruby, Ruby on Rails | 3 Comments

Having little time to follow the blogosphere and its crazy rhythms of publication is not a good enough excuse for not being up to date. This rings particularly true for me as a technical evangelist at IBM, and as someone who is deeply passionate about the development and the information technology world. The biggest challenge is to quickly and efficiently divide the wheat from the chaff or, in other words, filter out the noise from the overload of signals put out there. For me, feed readers are life savers, I couldn’t cope without them.

I recently adopted a setup that seems to be working particularly well. I purchased NetNewsWire for my Mac and FeedDemon for Windows, and automatically got a one-year subscription to the online premium service from the fine folks at newsgator. The two programs are a joy to use, especially for handling very large group of feeds in a short amount of time, as I often need to do. Each program automatically synchronizes with the newsgator service, therefore no matter which computer I’m using, I’m always dealing with the same folders, subscripted feeds and saved clipping. Sure, there are free services out there like Google Reader or Bloglines, but to me there is no comparison between the experience that I have when using a sluggish web interface and a rock solid, well designed desktop application. If I have the option, I’ll always choose the latter, especially since newsgator allows me to take advantage of a centralized repository of feeds from my desktop programs, just like as if I were using their online service through Firefox. For a few dollars, I got a setup that is working awesomely well for me and it’s saving me huge amounts of time. It also helped me to identify non-updated blogs, and those that I was no longer paying attention to, therein allowing me to reduce my over-all amount of feeds (granted with a conscious effort on my part) to a more manageable total of 160.

As mentioned above, my subscribed feeds are important to me, with a list that changes dynamically over time, as I add and remove entries. That said, I was looking at my Ruby and Rails folder when I decided to share my feeds with you. The list is understandably incomplete (after all, there are thousands of Ruby related blogs) and the presence of planets, aggregators and tags in bookmark services like del.icio.us, generate a few unavoidable duplicates. These are the Ruby/Rails blogs and sites that I currently subscribe to:

You can download the file Ruby-Rails.opml to easily import all of the above feeds into your own reader.

Since I’m sure there are plenty of other “must have” Ruby feeds and blogs that are not currently on my radar (no word of a lie, I’ve already added more since I put the list together), I openly invite you to write a small entry in your blog as well, and show us what feeds you subscribe to. Please link back to this original post, or I won’t be able to easily find your answer. Consider it a sort of Ruby and Rails feed survey.

And since we’re on the topic, and the amount of feeds that I follow is dramatically reduced now, I’d like to extend an invite for you to do the same thing with Python/Django, Haskell, and Objective-C, assuming you are into any of these communities respectively. Those are the languages that interest me the most and I’d like to start following a good selection of feeds on these topics. If you don’t wish to blog about it, or use the comment section below, you can always write me privately at acangianoATgmail.com, specifying if you are okay with me crediting your list to you. I’d like to collect and organize the most interesting ones in a “results” type of post.

I thank you in advance, as I think it’s an interesting “experiment” that can be quite useful, especially for those who are just starting to learn any of the languages above.

Social Bookmarks

Now available

Follow me

Download DB2

Recent Posts

Recent Comments

Categories

Blogroll

Mar

29

Why MacRuby Matters (Present & Future)

Benchmarking the experimental branch

The take home lesson

Sep

25

Don’t alienate developers

Nov

27

Ruby, Python, Haskell and Objective-C Feed Survey