The next release will have more improvements to news.arc than the underlying language, because that's what I've been working on most lately. But I'm going to be focusing more on the language soon.
The first three are right. As for 4, it's not so much that I prefer less communication as that I sometimes may be too busy to visit the site.
I think the thing people may not understand is that I can only work on Arc intermittently. In the spring as well as a YC cycle we had startup school and I got married. The next day the summer YC cycle started. During the summer I was busy with a larger than usual number of startups. As soon as it was over I went on honeymoon, during which I barely touched a computer. I got back to the US just before applications for the winter cycle were due. I've been reading them all the past week, and I still have over 100 left. (I probably wouldn't even be writing this if I weren't desperate for ways to procrastinate.) Then we have to move YC and ourselves to the west coast, then do interviews. I'm hoping that I'll be free to work on Arc in mid or late November, but I don't want to promise anything.
So it's not so much that I don't want to be held to a schedule as that I couldn't do things to a schedule even if I wanted to.
I'm hoping that ultimately doing so many things will make them all turn out better. But it does mean I can't do any of them more than part time.
In answer to your specific questions: I don't think I can commit to an upper bound for new releases, because the factors that determine whether or not I can work on Arc aren't cyclic. Yes, I'll incorporate bug fixes, the next time I get to work on the language, which I hope will be late this year. At the moment the most valuable things people interested in Arc could do are (a) find bugs in the current implementation, (b) think about the core language and specifically what new operators, if they existed, would make existing Arc programs like news.arc significantly smaller in tokens, and (c) try using Arc to write different kinds of applications and report what happens.
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.
Ah, but of course dynamic scoping is bad for any, any language, whatever the design goals. Everybody knows that since ages ago. <end of my turn to be clever>
My fascination about newLISP was exactly that: "What?! Dynamic scope by default?! ...Oh, but look, they say you can scope lexically & do closures with no fuss... Context as an explicit first-class object? hey, that's an idea, for once."
newLISP indeed has real flaws, - which can be mistaken for mistakes, unless you take into account the exotic design requirement for newLISP: to fit a Swiss-army-knife function library, together with functional and O-O programming support & a stand-alone web server, into a 300kb executable.
We can but guess of the author's intent. My guess is that the built-in distributed computing functionality has something to do with the plan.
I don't feel any rush in producing new versions, just as I didn't feel any rush in releasing the first one. Lisp hackers have waited 50 years for a good implementation. That didn't kill Lisp. Hackers used to this idea aren't going to panic because Arc hasn't been updated for n months. And the ones who feel that an actively growing source tree is more important than the underlying language were in the wrong place to begin with.
How are we supposed to look at Arc then? The problem doesn't lay only in the fact that no source has been written, but in the fact that who has full control over Arc doesn't discuss about the language with the community. Is Arc just a one-man work and arclanguage.org just a way to show the world this work from time to time?
It's ridiculous that to bring you back in the forum we needed such a harsh post.
If I were you I'd look at it from the Lisp tradition: as part of a 50 year history with many dialects, rather than as an urgent effort to manage one particular implementation consisting of a huge pile of libraries on top of a badly designed language core.
People who want languages like that already have plenty of options, even Lisp dialects.
I didn't mean to say that core language isn't important. It is important. My main point point is that the community should be able to partecipate in the design. This is why I've advocated a fork of Arc, because to improve the core of the language you need help from who will use the language. A prototype is a good way to make this happen even when you're in the design phase and not in the production phase, but it is useless without a communication channel between the designer and the users.
1. The time scale. I don't want to make what people think they want right now. Following that recipe earlier would have got me Perl, which lost its lead to the language I would have gotten a little later, Python, which lost its lead to the language I would have gotten a little later, Ruby, which... See the pattern?
2. The audience. "Make something people want" is a recipe for companies. Their goal is to make a lot of money, which means aiming for a wide audience. That shouldn't necessarily be one's goal in every kind of work. It's ok to want to be Jane Austen instead of Perez Hilton, even though Perez Hilton is what most people want.
I've got to say I agree with pg on this. It's more important that Arc turn out well in the long run than in the short run. Also, although Arc isn't moving very fast, I have to say that the more I actually program in it, the more I appreciate its design. I still find myself missing the lack of a proper library/module/namespace system, and of course given that some actual libraries would be useful, but that's about it for truly major issues.
That said, I do think pg could do with talking to the community a little more, and vice-versa.
Oops, yes, sorry. I just released a new version of the code and it had some new news.yc stuff in it that I hadn't adapted yet to arclanguage.org. Will fix.
It does fit, but on the other hand, being able to have a hanging or prefixed dot could allow useful naming conventions, and as long as it's standardized where dots are allowed, this won't conflict with intrasymbol dots (ie: "foo..bar" translates to one of "(foo .bar)" or "(foo. bar)"). I'm not so concerned about this with regards to dots, but with regard to #\! and #\?, used as suffixes for destructive and predicate functions respectively.
This was an earlier experiment that didn't work. Or at least, that I gave up on. The plan was to write a maximally brief (and thus horribly inefficient) meta-circular interpreter, and generate the compiler from it. So you'd literally have the metacircular interpreter as a sort of executable language spec.
I still believe this could be done, but it would be a dissertation's worth of work.
After I gave up on that, Rtm and I decided one summer to just hack together something that compiled into Scheme, and that's what's generating the page that you're reading.
