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:
At the core of Mathematica is a language. A very powerful symbolic language. Built up with great care over a quarter of a century—and now incorporating a huge swath of knowledge and computation.
Millions and millions of lines of code have been written in this language, for all sorts of purposes. And today—particularly with new large-scale deployment options made possible through the web and the cloud—the language is poised to expand dramatically in usage.
But there’s a problem. And it’s a problem that—embarrassingly enough—I’ve been thinking about for more than 20 years. The problem is: what should the language be called?
Usually on this blog when I discuss our activities as a company, I talk about progress we’ve made, or problems we’ve solved. But today I’m going to make an exception, and talk instead about a problem we haven’t solved, but need to solve.
You might say, “How hard can it be to come up with one name?” In my experience, some names are easy to come up with. But others are really really hard. And this is an example of a really really hard one. (And perhaps the very length of this post communicates some of that difficulty…)
Let’s start by talking a little about names in general. There are names like, say, “quark”, that are in effect just random words. And that have to get all their meaning “externally”, by having it explicitly described. But there are others, like “website” for example, that already give a sense of their meaning just from the words or word roots they contain.
I’ve named all sorts of things in my time. Science concepts. Technologies. Products. Mathematica functions. I’ve used different approaches in different cases. In a few cases, I’ve used “random words” (and have long had a Mathematica-based generator of ones that sound good). But much more often I’ve tried to start with a familiar word or words that capture the essence of what I’m naming. Continue reading
“Someone has to make the first great ebook publishing company; it might as well be us.” So I said a few weeks before the iPad was released this April. And a little while later Touch Press was formed. The iPad was released, and simultaneously, Touch Press’s first book The Elementswas released. The book has been on the iPad bestseller list ever since—in addition to being featured in all sorts of iPad television commercials and the like.
Well, it’s good for a publishing company to have a successful first book. But for me it’s been getting a little old telling people that I’m a partner in a new publishing company, but so far we’ve only published one book. So it’s exciting to be able to say that as of this week, Touch Press has a second book: Solar System.
The creation of large data repositories has been a key historical indicator of social and intellectual development—and indeed perhaps one of the defining characteristics of the whole progress of civilization.
And through our work on Wolfram|Alpha—with its insatiable appetite for systematic data—we have gained a uniquely broad view of the many great data repositories that exist in the world today.
Some of these repositories are maintained by national or international agencies, some by companies and other organizations, and some by individuals. A few of the repositories are quite new, but many date back 40 or more years, and some well over a century. But there is one thing in common across essentially every great data repository: a core of diligent and committed people who have carefully shepherded its development.
Curiously, though, few of these people have ever met their counterparts in other domains of data. And in our work on Wolfram|Alpha we are almost certainly the first group ever to have had the pleasure of getting to know such a broad range of leaders of great data repositories.
And one of the things that we have discovered is that there is much in common in both the methods used and the issues faced by these data repositories. So as part of our contribution to the worldwide data community we have decided to sponsor a data summit to bring together for the first time the leaders of today’s great data repositories.
It’s not easy to make a big software system that really fits together. It’s incredibly important, though. Because it’s what makes the whole system more than just the sum of its parts. It’s what gives the system limitless possibilities—rather than just a bunch of specific features.
But it’s hard to achieve. It requires maintaining consistency and coherence across every area, over the course of many years. But I think it’s something we’ve been very successful at doing with Mathematica. And I think it’s actually one of the most crucial assets for the long-term future of Mathematica.
It’s also a part of things that I personally am deeply involved in.
Ever since we started developing it more than 21 years ago, I’ve been the chief architect and chief designer of Mathematica‘s core functionality. And particularly for Mathematica 6, there was a huge amount of design to do. Actually, I think much more even than for Mathematica 1.
In fact, I just realized that over the course of the decade during which were developing Mathematica 6—and accelerating greatly towards the end—I spent altogether about 10,000 hours doing what we call “design reviews” for Mathematica 6, trying to make all those new functions and pieces of functionality in Mathematica 6 be as clean and simple as possible, and all fit together.
At least the way I do it, doing software design is a lot like doing fundamental science.
In fundamental science, one starts from a bunch of phenomena, and then one tries to drill down to find out what’s underneath them—to try to find the root causes, the ultimate primitives, of what’s going on.
Well, in software design, one starts from a bunch of functionality, and then one needs to drill down to find out just what ultimate primitives one needs to support them.
In science, if one does a good job at finding the primitives, then one can have a very broad theory that covers not just the phenomena one started from, but lots of others too.
And in software design, it’s the same kind of thing.
If one does a good job at finding the primitives, then one can build a very broad system that gives one not just the functionality one was first thinking about, but lots more too. Continue reading