I came to Arc because I wanted to use only the best language, and Arc was the only sign I saw that anyone was ambitious enough to try to build the best language today. I stayed with Arc for a while because I could make macro frameworks that explored new ways to program in Arc, without feeling like I was messing up the way anyone else was programming in Arc. Only when I came up with language ideas that couldn't work in Arc did I start to write my own languages.
Then I moved away from Arc mainly because I wanted to practice coding in JavaScript. That was because I wanted to be able to spend my time programming even if I was stranded at a computer that didn't have Arc installed. It was sort of a theoretical concern at the time, but then it came in handy for employment, where Arc was unlikely to be an employer's platform of choice. :)
That nice phenomenon I experienced in Arc, where I could experiment with new ways to program without leaving the language... I think that's the essence of Arc for me. Arc is conducive to Greenspunning new languages. Not only is Arc homoiconic, but it also has few pretensions of being perfect yet, and it's explicitly in the stage of soliciting new suggestions for the core operators (or at least it was). Using Arc, I felt welcome to Greenspun new sets of operators as I liked.
Usually when I have strong opinions about what Arc should become, I just pursue those opinions myself in my own languages. I even intend for my language Staccato to be conducive to Greenspunning; part of its design even involves an explicit "please put all your nonstandard Staccato implementation experiments here" zone. But Arc's lack of pretension is a quality of its community. It's something delicate that I won't necessarily succeed at in Staccato even if I have no regrets about the technical design.
---
If there's any language that has that quality of Arc, I would guess it's Agda. I've seen quite a few type system experiments that are developed as DSLs in Agda, so Agda seems to have the kind of culture that likes remixing the core operators. While Agda's syntax is not homoiconic, I think it's flexible enough to make these DSLs rather seamless.
If Arc has an edge over Agda for Greenspunning, it's that it's easier to Greenspun a new implementation of Arc than a new implementation of Agda. From what I hear, Agda's implementation involves a termination checker that's sophisticated enough that many users take advantage of it without knowing where its limits are. Those users probably aren't prepared to reimplement it themselves.
Incidentally, It's interesting that one of Paul Graham's reasons for not making Arc statically typed was that "static typing seems to preclude true macros" (http://www.paulgraham.com/hundred.html). Now that Haskell, Adga, and Idris all have macro systems, maybe that position should be revised. Or maybe these aren't true macros; I don't know them well enough to judge that.
Looks like Arc vs. Clojure has been pretty well covered by the other comments. To take a step back and look at your goals, in case you might find it useful... consider separating the need to eat from your other ambitions.
The demand for hackers is very high right now, so it's easy to find work.
Most people when they get a job and make more money, immediately raise their standard of living. I.e. they find a nicer place to live, they eat more expensive food, maybe buy a car or get a nicer one, etc. But you don't have to do that if you don't want to. You can, if you choose, keep your expenses low while working, and save a lot of money instead.
When your expenses are lower than your income, you don't need to work full time. For example, you could work part time. Or, you could work full time for part of a year and not work the rest of the year.
With "I need to eat" covered, then you have time to pursue your interests without fearing that you're going to starve if you don't get things going quickly enough.
YC has a less than 3% acceptance rate (https://blog.ycombinator.com/yc-portfolio-stats), so applying to YC isn't a great strategy for keeping from starving. (YC is great if what you want to do is build a world changing startup. For meeting your own basic income needs there are many far easier and much more certain ways to do that).
I don't mean to discourage you in any way from applying to YC if you want to do a startup. Just suggesting you have a plan B for the "so I can eat" part :)
I think you might find TripleByte's blog post on what kinds of programmers YC companies want to hire interesting for several reasons:
First, if you want to do a startup, it's interesting to see what kinds of technical skills have turned out to be important for startups.
Second, if you want to create an app, it's interesting to see what kinds of technical skills have turned out to be important for startups creating apps.
And third, if you want to get a job, it's interesting to see what kinds of technical skills are most in demand.
A highlight is that the most demand is for product-focused programmers.
Thus, if I were looking for something to study for the purpose of starting a startup, or creating an app that lots of people use/love, or for finding work, I'd consider focusing on:
But keep in mind that for most apps, for most startups, you don't need Lisp. Reddit, for example, started in Lisp and switched to Python because the libraries were better. Nor are most of the YC companies using Lisp.
Of course, every startup is different, and every app is different. For a particular app, or for a particular startup, Lisp might be a strong advantage. For Paul Graham's original startup ViaWeb, for example, Lisp was a decisive advantage.
Lisp is a programmable programming language. When do you need to program your programming language? When your programming language isn't doing enough for you on its own.
As other programming languages have gotten better, there's less of a gap between them and Lisp. ViaWeb was using Lisp competing against companies writing in C++. Nowadays the mainstream languages are higher level.
Lisp is a useful skill to learn because if you ever do get into a situation where it would be helpful to be able to program your programming language you can say "aha! A macro would make this easier!"
And yet, to get into YC, or to write an app that lots of people use/love, most of the time, in most cases, that's not necessary. (Or else startups would be looking for Lisp programmers).
Clojure also has a pretty cool way to not have to call (uniq) by hand. If, inside a backquote, you append a # to a symbol, clojure will replace that variable with a gensym. And it'll use the same gensym every time you use that variable in the backquoted form.
(defmacro and
"Evaluates exprs one at a time, from left to right. If a form
returns logical false (nil or false), and returns that value and
doesn't evaluate any of the other expressions, otherwise it returns
the value of the last expr. (and) returns true."
{:added "1.0"}
([] true)
([x] x)
([x & next]
`(let [and# ~x]
(if and# (and ~@next) and#))))
See how it uses and#, but it doesn't capture the variable and?
I'm not entirely sure how you would capture a variable (e.g., Arc's "aand"); if you try to, clojure errors by default. There's probably some way, but I don't know offhand.
I'm drifting off topic, but imagine this: When you call (eval ...), imagine you pass in the global namespace that the code will run in. (Maybe we're using aw's extension for this purpose.) When you pass in a namespace that contains your own implementation of (eval ...) itself, you've effectively modified the compiler, but only as far as that specific code is concerned! As long as our custom compilers are written in Arc, we can treat them like we treat Arc libraries, and we can mix code that uses different compilers. We can have all kinds of compilers open in split windows at the same time. :-p
We already have plenty of examples of first-class namespaces, like aw's implementation posted recently. So all this would take is an implementation of Arc in Arc. Do we have one of those? I thought I heard of one at some point.
My excitement is not because I think a pileup of various compilers in a single codebase is a great idea, but because I think it's easier to share code this way. Compiler hacks are prone to merge conflicts that inhibit code sharing, but sharing libraries is... well, not perfect in Arc either, but it's at least ameliorable by doing some simple search-and-replace renaming or by agreeing on a namespacing framework (like my framework in Lathe).
This came to mind because I was recently realizing that in my language Staccato, my Staccato self-compiler was approximating a style of programming much like that split window of yours, without sacrificing modularity.
Yeah I wouldn't use Arc in your situation. It can still be good for prototyping new ideas, but I'm not sure the gap with other languages is large enough to take on the risk of painting yourself into a corner..
I think Clojure fits most of the criteria that would lead someone to choose Arc. I think Clojure's main flaw compared to Arc is that it's a bit cumbersome to do iteration, because there's no general support for tail call optimization.
Arc has a few things positively going for it:
* Arc's implementation doesn't implement the whole language from scratch. Instead, syntaxes, data representations, and primitive operations are inherited from Racket, and most of the high-level tools are implemented in Arc itself as a library. What remains in the Arc implementation is a small, unintimidating core focused on some compilation and pattern-matching features. Since the core is small, it's easy to make certain modifications if needed. (Modifications to things inherited from Racket, like changing the reader syntax, are more challenging.)
* It extends s-expression syntax in a few minor ways. I think one of these extensions, the (a:b:c d) shortcut for (a (b (c d))), is particularly compelling. It tends to reduce lines of code, indentation, and parentheses all at once:
* Paul Graham wrote influential essays about language design that led to the release of Arc. Some people, including me, came to Arc because they read those essays and liked the high-level goals and priorities they expressed. Arc probably isn't even the best existing manifestation of those goals, but it is a Schelling point at least.
It doesn't seem fair to call Anarki design by committee. It's closer to a small number of scatterbrained people who periodically have a shiny new idea and add it in in anarchist fashion. Maybe design by Dory? http://www.imdb.com/character/ch0003708 :)
It would be nice, but I have a hard time recommending it to anyone with no releases since 2009.
Perhaps Anarki would be something to recommend. But that's not really being driven forwards either. Any changes are the result of design by committee, which doesn't tend to lead to great design.
PG is absent here. He hasn't posted in over five years. He's also mentioned that he doesn't care about initial popularity, as he doesn't think it matters for a "hundred-year language". I somewhat disagree; if people write off a language in year 0 because it's unpolished, they may not revisit the language in year 5 when it is.
It would be cool to have an Arc conference. I've met up with both akkartik and waterhouse when I traveled to SF for Startup School. Perhaps if you're interested, you could organize a virtual conference, or even a virtual chat with Google Hangouts or the like. Sacha Chua holds virtual hangouts for Emacs, and they've been pretty cool.
Mature: more people have used Clojure, kicked at the wheels, found bugs.
Who wants unhygienic macros? People here and those who like Common Lisp. Why? They're more flexible. They give you enough rope to hang yourself, but if you exercise taste in using them life can be quite good.
We often prefer arc because we want to poke under the hood and understand how interpreters and compilers work.
If your goal is to learn, it mostly doesn't matter what you use. Just build. The journey is what matters. Use something where you have someone to ask questions of. (Like here.)
(If your goal is something more specific, then Arc might well not be a good idea. But then neither will anything else, most likely. But you'll still have built something by the time you realize that you chose wrong.)
The people that run HN don't seem to be interested in doing so, and they almost never post here (except like one time: http://arclanguage.org/item?id=19389). So getting even an updated Arc release hasn't happened, nevermind actually letting the community push Arc forwards.
The community is definitely stagnant. PG has been the driving force behind its publicity, so because he hasn't said anything about Arc in a while, there isn't new blood coming in.
That said, Arc is probably a better language if you want to hack the language, and Clojure is better for almost everything else. This is especially true if you need libraries, or want something that Just Works^TM.
