Thursday, July 15, 2004

Learning Lisp
I've decided to learn Lisp.

Of all of the new technical kicks I could go on, this seems the least likely. I haven't even mentioned to my other hacker friends, because I'll get quizzical looks and disparging remarks. But I picked up Paul Graham's Hackers and Painters this week at the bookstore (literally - I haven't bought it yet, but fully intend to) and started reading. I've read many of his essays - and the new book mostly expands on those essays - but he convinced me about the value and relevance of Lisp in a way he hadn't before.

The three main points that convinced me were:

  • All other languages are gradually evolving into Lisp.
  • You can express things in Lisp, easily, that you can't express in other languages.
  • The right way to write programs is bottom-up, not top-down.

All of these things come together in a single, compelling idea:
The programs you write in Lisp will be fundamentally different - you will get a larger language with more abstract operators and a smaller program written in it.

I've been trying to work towards something roughly similar lately by trying to build systems that consist of two kinds of components - low-level components that solve generic problems and high-level components that reflect and provide solutions in terms of the problem domain. This is hardly an original idea, but I've seen very few systems that really attempted to model their problem domains in non-naive ways. Most "systems", frankly, are collections of code that lump together the features their designers and builders thought were important at the time they were building the system. I'm in the process of trying to rework/replace one of those kinds of systems right now.

I'm thinking in terms of building blocks - constructing something, lego-like, out of pre-fab materials, with the language as the mortar. The blocks and language are made out of the same material - the language - but they're conceptually and cognitively different.

Graham is suggesting something much more elegant. He's talking about expressing the solution directly, in the language itself. The difference is subtle - especially since I'm not expressing it very well - but huge. And it resonates with me to the point where I feel compelled to try to become proficient in the language. Even, possibly, to write real systems in it.

I still firmly believe Dennis Ritchie's dictum that the way to learn a language is to write programs in the language. I've gotten myself back up to speed in the basics (I noodled around in Interleaf Lisp about 10 years ago, but never really learned to use the idioms of the language properly). So now I need to pick some programs to write.

No comments: