I will take ages until we have a decent, reliable implementation of arc.
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
I did. If you you look at the introduction of R6RS where it thanks people "for their help in creating this report", you will see my name listed. But I discovered that while I wanted a personal programming language, the members of the committee had different goals, so there wasn't much I was able to offer.
By reliable implementation I mean something that you would bet your project on. When you choose to use it in production software you have certain expectations from it (stability, performance, etc.)
If the reason to start arc was "a different goal of the scheme community", well, then I guess it's all about politics...
Arc is used in production software. Using some other language will be a better choice if it has some feature or library you need that Arc doesn't have. However, for the features that Arc does have, its stability and performance is fine.
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
No. If someone else wants to travel to the other side of the world and I want to visit my local coffee shop, it's not politics for them to work on buying plane tickets and for me to work on buying a bicycle.
"No. If someone else wants to travel to the other side of the world and I want to visit my local coffee shop, it's not politics for them to work on buying plane tickets and for me to work on buying a bicycle."
Different people have different goals, desires, and needs. Let's suppose that I was the one who wanted to travel to the other side of the world... it wouldn't make sense to say to me, "hey, plane tickets are expensive! use a bike instead!"
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.
It's not a matter of politics that different people have different desires, and that different languages focus on different desires.
Building a language for production software is always about politics.
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.
I'm not sure anything will come of this testbed, but I find it enormously educational to ask myself 'what if' questions and play with arc until I figure out why it would be a bad idea to design lisp this way or that.
Maintaining backwards compatibility isn't one of the things I need or am looking for in a production language. If it's something you need for your production system, that's a valid requirement that would cause you not to choose Arc. But don't conflate your personal requirements with what's needed for a production system in general.
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
- "no, Arc doesn't have Y and my best guess is that it probably won't".
"To the question "do we have a decent and reliable implementation of Arc for production systems" the answer is yes."
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."
One of us can maintain a more regularly-fixed variant, but there's several of those and the community hasn't converged on one of them.
At this point we're arguing semantics, which is a futile exercise. So yes, we should just say x, y and z rather than fluffy words like 'production'.
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.
I'm not saying this is a good thing, btw. I think this whole model is wrong. But I'm just one guy shouting at the cosmos, and I certainly haven't seen more than the tiniest sliver of what people do with software.
Arc already is a possible production language. Look at C. It is one of (if not the) most popular language... ever. A massive amount of code has been written in C. C is used to write the OS that you are using right now. C++ (which is similar to C) is used in most web browsers.
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.
---
* [1]: Of course, a good hacker will probably despise programming in a bad language, but I still think they would be more productive than a bad programmer using a good language.
