Lisp is Not an Acceptable Lisp (2006)
steve-yegge.blogspot.com
steve-yegge.blogspot.com
It certainly looks like Arc has been "Rich Hickeyed" judging by the recent announcement of funding for Clojure. Think about that for a moment - a commercial organization is actually funding development of a new lisp!
This article is four years old, but since the prediction spans decades, I think it's fair to pick on it a little.
The OOP trend seems to be waning. The languages people are getting excited about lately seem to be de-emphasizing OOP and providing other mechanisms for some of the useful attributes of OOP.
Haskell and Clojure don't have OOP as most people know them, but Clojure's multimethods and Haskell's typeclasses replace OO polymorphism to a large degree. Scala and F# have OOP, but using it is optional.
Ten years ago, a new language intended for practical work and lacking OO wouldn't be taken seriously. That has changed, and the change seems to be accelerating.
Take clojure for instance. Initially it had multimethods, which is a really useful and general facility. I like it. But now they're adding that dispatch-on-first-parameter special case back in.
Similarly, Go has omitted most of OO, but they use interfaces to support that same special case.
Scala is explicitly marketed as a hybrid OOP/functional language. At least from "Programming in Scala," it seems as though writing idiomatic Scala really requires both paradigms. I see Scala as adding functional programming rather than de-emphasizing OOP, the former being a common thread in new (multi-paradigm) languages.
I don't think we should lose sight of the fact that extreme enthusiasm about functional programming and Lisp taking over as the dominant paradigm in programming is almost as old as programming itself.
See this short video about protocols (and a little generic method and defrecord stuff): http://vimeo.com/11236603 (you should look at it even if you don't like clojure, it has some interesting stuff in it about the expression problem, and how to solve it in there)
Issues like hygiene didn't really bother me too much. As long as you are aware of it its not an issue.
While I really like the power of Lisp/Scheme (especially macros), I find that for most programming task Python or Ruby are good enough. There was an interesting post along similar lines 'Why Ruby is an acceptable Lisp'[1].
One thing I am really interested is in seeing how Perl 6 works out. It supports Lisp style macros (by making the parser available to the programmer) while using conventional syntax. While I am a Python fanboy myself I would seriously consider Perl 6 once there is a CPython grade implementation available.
[1] http://www.randomhacks.net/articles/2005/12/03/why-ruby-is-a...
About macros: If I recall correctly, Scheme got hygenic macros in 1991 with R5RS. If I recall incorrectly it was earlier, definitely not later.
Many Scheme implementations clone CL's defmacro, which is non-hygienic unless you're careful, but is useful. There's also syntax-case, which is hygienic by default, but let's you break hygiene explicitly.
Macros should be used only when functions won't do, and not because of tool support. Macros act at compile time, not run time, so they aren't run-time objects that can be used flexibly the way functions can.
;-)
I used to have lot of open, long-standing concerns about the future of programming and productivity, but my sabbatical last year finally brought me some clojure.
Take what you will from that :)
If you read his most recent rant, you can see that although it's technically about visibility modifiers, it can read as a condemnation of compiler-enforced constraints in general.