Wednesday, April 07, 2004
It's always difficult to write the first post of a new blog. Where do you start? What do you say? Will anybody actually read this and care anyway?
Well, in the spirit of just charging forward and getting on with it, let me describe Finding Lisp and why I created it.
I have been programming for more than 25 years. During that time, I have worked with a large number of programming languages and systems. Like many who came to programming during the 1970s, I first learned BASIC. This was followed over the years by assembly language, Pascal, Forth, Fortran, C, Scheme, C++, Perl, and finally Java. Through the years and this set of experiences, I have learned a lot about the art of programming and the tools a programmer uses to practice this art. Over time, these experiences have cultivated a philosophy of programming. It looks something like this:
- Programming tools, and specifically programming languages matter. You can cut down a tree with a variety of tools, but a good, sharp saw will do the job much faster and easier than a butter knife. BASIC is a butter knife.
- There are "natural speed thresholds" in the world, mostly associated with the limits of human perception. What I mean by this is that invariably when discussing programming languages, developers will bring up the issue of speed. Specifically, somebody will say, "Yea, language X is great, but it's slower than language Y, so I use language Y instead." Typically, somebody comes up with a micro-benchmark that shows that language Y does indeed take 100 microseconds less time than language X to perform some task. The question is, who cares? There is "fast" and then there is "fast enough." As long as the user perceives the operation as being fast enough, there is only marginal benefit to being faster.
- With Moore's Law in effect for decades now, the average computer is fast enough for most every common task. This is not to say that this is the case for every task or even that it will remain the case forever.
- Now that we have achieved "fast enough" for a large variety of tasks, it makes far more sense to say, "What can we use all these spare CPU cycles for?" In my opinion, we "spend" those cycles making programmers more productive. While Moore's Law has given us oodles of transistors to play with and computer processing speeds have ramped exponentially, the wet-ware inside a programmer's head is basically the same as it was thousands of years ago. People can only juggle complexity to a fixed extent. Note that the same things have happened previously. The move away from assembly language to higher level languages like Fortran, Pascal, and C came with the recognition that it was worth "spending" a few of those precious CPU cycles on a compiler that would allow programmers to write code more productively.
- Now the question is, if we agree that we can spend some cycles to make programmers more productive, what should that language be? Throughout my programming career, it has been interesting to watch languages evolve. I started with BASIC and ended up last at Java. Java has many of the hallmarks of a good modern language. It "spends" CPU cycles to make programmers more productive and largely succeeds. I am far more efficient as a programmer working in Java than I ever was in C++. Yes, my programs may run fractionally slower, but it's hard to tell on a modern CPU unless you were to compare two versions of the program side-by-side. While Java is not perfect, it has gone a lot farther than many other languages. The question is, what next?
- It seems to me that many languages are adding features that are already in existence in Lisp. For instance, Java and the various scripting languages like Perl, Python, and Ruby all have dynamic memory management ("garbage collection"). Languages like C++ have added templates to try to add something resembling a good macro system. These concepts have all been working quite well for decades in Lisp. So if most other languages are evolving towards Lisp, why not just use Lisp and get there faster?
Finding Lisp is a chronicle of my journey to learn and utilitize Lisp. I hope it will become a guidepost for newbies interested in Lisp as well as a resource for those that decide to take the plunge.
Yes, Dave, people do eventually read these comments. I first learned LISP at Cornell from Corky Cartwright, a student of McCarthy's who last I checked teaches at U. Texas, Austin. LISP quickly became my favorite programming language and from about 1980 up to 1988 it was my 40+ hour a week programming language.
Then times changed and I moved in rapid succession through Modula briefly, C++ for many years, Forth briefly, Prolog briefly, Java several years, ML, Haskell, Python, and finally back to LISP. Of course there were many other languages along the way. I taught university courses in Pascal and Fortran, but didn't even mention them because I wrote no big systems in them. Point is I agree with you.
After learning Python, it struck me that programming languages seemed to be evolving back toward LISP. So, I've spend the last 6 months re-discovering LISP. What I've found is that LISP works better than ever.
I've read all of your books of note and fully endorse them. Those are the same three I put at the top of my own list.
Hrm... so far everything that I've read, from other sources, seems like Lisp requires a hardcore programmer with decades of experience.
I've got a decent sampling of just about every popular programming/scripting language on the net (Including: Assembly, C, C++, Java, Perl, Python, Ruby and others).
While I can generally understand code from any of the above languages I'm no were near able to make a program outside of a tutorial. Does that mean I should learn something (in full) before even attempting Lisp?
I don't think you need to "learn something in full" before you work with it. Practical Common Lisp gets a unit testing framework up in the first six chapters, as I recall, and that still leaves 25+ chapters of other material. My first programs in any language used just a few features; I think the same works in Lisp.
I'll agree that the learning curve may appear steep, because the prefix/paren notation doesn't map from "familiar" languages as quickly.
You can use any of the open source implementations as a foundation for writing some simple (but useful) programs. I'm using CLISP on Windows for a real production program; I have a few others on my Linux boxes for other experiments.
Does this help answer your question?
Post a Comment
Links to this post: