Oliver Steele

One — but only one — reason for Apple’s appeal is that Apple products are luxury goods. (I’ll get to the second reason in a moment.) Apple products compete on design, not price. The Apple stores, with their hardwood floors and wide open spaces, are modeled after a luxury car showroom, and don’t share the convenience store layout and shelving of other computer stores.

Focusing on the high end of the market is a reasonable strategy¹. (Sony is trying it with the VAIO.) In an area that depends on third parties to create programs and peripherals, this strategy has a benefit beyond high profit margins. Hardware and software makers are disproportionately interested in Apple’s customers, because these customers have shown themselves to be disproportionately willing to spend money on computer products. This is why Apple can have 1% of the desktop market but — unlike Linux in 2004 — command compatability from web sites and large software vendors. Selling to Apple customers is like opening a store in Beverly Hills; if the products are good enough to sell there, it’s worth the real estate cost.

However, there’s another appeal to the Macintosh: the absence of choice. When I had thought my next computer would be a PC, I was beset by a number of decisions: laptop or tablet? full tablet or convertible? faster than my old computer, or lighter? or brighter screen? Once a series of viruses² convinced me to switch to a Macintosh, the whole decision process became simpler: Did I want the big laptop or the little one? By deciding to buy a Macintosh, I had given up even the possibility of buying a tablet computer, an ultraportable, or a honking media monster with a superbright screen — and, contrary to what I had expected, this surrender was a huge relief³.

This lack of choice, coupled with the quality of the choices that do remain, is something I’ve found all across the platform. There seem to be at least hundreds of times more programs for Windows than there are for the Mac. Most of these programs are crap. For a while I maintained both a PC (my work computer) and Macintosh (at home). When I needed a draw, or chat, or email program, say, the pattern seemed to be this: On the PC, there were a few dozen programs to evaluate. On the Macintosh, there would only be one or two. But the best Macintosh program was comparable to the best Windows program: sometimes a little bit worse, more often a little better⁴. The real difference was that on the Macintosh, I could skip the evaluation process. Which leads to the other reason that I switched to the Macintosh: despite the greater number of programs available for the PC, the ones that I ended up both being able to find and wanting to use, ran on the Mac.

One could go into why the average program is better on the Macintosh. Some candidate reasons have to do with what the value rankings of people who buy Macintoshes versus PCs, or what motivates someone to develop a program for the Mac versus the PC, or how the nature of ones programming environment affects the kind of program one creates. What struck me instead is the relief of not having choice, or, of having ones choices made for you. It’s like going into, not a luxury goods store, but a boutique. In a luxury store, the brands are better, and the quality is higher, but you’re still doing your own shopping. In a boutique, the owner has picked out one or a few of each item, so that if you trust their taste, you don’t have to choose. (Trader Joe’s is another example of a company that has mass-produced the boutique.) The Macintosh ecosystem isn’t a single person with a single design sensibility. But Apple, through a combination of design leadership and price-imposed exclusivity, has managed to turn it into a boutique.

Notes

¹ “Focusing on the high end is a reasonable strategy”: Clayton Christensen warns about the danger of “retreating upmarket”: that as products or their components become commoditized, one is vulnerable to an “attack from downmarket”. This is true for a company operating within a single product category. Apple has shown repeatable success in either introducing or dominating new categories: the personal computer, the high-end laptop, the modern all-in-one desktop computer, the wireless base station, the hard disk music player.

² “a series of viruses”: I wasn’t actually infected by any of them until Windows XP Service Pack 2, which destroyed much of the remaining utility of my mostly locked-down PC.

³ “this surrender [of choice] was a huge relief”: Barry Schwartz’s The Paradox of Choice describes this phenomenon. I haven’t read the book yet (I’ve just read the reviews), so I don’t know whether it describes the Macintosh.

⁴ “more often a little worse”: I ended up with Thunderbird on the PC, but Apple’s Mail client’s ability to perform offline edits on IMAP mailboxes were a generation beyond this. I was never able to find anything on Windows that compared to the combination of power and simplicity in Omnigraffle.

If everyone in America makes an extra-large Thanksgiving dinner so that they can feed guests the next day, isn’t this a pyramid scheme?

The developer world is divided into two camps. Language mavens wax rhapsodic about the power of higher-level programming — first-class functions, staged programming, AOP, MOPs, and reflection. Tool mavens are skilled at the use of integrated build and debug tools, integrated documentation, code completion, refactoring, and code comprehension. Language mavens tend to use a text editor such as emacs or vim — these editors are more likely to work for new languages. Tool mavens tend to use IDEs such as Visual Studio, Eclipse, or IntelliJ, that integrate a variety of development tools¹.

New languages, such as Laszlo and Groovy, and new language extensions, such as AOP, are typically available for text-editor-only development before they have support within an IDE². After a while, if the language or extension is successful, the tools catch up. This isn’t just because it’s harder to implement a tool than just a language. It’s because language expertise and tool expertise are to a certain extent alternatives, that each reinforce themselves to the exclusion of the other. Here’s why.

Language-Maven Perspective

If you’ve spent most of your time learning about languages and how to use them, your picture of the world may look like this:

In this diagram, the choice of language can make a great deal of difference to your productivity, because you know how to apply each language feature to a variety of situations. The choice of IDE, on the other hand, doesn’t matter much, because you’re mostly using the IDE for its text editor — maybe with a little bit of compilation support thrown in, but not for the whole set of modern IDE features that a modern tool maven uses.

Tool-Maven Perspective

Conversely, if you’ve spent most of your time mastering the development tools of your trade, you understand what it’s like to get into a flow state with an integrated editor and debugger, and to go at a program with refactoring and code comprehension tools at your disposal. Your picture of the world may look like this:

An IDE presents huge advantages relative to a simple text editor, for you. The choice of programming language, on the other hand, doesn’t matter that much — you’re mostly working with the same old classes and methods, statements and expressions, in any of them, and the real development power comes from the IDE.

Two Camps

Why can’t one be a language maven and a tool maven? It’s hard. One reason is that developers have limited time, especially for learning new skills. You can use any given block of time to master language features, or to master development tools. Each of these choices contributes to a positive feedback cycle, but they’re competing cycles, so they create divided camps.

Taking the time to learn language features puts you in a position to appreciate the features of new languages. You can then adopt a language before tools support it, because you don’t rely on the tools for your productivity anyway. And it’s worth adopting these tools early, because their features are valuable to you — making use of them is where your expertise lies.

Invest the time in mastering development tools, on the other hand, and you won’t want to give these tools up to try a new language — the development tools are a major part of your productivity. For you, a new language doesn’t have many advantages over other languages anyway, because you haven’t studied how to use language features to make you productive.

This means that the more you invest in language features, the more they benefit you, to the exclusion of tool features — and vice versa. And this is what creates the two camps, with two perspectives on the relative merits of language features and tool support:

Language Buffet

At any given time, the editor-only developer is in a position to choose from a wider selection of languages — because, at any given time, more languages have a compiler and a runtime, than a compiler and a runtime and a language-aware editor and and debugger and etc.. The diagram below shows what this looks like for a number of languages at different points in their evolution. Within each language, the line at the end of the red transition marks the point at which it has acquired enough features to be useful for some class of programming. The line at the end of the purple transition marks the point at which tool support (beyond a compiler and runtime) exists for it too. At any time, more languages are programmable (the red squares) than have tool support (the blue squares).

One consequence of the greater language selection available to the editor-only developer is it typically includes languages that are more powerful. So while one reason that the “Language” block is bigger in the “langauge maven” illustration above (reproduced below) is that the language maven dedicates more time to learning how to leverage language features, the other reason is that the language maven may have a more powerful language to work with, because there are more languages available to her.

The Language Developers Dilemma

In fact, the most powerful languages may initially have the least powerful tool support. The reason for this is that the language developer, like the language adopter, has to make a choice: whether to dedicate limited development resources towards language features, or towards tool support³.

Consider the diagram below. This diagram represents three languages, whose respective developers have chosen to concentrate initially on language features (the top arrow), on tool support (the left arrow), or (the middle arrow) a middle-of-the-road strategy that emphasizes them both equally. The arrows are roughly the same length, representing roughly equal amounts of effort.

Although the arrows are equal length, they achieve different levels of language features and tool support. The “language-first” strategy of language development achieves a greater degree of language features, as indicated by the red tics across the bottom, but a lesser degree of tool support, as indicated by the blue tics across the right. And conversely for the tool-first strategy.

Of course, if a language succeeds, it will eventually get tool support. So in the long run both the language and the tool mavens will use the popular languages, such as Java. That’s where I’m hoping we’re going with Laszlo.

The Perils of the Pioneer

All this makes the language approach sound comparable to the tool approach; it’s just a matter of which skills to learn. But this isn’t always true. We could argue about whether understanding closures or a source debugger makes one more productive. But what isn’t arguable is that there are penalties, beyond the lack of tools, to adopting a language early.

One is that the language may not have staying power. Another is that, just as tools lag initial development, so do other ecosystem artifacts such as books, articles, newsgroups, and, in the enterprise world, the ability to hire developers who know a language, or to be hired on the basis of knowing one.

There are contexts where none of these disadvantages matters. If you learn languages easily, finish projects quickly, and move on to new projects frequently, it doesn’t matter whether a language is going to succeed, so long as it helps you with your current project. If you learn languages from reading source code or reference manuals, you don’t need the books and articles that will follow later. And if you’re working with a small team (perhaps as small as one) of elite developers, you aren’t hiring them for what they already know anyway.

Which isn’t to say that you can’t be an elite tool maven too, it’s just that the conditions for success are different. You can be the only one on a team to use Eclipse. If you’re the only one on your team using Haskell, something is probably wrong.

Comments

Bob Congdon points out Lisp and Smalltalk as counterexamples to the “language developer’s dilemma”: both are powerful languages with powerful development environments.

Lisp was a powerful language first, and had a powerful environment second: it only appears to be an exception because it has been around so much longer than any other extant language and has had time to acquire both. Smalltalk, however, is a genuine exception. Smalltalk might be viewed as a step backwards in language features from Simula 67, and a simultaneous step forwards in tool support — but this is holding the language to a higher standard than any other.

Congdon also points out that it is possible to both a language maven and a tool maven. True in theory, just as it’s possible in principle to become both a concert pianist and mathematician, but in practice there may not be enough hours in the day to do both.

And Harry Fuecks explains some of what I was trying to say better than I did, as well as adding points of his own.

Notes

¹ A sophisticated emacs user, who uses something like psgml-mode or jde for every single language they edit, is arguably in both camps. I haven’t met many of those, though. The emacs users I know use it configure it as an HTML-editor or a T_EX-editor, say, but use it as a text editor for everything else.

² C#, with Visual Studio.NET, was an exception — at least, if you’re outside Microsoft. Microsoft is an exception to almost everything.

³ And this is why Microsoft is an exception: because its development resources are effectively unlmited.

Last month, Laszlo Systems released the Laszlo platform as Open Source. The intent was to to remove the bottleneck in the virtuous cycle of software development.

Today IBM alphaWorks released IDE for Laszlo. This is an Eclipse-based IDE for creating, editing, debugging, and testing applications written in Laszlo.

Eclipse is an impressive platform, and the IDE for Laszlo is an impressive effort. This page demonstrates many of its features, with screenshots for each. (It was written in LZX, using IDE4Laszlo.) Kudos to the developers!

From http://alphaworks.ibm.com/tech/ide4laszlo :

IDE for Laszlo is a technology preview of an Eclipse-based development environment for creating, editing, debugging, and testing applications based on the LZX declarative mark-up language.

Laszlo is based on LZX, which is an XML and JavaScript description language similar in spirit to XUL (XML User interface Language) and XAML (“Longhorn” mark-up language by Microsoft®). The Laszlo Platform is an open-source platform for the development and delivery of Rich Internet applications (see http://www.openlaszlo.org for more information) where the LZX XML mark-up is used to create the user interfaces.

The IDE consists of a set of plug-ins that allow creation and testing of Laszlo applications, all within the Eclipse platform. These applications can then be deployed and run on a Web server. IDE for Laszlo also provides a rich editing environment for the LZX mark-up language. Its editing features include XML- and script-based content assistance, XML syntax highlighting, and XML code formatting.

In addition, IDE for Laszlo allows the developer to preview the resulting application without deployment, within the Eclipse environment. It supports markers for reflecting compilation and syntactical errors. When development is complete, the applications created can then be deployed and run.