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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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?
6. 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.