Because working with arc is more enjoyable than working with scheme.

;=

I think you're assuming that people here only use Arc. I for example spend 99% of my programming time in Clojure. And still, in many respects, arc is better than other languages. For example, I think arc is perfect (syntax wise) for being an embeddable language. An end user of my app can easily become familiar with Arc, which is not the case for scheme or clojure. It's certainly both easier and more enjoyable to use than scheme is.

There's also a time/money/productivity argument to be made as well. I will not elaborate, suffice to say Arc wins this one hands down.

Short version:

This. Very this. I think Arc's smallness is a Good Thing.

---

Long version (do I have too much spare time on my hands...?):

The funny thing is, when I first started programming in Arc, I had almost no Lisp experience, and almost no functional programming experience either. Sure, I knew lambdas and closures (due to my JavaScript experience), but I didn't write my JavaScript in a very functional style. I kinda sorta understood the concept behind recursion, but when I tried to read a program written in recursive style, I didn't understand it and my brain hurt.

Yet, I was able to start writing programs in Arc... and anytime I had a question like, "I wonder how that function works", I could just look in arc.arc and see for myself. Despite all the limitations described above, I didn't have a very hard time learning Arc. After a short while (maybe 2 days or so), I had even started to get into the "rhythm" of Arc, reading and understanding code by it's context, rather than having to parse each individual node. I even forced myself to learn to read recursion a bit better.

I thought this was astonishing. Being able to pick up and quickly learn and use a language and paradigm that I had almost no experience with, just by reading the language itself. It was like how a baby learns to speak a language, except I'm not a baby, so I don't have that magical ability anymore. I didn't have that experience with Python. I could pick up and use Python because it was similar to JavaScript (both tend to emphasize imperative/procedural style), but I'm still constantly looking up how to do things in the Python documentation...

And then there's Racket. Racket has a large amount of documentation, and they even have a search engine to trawl through it and find what you want. Yet I still have a hard time figuring out what a function does, even though they give me what parameters the function expects, what value the function returns, a brief description of what the function does, and sometimes even examples!

I find Arc easier to learn and use, despite (or perhaps because of?) it's philosophy that "code is the spec". In a sense, I think being smaller is better for exploratory programming. Having a nice, robust, stable language with tons of well-written big libraries is great for writing robust programs. But I think a lot of that just gets in the way when you want to fool around and experiment.

In that situation, I think you're better off axiomitizing things as much as possible. Lisp does that by (over?)emphasizing lists, and then having a bunch of functions that operate on lists. You can then go in later and change the datatype to a hash table or whatever, once the program is in a more complete state.

It's easier to add things, than it is to take things away. Lua wins not because it can do everything, but because it's small, and smallness is good in embedded languages. I think Arc wins for a similar reason: it's small. I think it'd be a lot harder to evolve that kind of smallness in an existing language, compared to starting with a clean slate.

Oh yeah, maybe it would help if you thought of Arc as being more of a thin skin on top of an existing language (like Scheme). This is actually true in pgArc, Anarki, and ar, because they let you access the underlying Racket functions. So you get the niceness of Arc by default, but you can tap into Racket's libraries when you need to.

I also plan to eventually do the same thing with Arubic... allowing Arc programs to import and use Python libraries. And if I recall correctly, jarc and rainbow also let you call into Java's libraries. And then wart, which I assume lets you call CL functions.

Um, in what way is Arc not "reliable" today?

But anyway, so what? Extraordinary results usually take years. If you decide not to do something because it will take "ages" to do, you are probably dooming yourself to a mediocre outcome.

why not get involved in the evolution of scheme

If the reason to start arc

To clarify, I was speaking for myself. If you'd like to know why Arc was started, I recommend you read the essays: http://paulgraham.com/arc.html

I guess it's all about politics

And vice versa... if I were the one who wanted to travel to a local coffee shop, it wouldn't make sense to say to me, "hey, bikes are slow! use a plane instead!"

Two different people have two different needs, and the way that they can best achieve their needs are different. Arc isn't designed to be a production language. You can use it for production, but that's not Arc's goal. There are already other languages out there that are suited for production.

It doesn't make sense to demand that everybody use a "production language" just as it doesn't make sense to demand that everybody use a language designed for exploratory programming.

Thus, it is legitimate to say, "I want to do production work and Arc doesn't seem suited to that task", in which case we can try to recommend other languages that are better suited to production work.

But it's pretty silly to say, "Arc doesn't do production work well... you guys should use Scheme/Common Lisp/Java/etc. instead!" because that's assuming that we want to do production work.

My sense of arc is that it isn't concerned with becoming a production language that cares about backwards compatibility. So this is my answer to your question. Why arc? Because it's more permissive than lisp or scheme, and therefore a more suitable testbed for trying out programming language design. Because it is free from the political shackles of production software.

To the question "do we have a decent and reliable implementation of Arc for production systems" the answer is yes. People use Arc today for production systems.

Is Arc something that you would want to use for your project? I have no idea. I don't know what your skills are or what your requirements are.

I can offer some general guidelines. Arc is a language for hackers. If you're not not a hacker, then Arc is probably not going to be a language for you.

Arc is a language for exploratory programming. If your project is a straightforward engineering effort with a known solution, then while Arc might not be worse than some other platform it probably isn't going to be better.

Arc is a language designed to maximize the individual productivity of a programmer. It is not designed for programming teams working in a bureaucracy. If your project is large enough that you need a team of programmers to work on it, then Arc is probably not going to be a good choice for you.

And then there are particular features that you may need for a particular project. An easy question to answer is "I need X, Y, and Z, does Arc have that?". Then we could answer:

- "why yes, Arc has X, Y, and Z", or

- "why no, Arc doesn't have Y", or

- "no, Arc doesn't have Y but I think it probably will sometime in the future", or

But arc doesn't get regular bugfixes. The queue bug causes it to segfault, and it was fixed over months without any official support, and it still hasn't been integrated into arc 3.1.

When an outsider asks, "is arc reliable?" he's partly asking, "will discovered bugs get fixed in a timely manner?" I don't want to over-sell arc to outsiders, so my answer is "No."

In my experience people who use the words 'production use' are often talking in the context of a system that runs all the time, and that has a team of programmers working on it. In this context there can be lots of x's, y's, and z's that go into 'production', but it always includes "should I be afraid of upgrades?" (roti can confirm or deny in this case.) There's a reason perl and python and common lisp and racket have gone through contortions to indefinitely support bad ideas.

Yet, I would hardly call C or C++ very good "production languages", at least according to my definition. A smart hacker with a bad language is probably far more productive than a bad programmer with a good language[1]. Languages can help or hinder, but ultimately it comes down to the programmer.

So, yes, you can use Arc for production work. It may not be designed for it, but it is still possible. It also helps that you can use Racket code alongside Arc code, letting you tap into Racket's power when you need it. If you want a language specifically designed for production work, then Arc is probably not what you're looking for.

But if you want a nice lightweight language that is designed to be very hackable, malleable, and concise, while still giving you the underlying power of Racket when needed, then Arc could very well be what you want.

---