My prediction: someone will get tired of waiting, and they'll Torvalds Arc into obsolescence before it's ever released
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!
Has Paul Graham ever addressed in writing the disconnect between the amount of hype Arc got before it was released versus nearly instantly vanishing almost completely from public mind-share?
At the risk of predicting future fashion trends, which is rarely a good idea, I'll venture that objects are going to continue to be trendy for at least a few more decades.
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.
I don't actually see a trend in the last 2-3 years of people getting more excited about Haskell, Clojure, Scala, and F#. Two years ago, people on forums like this one were extremely excited about these languages. Outside of the forum scene, and into the industry, I see a lot more eye-rolling and knowing "here we go again" stares than excitement about these.
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.
Not to mention that Scala is explicitly OO, F# is based on Objective Caml, and Clojure owes a lot of its success to the libraries provided by a huge, thriving OO community. OOP is not waning unless you define OOP as the design pathologies imposed by bad OO languages.
I don't disagree, but it seems like you're overstating your point by calling OOP "optional" in Scala (and possibly F#).
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.
As often happens, the good bits of a trend will remain (polymorphism and open recursion for example) and the bad bits (elaborate design patterns) and the irrelevant bits (public, private & protected) will be removed.
You're right and I'm glad OO is waning a bit. But I think what's really happening is that some popular features of OO are getting more ingrained and others are shed.
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.
Clojure even goes beyond what java can do with protocols and defrecord is basically a class. So you could almost say its OO from the point of the original description (encapsulation (with name spaces), polymorphism (multi methods). Inheritance you can do with the ad hoc hierarchy system. Its pretty cool. The thing is just in Clojure you only use this stuff when it is useful not like in mainstream OO where you have to drag it along with you all the time and therefor miss out on all the functional goodness (and on lisp/concurrency goodness)
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)
When I started to learn Lisp, the "Which Lisp?" problem was the first thing to hit me. Same with Scheme. I eventually went with CLISP and PLT (Racket).
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.
About "which Lisp": I think most people recommend PLT Racket for newbies. I do, even though I use Kawa Scheme daily.
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.
How is it to work with kawa. I only no that it exists not more. Some question:
1. Can you use it professionally?
2. Whats the benefit over clojure?
3. Does it live close to java and is it still lispy to work with java (clojure does well there I think)
4. How fast is it?
1. Yes
2. Scheme is a better-established standard. Nice macro system.
3. Easy Java integration and totally lispy...not 100% Schemey because you can't do continuation capture.
4. It's way faster than PHP4. I haven't benchmarked it in years, because performance hasn't been an issue.
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.
In a real world of webs applications and jobs for the net, macros are a dream for another universe. Php people don't dream, they step by step are making what macros can't do: expanding their universe. Joomla! they say.
no the just really GROW the language. Some new features somewhere else that they don't understand just trick it somehow in there. convert it to string and back or just stuff everything in some global variable or something. If it breaks you can just make a ugly fix on it with the next version.
My inference from the times I can remember him mentioning it: Basically, Steve likes dynamic typing. He feels that arbitrary language-enforced constraints just get in the way. Haskell is the most strongly statically typed language in existence, so obviously it's not his cup of tea.
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.
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!