Personally I'd volunteer to take the lead, really fork Arc, and go on with Arc-F. Unfortunately, I'm not at all experienced in actually launching and maintaining a website. Worse, Arc-F can't host news.arc (or a ported version) yet; I'm somewhat redesigning the Arc server because of the lousy and inconsistent design, but I'm kinda stuck on how to handle the continuation server functions bit, which strike me as the dirtiest bits of the Arc Server.
The last alternative - let Arc die - is something we should seriously consider though. Clojure is gaining the popularity that Arc could have had. Like Arc it's a redesigned Lisp (fn and new ssyntax, anyone?); unlike Arc, it wasn't hyped very much for >6 years, its maintainer is still visibly leading the language, and it runs on the JVM. The only advantage of Arc that I see is that it supports both imperative and functional paradigms - and some might argue that this isn't actually an advantage.
Letting Arc die would hurt me a lot, though. Other than the original writers of Arc, I can probably reasonably claim to have made the largest contribution to Anarki (many of the docstrings in the Anarki arc.arc, for example, were by me).
Oh honestly. Perl had the popularity Arc could have had. Then Python did, then Ruby. The fact that the "winner" keeps changing shows that it doesn't matter which one you beat.
I've long since stopped worrying about other languages. If they're genuinely better, they deserve to win. And if they merely have "momentum," they'll ultimately be superseded, just like every other language du jour before them.
I get this feeling that Arc is the language that is just going on by momentum.
Further, I don't think Arc, PG version, is as well-designed as you think.
For example: "code is spec". Apparently the code itself is to be the specification for the language. However, this brings up some questions: for example, does the fact that (ssplit '(1 2 3) 0) return ((1) (2 3)) part of the specification, or is that a bug? http://www.arclanguage.org/item?id=8450 .
Or how about the cute little fact that the PG 'map function can be safely recontinued when you capture the continuation in the mapping function if the given structure is a list, but is not safely recontinuable if the given structure is a string? Is this a deliberate design decision, an oversight, or something you don't specify and so any other implementation can do what they want?
And while tagging allows the programmer to arbitrarily create new types, those new types don't get along well with the builtin functions. I can't build a vector type in PG Arc that will work with the builtin functions. I can't build a quaternion type which I can multiply with a scalar number using '* .
These are design points which have been belabored for years; Brooks in 1975 attacked using "implementation as spec", pointing out that it limits future implementations by forcing them to always use the old implementation, for example.
If arc is continuing by momentum, it's a very different kind of momentum than the momentum languages like Java, Python and Perl survive on. They have momentum in that they have many large and complex libraries and programs written in them which are being actively used to the point where rewriting said software in another language is no small task; and hence most people are interested, not in making a new and better language, but in making the old language better.
Arc has none of this. The reason why it continues is because the people using it are enamored of it for its own sake, not because they depend on it. This is both a blessing and a curse. A blessing, because it means Arc is free to change and improve; a curse, because it means Arc is incomplete and a moving target.
This is one reason why it is important for you to be here: some simple things like the problem with 'splice are clearly bugs, but other things are not. For example, the fact that '(1 . 2 . 3) reads as '(2 1 3) is just something drained accidentaly from mzscheme's reader or is part of Arc? Since you've written Arc, you're the only one to really know this.
We can only suppose.
Perl, Python, and Ruby are successively closer approximations of Common Lisp.
I admire the ideas behind Clojure because it makes a different set of design decisions from Common Lisp. This seems to have even gotten the attention of Common Lisp developers, and those guys are pretty hard to impress.
The focus on immutability, literals for data structures other than lists that share a common "seq" interface, first class functions and closures, multi-methods without OO, lazy sequences, and full fledged macros hit an interesting sweet spot that is not touched by any other language I know. Mr. Hickey has managed to put all of those things together in a way that strengthen, reinforce, and complement one another. That is an impressive feat of language design.
My point is that Clojure is not "just" popular. By making unique decisions about the semantics of the language, and not just improving the syntax over the semantics of an existing language, Clojure may very well be one of those languages whose ideas remain influential long after it stops being popular.
(I'm curious, does Arc innovate in terms of its semantics being significantly different than its predecessors? It seems to have the goal of taking existing Lisp paradigms and
making it possible to express them more succinctly. But I might be missing something important.)
So, even by the criteria you put forth, Clojure might be a language worth watching.
Perl had the popularity Arc could have had. Then Python did, then Ruby.
I will point out that Perl still has the popularity. Python and, particularly, Ruby have dramatically fewer developers and lines of code than Perl. But, then, Perl has fewer developers and lines of code than PHP. So, unless PHP is the exception that proves the rule, the popularity argument is obviously moot. But, I do think there's something to be said for pragmatism. While Perl (or Python, Ruby, etc.) has its flaws, it also has a vast community of people working on solving them...will Perl 6 be ready before arc is usable for a similarly wide array of problems? Seems pretty likely.
One pattern that I observe - you respond only to those points that rebuff you. Rather than proposing solutions and/or accepting that you have been less than clear about your plans for Arc (especially as this is a real community now and not your personal pet project), you have been exceedingly discourteous to your fellow Arc-enthusiasts. I feel sorry for them and happy for myself that I am not part of this farce.
Funny thing is, when I read your essays a couple of years back, I did respect you. Reading stuff like this kind of erodes that dramatically. Good luck pg.
Clojure is on my list. When (if) I give up on Arc It will be the next language I'll learn and use. A lot of libraries from the start. Good performance (the JVM is fast once started). And, most importantly, Rich Hickey follows the language and promotes it. Arc had the great advantage that it had a community of users from the beginning. After its launch, a lot (relatively) of people were already using it. Despite this advantage, Arc hasn't reached the popularity that Clojure has today. Arc had the possibility of being a great language. That possibility has been wasted.
If you want to fork arc, you'd better change its name to break with the past. Make something new. I like the ideas behind snap. I only wonder how much time it would take to have a usable system. Sadly, I'm not able to really help :(
Just in general - is there anything in arc which gives it a big edge to programmers when compared to clojure?
Here are some of the differences, but I can't tell if one of them is crucial. I listed three below for which I've no clue what the impact is.
http://clojure.org/lisps
* The read table is currently not accessible to user programs
* Keywords are not Symbols
* Symbols are not storage locations (see Var)
* immutable data and first-class functions
* *first* is clojure's *car* ;)
> Just in general - is there anything in arc which gives it a big edge to programmers when compared to clojure?
Mutation. It's one thing to allow functional programming. It's another thing to force it.
The only thing constant is change.
> * The read table is currently not accessible to user programs
Neither does Arc, although Anarki does allow redefining of 'ssyntax and 'ssexpand, which almost gives you the same thing.
IMO not giving access to the read table is a good thing. There are very subtle problems with this, starting with: the read table affects all code loaded after the readtable modification.
It affects them whether or not the code was written by you, and whether or not it was written with that readtable definition in mind.
This can cause unfortunate library breakage when two libraries try to modify the same readtable entry; the poor user is thus left at the mercy of which library loaded last.
In fact Arc-F has revoked Anarki's feature which allows 'ssyntax and 'ssexpand to be modified; redefine them all you want, Arc-F will use the built-in traditional 4 ssyntaxes : ~ ! .
HOWEVER, there are currently two reserved context metacommands which will eventually allow ssyntax redefinition at the level of the individual file: 'import-ssyntax and 'interface-ssyntax.
The important thing is that they are context-based, and because they are context-based, they are not global and they will (in general) affect only one loaded file.
> * Keywords are not Symbols
Unimportant - salt to taste.
> * Symbols are not storage locations (see Var)
> * immutable data
Oh, Clojure is not quite completely immutable. Clojure has refs, and they can be mutated within the context of a 'dosync form. Kind of like the Haskell "do" syntax. It's more that Clojure defaults to immutability, and has special syntax to define portions that are imperative.
