I had high hopes for Arc over a decade ago, then it languished, then pg stopped participating.... then I looked at Racket (then PLT-Scheme) since that's what Arc was built on and realized Racket was the language I was looking for :)
I think anyone who is interested in a lisp has been positively influenced by Paul Graham, I certainly have.
You said this in the HN thread:
"I'm sure Arc is the wrong choice if I want to be as effective as possible in 6 months. If Arc is only the best choice if I want to be as effective as possible in 5+ years someone save me ;)"
The specific language is only one aspect of effectiveness - others include available libraries, an active contributing community, etc. I don't think there's reliable evidence that Arc will change enough in 3 years to fulfill your "effective as possible" goal.
Paul's last submission to his own forum has been over 5 years ago! And his last comment has been over 4 years ago. It would seem that he's not actively involved any more.
I was very excited to hear about Arc over 7 years ago, and I had high hopes that Paul might be the person to create a successful lisp and rally a great community. This has not happened, and I think it would be foolish to think this will change much in the next three years.
In the end, I ended up choosing Racket as my lisp - it made my short list to evaluate in part because Paul chose it to implement Arc :)
I'm certainly not trying to "save [you]", but I see many similarities between your quest for the most effective language and my own and countless others :) The language is very important, and concision is important, but you really need to evaluate the entire ecosystem to make a good choice.
I really have mixed emotions regarding the two approaches of building on the JVM vs. building from scratch.
On the one hand, building on top of the JVM gives quite a head start in many ways, and I think it's a bit ridiculous how poor the interop situation is for native programs despite the availability of FFIs (although some/much of this may be fundamental to language differences).
On the other hand, it seems the least common denominator problem always creeps up when building on a VM plus you have an extra dependency in the chain, etc.
If the Y axis is features and the X axis is time, it seems clear that building on a VM gives you a higher Y intercept. The question is whether the slope is unduly impeded. I suspect it might be, but that's totally subjective on my part.
Can you summarize the principal changes required to work with an immutable cons ? I guess now that the files are versioned (thanks!) I can just do a diff, but if there are extensive changes, it might cause a Lisp newbie to miss the forest for the trees.
;; set a pointer to the cons cell, then dereference it as a pointer,
;; and bang the new value in the given offset
Hmm... so the fix was to "cast" the immutable cons cell to a mutable cons cell? Glad it works, but I was kind of hoping to learn that the immutable cons cell thing was workable for Arc. I guess I should read up on the MzScheme decision to make it immutable and see what pros/cons are associated with it.
My wife (a fine artist) liked the aesthetics and said it reminded her of a Mondrian painting, but she didn't get the lowercase 'a' or keystone :)
After your explanation, I do see the lowercase 'a'. But, it does bother me a little that the 'keystone' is rectangular vs. a wedge, as it seems like it might slip out of the arch.
I also see orthogonality and (as another poster said) a floppy disk.
Probably the most prominent image is a square which unfortunately doesn't seem very arc or arch like to me.
There seems to be a lot of potential with arcs, arches, 'A', lambda character, etc. Also, having a logo change is not a huge problem, so not getting paralyzed with an attempt to get the perfect logo initially is important IMO.
Indeed, our experience is that making the result of `cons' immutable
does not create many porting problems. Nevertheless, if your code does
use `set-car!' or `set-cdr!', and if converting to a more functional
style is difficult, then consider using `mcons' and the `scheme/mpair'
Oddly, the Ruby version runs more slowly every time I run it. I think memory locality may be the problem, as the Ruby process grows each time (now at 85 MB). That's nothing compared to my MzScheme process which is now consuming 700MB. That's probably due to the inefficient way in which nwords is constructed. A bit of tuning there might work wonders for overall performance.