As president of the Open Source Initiative (www.opensource.org), Eric Raymond is working hard to build bridges between old-line Unix programmers and the emerging Linux evangelists in the business world.
But much more than these goals fill the plate — and mind — of the author of “The New Hacker’s Dictionary,” the now-legendary 1991 book about the Internet and hacker culture. (http://www.catb.org/~esr//jargon).
For one, he’s out with his new book, “The Art of Unix Programming” (Addison-Wesley, 2003), which offers insights into programming culture and thought-processes about working with Unix. During a break in his promotion schedule with the book recently, Raymond chatted up a bunch of technology topics with internetnews.com.
Q: Over the past decade, programmers going through school cut their teeth on Windows. Is this still the case or are they learning now on Linux?
Both things are happening. The one thing that’s clear is, it’s all PCs today. The minicomputers, the mainframes — from the point of view of the kids today, those machines might as well never have existed.
Q: Any other trends that you see as important?
The switch to 64-bit [computing] is going to be a bigger deal than I thought a few years ago. And the reason for that is, the demand for really large address spaces is happening faster than I thought it would.
Q: XML (Extensible Markup Language) is wildly
popular with developers right now. Are there any misconceptions people have about what it can do?
The most serious misunderstanding that I run into about XML is that it’s somehow going to magically solve their data structure and data-organization problems. XML won’t do that, because XML is basically just a syntax. It only resolves the low-level issues of how you join up records and write down a structure that you designed at some higher level. There are still a whole host of issues about document types, database schemas, and about how to move
data between different schemas and different document type, which XML doesn’t solve by itself. The real world is heterogeneous. It’s always been that way, it’s always going to be that way.
Q: Let’s talk about XML security.
I know the guy who’s running the XML Digital Signatures group. There’s a standard that he expects will be issued shortly. At that point, we will have a standardized way of securing XML data blocks in a way that can be verified. And that kind of authentication and encryption is of course the basic building block of security. So I think we’ll some significant developments in deployment in the very near future.
Q: What do you think about SOAP, the XML-based Simple Object Access Protocol that supports the exchange of information in distributed environments?
I actually think SOAP
There’s a phenomenon we call second-systems syndrome, where you design an early system that does 80 percent of the job. It’s fairly lightweight, and you notice all the things you should have done Then you go back for the second system, and often there’s a tendency to go overboard to the point where it collapses under its own weight.
SOAP has a bad case of second-systems effect. I don’t think SOAP is going to remain viable because of the overweight. One of two things is going to happen. Either people are going to decide that XML RPC is sufficient after all, or somebody is going to come along and do a third system.
Q: What’s your take on Java?
I’m not very involved in Java.
Q: Speaking of scripting languages, along with Python there’s Perl and PHP. Your thoughts?
I think these new-generation scripting languages are very handy, powerful tools. They don’t solve every problem, but they give you such tremendous leverage on rapid application development and getting a prototype up there that you can ticker with. That’s so valuable, because the development friction with conventional, compiled languages is so bad, that you don’t try
out a lot of alternatives. You don’t have the freedom to experiment.
Q: Scripting languages used to take second place to compiled languages because they took up too many computing cycles. Is that issue now moot?
Sure. The whole history of development tools is a history of machine time steadily becoming cheaper relative to programmer time. Or to put it another way, programmer time has steadily been getting more expensive relative to machine time, and as that happens it makes more sense to automate the low-level bookkeeping [like] resource and memory management, so that programmers can concentrate on higher level tasks. And that’s really what scripting languages do for you.
Q: A related question: has the availability of cheap cycles led to software bloat and also killed the idea that apps need to be well engineered?
I don’t think that cheaper machine resources pulled the rug out from under software engineering. If anything, they make clean design more necessary, because it’s so easy to write huge volumes of code.
Viewed from 30,000 feet when you’re looking at functional differences between the languages, Perl and Python are pretty close. Anything you can do with one, you can pretty much do with the other. The difference is Python makes it moderately hard to write code that’s ugly and opaque. I find Python much easier to read six months down the road than Perl is. And I’ve become convinced that, at the scale of projects we’re doing today, long-term maintainability is probably the most important quality a language can have,
bar none. It’s more important than performance.
Q: Especially if all the maintaining is going to be done off shore?
Yeah! Not that I think that’s going to be a long-term trend. I think that’s going to reverse itself. I think they’re going to find there are large hidden costs that don’t tend to show up in dollars-and-cents cost accounting.
Q: In terms of cultural differences, or because you need developers on site so they can communicate?
Both of those things, and also loss of customer contact. And then the biggie, which is that if you are off-shore, you’re losing institutional knowledge. You’re hollowing out your organization in a way that’s going to come back to haunt you later on. So I think off-shoring is just another management fad and we’re going to see it blow over.