Important Shock

Edit: Fixed some factual inaccuracies about the language itself.

Tim Burks, noted contributor to RubyCocoa and creator of RubyObjC, gave a talk at C4[1] about his experiences with creating a Ruby <-> ObjectiveC bridge, and the problems he overcame in doing so. It was an interesting presentation, and we were all suitably appreciative when he showed his custom visual chip-design software written in Ruby with a Cocoa interface.

And then he dropped a bombshell.

For the past year, Tim’s been working on a new dialect of Lisp - written in Objective-C - called Nu. Here are its features (more precisely, here are the ones that I remember; I was so awestruck that many went over my head):

• Interpreted, running on top of Objective-C.
• Scheme-y syntax. Everything is an s-expression (data is code, code is data). Variable assignment was done without let-clauses (which are a pain in the ass) - all one has to do was (set varname value).
• Variable sigils to indicate variable scope.
• True object-orientation - everything is an object.
• True closures with the do-statement - which, incidentally, is how Ruby should have done it.
• Macros. HOLY CRAP, MACROS! When Tim showed us an example of using define-macro for syntactical abstraction, Wolf Rentzsch and I started spontaneously applauding. His example even contained an example of absolutely beautiful exception handling that should be familiar to anyone with any ObjC or Ruby experience.
• Symbol generation (__) to make macros hygenic and prevent variable name conflicts.
• Nu data objects are Cocoa classes - the strings are NSStrings, the arrays NSArrays, etc.
• Ability to create new Obj-C classes from inside Nu.
• Interfaces with Cocoa libraries - you can access Core Data stores from within Nu in a much easier fashion than pure ObjC, thanks to Tim’s very clever idea of using a $session global to store the NSManagedObjectModel, NSManagedObjectContext, and NSPersistentStoreCoordinator.
• Ruby-style string interpolation with #{}.
• Regular expressions.
• Positively drool-inducing metaprogramming, including a simulation of Ruby’s method_missing functionality.
• A web-based templating system similar to ERb in 80 lines of Nu code - compare that with the 422 lines of code in erb.rb.

Tim showed us a MarsEdit-like blog editor written entirely in Nu, using Core Data as its backend - and then showed us the built-in Nu web server inside that program, complete with beautiful CSS/HTML/Ajax.

As F-Script is to Smalltalk, so Nu is to Lisp. Tim said that he hopes someday to open-source Nu; if he does, he will introduce what is quite possibly the most exciting development in the Lisp-related community in a long time. I don’t think I speak for just myself when I say I cannot wait to get my hands on it.

Things have been quiet here in this blog. Too quiet. As such, I’m keeping the name-five-things-you-hate-about-a-language-you-like ball rolling, having seen it rolled with zest and vigor by brian d foy, Titus, Jacob Kaplan-Moss and Vincent.

Without further ado:

Five Things that Suck About Objective-C/Cocoa:

1. Syntax for NSString literals. For the uninitiated, in Objective-C code enclosing "insomnia" in simple double-quotes creates a C-style char[] string; if you wish to use the far more powerful and versatile Objective-C NSString class, you must add an @ (making @"insomnia"). Backwards-compatibility with C is a good and useful thing, but why require more keystrokes to do the most commonly-used thing? I myself last weekend puzzled over a wonderfully non-specific “invalid reciever” error for a long time before realizing that I forgot an @ when sending strings to an arrayWithObjects: method. Aside from that, why use the @-sign as a prefix for NSStrings when it’s used in a plethora of other places, such as @interface, @implementation, @end and @selector? Though 90% of my @-key-presses in Textmate are prefixes to NSStrings, I can’t have a keypress of @ automatically expand to @”" - there are too many other things to do with the poor little @-sign. The oft-neglected | (pipe or vertical bar, I’ve heard both) character is far less disruptive to the flow of typing.
2. reallyLongAndCamelCasedMethodNamesGetAnnoying. I refer specifically to the lovely NSWorkspace method openURLs: withAppBundleIdentifier: options: additionalEventParamDescriptor: launchIdentifiers:
   And ObjC method names can be concise yet informative - take for example NSString’s compare: options: range: locale:. I must admit, this complaint is not entirely valid, especially considering Textmate/XCode’s fancy code completion.
3. No operator overloading. Come on, guys - why reject this crucial part of Smalltalk heritage? I, for one, am sick of writing objectAtIndex and objectForKey: as compared to Python’s []. Though Smalltalk allows one to define new operators, I’d be perfectly happy to settle for a few overloadable operators (string concatenation is desperately needed).
4. Mysterious helper methods. I didn’t know of the existence of NSHomeDirectory(), NSTemporaryDirectory(), or NSClassFromString() until very recently. True, this is my fault, but I think that F-Script’s idea of storing all of these methods in a singleton System object is excellent, and much more in line with Objective-C’s Smalltalk heritage. (Actually, I have a half-finished ObjC class that makes NSBeep() and all those other miscellaneous C functions into class methods; if there’s any interest, I’ll finish and release it. I suppose that makes this complaint invalid. Oh well.)
5. File management is a mess. Essential code is scattered throughout NSWorkspace (in all its brain-dead glory), NSFileManager, NSFileHandle, NSPipe, NSDirectoryEnumerator, and NSData - few things are as infuriating as hunting down the correct class that does exactly what I want. (Actually, no. Finding a better solution after thirty minutes of hacking around some perceived inadequacy is worse.

So there you have it. To be honest, it took me quite a while to write this, mainly because Objective-C is such a great language and Cocoa is such a great set of libraries. I suppose that the imperfections in a consistently useful and friendly toolkits stand out, and in retrospect I sort of feel guilty for my picky attitude. After all, it could be much, much worse.

I’ve joined the CenterStage open-source project as a Cocoa developer, and I’m having a great time working on such a large project with such passionate and intelligent people. I have taken it upon myself to improve, such as I can, the quality of the application intended to catalog and organize movie files, known as BackStage. Since part of a media center application is eye candy, I recently renovated a Quartz Composer composition that shows a 3D DVD box for the selected movie. I had played with QC a few times, and found it to be a really cool and flashy tool with a user interface I had never seen before; I looked forward to working with it on a serious project.

I can say without a doubt that Quartz Composer is nothing more than a toy. For anything more complex than an RSS screensaver, the visual data mapping becomes a chore to connect and use. The patches, while a good idea in theory, turn out to be only barely usable in practice. There’s no patch for a clickable button, for a slider, for any widget which anybody might concievably want to use - but to hell with all that, we have a glowing Apple logo patch! If, as I needed to, you need an input to an Interpolation patch so that you can turn it on and off, too bad! You’re limited to what Apple give you. Additionally, Apple have not made the slightest effort to allow people to export, import or add new patches or clips - why? Why is this third-rate software bundled along with such first-rate tools as XCode, Interface Builder and the ObjectAlloc debugger?

And there’s no undo function. How can you possibly justify releasing a program aimed at developers that doesn’t have undo-and-redo support? Much to my dismay, the only solution I could find to work around this glaring lack of functionality was to a) have around seven different save files so that I could revert if necessary, and b) keep another scratch project in which to cut-and-paste everything that I remove from the actual project. This is absolutely inexcusable, and Quartz Composer’s inclusion in the fantastic Apple developer tools is nothing but an embarrassment, plain and simple.

What mental lapse caused the selection of Javascript as the only scripting language inside QC? The target audience - OS X developers, Cocoa and Carbon in particular - have a low likelihood of knowing, much less enjoying the use of Javascript. Ask yourself - why are there so many libraries which proport to, in the words of MochiKit, make Javascript suck less? Why, indeed, would Google make GWT?

“But Patrick,” you say, “Javascript was a good choice because you shouldn’t be writing much code in QC.”

Oh, really? Even if the assumption for your argument was valid - which it isn’t; due to the fundamental brokenness of the QC patch system and dearth of patches and clips, I am forced to write code - Javascript is still a bad idea. There’s no printf(), no wait(), curly brackets out the wazoo, and tacked-on OO. Sure, with Firebug it sucks less, but we’re not exactly working in Firebug, are we? No, we’re working in Quartz Composer, where the extent of debugging is the Log() function.

Even if you have to use Javascript - despite the fact that Ruby or Python both blow JS out of the water - you could have made it much, much better. Sure, patches are a good visual paradigm - now why not let us pass them around programatically, trigger scripts at various events, and include a text editor that does little more than highlight syntax? A visual paradigm should work on top of handwritten code, not in its place; if I really wanted to I could write a Swing/SWT GUI application with a text editor.

Nothing inspires confidence like discovering that the extent of the documentation is a .rtf file in the application’s directory; the meagre resources on the ADC site as regards QC serve mostly as a guide on how to put compositions inside Cocoa apps or - the thought is almost painful - Dashboard widgets..

Quartz Composer needs some serious work for it to be useful as anything other than a pretty interface to make screen savers. I have a hunch that there is a sizable market for an improved version of QC - hell, I’d pay for it if it made my life easier.

Moral of the story? Before labeling something as a developer tool, first make sure it’s not an abysmal piece of software.

As many of you know, Apple is releasing the new incarnation of Objective-C (creatively dubbed Objective-C 2.0) along with XCode 3.0 and Leopard. Though much of it is hidden under Apple’s elaborate nondisclosure agreements, people like Andy Matushack and Scott Stevenson as well as other sites have uncovered more information from the ObjC mailing lists and repositories than the meager scraps of info that Apple released on their website.

Since I can’t give any new information about this, I’ll just list my opinions, then brace for the reaming I’ll receive in the comments.

Disclaimer: Apple may change all of these things. This post is naught but conjecture heaped upon conjecture.

(more…)