Richard P. Gabriel is Sun Microsystems's open-source expert. He has written four books and more than 100 articles, mostly about programming languages and practices. He's leader of the Feyerabend Project, whose goal is "to repair the arena of software development and practice." It was inspired by the philosopher Paul Feyerabend, who wrote in 1975, "Given any rule, however 'fundamental' or 'necessary' for science, there are always circumstances when it is advisable not only to ignore the rule, but to adopt its opposite." Gabriel recently told Computerworld's Gary H. Anthes what's wrong with software today and how it might be improved.
Q: What's wrong with today's programming languages? They are brittle. They were based on the assumption that computers were for scientific and engineering applications. They were designed when computers did thousands of instructions per second, not billions. And when computers cost millions, programmers cost US$12,000 a year. Now developers cost $50,000 to $200,000 a year, and they can each have the equivalent of five Cray 2's [supercomputers] on their desk. So it's time to use some of that CPU power to help the programmer.
Q: How could languages be less brittle? The software we build doesn't exhibit homeostasis that's when an organism is perturbed, it tries to return to its normal state. When someone hacks into a Unix system and does something bad, it doesn't get better until someone repairs it and it is rebooted. But you could make every component in the system tend toward its default state over time. You could have the programming language set up so that your system kind of gravitates back toward its initial state. If you had proposed that in 1959, when programming language ideas were being thought up, they'd have said, "That's crazy. Why would we waste our computers' time doing that?"
Q: What else could be done?
From the late 1970s to the late 1980s, folks in the artificial intelligence world tried to program computers differently, with languages like LISP. They had expert systems, which is an easier way to program a computer and not as susceptible to errors. On the other hand, the results that you got might not be precisely what you expected. A rule-based system will give you robust, flexible behavior which is at the 95 percent level, but certainly sufficient. We have abandoned all of these ways of programming. Java goes a fair way to some of these goals, but still there is a relentless insistence on correctness and precision instead of flexibility and adaptability.
Q: Are you suggesting we write applications today as expert, or rule-based, systems? Is that possible? I am taking Microsoft Word and programming it up as a rule-based system. Maybe there is enough horsepower for every keystroke to be interpreted by rules. Then, if one of your colleagues added something to their version of Word that was written that way, all you would have to do to incorporate those things is just throw them into your pile of rules. You could add or change rules, and the thing wouldn't break. It's a proof of concept to see if there's enough horsepower in the computers to do this.
Q: You've suggested that users are not involved enough in software development. How can you get user involvement? Software designers put their backs to the world and they face technology. Their lingua franca is source code. If you can't talk source code, they won't pay attention to you.
But if you look at something like extreme programming, which tries to involve the actual users right away, they build a little bit, they give it to the users, they get feedback right away before they have made a lot of commitments and they incrementally build something that is maybe pretty darn good in the first release. They've built something better and faster and saved their shareholders money.
Q: What's the next milestone for the Feyerabend project? We just held a workshop in which we came up with a set of problem statements that can guide the research of software folks over the next 10 to 20 years.
For example, "Design a system where if someone deletes 1KB of code, the system will self-repair in 24 hours." I will be summarizing the workshop in the next month, and we will publish a manifesto. Maybe some prizes will be given for them.