Editor's Column - AppleScript and Dylan

Mary Elaine Califf

Since not everyone in MADA read the Dylan newsgroup or mailing list, I thought that I would devote this space to selections from a recent thread that I think will be of interest to many.

The question

Tom Gordon wrote:

The AppleScript programming language, for those of you who might not have heard of it yet, is a new "shell" or "extension" language for Macs from Apple. Users will be able to write programs which send applications messages, also across networks.

Yes, AppleScript is a dynamic object-oriented language.

My question: why isn't AppleScript Dylan? Apple had the opportunity to recreate a Lisp machine like environment, with a single, elegant object-oriented language for both developers and users. Instead it looks like Mac users will have to live with the usual Tower of Babel: HyperTalk, AppleScript, and Dylan (not to mention C++, etc.)

Are there engineering reasons for this decision, or is this just the result of different organizational pressures and interests?

The Response

Larry Tesler replied:

Since it was I who started both projects (around four years ago), I can assure you that the outcome was not politically motivated.

Note that:

1. AppleScript is an end-user language, in the vein of spreadsheet macros.
2. Dylan is a language for professional software development, in the vein of C.
3. Their audiences will be almost as different as MacDraw's is from QuickDraw's.

   Nevertheless:

4. Chunk expressions and other powerful features of AppleScript, though not implemented in the standard Dylan library, can be supplied by a non-standard library.
5. The designers of each language kept the other language in mind.
6. Therefore:
7. AppleScript can be implemented by translating it to Dylan.

So why did Apple not implement Macintosh AppleScript 1.0 using Dylan?

Because it is risky to plan a future product that can't be completed until after a more complex future product has been completed and its performance and memory footprint understood. I hope that helps.

Larry

P.S.: HyperTalk is approximately a subset of AppleScript. In this case, we worked to maintain similarity, because the users and uses of both are expected to be similar. There are some differences, but they are not gratuitous.

excerpts from discussion

Tom Gordon:

This is all very encouraging. Thank you for the inside information.

As we all know from the Dylan FAQ, an "Algol" syntax is being designed for Dylan, as an alternative to the Lisp/Scheme syntax. Wouldn't it be nice if this syntax would be "compatible" with the syntax used in both AppleScript and HyperTalk? I put "compatible" in quotes, because I'm not at all sure to what extent this can be achieved. AppleScript's model of object-oriented programming appears not to be based on generic functions, but on "sending" messages to objects.

Brian Harvey:

[Accusing Apple of elitism in distinguishing between Dylan as a tool for programmers and AppleScript as a tool for users]

One reason things have changed is the commercial reason that companies fear they can't make money on software if they provide source code. (It's not clear to me that this fear is well-grounded; the Unix source code is widely distributed and that doesn't stop AT&T making money.) But another reason is plain elitism as Apple corporate policy. Remember how on the original Macs if you wanted to be able to reboot your Mac without power cycling it you had to go down on your knees and convince Apple that you were *worthy* of being allowed to buy a "programmer's switch"?

Remember how in Hypercard there are five levels of intelligence built into the program's model of the user, and you have to type magic passwords to prove you're intelligent enough to be allowed to use HyperTalk? There is no commercial reason for this, just elitism. I'm sorry if this comes off as an irrelevant flame, but I think this question of whether you think your users can think or not is crucially important to the kind of world we technologists are going to build for the next generation. Apple puts a lot of effort into education, and I hate seeing that effort poisoned by this elitism that's at the heart of every technical decision they make.

I was really really pleased when HyperCard came out, because it was Apple's first grudging step toward tearing down the wall *they* had erected between programmers and users. But, in designing HyperTalk, why couldn't they have reinvented Logo, instead of reinventing Cobol?

Chris Espinosa:

I have read recently that AT&T has sold USL to Novell, who does not distribute the source code to its products. I think the proprietary vs. "open" debate, while a good discussion in its own right, is not pertinent here. Proof of that is the extremely substantial amount of Apple II software that was written because that machine had AppleSoft BASIC in ROM, even though Microsoft's source code for it was not published. Good platforms attract programmers, open or not.

As a member of the team that developed the original Mac, what I remember is how we shipped a programmer's switch in every box. The reason that we didn't bring the reset and IRQ buttons out to the front is our experience with the Apple II, where people were accidentially resetting the machine, losing data and corrupting disks. By making it an option (available to everyone) to install the switch, we put the risk-versus-benefit choice in the hands of each individual user. At its worst you could call that paternalistic, but I think "elitist" is just plain wrong.

As the product manager who shipped HyperCard, I remember our decision to ship HyperCard to literally millions of people pre-set to allow them to browse and edit the stacks we supplied. By going to the Preferences card in the Home stack, they could turn on scripting ability. (No "magic password" was required for three years, when Claris divided the product into two versions, a "development" edition and a "browsing" edition. The "browsing" edition that was still given away free still had the full programming power. Now there's a separate HyperCard player that does not have the programming features--still given away free.) Brian's half-empty glass is that we "dumbed down" a programming environment. My half-full glass is that we gave millions of people who never considered programming the chance to get into it. Tens of thousands did. And those who didn't still had a useful tool.

I'm afraid that the issue is that Apple fundamentally believes in using technology to create products to sell to non-technologists. Brian equates the ability to program and read source code with being "able to think". That's the most elitist thing I've ever heard. I respect my customers because they have the ability to think about their jobs, their desires, and their inspirations without having to learn arcane computer languages to do so.

Making technology accessable to millions of not-technologists is the hardest thing we know how to do. I think Larry's analogy is excellent: Dylan is QuickDraw to AppleScript's MacDraw. They are not a class division; they are two points on a continuum, two different ways of satisfying different kind of people. I agree with you that the best thing would be to make a product that could grow smoothly from technologists to non-technologists, and that's also a hard thing to do (but very valuable). Meanwhile, I don't see anything elitist about delivering technology-oriented tools (like Dylan) to technologists, and productivity-oriented tools (like AppleScript) to non-technologists.

Bob Kerns:

[responding to Brian Harvey]

I will add that that in HyperTalk, we have a language which is "easy to learn", but can only be used effectivly by expert programmers! Only us elite programmers know the various tricks by which you can do such things as arrays, lookup tables, or objects representing domain abstractions. Not to mention the knowledge you need to make your code run acceptably fast!

Hypercard's strength lay in its interactivity and the fact that it's relatively easy to learn to do trivial things in HyperTalk when you want just a little more than what you can get with the interactive interface.

One of the Mac's strengths has been that you don't HAVEto program it to use it. However, one of its biggest failings has always been that if you want it to do a bit more than it does now, you have a huge barrier to cross, higher than almost any other system I can think of.

I have the impression that many in Apple think these two facts are somehow logical consequences of each other, but I strongly disagree.