This is the sixth in a series of posts about Paul Graham’s book Hackers & Painters.
I knew that Paul Graham felt strongly about dynamic typing. It is, after all, a critical feature of Lisp, a language Graham is so enamored with that he wrote his own dialect of it. Still, I was surprised to see him use the heading “Seat Belts or Handcuffs?” for a section weighing dynamic vs. static typing in the book’s tenth chapter, “Programming Languages Explained.” He grudgingly admits that “some smart people seem to like static typing, so the question must still be an open one.” (In the next chapter, he elaborates on his reasons: “…static typing seems to preclude true macros—without which, in my opinion, no language is worth using.”)
Graham’s passion for dynamic typing pales in comparison to this astonishing claim about open source software: “I’m certainly not against the idea of property, and yet I would be very reluctant to install software I didn’t have the source for.” Why? Because if he has the source, he can fix any bugs he encounters. And, more importantly, so can everyone else. “Lots of smart people have examined the source code of open source operating systems like Linux and FreeBSD and have already found most of the bugs. Whereas Windows is only as reliable as big-company QA can make it.” That’s a bold statement, and I’m told that PG is no hypocrite: He runs nothing but Firefox and vi on his machine. But he’s also a fan of closed-source webapps. The distinction being, I suppose, that bugs in a webapp can only affect your system if there’s a bug in your web browser as well. System crashes are unpleasant, but using them as the foundation for such a broad principle is rather eccentric. It’s a bit like becoming vegan to avoid salmonella.
Graham once again runs into the audience problem: Is this book for hackers, or for the merely curious about hacking? The chapter is squarely aimed at the latter, explaining terms like “high-level language.” It seems to have been written primarily to bring the mass-market reader up to speed for the next chapter, “The Hundred Year Language.”
Having established that we are now living in a Renaissance of programming languages, he wonders what will happen over the next century. Some of his conclusions are uncontroversial: Mainstream languages will be more high-level than they are today, with more layers of abstraction between them and the machine. Processors will, after all, be many times more powerful than they are today, even if Moore’s law is indeed petering out. “Inefficient software isn’t gross. What’s gross is a language that makes programmers do needless work.”
He lambasts object-oriented programming, but predicts that it will stick around as an unfortunate legacy of the 20th century: “Though I don’t think it has much to offer good programmers, except in certain specialized domains, it is irresistible to large organizations.” This is a surprising stance. To most programmers, I would say, there is something intuitively very appealing about the clean separation of concerns that well-encapsulated objects provide so naturally.
But the most astonishing claim of the chapter is that “parallelism will be something that is available if you ask for it explicitly, but not ordinarily used. This implies that the kind of parallelism we have in a hundred years will not, except in special applications, be massive parallelism. I expect for ordinary programmers it will be more like being able to fork off processes that all end up running in parallel.” Really? There is, today, a resurgence in interest in functional languages because the number of cores in computers is increasing much more quickly than the power of individual cores is. In the year 2010, a popular word processor run on a single core seems rather pokey. Everyone is trying to build their applications for multiple cores. Future compilers will almost certainly be smart enough to provide us with parallelism automatically. Cores may be a million times faster, but text editors will have a billion times as much bloat.
0 responses so far ↓
Comments are closed.