Reading 04: Lost in Translation

One of the things I found inconsistent about Paul Graham’s discussion of “the 100-year language” and throughout all the Lisp evangelization, was that Lisp by definition seems to be excluded from his 100-year language criteria and yet, he couldn’t stop raving about how every other language was just now about to catch up to Lisp. In the 100-year language chapter he emphasized that in the future we will and probably should trade programming convenience for execution efficiency. The hardware of the future will enable us to make those types of inefficient programs because it will put many extra cycles at our disposal. He goes on to say that the language of the future is basically the pseudocode you would write to solve a problem if there were no syntax or compiler restraints to do so today, and that is the language you should write for the future. Fine. But then he goes on a two-chapter rant about how powerful Lisp is and how it allowed Viaweb to keep their hold on the online marketplace software. Lisp is almost certainly not what someone would come up with if they had to write pseudocode to solve a problem. The syntax is very much not intuitive to a programmer sitting down and hacking out an MVP unless they are Lisp wizards. I take all of points about Lisp being more powerful, and I will probably venture to learn more about macros going forward. However, it is clear that Graham’s bias towards Lisp forced him to construct a benchmark for the 100-year language that he thought only Lisp could live up to, but in fact, he was the only one who could see it that way because he himself is a Blub programmer.

That aside, Graham made some convincing arguments about the importance of picking the best, most powerful language in software design. I thought it was interesting that he discriminated between programming language choice in startups v. large organizations. In startups you are usually the master of every piece of software your company has to use, so you can choose to make it whatever you want. In a large organization, you will have to interface with software not written in the most powerful language, and your manager might require you to explicitly not use the most powerful language because the less powerful one makes repeatable, expected results. I think at this point, both types of companies will begin to converge on languages not for their efficiency or syntactical ease but for the availability of and dev support for libraries in that language.

Graham clearly recognizes library support is not a strong-suit for Lisp, and on page 191 he argues that libraries are suitable for quick and dirty projects that won’t ever become large applications and that the benefits of a couple hackers using the most powerful language available will outweigh the benefits of pre-existing libraries. I fundamentally disagree. Technologies and methodologies are changing so rapidly that it is almost become demanding that to build a comprehensive new product you have to stand on the shoulders of the giants that came before to develop wholistic software products. Take wireless communication. At the time when Graham was making server-side applications for the web, he really only had to care about socket programming. Today, if you are doing application development, you are likely targeting mobile and that means you have to consider development for Bluetooth and wireless. Without languages, like Python, with pre-existing libraries to manage interactions with those technologies’ stacks, your organization would essentially have to program their own device drivers and maintain them over the life of your product. What a nightmare. “Data science” for all the misgivings I have about that term, is the same way. Are there enough mathematical geniuses who also happen to know Lisp that any more than 10 startups could do something in the field of data analysis? Probably not. As the technological world gets more complex in hardware and ideas, the availability of libraries to make development sensible will be the defining factor of the language of the future. That’s why open source languages are so successful and why, despite my philosophical disagreements with the way the language allows people to abuse software design, Python is likely the best bet at being the language that is still around in 100 years.