Sunday, February 18, 2007

Open And Closed Systems

In Martin Fowler's keynote at RailsConf, he talked about "post-modern languages," which is to say, essentially, languages that are designed with the expectation that other languages will also exist. The idea originally comes from Larry Wall, the creator of Perl. You can generalize the idea out to the Unix ecosystem and contrast the Unix design philosophy -- lots of little programs, each of which does one thing well, and numerous glue languages -- with the Smalltalk philosophy of "everything in the box from the hardware on up conforms to one idea." (Or, as it's been well-termed elsewhere, the idea of "Turtles all the way down.")

I've been thinking about this a lot, because it's an interesting question. Unix is obviously more successful than Smalltalk. On the other hand, look at Apple computers, how much better they are than Windows boxes, how much simpler to use than Linux boxes. Whether Apple is more successful than Microsoft or less so depends on what you think Apple's goal is. I think Apple's a lot more successful than Microsoft. Real artists ship.

But go beyond that -- the iPod / iTunes / iTunes Store triad is as much an example of a very successful closed system as any Mac, maybe more so. I got this idea from Steve Levy in a Boing Boing Get Illuminated! podcast, and it's a damn good idea. Most competitors to the Apple music triad have tackled only one of its three components, and Apple pwned them all. None of them had the elegance, the ease of use, or the tremendous downloads catalog. By packaging everything within one excellent closed system, Apple came into a settled market, turned it upside down, shook it really hard, and picked up all the money that fell out.

And the funny thing is, it's no secret that Steve Jobs is a fan of Smalltalk. Even today, the language used in the development of Mac apps, Objective-C, is this weird hybrid of C and Smalltalk. To some extent the same Smalltalk-esque closed-system philosophy that makes Macs such a pleasure to use is also responsible for the colossal success of the iPod. Like so much with Apple, it ultimately all traces back to Smalltalk. Even Jobs' business models are based on Smalltalk.

So this is a powerful argument in favor of closed systems. On the other hand, the Mac was a lot less useful when it didn't run Unix. That's an argument in favor of post-modern ecologies. I don't know.

Personally, for me, the jury's still out on this one.


  1. Steve even used an Alan Kay quote to launch the iPhone:

    People who are really serious about software should make their own hardware.

    I think the focus on systems or philosophies is seductively misleading, though. Apple (mostly Jobs and Ive) are the rare breed that are perfectionist in concept as well as execution.

    Most people are conceptual perfectionists and half-asse implementors.

  2. This is a reason I've heard RoR developers give for why they don't like Smalltalk. They don't like that everything lives in the image. They feel that lacks flexibility and openness. They say they prefer the file-based nature of Ruby. I've heard non-Ruby developers complain they don't like RoR's "convention over configuration" approach. That feels limiting to them.

    I've seen a few "bridge" technologies that allow Ruby to interoperate with .Net, though my impression is it's always one-way--Ruby to .Net, not the other way around. There is also JRuby, though I don't know much about it. I imagine this enables Ruby developers to use the Java API. There are some other interopation technologies available for Ruby, as I'm sure you are aware.

    I've seen similar capabilities with Squeak as with Ruby. Squeak has the FFI (Foreign Functionality Interface). There is a library for it that allows you to control an external application from within the Squeak environment (or maybe that's just your default web browser. I forget). I've seen it used. It can of course interact with external databases, though as Ramon points out its interoperability with SQL Server is limited. I've seen similar interoperability technologies available for Squeak as for Ruby.

    So despite its closed nature, Squeak does have a couple "escape portals" (sockets and FFI) that allow you to get out and work with other technologies. The reason Alan Kay would give for the design of Smalltalk is he was inspired by an implementation of Lisp on the PDP-1. I don't remember who did it, but the guy managed to make Lisp the OS of the computer. Smalltalk was originally the same way. You could boot the Xerox Alto in it, and it became the OS. As it went through its iterations the idea became so large it made sense to make it the OS. There was nothing else like it for a few years, until the Xerox Star came along. Since Squeak is based on that model, you get what we have, but it acknowledges its limitations by not insisting on being the OS of the computer.

    The Apple iPod and Boot Camp are kind of the same acknowledgement. The iPod/iTunes combo works on Windows as well as the Mac. Since Apple moved to Intel, Boot Camp allows people to dual-boot into Windows if they want to (and before that there was Virtual PC--though it was pokey). So Apple acknowledges the need for some "escape portals" as well for some of its customers.

    And by the way, Mac OS X was not the first time Unix could be loaded on the Mac. I remember using Unix (System 6) on a Mac SE back around 1990. It was a separate package you had to buy from Apple. It had a GUI. Each window you opened was a command line (shell) interface. I don't remember if it could multitask Mac programs with Unix tasks. Probably not. It was a long time ago. In any case, I think it was the first pre-emptive multitasking environment on the Mac. Higher end Macs (like the Mac II) had a multitasking version of Finder, but it was cooperative.

  3. Correction:

    Meant to say, "I remember using Unix (System IV) on a Mac SE back around 1990". I got my terms mixed up. It was a version behind the then-current release of Unix, System V, release 4.


Note: Only a member of this blog may post a comment.