John Gruber recently talked about the new bridges that are coming up in 10.5: bridges to write Cocoa in Ruby and Python. What he said can be summarized in this:
- The Java bridge was all hokey, and the benefits they got weren’t great because Objective-C and Java are, at their core, the same kind of language.
- Ruby and Python are meant to solve entirely different set of problems; for example, they have built-in regular expressions.
- You don’t need to write your whole application in Ruby or Python or Objective-C, you can mix as you want.
This is good. John is onto something here. But wait! Hm. “You don’t need to write your whole application in one language”. I recognize that from somewhere. Right – .Net.
There are an awful lot of languages that are available in .Net versions now. There are newer languages and there are existing languages adapted for .Net use. Everything running under .Net has to be divided into two different buckets – managed code and ‘unmanaged’ code. ‘Unmanaged’ is Microsoft shorthand for “your old stinking, non-garbage-collected, buffer-overrun-suspectible”. One of the most common kinds of unmanaged code is unmanaged C++.
Writing unmanaged code is generally frowned upon. There are “albatrosses” that “you do not want to strap around your neck” in the software industry: writing Groupware, writing non-perfect regular expression engines, and also writing unmanaged code. Unmanaged code is also inherently less portable, and to the extent that you can move your code from Microsoft-approved Unit A to Microsoft-approved Unit B with your current executable (and, if you wait two years, to Unit that runs Mono A), that advantage is lost. Managed code, on the other hand, is good. Managed code compiles down to bytecode – to CIL, formerly called MSIL.
Yes, you heard right – in .Net, all languages are the same. All languages compile down to the same bytecode. Your reaction to this is either “that’s great!”, “so what?” or “ugh!”. I personally remain in the ugh! camp. You see, say there’s a language with a great regular expressions engine. (Let’s call it “Earl”. Yes. Earl.)
Let’s say it kicks System.Text.RegularExpressions around the block seven times before noon. Now you want to use Earl when your write .Net code to write your regex code in it. And now what? Even if Earl is ported to a .Net version, it’s gotta compile down into CIL, and if Earl’s portable kickass regex engine depended on compiling down into instructions specifically tuned towards making it faster, its advantage is lost. Now, this may be total bullshit in the eyes of those who know how Perl and Python and Ruby actually run as .Net languages. I happen not to know, and if this is wrong, I do apologize.
But what I do know is that there is very little room for your own syntactical tomfoolery in .Net. What your code compiles down to is CIL, which has to run on every box with the .Net framework on it. You do not get special cases. You know what gets special cases? That’s right. C# gets special cases.
Why does C# get special cases? C# is evolved along with the .Net runtime. As .Net progresses, C# adapts, and as C# needs to grow new features, .Net expands. C# is the ultimate .Net language. The other languages are along for the ride – Visual Basic.Net to not bug those who code Visual Basic, Managed C++ to not bug those who code C++, JScript.Net to not bug those who coded ASP pages and Windows Scripting Host scripts with JScript, and J# to not bug those who code J++ (all three of them). Since these were basically your choices if you were programming for Windows before .Net (and to also use plain C and the Win32 APIs, which I hear is slightly charmier than, say, skinning a live elephant), Microsoft were right to bring at least some along for the ride.
But the most successful new .Net languages are those who work like C#. They’re the ones that are, in some way, a better C# than C# itself. So, my roundabout point here is that .Net also offers you ways to work in several languages, much like you could pick any color you wanted for your T-Ford, as long as it was C#. Er, I mean black.
Which brings us back to Mac OS X. Actually, it doesn’t. It brings us to, by some weird twist, C.
C has dominated programming for the last 35 years. Anyone who says differently is lying or work on Sun’s or Microsoft’s marketing team. One of the first properties I assess of a new programming language is “how easy is it to drop into C”? Dropping into C isn’t important because I like C. (I do like C to some extent.) Dropping into C is important because… you know all those libraries you can download off the web? C. This isn’t restricted to just C code. Many modules for scripting languages are written in C. Even Java, the great big island, the one that has a policy of Only Use Other Java Code With Your Java Code, has an interface for dropping into C – JNI. (Java Native Interface.)
Well, what does this have to do with Ruby or Python? Dropping into C from Ruby or Python isn’t easy. Dropping into C from Objective-C is very easy, however, since Objective-C is a strict superset of C. Even a mostly-Ruby Cocoa app can use a variety of C libraries almost natively. You do not need to write Ruby wrappers. Read that again: You do not need to write Ruby wrappers.
So at the end of the day, writing Ruby Cocoa apps is going to be a whole lot better and easier than writing Java Cocoa apps. The only reason you had for writing Java Cocoa is your irrational fear of square brackets, the garbage collection or “wanting to hook into the great wealth of Java libraries”, which I suppose made some kind of sense, even despite the fact that there are around 50 kajillion times more C libraries than Java libraries, because at least the Java libraries are already object-oriented.
Writing Java-Cocoa with some Objective-C is like trying to write some parts of your book in
BritishInternational English and some parts in US English. Same everything, you just wrote ‘old chap’ in one chapter and ‘homeboy’ in the next. Writing Ruby-Cocoa with some Objective-C is like writing half your book in Swedish and half your book in English. The two are noticeably different, and Swedish kicks English’s ass in a variety of places, so you can actually play on their respective strengths.