It's really odd.
One can go through life feeling very clever and up to date, learning paradigms like object oriented programming, grokking new languages (like Python and C#) and getting really good at DB interaction.
Then, a couple of years ago, I took on a contract and ran into a ex-CIO who seemed quite good at architecture. I got talking with him about languages one day and he said his favourite language was common lisp.
I was genuinely surprised and I came out with what I later find is one of the stock standard arguments against lisp, "isn't it quite slow". He said you get speeds approaching C/C++ and more power to boot. He recommended that I have a look at SICP if I was interested in finding out about lisp like languages.
I still haven't finished SICP (still on my list to finish off), but one quote in the foreword really stuck with me
Lisp changes. The Scheme dialect used in this text has evolved from the original Lisp and differs from the latter in several important ways, including static scoping for variable binding and permitting functions to yield functions as values. In its semantic structure Scheme is as closely akin to Algol 60 as to early Lisps. Algol 60, never to be an active language again, lives on in the genes of Scheme and Pascal. It would be difficult to find two languages that are the communicating coin of two more different cultures than those gathered around these two languages. Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place. The organizing principles used are the same in both cases, except for one extraordinarily important difference: The discretionary exportable functionality entrusted to the individual Lisp programmer is more than an order of magnitude greater than that to be found within Pascal enterprises. Lisp programs inflate libraries with functions whose utility transcends the application that produced them. The list, Lisp's native data structure, is largely responsible for such growth of utility. The simple structure and natural applicability of lists are reflected in functions that are amazingly nonidiosyncratic. In Pascal the plethora of declarable data structures induces a specialization within functions that inhibits and penalizes casual cooperation. It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures. As a result the pyramid must stand unchanged for a millennium; the organism must evolve or perish.
Strangely enough about 11 years worth of my experience is in Pascal. After discovering lisp, I find large parts of what goes on inside pascal to be very much about building rigid structures and being very careful to think about types. Pascal is good for what it does and is quite useful for relatively simple apps, but to make more complex dynamic software, one ends up writing subsets of lisp in pascal (Greenspuns tenth rule http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule
Since reading that I've come across other quotes from people doing lispy things, this from Rich Hickey who developed Clojure
Discovering Common Lisp after over a decade of C++, I said to myself — 'What have I been doing with my life?', and resolved to at some point code in Lisp. Several years of trying to make that practical, with 'bridges' like jFli, Foil etc, made it clear that bridges weren't going to be sufficient for the commercial work I was doing.
quoted from http://lwn.net/Articles/335966/
The 'what have I been doing with my life?' part of the quote has really resonated with me. With such an amazing language, large chunks of what I've been doing seem somehow wasted when I could have done them with more ease in lisp.
I am starting to sound like a bible salesman, but you get that.
The next trick to pull off will be to use lisp to make some wildly useful tools in the C/C#/Pascal/SQL/HTML world that I live in. Should be fun, though may take some time.