In a few weeks it’ll be 25 years ago: June 23, 1988—the day Mathematica was launched.

Late the night before we were still duplicating floppy disks and stuffing product boxes. But at noon on June 23 there I was at a conference center in Santa Clara starting up Mathematica in public for the first time:

(Yes, that was the original startup screen, and yes, Mathematica 1.0 ran on Macs and various Unix workstation computers; PCs weren’t yet powerful enough.)

People were pretty excited to see what Mathematica could do. And there were pretty nice speeches about the promise of Mathematica from a spectrum of computer industry leaders, including Steve Jobs (then at NeXT), who was kind enough to come even though he hadn’t appeared in public for a while. And someone at the event had the foresight to get all the speakers to sign a copy of the book, which had just gone on sale that day at bookstores all over the country:

So much has happened with Mathematica in the quarter century since then. What began with Mathematica 1.0 has turned into the vast system that is Mathematica today. And as I look at the 25th Anniversary Scrapbook, it makes me proud to see how many contributions Mathematica has made to invention, discovery and education:

But to me what’s perhaps most satisfying is how the fundamental principles on which I built Mathematica have stood the test of time. And how the core ideas and language that were in Mathematica 1.0 persist today (and yes, most Mathematica 1.0 code will still run unchanged today).

But, OK, where did Mathematica come from? How did it come to be the way it is? It’s a long story, really. Deeply entwined with my own personal story. But particularly as I look to the future, I find it interesting to understand how things have evolved from all that history.

Perhaps the first faint glimmering of an orientation toward something like Mathematica came when I was about 6 years old—and realized that I could “automate” those tedious addition sums I was being given, by creating an “addition slide rule” out of two rulers. I never liked calculational math, and was never good at it. But starting around the age of 10, I became increasingly interested in physics—and doing physics required doing math.

Electronic calculators arrived on the scene when I was 12—and I immediately became an enthusiast. And around the same time, I started using my first computer—an object the size of a large desk, with 8 kilowords of 18-bit memory, programmed mostly in assembler using paper tape. I tried doing physics with it, to no great success. But by the time I was 16, I had published a few physics papers, left high school, and was working at a British government lab. “Real” theoretical physicists basically didn’t use computers in those days. But I did. Alternating between an HP desk calculator (with a plotter!) and an IBM mainframe programmed in Fortran.

I was basically just doing numerics, though. But in the physics I wanted to do, there was all sorts of algebra. And not just a little algebra. Huge amounts. Expressions from Feynman diagrams with hundreds or thousands of terms, all of which had to be precisely right if one was going to get the right answer.

I wondered what to do. I imagined spending my life chasing minus signs and factors of 2. But then I started thinking about using a computer to help. And right then someone told me that other people had had that idea too. There were three programs that I found out about—all as it turned out started some 14 years earlier from a single conversation at CERN in 1962: Reduce (written in LISP), Ashmedai (written in Fortran) and Schoonschip (written in CDC 6000 assembler).

The programs were specialized, and it wasn’t clear how many people other than their authors had ever used them seriously. They were pretty clunky to use: typically you’d submit a deck of cards, and then some time later get back a result—or more often a cryptic error message. But I managed to start doing physics with them.

Then in the summer of 1977 I discovered the ARPANET, or what’s now the internet. There were only 256 hosts on it back then. And @O 236 went to an open computer at MIT that ran a program called Macsyma—that did algebra, and could be used interactively. I was amazed so few people used it. But it wasn’t long before I was spending most of my days on it. I developed a certain way of working—going back and forth with the machine, trying things out and seeing what happened. And routinely doing weird things like enumerating different algebraic forms for an integral—then just “experimentally” seeing which differentiated correctly.

My physics papers started containing all sorts of amazing formulas. And not imagining that I could be using a computer, people started thinking that I must be some kind of great human algebraic calculator. I got more and more ambitious, trying to do more and more with Macsyma. Pretty soon I think I was its largest user. But sometime in 1979 I hit the edge; I’d outgrown it.

And then it was November 1979. I was 20 years old, and I’d just gotten my PhD in physics. I was spending a few weeks at CERN, planning my future in (as I believed) physics. And one thing I concluded was that to do physics well, I’d need something better than Macsyma. And after a little while I decided that the only way I’d really have a chance to get what I wanted was if I built it myself.

And so it was that I embarked on what would become SMP (the “Symbolic Manipulation Program”). I had a pretty broad knowledge of other computer languages of the time, both the “ordinary” ALGOL-like procedural ones, and ones like LISP and APL. At first as I sketched out SMP, my designs looked a lot like what I’d seen in those languages. But gradually, as I understood more about how different SMP had to be, I started just trying to invent everything myself.

I think I had some pretty good ideas. And actually even some of my early SMP design documents have a remarkably Mathematica-like flavor to them:

Looking back at its documentation, SMP was quite an impressive system, especially given that I was only 20 years old when I started designing it. But needless to say, not every idea in SMP was good. And as a long-time connoisseur of language design, I can’t resist at the bottom of this post mentioning a few of my “favorite” mistakes.

Even in my early designs, SMP was a big system. But for whatever reason, I didn’t find that at all daunting. I just wanted to go ahead and implement it. I wanted to make sure I did everything as well as possible. And I remember thinking: “I don’t officially know computer science; I’d better learn it”. So I went to the bookstore, and bought every book I could find on computer science—the whole half shelf of them. And proceeded to read them all.

I was working at Caltech back then. And I invited everyone I could find from around the world who’d worked on any related system to come give a talk. I put together a little “working group” at Caltech—which for a while included Richard Feynman. And I started recruiting people from around the campus to work on the “SMP Project”.

A big early decision was what language SMP should be written in. Macsyma was written in LISP, and lots of people said LISP was the only possibility. But a young physics graduate student named Rob Pike convinced me that C was the “language of the future”, and the right choice. (Rob went on to do all sorts of things, like invent the Go language.) And so it was that early in 1980, the first lines of C code for SMP were written.

The group that worked on SMP was an interesting one. My first recruit was Chris Cole, who’d worked at IBM and become an APL enthusiast, and went on to found a rather successful company called Peregrine Systems. Then there were students with a variety of different skills, and a programming-enthusiast professor who’d been a collaborator of mine on some physics papers. There was some eccentricity along the way, of course. Like the person who wrote very efficient code, all on one line, with functions colorfully named so their combinations would read as little jokes. Or the quite brilliant undergraduate who worked so hard on the project that he failed all his classes, then promised he wouldn’t touch a computer—but was soon found dictating code to someone else.

I wrote lots of code for SMP myself (about 1000 lines/day). I did the design. And I wrote most of the documentation. I’d never managed a large project before. But somehow that part never seemed very difficult. And sure enough, by June 1981, SMP Version 1 was running—and even looking a bit like Mathematica:

For its time, SMP was a very big software system (though its executable was just under a megabyte). Its original purpose was to do mathematical computation. But along the way I realized that even to do that well, I had to create a whole, rather general, symbolic language. I suppose I saw it as being a bit like physics—but instead of dealing with elementary particles, I was trying to find the elementary components of computation. I developed a kind of aesthetic: always try to pack the largest capability into the smallest number of primitives. Sometimes I would puzzle for weeks about how to do something—but in the end I’d come up with a design, then implement it.

I understood the idea that everything could be represented by symbolic expressions. Although the whole business of symbolically indexed lists prevented SMP from having the notion of “expression heads” that’s so clean in Mathematica. And there was definitely some funkiness in the internal implementation of symbolic expressions—most notably bizarre ideas about storing all numbers in floating point. (Tini Veltman, author of Schoonschip, and later winner of a physics Nobel Prize, had told me that storing numbers in floating point was one of the best decisions he ever made, because FPUs were so much faster at arithmetic than ALUs.)

Before SMP, I’d written lots of code for systems like Macsyma, and I’d realized that something I was always trying to do was to say “if I have an expression that looks like this, I want to transform it into one that looks like this”. So in designing SMP, transformation rules for families of symbolic expressions represented by patterns became one of the central ideas. It wasn’t nearly as clean as in Mathematica, and there were definitely some funky and far-out ideas. But a lot of the core elements were already there.

And in the end, the table of contents from the SMP Version 1.0 documentation from 1981 had a fair degree of modernity:

Yes, “graphical output” is relegated to a small section, alongside “memory management”. And there are the charming “programming impasses” (i.e. system hangs), as well as “statistical expression generation” (i.e. making random expressions). But “parallel processing” is already there, along with “program construction” (i.e. code generation). (SMP even had a way of creating C code, compiling it, and, very scarily, dynamically linking it into the running SMP executable.) And there were lots of mathematical functions, and mathematical operations—though vastly less powerful than in Mathematica.

But, OK. So SMP 1.0 was running. What should be done with it? It was pretty clear there were lots of people who would find it useful. It only ran on quite big computers—so-called “minicomputers”, like the VAX, that was the size of several large refrigerators, and cost a few hundred thousand dollars. But still, I knew there were plenty of research and engineering organizations that had such machines.

I really didn’t know anything about companies or business at the time. But I did understand that it cost money to pay people to work on SMP, and it seemed pretty obvious that a good way to get that money was to sell copies of SMP. My first idea was to go to what would now be called the “technology transfer office” at Caltech, and see if they could help. At the time, the office essentially consisted of one pleasant old chap. But after a few attempts, it became clear he really didn’t know what to do. I asked him how this could be, given that I assumed similar things must come up all the time at Caltech. “Well”, he said, “the thing is that faculty members mostly just go off and start companies themselves, so we never get involved”. “Oh”, I said, “can I do that?”. And he leafed through the bylaws of the university and said: “Software is copyrightable, the university doesn’t claim ownership of copyrights—so, yes, you can”.

And so off I went to start a company. But it wasn’t as simple as that. Because a little while later the university administration suddenly decided that, no, it wasn’t OK. It got very weird—and scurrilous (“give me a cut, and I’ll sign off on this”, etc.). Richard Feynman and Murray Gell-Mann interceded on my behalf. The president of the university didn’t seem to know what to do. And for a while everything was completely stuck. But eventually we agreed that the university would license whatever rights they might have—even though they were (very foolishly, as it later turned out when they tried to recruit computer science faculty) changing their bylaws about software.

As it happened there was one “last problem” though, come up with by the then-provost of the university. He claimed that having a license in place between the university and the company created a conflict of interest if I worked at the university and owned part of the company. “OK”, I said, “that’s easy to resolve: I’ll quit the university”. That seemed to come as a big surprise. But quit I did, and moved to the Institute for Advanced Study in Princeton, where, as the then-director pointed out, they’d “given away the computer” when John von Neumann died, so they couldn’t really be too worried about intellectual property.

For years, I’d wondered what had actually been going on at Caltech. And as it happens, just a couple of weeks ago, I agreed to visit Caltech again (to get a “distinguished alumnus award”), and having lunch at the faculty club there—I discovered that at the next table was none other than the former provost of Caltech, now about to turn 95. I was very impressed at his immediate and deep recall of what he called “the Wolfram Affair” (was he “warned”?), and the conversation we had finally explained things a bit better.

Frankly, it was more bizarre than I could have possibly imagined. The story in a sense began in the 1930s, when Arnold Beckman was at Caltech, invented the pH meter, and left to found Beckman Instruments. By 1981, Beckman was a major donor to Caltech, and the chairman of its board of trustees. Meanwhile, the chairman of its biology department (Lee Hood) was inventing the gene sequencer. He’s told me he tried many times to interest Beckman Instruments in it, but failed, and so started his own company (Applied Biosystems), which became very successful. At some moment, I’m told, Arnold Beckman got upset, and told the administration that they needed to “stop IP walking off campus”. Well, it turned out that the only thing of relevance happening on campus right then was none other than my SMP project. Which the then-provost said he thought he had a duty to “deal with”. (Well, he was also a chemist, who Feynman and Gell-Mann, as physicists, claimed had a “thing about physicists”, etc.)

But notwithstanding this whole adventure, the company that I named Computer Mathematics Corporation got started. At the time, I still thought of myself as a young academic, and didn’t imagine that I’d know how to run a company. So I brought in a CEO, who happened to be about twice my age. And at the behest of the CEO and some venture capitalists, the company arranged to merge with a startup that was doing what they thought was going to be really hot artificial intelligence R&D.

Meanwhile, SMP began to be sold under the banner of “mathematics by computer”:

There were horrible missteps. CEO: “Let’s build a workstation computer to run SMP”; me: “No, we’re a software company, and I’ve seen this Stanford University Network (SUN) system that’s going to be better than anything we can build”. And then there were the charmingly misguided agency-created ads:

And pretty soon I decided the whole thing was too frustrating. SMP remained something of a cash cow, and although the CEO wasn’t good at making money, he was good at raising it, going through a dizzying number of investment rounds—until there was finally an undistinguished IPO many years later.

I was meanwhile having a terrific time doing basic science, and discovering things that laid the foundations for A New Kind of Science. And in fact SMP turned out to be a crucial precursor to what I did. Because it was my success in inventing computational primitives for the language of SMP that got me thinking about inventing computational primitives for nature—and building a science from studying the consequences of those primitives.

You might ask what happened to SMP. It continued to be sold until sometime after Mathematica was released. None of its code was ever used for Mathematica. But occasionally I used to start it up, just to see how it “felt” compared to Mathematica. As time went by, it became harder to find computers that would run SMP. And perhaps 15 years ago, the last computer we had that could run SMP stopped working.

Well, I thought, I’d always been sent a personal copy of the SMP source code—though I hadn’t looked at it for ages. So now why not just recompile it on a modern system? But then I remembered: I’d had this “great” idea that we should keep the source code encrypted. But what was the key? I asked everyone I could think of. But nobody remembered.

It’s been years now, and I’d really like to see SMP run again. So here’s a challenge. This is the source for a C program encrypted like the SMP source code. Actually, it’s the source for the program that did the encryption: a version of the circa-1981 Unix crypt utility, “cleverly” modified by changing parameters etc. Can someone break the encryption? And finally free SMP from the strange digital time safe in which it’s been locked for so long. (Here’s what Wolfram|Alpha Pro has to say if one just uploads this raw file)

But back to the main story. I stopped working on SMP in 1983, and began alternating between basic science, software projects, and my (wonderfully educational) “hobby” of doing technology and strategy consulting. I used SMP a bit, but mostly I ended up writing lots and lots of C code, usually gluing together algorithms and graphics and interfaces.

The science that I’d started was going very well—and it was clear that there were lots of important things to do. But instead of trying to do it all myself, I decided I should try to get other people involved. And as part of that, I resolved to start a research institute—and got what amounted to bids from different universities for it. The University of Illinois was the winner, and so in August 1986 off I went there to start the Center for Complex Systems Research.

But by this point I was already getting concerned that my scheme of “other people doing the science” wasn’t so good. And within just a few weeks of arriving in Illinois I’d come up with plan B: build the best tools I could, and the best personal environment I could, and then try to do as much science as I could myself. And since I was pretty well plugged into the computer industry, I knew that powerful software systems would soon be able to run on the zillions of personal computers that were starting to appear. So I knew that if I could build something good, there’d be a good market for it, that would support an interesting company and environment.

And so it was that late in August 1986, I decided to try to build my ultimate computation system—that could do all the computations I wanted, or could imagine I would ever want.

And of course the result was Mathematica.

I knew a lot about what to do (and not do) from SMP and my other software experiences. But it was refreshing to be able to start from scratch, just trying to get the design right, without prior constraints. In SMP, algebraic computation had been the central goal. But in Mathematica, I wanted to cover lots of other areas too—numerics, graphics, programming, interfaces, whatever. I thought a lot about the foundations for the system, wondering for example whether things like the cellular automata I’d studied in my basic science could be relevant. But I just kept on coming back to the basic paradigm I’d already developed for SMP. Symbolic expressions and transformations for them seemed exactly right as a high-level, yet general, representation for computation.

If it hadn’t been for SMP, I would certainly have made a lot of mistakes. But SMP pretty much showed me what was important and what was not, and where the issues were. Looking through my archives today, I can see the painstaking process of puzzling through problems that I knew from SMP. And one by one coming up with solutions.

Meanwhile, just as for SMP, I’d assembled a team, and started the actual implementation of Mathematica. I’d also started a company—this time with me as CEO. Every day I’d write lots of code. (And to my chagrin, quite a bit of that code is still running in Mathematica today, especially in the pattern matcher and evaluator.) But my biggest focus was design. And following a practice I’d started with SMP, I wrote documentation as I developed the design. I figured if I couldn’t explain something clearly in documentation, nobody was ever going to understand it, and it probably wasn’t designed right. And once something was in the documentation, we knew both what to implement, and why we were doing it.

The first code for Mathematica was written in October 1986. And by the middle of 1987 Mathematica was beginning to come to life. I’d decided that the documentation should be published as a book, and hundreds of pages were already written. And I estimated that Mathematica 1.0 would be ready by April 1988.

My original plan for our company was to concentrate on R&D, and to distribute Mathematica primarily through computer manufacturers. Steve Jobs was the first to take Mathematica on, making a deal to bundle it with every one of his as-yet-unreleased NeXT computers. Deals with Sun, Silicon Graphics, IBM and a sequence of other companies followed. We started sending out a few beta copies of Mathematica. And—even though this was long before the web—word of its existence began to spread. Some media coverage started up too (I still like that kind of ice cream):

Sometime in the spring of 1988, we officially set June 23 as the release date for Mathematica (without Wolfram|Alpha, I didn’t know it was Alan Turing’s birthday, etc.). There was a lot to get ready. In those days releasing software didn’t just involve flipping a switch. Like I remember we were right down to the wire in getting The Mathematica Book printed. So I flew to Canada with a hard disk and personally babysat a phototypesetting machine for a long weekend, handing the box of film it produced to a person who met me at the airport in Boston and rushed it to the printer. But despite adventures like that, shortly before June 23 off were mailed some mysterious invitations:

And at noon on June 23 the room had filled, and we were ready to launch Mathematica into the world.

It’s been a great 25 years since then. The foundations that we laid in Mathematica 1.0—greatly informed by my earlier experiences—have proved incredibly robust, and we’ve been able to just build and build on them. My “plan B” of developing Mathematica, then using it to do science, worked out just great, and led to A New Kind of Science. And from Mathematica, we’ve been able to build a great company, as well as build things like Wolfram|Alpha. And over the course of 25 years, we’ve had the pleasure and privilege of seeing Mathematica contribute in all sorts of ways to many things in the world.

What was SMP like? Here are a few examples of SMP programs that I wrote for the SMP documentation:

In some ways these look quite similar to Mathematica programs—complete with [...] for functions, {...} for lists and -> for rules. But somehow the readability that’s a hallmark of Mathematica isn’t there, and instead the SMP programs seem quite cryptic and obscure.

One of the most obvious problems is that SMP code is littered with $ and % characters—appearing respectively as prefixes for pattern and local variables. In SMP, I hadn’t had the Mathematica idea of separating pattern constructs (such as _) from names (such as x). And I thought it was important to emphasize which variables were local—but didn’t have a subtle cue like color to do it with.

In SMP I’d already had the (good) idea of distinguishing immediate (=) and delayed (:=) assignment. But in a nod to languages like ALGOL, I indicated them by the rather obscure : and :: (For rules, -> was the immediate form, as it is Mathematica, while --> was the analog of :> and S[...] was the analog of /. )

In SMP, just like in Mathematica, I indicated built-in functions with capital letters (at the time it was a fairly new thing to distinguish upper and lowercase at all on a computer). But while Mathematica typically uses English words for function names, SMP used short—and often cryptic—abbreviations. When I was working on SMP, I was quite taken with the design of Unix, and wanted to emulate its practice of having short function names. That might have been OK if SMP had just a few functions. But with hundreds of functions with names like Ps, Mei and Uspb things began to get pretty unreadable. Of course, back then, there was another issue: lots of users couldn’t type quickly—so that provided a motivation to have short function names.

It’s interesting to look at the SMP documentation today. SMP had plenty of good ideas—most of which I used again in Mathematica. But it also had some quite bad ideas—which happily aren’t part of Mathematica. One example of a bad idea—that even sounds bad as soon as one hears it—are “chameleonic symbols”: symbols that change their name whenever they’re used. (These were an attempt at localizing things like dummy variables, a bit like an over-automated form of Module.)

There were some much more subtle mistakes too. Like here’s one that in a sense came from trying to go too far in unifying the system. Like Mathematica, SMP had a notion of lists, like {a,b,c}. It also had functions, like f[x]. And in my effort to achieve the maximum possible unification, I thought that perhaps one could combine the notion of lists and functions.

Let’s say one has a list v={a,b,c}. (In SMP assignment was done with :, so this would have been written v:{a,b,c}.) Then for example in SMP v[2] would extract the second element in the list. But this notation looks a lot like asking for the value of a function v when its argument is 2. And this gave me the idea that perhaps one could generalize lists—to have not just integer-indexed elements, but elements with arbitrary symbolic indices.

In SMP, pattern variables (x_ in Mathematica) were written $x. So when one defined a function f[$x] : $x^2 one could imagine that this was just defining f itself to have a value that was a symbolically indexed list: {[$x]: $x^2}. If you wanted to find out how a function was defined, you just typed its name—like f. And the value that came back would be the symbolically indexed list that represented the definition.

An ordinary vector-type list could be thought of as something like {[1]:a, [2]:b, [3]:c}. And one could mix in symbolic indices: {[1]: 1, [$x]:$x f[$x-1]}. There was also a certain unification with part numbering in general symbolic expressions. And at some level it all seemed rather nice. And to describe my unified concept of functions and lists, I called the f in f[x] a “projection”, and x a “filter”. (There were jokes about lists of definitions being “optical benches”.)

But gradually cracks started appearing. It got pretty weird, for example, when one started making definitions like v[2]:b, v[3]:c. According to SMP’s conventions for assignments v would then have value {[3]:c, [2]:b}. But what if one made a definition like v[1]:a? Well, then v suddenly had to reorder itself as {a, b, c}.

It got even weirder when one started dealing with multi-argument functions. It was quite nice that one could define a matrix with m:{{a,b},{c,d}}, then m[1] would be {a,b}, and either m[1,1] or m[1][1] would be a. But what if one had a function with several arguments? Would f[x, y] be the same as f[x][y]? Well, sometimes one wanted it that way, and sometimes not. So I had to come up with a property (“attribute” in Mathematica)—that I called Tier—to say for every function which way it should work. (Today more people might have heard of “currying”, but in those days this kind of distinction was really obscure.)

Symbolically indexed lists in SMP had some really powerful and elegant features. But in the end, when the whole system was built, there were just too many weirdnesses. And so when I designed Mathematica I decided not to use them. Over the years, though, I’ve kept thinking about them. And as it happens, right now, more than 30 years after SMP, I’m working on some very interesting new functionality in Mathematica that’s closely related to symbolically indexed lists.

I learned a huge amount designing SMP—and then seeing how the design played out. One particularly memorable moment for me was this. Like Mathematica, SMP had pure functions. But unlike Mathematica, it didn’t have a syntax like & to indicate them. And that meant that it needed a special object called a “mark” (written `) to indicate when a pure function was supposed to give a literal, constant, value. Well, about 5 years after SMP was released, I was looking at one of its training manuals. And out jumped at me the sentence: “Marks are the enigma of SMP”. And in that moment I realized: that’s what a language design mistake looks like.

SMP was in many ways a very radical system—a kind of extreme experiment in programming language design. It had only grudging support for most of what were then familiar programming constructs. And instead almost everything in it revolved around the idea of transformation rules for symbolic expressions. In some ways I think SMP went too far into the unfamiliar. Because in a sense what a programming language has to do is to connect the human conception of a computation to an actual computation that a computer can execute. And however powerful a language is, it doesn’t do much good if humans don’t have enough context to be able to understand it. Which is why in Mathematica, I’ve always tried to make things familiar when I can, limiting the unfamiliar to places where it’s really needed in supporting things that are fundamentally new.

One of the things about designing a system is knowing what’s going to end up being important. In SMP, we spent a lot of effort on what we called “semantic pattern matching”. Let’s say one made a definition like f[$x+$y, $x, $y] := {$x, $y}. It’s pretty clear that this would match f[a+b, a, b]. But what about f[7, 3, 4]? In SMP, that would match—even though the 7 isn’t structurally of the form $x+$y. It took lots of effort to make this work. And it was neat to see in simple examples. But in the end, it just didn’t come up very often—and when it did, it was usually something to avoid, because it typically made the operation of programs really hard to understand.

There was something similar with recursion control. I thought it was bad to have f[$x] : $x f[$x-1] (with no end condition for f[1]) go into an infinite loop trying to evaluate f[-1], f[-2], etc. Because after all, at some point there’s multiplication by 0. So why not just give 0? Well, in SMP the default was to give 0. Because instead of running all the way down the evaluation of each branch of the recursion tree, SMP would repeatedly stop and try to simplify all the unevaluated branches. It was neat and clever. But by the time one started parametrizing this behavior it was just too hard for people to understand, and nobody ended up using it.

And then there was user-defined syntax. Allowing users for example to set “U” (say, for “union”) to be an infix operator. Which worked great until one wanted to type a function with a “U” in its name. Or until one completely trapped oneself in one’s syntax, diverting the parsing of any form of escape.

SMP was a great learning experience for me. And Mathematica wouldn’t be nearly as good if I hadn’t done SMP first. And as I reflect now on “mistakes” in SMP, one thing I find quite satisfying is that I don’t think I’d make any of them today. Between SMP and 25 years of Mathematica design, most of them would now fall into the category of “easy issues” for me.

It’s funny, though, how often variations of some of the not-so-good ideas in SMP seem to come up. And actually I’m very curious with my modern design sensibilities how exactly I’d feel about them if I ran SMP today. Which is part of the reason I’m keen to release SMP from its “digital time safe”, and get it running again. Which I hope someone out there is going to help me make possible.