Various languages were represented in the audience. Generally, python and erlang users were less impressed; but users of java and other blubs found a new way in which their language was inadequate :)
Some were concerned about unreadability, and others dismissed arc as impractical, but overall I think people seemed to appreciate the power macros can bring to a language, and how hopeless the situation is for java et al, given their heteroiconicity.
I could not agree more. Arc's web development model is the best I ever found. You can really make apps as fast as what Rails or Django offer, without being limited to CRUD applications or being stuck in an official way of thinking : in Rails, if your table is called pets, then your class MUST be called Pet (don't even think about not using classes), that's convention. If you have other conventions or if, in your mother tongue, the plural of "cheval" is "chevaux", well, too bad for you. Oh, or you can reconfigure the whole thing, of course...
Well, maybe a few functions providing a "preconfigured" framework for CRUD applications would be interesting. We would have all the benefits.
You can really make apps as fast as what Rails or Django offer
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
It's trivial (takes one line) to have a class with a name different than the table:
class MyPet < ActiveRecord::Base
You can turn off pluralization in one line.
I hardly consider those minor changes to be reconfiguring the whole thing. You may want to actually develop some non-trivial applications with Ruby/Rails before comparing to Arc.
> "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."
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.
Of course, it is still better than with, say, PHP, where it is bureaucracy and patches all the way down (that could be a motto : "PHP : patches all the way down").
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.
"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.
Hey, I know I haven't been there for a while, and now I'm here to show you some Lua code.
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.
Arc has lists and hash tables (and unofficially vectors), Lua only has tables ; again, a lot of code in Arc tries to convert lists as hash tables.
Agreed re: libraries. I expect that libraries might start showing up once/if folks feel that pg hasn't simply left entirely as it appears currently. Typical catch-22 - who wants to write libraries for a language that might stagnate or die?
The boring stuff, like building nice parameterized SQL queries and getting back the data from SQL. Launching a system process in parallel and keeping track of its status (and potentially aborting it if e.g. it takes too long)
If we do all of the boring stuff in a clean, concise way, that makes everything easy, with the option of adding macros on top to boot, the boring stuff might well become fun, or at the very least, painless.
Some times ago I started a GTK+ binding, now "paused". It's more boring than I thought initially. If you wish look at it for a starting point (file gtk.arc in Anarki). I now think a binding towards tcl/tk would look nicer and easier to use, though.
That's true. Programming languages take years to evolve, not months. Moreover, Arc is in the language design phase. As of today, the syntax and the semantics of the language are more important than libraries. For example, I'd like to see something like Kenny Tilton's cells (http://github.com/stefano/cells-doc/) nicely integrated within the core language.
I would suppose that since a) this language is not used in anything "important" yet, and b) it's open source; yes, it can be in the design phase. I should think that the design phase persists until, for some reason, the language becomes "formalized", or until it is impossible to change anything major without ruining things for a lot of people. At that point you can still "design" the language, but since it has a generally understood "style" and so forth, it won't be able to change too much unless you make a whole new language.
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. ^^
Sorry for all of the quotes; it looks kind of funny, I'm sure.
On the basic datatypes of arc: you cannot remove symbols or lists from arc. Then it would no longer be a lisp. I suppose you could just have strings be symbols or vice-versa, but then you either put overhead on usage of strings for variable lookup or overhead on usage of symbols for string manipulation.
Yes, but, for example, association lists could be implemented as hash tables while beeing seen and manipulated as regular lists. That's tricky, but that should be feasible. And Clojure removed cons cells and thus "traditional" lists, but it's still a Lisp...
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...
I really think "foo" could be just an alternate syntax for 'foo (just as |foo| is) so that we still have a Lisp... Add string manipulation facilities to symbols, and you're done. In any case, characters just seem useless...
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...
Another lisplike, Skill, uses 1-char length symbols for characters (i.e. no separate character type). Also, many of its string manip functions also accept symbols (although they still all return strings).
Another point to consider is that if your a-list is very small (<= 5 elements) it could be faster than hash tables. The sharing behavior could be achieved with some sort of concatenated hash-tables, a list of tables to consider in turn to find the desired element. This seems very slow though. BTW, removing a-lists would be useless: they're so simple to implement that a lot of developers (me included) would re-invent them to use in their applications.
My two cents on strings/symbols, there are semantic reasons they should always be separate. It's not about string mutation, ignore the implementation, it isn't relevant.
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.
Mixing strings and symbols is a bad idea, they are different things and should remain that way.
Oh I don't disagree, I'm actually a Smalltalker and I'm accustomed to Symbol being a subclass of String and a String being a list of Characters. I actually have refactoring tools so I just wanted to point out that they are different for more than just implementation reasons and there's a logical reason to have symbols beyond mere optimization.
I just hang out here because I like to see how a new Lisp is born and how you guys think, even though I don't actually use Arc.
The reasons I use Arc (well, not these days, due to incredible lack of time, but...) :
- 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 :)
Now, sure, PLT is an excellent language/environment. But it's waaaaay older, that helps. Actually, if today I was given the opportunity to program in a Lisp of my choice (for work I mean, not for fun), I'd use Arc for a basic webapp and mzscheme for almost everything else.