Lisp

I've heard from many people that lisp changes the way you think. But when I learned Racket and wrote a compiler for it, it didn't.

Maybe that was because I never fully grokked the true power of lisp. Or maybe it was because I'd used Haskell and J previously, so all the "mind blowing" features people attribute to lisps were already familiar to me. These days, the only lisp feature I (occasionally) long for in other languages is quasi-quoting.

Being able to extend the language with macros is a feature lisp fans seem to really like. But the power of macros is double-edged, because extending the language increases its surface area, and makes it harder to understand.

It's as if the lisp community does not want to heed the worse is better lessons. Personally, I think the reason lisps are not more widely used (despite being good for many purposes) is precisely because they tend to turn into DSLs. For many people, solving a problem in lisp is the same as writing a DSL for the problem. But now anyone who wants to read your solution has to understand your DSL, which means all their previous experience in learning other languages does not help them to understand your solution. This is particularly annoying to programmers, who invest a lot of time learning the tools of their trade, and so DSLs can be somewhat anti-social compared to expressing the problem in a more familiar language (even if the solution is less elegant than the DSL).

Paul Graham said that when a programmer "when a programmer is looking down the power continuum, he knows he's looking down", because the languages lacking some critical feature are obviously less powerful. Meanwhile more powerful langauges simply look strange to the programmer who is unfamiliar with them, because they can't recognize the importance of unfamiliar features.

I'm an array programmer, so I know lisps have some features that my favorite array-oriented langauges lack. However, when I look at lisps I know I'm looking downward in the power continuum, despite the fact that most array languages lack macro systems and may not be homoiconic. That's because, in order to gain those features, I would have to trade away some of what makes the array languages valuable - their directness of expression, terseness, and implicit power.