Arc Forumnew | comments | leaders | submitlogin
Where are we going?
33 points by stefano 3168 days ago | 85 comments
I've been following Arc since the beginning, like many of you. I've seen it going from a growing community of ideas to a shrinking community too small to improve the language quickly. The problem, though, is not the size of the Arc community right now (this is still a young language after all) but the fact that Arc lost its momentum: instead of attracting new people, users now go away from here. How did we get to this situation? What has changed? On day 0 Arc was launched as a prototype for a programming language. Some ranted about the deficiencies of the implementation (slow, no Unicode, useless error messages, no debugging facilities, etc.), but they were acceptable because it was a prototype. The goal of a prototype is to give the users a feeling of the language, so that they can contribute by saying what's wrong, what's good and what's missing. The author(s) should then discuss with the community to decide future directions for the development. This is what happened in the early days of Arc. This period didn't last very long, though. After the release of Arc2, pg almost abandoned the forum, and feeling the absence of the "boss" many left the building. Some left permanently, others lurk the forum just to see if it will come back to life. What the remaining community had was a prototype not suitable for real world development and not suitable for its role of prototype because the author wasn't there to listen to his users. This lead to a plethora of alternative implementations (anarki, rainbow, arc2c, snap, nyac, primitivearc, arc-f, ...), all trying to overcome the limits of the original, unmaintained version. The lack of a central authority lead to a dispersion of the few resources (in terms of people and time) available. New ideas died because the language (together with its main site) was held by an absent leader. To give one example, not too much time ago, there was the idea of a central repository of Arc libraries. The right place would have been under This is still an invalid link. Every effort is useless if it will never be part of the official Arc instead of laying around in some github repository. There are only three possibilities for Arc right now: pg comes back (Hahaha!), someone takes the lead and makes a real fork of Arc, not just of the implementation, but also of the community and of the main site (no more The last possibility is to let Arc die.

I'd appreciate the opinion of who is still here (even lurkers) on this post. What do you think about the history of Arc so far? What do you see in its future?

13 points by lojic 3167 days ago | link

What do you think about the history of Arc so far?

From my perspective, it appears to be a history of different expectations.

On the one hand, it seems that pg:

  1. is taking a long term view of the language
  2. is focusing on core language issues
  3. doesn't want to be held to a schedule
  4. prefers less communication with the community
whereas, it seems at least part of the community wants:

  1. to see *signs of life*
  2. useful libraries
  3. to know the plan (or whether there is one)
  4. more interaction from pg (communication, acceptance of bug fixes, etc.)
As with many misunderstandings, better communication might go along way in helping to set proper expectations.

For example, I have some questions for pg that might be shared by others in the community:

1) What is a reasonable upper bound for producing new releases of Arc - 6 months, 3 years, ... ?

2) Will you accept bug fixes for the language in the future? If so, approximately when?

3) Besides the profiler you mentioned, what contributions would you like from the community? Do you want any contributions from the community?

I think some of the disappointment that is felt by some in the community is due in part to the potential we see in the language. Yes, we know you're taking a long term view, but when we saw the potential to use Arc in place of current tools, we hoped we could use it soon. Obviously it's usable now, but that's a relative term.


15 points by pg 3167 days ago | link

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.


5 points by almkglor 3167 days ago | link

Did you have to be so crude?

Well I'm also kinda pissed that PG doesn't seem to be noticing anything Arc-related anymore, but his loss IMO.


4 points by silence 3166 days ago | link

Thanks for all your hard work almkglor. I have learned a lot.


17 points by cchooper 3168 days ago | link

Personally, I think the only thing that went wrong in the history of Arc is that pg didn't correct people's misunderstandings about what it was, and what it was trying to achieve. A 100-year language is not going to be usable tomorrow, and a language designed by the optimal number of people (one) is not going to accept many patches!

If people want a practical language to use now (and there's nothing wrong with that!) then they should go ahead and build one. I'm happy to join any project that anyone may have for developing an Arc-like language. I might even start one myself (why not? It'll be fun!) if I have the time.

A language doesn't survive in its implementations, but in its ideas. Modern languages (especially Python/Ruby, but even C# and Java) are becoming Lisp. Dynamic typing, late binding, functional programming, closures, generic functions, MOP... the 'popular press' laughed at them, but now these are the hot topics in language design. Those ad hoc, informally-specified, bug-ridden, slow implementations of half of Common Lisp are getting better every year. Common Lisp and Scheme will die, but in 10 years everyone will be using Lisp, and they won't even know it.

The same goes for Arc. Clojure already uses some ideas from Arc (e.g. fewer parens in conditionals). If the ideas are good (and I think they are) then they'll spread. If people want to build new languages (e.g. Arc3F) that use them, then that spreads them further, That, I think, is the true future of Arc, as a source of eternal ideas.


6 points by lojic 3165 days ago | link

I have to admit that Clojure looks very interesting. Functional programming, concurrency with software transactional memory, access to a huge Java library, conciseness, etc. It's also a Lisp-1 like Arc w/ Common Lisp style macros, but it has namespaces. It doesn't have TCO due to JVM limitations and I don't think it has continuations, so an Arc-like web server might be more challenging.

The concurrency story is particularly interesting given the proliferation of cores and slowing of GHz.

The Clojure version of Norvig's spelling corrector appears to be one line shorter than Norvig's Python version:

I would really like to see an Arc version of that. I translated Norvig's Python version to Ruby easily, so I expect that someone fluent in Arc could do it easily.

The other Lisp versions I've seen (Scheme/Common Lisp) were quite a bit longer and less elegant IMO.

I'm not super excited about Clojure's dependence on the JVM, but on the other hand, that gives it a huge head start with libraries and state of the art VM/JIT technology.

Rich Hickey doesn't seem to have the star power of pg, but he is very involved in the language and community. He seems like more of a Matz or Guido which doesn't seem that bad - he seems quite sharp in his web cast presentations.

I could be way off, but it seems like it would be easier to add Arc innovations to Clojure than to add Clojure-like concurrency support to Arc.


4 points by almkglor 3165 days ago | link

> continuations, so an Arc-like web server might be more challenging.

Arc's server doesn't actually use continuations - it uses functions that serve as continuatinos. There's no call to 'ccc or any of the wrapping forms in srv.arc (at least none that I remember)

> The concurrency story is particularly interesting given the proliferation of cores and slowing of GHz.

This is true and I think the "extra-cycles-to-waste" property expected by PG isn't going to put out in a hundred years.

> state of the art VM/JIT technology

Forget the libraries. This is what's scary about any JVM language.


1 point by sacado 3165 days ago | link

"Arc's server doesn't actually use continuations - it uses functions that serve as continuatinos. There's no call to 'ccc or any of the wrapping forms in srv.arc (at least none that I remember)"

That's right, no 'ccc. That's why I could implement it so easily in Lua (no real continuation in Lua either). As for TCO, I'm not sure it's a real problem in this case. Sure, a lot of simple functions are written in a recursive style, but they can be trivially rewritten in an iterative style.


2 points by fjl 3146 days ago | link

arc is a movement, not a language.

the primary goal was not to build a language but to get an avalanche of new lisp implementations started.

that lisp is quite easy to implement makes the idea even more compelling.


2 points by Zak 3078 days ago | link

>It doesn't have TCO due to JVM limitations

This is only half-true. Clojure cannot automagically convert a self-call in the tail position in to iteration, but it does have the recur form to provide essentially the same semantics. I've also found it useful that recur throws an exception if used outside of the tail position, making it obvious which recursive forms consume stack space and which do not.


2 points by arjungmenon 3167 days ago | link

I personally feel that a language core should be the work of a single person. Period.

The core set of axioms that form a language are almost fundamental as the laws of nature to that language. Just imagine theory of relativity being developed by several scientists together... almost impossible.

Even 2 persons should not work together on a language core. The quantity of communication required if 2 persons work on a single language is so large, that hinders and messes up the development process.

If there's one place where the saying "Too many cooks, spoil the soup" applies; its core language design.


12 points by almkglor 3168 days ago | link

LOL. PG has been taking some flack recently IMO; e.g. .

Personally I'd volunteer to take the lead, really fork Arc, and go on with Arc-F. Unfortunately, I'm not at all experienced in actually launching and maintaining a website. Worse, Arc-F can't host news.arc (or a ported version) yet; I'm somewhat redesigning the Arc server because of the lousy and inconsistent design, but I'm kinda stuck on how to handle the continuation server functions bit, which strike me as the dirtiest bits of the Arc Server.

The last alternative - let Arc die - is something we should seriously consider though. Clojure is gaining the popularity that Arc could have had. Like Arc it's a redesigned Lisp (fn and new ssyntax, anyone?); unlike Arc, it wasn't hyped very much for >6 years, its maintainer is still visibly leading the language, and it runs on the JVM. The only advantage of Arc that I see is that it supports both imperative and functional paradigms - and some might argue that this isn't actually an advantage.

Letting Arc die would hurt me a lot, though. Other than the original writers of Arc, I can probably reasonably claim to have made the largest contribution to Anarki (many of the docstrings in the Anarki arc.arc, for example, were by me).


18 points by pg 3168 days ago | link

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.


9 points by almkglor 3167 days ago | link

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? .

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.


6 points by rntz 3167 days ago | link

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.


8 points by pg 3167 days ago | link

These are just bugs. Good design doesn't equal not having bugs. If it did, someone who merely patched bugs in a system would be a great designer.


9 points by stefano 3167 days ago | link

> These are just bugs

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.


8 points by jimbokun 3167 days ago | link

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.


5 points by stefano 3167 days ago | link

Clojure has already taken many things from Arc (there is also 'prn !)


8 points by SwellJoe 3168 days ago | link

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.


7 points by z0ltanz0ltan 3168 days ago | link

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.


10 points by pg 3168 days ago | link

you have been less than clear about your plans for Arc

It seems to me that I've been much more explicit about this than people working on new languages usually are at this stage:


4 points by akkartik 3167 days ago | link

In fact, I always felt PG released arc sooner than he would have because of all the people who asked to see it.


1 point by bayareaguy 3164 days ago | link

Judging from it's first year, I don't think Arc will follow the popularity paths of those other languages. It's more likely to go the way of Dylan.


5 points by stefano 3168 days ago | link

Clojure is on my list. When (if) I give up on Arc It will be the next language I'll learn and use. A lot of libraries from the start. Good performance (the JVM is fast once started). And, most importantly, Rich Hickey follows the language and promotes it. Arc had the great advantage that it had a community of users from the beginning. After its launch, a lot (relatively) of people were already using it. Despite this advantage, Arc hasn't reached the popularity that Clojure has today. Arc had the possibility of being a great language. That possibility has been wasted.

If you want to fork arc, you'd better change its name to break with the past. Make something new. I like the ideas behind snap. I only wonder how much time it would take to have a usable system. Sadly, I'm not able to really help :(


7 points by bOR_ 3168 days ago | link

Just in general - is there anything in arc which gives it a big edge to programmers when compared to clojure?

Here are some of the differences, but I can't tell if one of them is crucial. I listed three below for which I've no clue what the impact is.
  * The read table is currently not accessible to user programs
  * Keywords are not Symbols
  * Symbols are not storage locations (see Var)
  * immutable data and first-class functions
  * *first* is clojure's *car* ;)


6 points by almkglor 3168 days ago | link

> Just in general - is there anything in arc which gives it a big edge to programmers when compared to clojure?

Mutation. It's one thing to allow functional programming. It's another thing to force it.

The only thing constant is change.

> * The read table is currently not accessible to user programs

Neither does Arc, although Anarki does allow redefining of 'ssyntax and 'ssexpand, which almost gives you the same thing.

IMO not giving access to the read table is a good thing. There are very subtle problems with this, starting with: the read table affects all code loaded after the readtable modification.

It affects them whether or not the code was written by you, and whether or not it was written with that readtable definition in mind.

This can cause unfortunate library breakage when two libraries try to modify the same readtable entry; the poor user is thus left at the mercy of which library loaded last.

In fact Arc-F has revoked Anarki's feature which allows 'ssyntax and 'ssexpand to be modified; redefine them all you want, Arc-F will use the built-in traditional 4 ssyntaxes : ~ ! .

HOWEVER, there are currently two reserved context metacommands which will eventually allow ssyntax redefinition at the level of the individual file: 'import-ssyntax and 'interface-ssyntax.

The important thing is that they are context-based, and because they are context-based, they are not global and they will (in general) affect only one loaded file.

> * Keywords are not Symbols

Unimportant - salt to taste.

> * Symbols are not storage locations (see Var) > * immutable data

Side effect (LOL) of the enforced FP.

> * first is clojure's car ;)

Unimportant - salt to taste


1 point by bOR_ 3168 days ago | link

Thanks for the answer. I'll try, play and see how immutability affects me.


6 points by almkglor 3168 days ago | link

Oh, Clojure is not quite completely immutable. Clojure has refs, and they can be mutated within the context of a 'dosync form. Kind of like the Haskell "do" syntax. It's more that Clojure defaults to immutability, and has special syntax to define portions that are imperative.


19 points by pg 3168 days ago | link

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.


14 points by stefano 3168 days ago | link

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 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.


11 points by pg 3168 days ago | link

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.


7 points by stefano 3167 days ago | link

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.


9 points by jimbokun 3168 days ago | link

Your mantra in your role running Y-Combinator is "make something people want."

Is Arc exempt from that?


17 points by pg 3168 days ago | link

You're forgetting two things.

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.


10 points by jimbokun 3168 days ago | link

"I don't want to make what people think they want right now."

Fair enough. I think this sentence pretty succinctly answers the questions in the original post of this discussion.


5 points by john_amendall 3168 days ago | link

Actually, it might be! PG doesn't need to make a living off of Arc.


3 points by cronin1024 3168 days ago | link

Yes and no - he may not be selling Arc itself, but his reputation as a Lisp expert is indeed on the line.


7 points by horia314 3168 days ago | link

hardly. I don't think anybody will thing less of him if Arc somehow fails. It was an ambitious project to begin with.


10 points by rntz 3168 days ago | link

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.


7 points by conanite 3081 days ago | link

I know, it's 87 days later, sometimes I take my time ... this article stirred me from some months of guilty inaction so I took another look at rainbow (arc in java).

The latest checkin supports complex numbers and a little bit of trigonometry, and it also goes faster, yippee! I was planning to use arc to play with fractals (ergo need for complex numbers) when I have a bit of spare time. This checkin makes rainbow a fairly complete implementation of arc, so if you're interested in trying out arc but need some of that ready-made java library goodness, rainbow might be your thing.

It's at and I'll document the trig functions and other features if anyone's interested. Anyone? Hello?


2 points by shader 3080 days ago | link

Nice to see that someone is still here ;)

So, how much of the java libs does rainbow have access to? And do you think that it could be used for web serving on a shared host? (I know, I've been asking that question too much lately)


3 points by conanite 3079 days ago | link

rainbow has various low-level functions for interfacing with java, including

  java-new (class . args)
  java-invoke (obj method . args)
  java-implement (class strict . functions)
so technically you can access any java library you want from your arc code as long as it's in your classpath. Ultimately though it's prettier to hide these calls behind macros or functions in arc so your code is more expressive. I've done this a little for swing (java's desktop UI library) - for example there are event handler macros like

  on-key (component (var) . body)
  on-scroll (component (var) . body)
where "body" is event handler code. From the perspective of the calling code, there's no way to tell it relies on java behind the scenes.

Java objects have the arc type 'java-object

  (type some-big-java-object)
  -> java-object
so defcall is defined to invoke 'java-invoke - you should almost never need to use 'java-invoke directly. In other words,

  (some-big-java-object 'equals another-big-java-object)
results in the call

  (java-invoke some-big-java-object 'equals another-big-java-object)
which, naturally, results in a call equivalent to

Strings, numbers, booleans and lists automatically convert to and from arc types. Here's a longer example:

  arc> (set foo (java-new "java.util.HashMap"))
  arc> foo
  arc> (type foo)
  arc> (foo 'put 'bar "toto")
  arc> foo
  arc> (foo 'keySet)
  arc> (type (foo 'keySet))
  arc> (foo 'getClass)   
  class java.util.HashMap

As for serving on a shared host - I switched from java to ruby a while ago precisely because it's a pain to use java on a shared host - and most java hosting plans offer a shared tomcat (tomcat: popular java app server) instance, so even then you couldn't use arc's webserver natively. You could implement the necessary servlet interfaces in arc and then package it like a java web app and tomcat would deploy it. So at least the logic of your app would be written in arc. If you want to try this, I'll be happy to help.


1 point by shader 3078 days ago | link

Nice to know that java isn't too hard to access, not that I expected it to be.

As for hosting, I'm currently using dreamhost. They provide support for python and perl via fastcgi, so I've been looking for a lisp option that could leverage that. Most of them don't have much in the way of libraries. And I like arc. So the option of using arc with java libs seems like a plus. How hard do you think it would be to write arc's web tools based off of fcgi? Unfortunately I don't even know what it takes to run rainbow via the jvm on a server, but I would presume that it's possible.


1 point by rincewind 3077 days ago | link

Have you thought about interop with Clojure?


1 point by conanite 3077 days ago | link

Not yet :)

but theoretically you could host a bunch of languages in a single jvm instance - and have arc, clojure, jruby, jython, and javascript (via rhino) all calling each other in a big polyglotfest. Java 6 includes a scripting framework ( ) that standardises the way a jvm hosts a ScriptEngine. I haven't looked at this yet at all but it's on my todo list.


1 point by CatDancer 3077 days ago | link

web serving on a shared host

what's your project?

how much do you want to pay for hosting?


1 point by shader 3077 days ago | link

Nothing too complicated or high volume. Our church website and a realtor's website, currently in php. We've been working on a design for a quasi-framework, and were hoping to do it in lisp. Currently my host is dreamhost, which pretty much permits anything, and has shell access. If I could use an fcgi interface, I'm pretty sure it would work. Which lisp / web framework do you recommend?


3 points by CatDancer 3076 days ago | link

How much are you paying for DreamHost? The cheapest Linode ( plan is $20/month. Download and unpack MzScheme, fire up Arc, and you're up and running. Sounds to me quicker and easier than messing around with fcgi, unless there's something about your situation that I'm not realizing.

If you want your two web sites to be running with different domain names (,, you have a couple options: you can run Apache (or any other HTTP server that can forward requests) in front of Arc, and be running two Arc processes, one for each site. Or you could hack Arc (or ask a hacker here to hack Arc for you) to look at the "Host" header.

Which lisp / web framework do you recommend?

Well, I use Arc myself, simply because I can use any language I want, and I like Arc. What I'd recommend for you would depend on what your goal was. If you want a powerful programming environment that will enable you to implement your two sites quickly and easily without having to do any Linux system administration, I'd recommend taking a look at AppJet (


2 points by revorad 3078 days ago | link

Hey thanks for that, conanite. I just posted the link on HN. Could you please answer this question? -


1 point by conanite 3077 days ago | link

Hey, thanks for that, revorad! It looks like stefano got there before me ... but yes, it's a complete arc, with ccc and tail-call optimisation. Unfortunately the JVM doesn't do this stuff natively so there's a whole arc VM running inside the jvm which as you can imagine slows things down a bit.


0 points by ltol 3073 days ago | link

Bug report: "Rainbow" poor name. Please fix.


1 point by absz 3073 days ago | link

I have to say that I like the name; it's also a multilingual pun, which gives it major bonus points (


1 point by ltol 3073 days ago | link

Pun was clear. Merit of French less so. Problem with name: Hard to google.


4 points by conanite 3073 days ago | link

> Hard to google

True. When I search for "rainbow lisp", google asks me did I mean "rainbow lips". Rainbow's github page is the 6th result for "arc rainbow", alone among many discussions of the shape of the multicoloured atmospheric phenomenon.

Once we've taken over the world, I think it will get better.

> Merit of French

I happen to live in france. It was a convenient pun. No other reason, especially not love of the language that I haven't got to grips with even after nine years of living here.


8 points by projectileboy 3168 days ago | link

This is just one guy's opinion, and I'm hardly a 133t Lisp hax0r. But I'm not a part of this community to ride the next big wave. I'm here because I'm tired of the next big waves, because they almost always suck. I'm here because I want to be able to latch on to something that actually provides me with some small measure of joy, and that has a chance of having some real, lasting impact.


7 points by andreyf 3168 days ago | link

What about "100 year language" don't people understand? PG's point isn't to make the language popular now, or in a decade... it's to make it popular 100 years from now.

Personally, I think it underestimates how different the world will be 100 years from now to talk about how programming languages will be then (just imagine what kind of "computers" we'll have then!), but I suppose the "100" number is arbitrary... I think PG just means generally looking at "long term", not "short term", and having a community is a short term advantage.


7 points by bOR_ 3168 days ago | link

PG won't be alive in a 100 years.. and there's a difference between slowly searching for an optimal language and not working at arc at all.

It is a bit sour for the community if their effort are not affecting the progress of the language towards its goal.

To be fair, PG has a point though that n months isn't that much if Arc is supposed to be 'finished' in about 30 years from now. We might just have wrongly expected things to move at a somewhat faster pace.


2 points by shader 3168 days ago | link

Speaking of optimizing for "100 years", what are some design decisions which would make the language more flexible/easy to use that, while possibly sacrificing speed or efficiency, would make the language more useful in the long run?

It seems to me that computers (currently, it may not last) are doubling in speed rather frequently, so any efficiency problems in the language will quickly be outweighed by it's usability. That's partly why one of the most popular tools for making websites is ruby. It may not be fast, but it's cheaper to double the server capacity than hire more programmers.



3 points by nlavine 3168 days ago | link

If you're looking at long-term prospects, my understanding is that the idea that computers have "speed", which "matters", is actually temporary (should stop around 2040 if current trends continue). At that point you run into the thermodynamic limits of computation, where the question is how much energy you're willing to put into your computation to get it done.

I don't know quite enough about that yet to talk about details, but see for some more information (haven't read all of it yet). The paragraph right under Figure 1 seems to be crucial.

However, I'm not sure that affects language design a great deal. It seems to me the goal of a language is to let you express algorithms in a concise and efficient manner, and I don't see that becoming unimportant any time soon.


2 points by shader 3151 days ago | link

Well, I think we're sort of agreeing with each other. You said that speed should be irrelevant, because language design was about describing algorithms concisely and efficiently; I said that we should try and think outside the box, by ignoring our sense of efficiency. If it didn't matter how the feature was implemented, what features could we come up with that could radically change how easy it is to code? Maybe there aren't any, but it is an interesting idea. That is not to say that I'm only interested in inefficient improvements ;)

Another possibility: Lisp is an awesome family of languages partly because they have the ability to create higher and higher levels of abstraction via macros. "Complete abstractions" they were called in Practical Common Lisp. Are there any other means that could create "complete abstractions"? Or easily allow higher level abstraction?


2 points by rntz 3168 days ago | link

Moore's law has actually been failing as of late. I suspect that exponential increase in computer capability is a feature of the yet-nascent state of computer technology. Assuming that it will continue into the foreseeable future is a bad idea. Performance is important; it's just not as important as some think, and in particular, it's not so much all-around performance as the ability to avoid bottlenecks that's important. This is why a profiler for arc would be nice, as would some easy and standard way to hook into a lower level language for speed boosts.


2 points by andreyf 3167 days ago | link

If you generalize Moore's law to cost of computation per second, it isn't failing. In 100 years, network availability, speed, and capacity will lead to yet-unimagined changes.

How will programming languages take advantage of a thousand or a million CPU's?


3 points by jimbokun 3167 days ago | link

Isn't Google (and others) already answering that question today?


3 points by andreyf 3166 days ago | link

OK, so let's rephrase it practically - how do you design a programming language if the IDE is running on Google's infrastructure?


7 points by eds 3165 days ago | link

I think part of the reason we were all hoping for more frequent releases was because, despite the fact that pg explicitly described arc as a 100-year language, he also stated that his design philosophy involved rapid iterations.

"I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly."

I actually think was a good plan, I just wish pg were able to follow it ;-) Even small improvements or bug fixes would make the community feel engaged.


4 points by EliAndrewC 3168 days ago | link

I'd love for PG to spent more time per month on Arc, since to me personally it's probably the most interesting thing he does. I enjoy his essays and think YCombinator has produced some great startups which I sometimes use, but Arc is more interesting to me than either of those things.

With that being said, I knew all along that Arc is an experiment in trying to make a 100 year language, not something that was intended to help me deploy commercial applications as soon as possible. So I've played around with Arc a little and been happy to have the experience.

I'll play around with it more as it gets more advanced and gets more libraries and such. Until then, I'll remain a happy Python programmer and look forward to whatever PG and the rest of the Arc community slowly end up evolving towards.


4 points by kens 3167 days ago | link

I've been meaning to write a blog post on my view of what Arc is doing right and wrong, but don't have the time. Instead I'll suggest that the generic language design critique at is worth applying to Arc; hopefully someone can answer those questions with respect to Arc.


2 points by cchooper 3167 days ago | link

I think all of those questions were pretty thoroughly answered in the original rationale essays for Arc. My only reservation is with question 4, because most of Arc could have been implemented as macros on another Lisp. That might change as it gets fleshed out.


3 points by sacado 3165 days ago | link

Well, on the design side, Arc is great, and I really love hacking with it. I'll keep doing it whatever happens. I'm even one of the few (I guess) users of the language for "real" work. The application I wrote a few months ago is still in use and she's fine, thanks for asking.

However, as it is now, it is really not a practical language : the implementation is slow, bugged, impractical (do you have the right version of mzscheme ?) and doesn't provide useful error messages.

I know, I know, this is a feature, not a bug. It will be ready in about a hundred years. It is not supposed to be a language "du jour" as, say, Python et al, addressing the trivial problem of solving today's needs. Well, that's great, but I do have needs to solve today. So, as for now, I'm using Lua or Python for real work.

Hence Luarc I already told about, which I'm using now for webapps. It doesn't have all the commodities of Arc (or even other Lisps), it even hardly has macros but, guess what ? It has libraries and can communicate with the world. I can even read from databases ! Can you imagine that ? Oh, I know, this is so "21st century", but I can do it ! It has all I really need : closures, dynamic typing, easy and fast development, apps written in a continuation-passing style, etc. I would like more, but I already have that.

Arc is for the next century ? Well, OK then, see ya in 2108. And I'm sure I'll be using it everywhere then, not only for my hobbies and for esthetical/philosophical reasons. If I'm still alive, of course.


6 points by DougBTX 3168 days ago | link

A cynical view of someone who has not participated in the arc community, and barley lurked longer then the time taken to sign up:

1) How long was it between you first hearing about Arc, and you seeing the first prototype? For me, it was a long time. Expect similar changes to happen along similar timeframes.

2) Arc is a Lisp: a language notorious for community fragmentation and trivially incompatible implementations. Without a strong, active leader, expect more of the same.

3) Arc isn't so much a prototype language, as a mini-fad / hype-based language. All things which survive find a purpose, Arc has rejected practicality as a goal, and anyone doing language research has probably already written their own Lisp dialect, so the market is probably limited to Hacker News readers. Activity on probably spikes whenever it comes up on HN, and depending on the news, has a long or short trail off. I probably won't return until another interesting Arc headline reaches to front page.


6 points by arco 3168 days ago | link

I agree that the authors have failed to create a sense of community by mostly being absent. They do provide a bit of feedback, but it is minimal at best. It is clear that their interest in this project is not aligned with the current interests of the self appointed "user base".

However, in my opinion (and I'm a nobody so you may want to stop reading here), the arc core as well as some of the code that ships with it (news.arc, blog.arc, html.arc) rank amongst the best examples of working lisp code that highlight the power of lisp. news.arc is a great example of the use of macros and arc.arc is a great example of the power of embedded languages (feel free to point out better). To say nothing of the fact that this stuff is simply beautiful in a way I don't get from script-fu, elisp (slime being the one exception), edi weitz libraries, SICP etc. (it probl has something to do with how concise arc is).

So whatever. If more arc is thrown our way, I'll be happy to take it.


1 point by fjl 3146 days ago | link

the key point in this is conceptual closedness, designing things to fit into each other, leaving room for your solution to fill in the blanks.

arc/scheme (and, to a degree, common lisp) code shows this much clearer than other languages. abelson and sussman followed that route in SICP, too, but you need to read between the lines.


4 points by lisper 3168 days ago | link

Not that I really want to flog this dead horse, but since you ask: my enthusiasm for Arc is dampened by the fact that it's a Lisp-1 with non-hygienic macros. This is not a problem as long as the code base and the user community is small, but the larger the code base gets the more of a problem it will be. By the time the code base is large enough for the problem to be evident it will be very painful to fix it.

IMHO of course. Paul sees things differently.


4 points by almkglor 3167 days ago | link

This is IMO true and has been of concern to me; I've tried to ameliorate this by adding packages and 'symeval to Arc-F, but I'm not 100% sure that those aren't just hacks to get around the weakness of the core design ^^


4 points by arco 3168 days ago | link

does your opinion come from experience? or it's just that you have a hunch in this direction?


6 points by lisper 3167 days ago | link

Neither. I've never done any large-scale coding in Scheme (I'm a Common Lisper) but it's more than just a hunch. The theory behind name capture is easy to understand. The only counter that I've heard is, "Well, it just doesn't seem to be a problem in practice." I believe that this is only because the Arc code and user base have not yet reached the scale where the problems manifest themselves.

But even if Paul is right and name capture is rarely if ever a problem in practice, punting on name capture seems to me fundamentally at odds with the stated goal of producing the 100-year language. At best it's an unnecessary burden on the programmer, and at worst it's a time bomb that could go off any time. Either way it doesn't make me optimistic that Arc is going to win in the long run.


2 points by byronsalty 3167 days ago | link

I don't think option #2 is feasible given the licensing of Arc. I think all forks are currently in violation of the Arc license. Which sucks.


2 points by nzc 3154 days ago | link

Let Arc die? What makes you think the number of posters here in any way reflects the chances of Arc "living" or "dying", whatever that means? People need to chill out and give things some ... time.


5 points by Darmani 3154 days ago | link

Ironically, before that comment, I had been concerned on how this forum had been dead for 6 days...


2 points by ebwen 3168 days ago | link


i am just learning, that my thought of learning lisp/arc seems to be futile.

what should i learn?


6 points by andreyf 3165 days ago | link

Stop it with the meta-decisions - learning Arc will take up one thorough afternoon. It's worth it because you'll start seeing ways of writing code in any language that mimics features Arc has.


5 points by skittles 3167 days ago | link

Clojure will give you jvm knowledge (which could help you get a job). It also forces functional programming which is becoming more important. I think everyone interested in a new lisp should help Clojure. It feels more like a viable lisp in the short term than any other.


5 points by niels_olson 3167 days ago | link


1 point by ltol 3073 days ago | link

Agree on "absent leader." Lisp needs not pg, but Lain.

Write CPAN for Arc, in Arc. Find holes in language, too. Worked great for Ruby, Haskell.