I find this quite hard to believe. I've been developing Ruby/Rails web applications for over 2 years, and while I like the idea of Arc and would love to be as productive in a Lisp as I am in Ruby/Rails, that is not reality yet because of the libraries.

The toy example pg put up way back when did show off Arc, but once you add real world requirements, Arc comes up a little lacking.

  * scalability of not requiring session affinity
  * database libraries
  * regular expressions
  * Rails *huge* library

  class MyPet < ActiveRecord::Base
    set_table_name 'pets'
    ...
  end

> The toy example pg put up way back when did show off Arc, but once you add real world requirements, Arc comes up a little lacking."

Oh, you are totally right about that. That's why I reimplemented the Arc web server in Lua. Now, I have libraries too (even if Lua isn't the richest language in this regard, at least communicating with the outside world is damn easy -- that's the language's goal). I think I'll try to write a small CRUD framework to see what can be done.

> "It's trivial (takes one line) to have a class with a name different than the table [...] You can turn off pluralization in one line.

> I hardly consider those minor changes to be reconfiguring the whole thing."

Ok, that was a little exageration. But to me it feels like bad design : why didn't they default to "the table has the same name as the class" ? That's simpler, easier to implement (no exceptions to take care of) and foreign-language friendly.

> "You may want to actually develop some non-trivial applications with Ruby/Rails before comparing to Arc."

I did it. It's especially when the application starts to be non-trivial that I hate having to fight with Rails designers' points of view to make my stuff work. On the opposite, with Arc/Luarc, the more my application grow, the better its design feels, because I have to make explicit things I considered implicit / subject to change in the previous versions.

That is probably only my own vision, but with the Arc model, I can see my applications becoming more mature and stable, while with the Rails model, I see them getting more and more patched, with more and more bureaucracy to make everything work.

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.

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

Well, I'm still playing with Arc, and particularly still love its webapp's model, but I'm really fed up with the lack of libraries especially when I want to do real work, so I actually wanted to see if its web server could be easily implemented in another (good) language. Well, it can, even if it's not as elegant as Arc's code.

What I've learnt :

First, macros are really great, I miss them ; Lua has extensions if you want to play with macros, but I didn't use them here

I already wrote about that, now I'm sure : Arc has too many basic datatypes. It has string, symbols and characters, Lua only has strings, and that's clearly enough ; a lot of code in Arc is converting strings, symbols and characters into each other.

What do you want to be designed? One of the major problems about "designing" a new lisp is that, since anyone can "do it" in their spare time, they don't see the point. Maybe they're right. ^^

As for strings and symbols, I don't really know how they are actually implemented, but as far as I know, the idea is that 'foo and 'foo are the same memory location, while "foo" and "foo" are not necessarily the same object(thus allowing string mutation). Or maybe I'm wrong ?

Lua's strings are implemented the same way : "foo" is always the same location as any other "foo" and string manipulation really doesn't seem to be a problem at all...

    (= foo '((key1 . val1) (key2 . val2)))
    (= bar (cons '(key2 . different-val2) foo))
    bar
    => ((key2 . different-val2) (key1 . val1) (key2 . val2))

Probably means we want to have some sort of "source" slot too, so that we can display shadowed values. Hmm. The association sublists e.g. '(key1 . val1) can probably be directly shared, but lists also imply an ordered set, so we need to store that info too. Hmm.

>As for strings and symbols, I don't really know how they are actually implemented, but as far as I know, the idea is that 'foo and 'foo are the same memory location, while "foo" and "foo" are not necessarily the same object(thus allowing string mutation)

This is correct. And when you really look at it, changing strings as if they were arrays of characters is hardly ever done in Arc; usually what's done is we just read them off as an array of characters and build a new string.

> In any case, characters just seem useless...

  >  => ((key2 . different-val2) (key1 . val1) (key2 . val2))

Two symbols 'foo can always be considered to mean the same thing, two strings "foo" can't, they may be only the same by coincidence. This matters if automated refactoring tools become available because you can safely rename all occurrences of a symbol, the same cannot be said of strings.

- excellent macro system (even if mzscheme seems to have a "dirty" defmacro too),

- the empty list is the false boolean,

- the syntax (particularily [] and :) is really a great improvement,

- I never built webapps that fast (and with so much fun),

- my list is close to almkglor's, but he's before me in the leaders' list, and I'll never catch him, so I can't follow him on this point :)