Personally, I think the only thing that went wrong in the history of Arc is that pg didn't correct people's misunderstandings about what it was, and what it was trying to achieve. A 100-year language is not going to be usable tomorrow, and a language designed by the optimal number of people (one) is not going to accept many patches!
If people want a practical language to use now (and there's nothing wrong with that!) then they should go ahead and build one. I'm happy to join any project that anyone may have for developing an Arc-like language. I might even start one myself (why not? It'll be fun!) if I have the time.
A language doesn't survive in its implementations, but in its ideas. Modern languages (especially Python/Ruby, but even C# and Java) are becoming Lisp. Dynamic typing, late binding, functional programming, closures, generic functions, MOP... the 'popular press' laughed at them, but now these are the hot topics in language design. Those ad hoc, informally-specified, bug-ridden, slow implementations of half of Common Lisp are getting better every year. Common Lisp and Scheme will die, but in 10 years everyone will be using Lisp, and they won't even know it.
The same goes for Arc. Clojure already uses some ideas from Arc (e.g. fewer parens in conditionals). If the ideas are good (and I think they are) then they'll spread. If people want to build new languages (e.g. Arc3F) that use them, then that spreads them further, That, I think, is the true future of Arc, as a source of eternal ideas.
I have to admit that Clojure looks very interesting. Functional programming, concurrency with software transactional memory, access to a huge Java library, conciseness, etc. It's also a Lisp-1 like Arc w/ Common Lisp style macros, but it has namespaces. It doesn't have TCO due to JVM limitations and I don't think it has continuations, so an Arc-like web server might be more challenging.
The concurrency story is particularly interesting given the proliferation of cores and slowing of GHz.
The Clojure version of Norvig's spelling corrector appears to be one line shorter than Norvig's Python version:
I would really like to see an Arc version of that. I translated Norvig's Python version to Ruby easily, so I expect that someone fluent in Arc could do it easily.
The other Lisp versions I've seen (Scheme/Common Lisp) were quite a bit longer and less elegant IMO.
I'm not super excited about Clojure's dependence on the JVM, but on the other hand, that gives it a huge head start with libraries and state of the art VM/JIT technology.
Rich Hickey doesn't seem to have the star power of pg, but he is very involved in the language and community. He seems like more of a Matz or Guido which doesn't seem that bad - he seems quite sharp in his web cast presentations.
I could be way off, but it seems like it would be easier to add Arc innovations to Clojure than to add Clojure-like concurrency support to Arc.
> continuations, so an Arc-like web server might be more challenging.
Arc's server doesn't actually use continuations - it uses functions that serve as continuatinos. There's no call to 'ccc or any of the wrapping forms in srv.arc (at least none that I remember)
> The concurrency story is particularly interesting given the proliferation of cores and slowing of GHz.
This is true and I think the "extra-cycles-to-waste" property expected by PG isn't going to put out in a hundred years.
> state of the art VM/JIT technology
Forget the libraries. This is what's scary about any JVM language.
"Arc's server doesn't actually use continuations - it uses functions that serve as continuatinos. There's no call to 'ccc or any of the wrapping forms in srv.arc (at least none that I remember)"
That's right, no 'ccc. That's why I could implement it so easily in Lua (no real continuation in Lua either). As for TCO, I'm not sure it's a real problem in this case. Sure, a lot of simple functions are written in a recursive style, but they can be trivially rewritten in an iterative style.
This is only half-true. Clojure cannot automagically convert a self-call in the tail position in to iteration, but it does have the recur form to provide essentially the same semantics. I've also found it useful that recur throws an exception if used outside of the tail position, making it obvious which recursive forms consume stack space and which do not.
I personally feel that a language core should be the work of a single person. Period.
The core set of axioms that form a language are almost fundamental as the laws of nature to that language. Just imagine theory of relativity being developed by several scientists together... almost impossible.
Even 2 persons should not work together on a language core. The quantity of communication required if 2 persons work on a single language is so large, that hinders and messes up the development process.
If there's one place where the saying "Too many cooks, spoil the soup" applies; its core language design.
