I vote for building real applications and letting those drive the requirements of the language. Only that way can we have a truly minimalist language (if that's still a goal) - everything in the language is required by at least one application. Even performance - yes, I would love some, thanks - isn't so strictly necessary until we build apps that really need it. And then we get performance in the areas that actually matter.
From the itch-theory of open source: pg had an itch for a news forum, I have an itch for a personal-finance-management system, an app to tell me who's borrowed my books, a dedicated arc IDE (@cchooper: I'm trying that in rainbow btw, it's a lot of fun). Oh, and tetris.
I don't have an itch for an arc-xml converter, or an arc sql library, or for a better arc security model or sandbox features. But such libraries might well be important for an application we write, and that would be a good time to implement them ...
My experience shows one real application could easily require many, many libs. Yes there are exceptions, don't bother listing them because the rest of the universal code base relies on libraries.
Libraries are both a weakness and strength for lisps. Yes there are libs that do EVERYTHING out there. Each one has a different style and approach. There are no standard methodologies across the libraries. This makes it difficult. Everytime a developer brings in another library they have to figure out how to use it. Versus interfacing with libraries in python, ruby or even Java / C#... everything is much more uniform.
There is a bigger opportunity with small to medium size experimental projects. I think a great example is: http://www.pageonetimes.com/ which is based on PG's news code.
personal-finance-management system
In the past I've implemented front and back-end financial software. I think it's a huge undertaking and best implemented with as many tested and true libraries as you can find. It's absolutely possible in arc, but why use arc when it's not the best choice (for now atleast). Meanwhile there are a number of other areas where the code will not be nearly as library dependent.
a dedicated arc IDE
I think an IDE is a great idea. In my opinion, the way to do it is to use existing IDEs. DrScheme (already works...), Eclipse, SLIME all come to mind. Now before everyone goes nutty thinking we need our own IDE - yeah eventually. But who is going to put in hundreds of hours of time into implementing a new IDE when you could plug into three existing IDEs in a fraction of the time.
I think at this point a completely new IDE would need to incrementally improve on the best IDEs that are out there. VIM, Emacs, Eclipse, XCode, VisualStudio, etc (ya, a decent IDE seems to be one of the few things M$ does right).
I agree that the lack of libs is a real problem. My real world example: I have have a bunch of RSS feeds, and I want to regularly poll those feeds, extract some content, and add it to my site (pageonetimes.com).
Doing it with Arc alone is too much for me - for mysterious reasons get-http.arc isn't working for me. Even if it did, I would have to write my own rss parser. Instead I am using Ruby for this, and grabbing the RSS content, parsing it, and saving the results is about 10 lines of code using standard libraries.
What kind of problems exactly does get-http.arc give you? It's a translation of a piece of Common Lisp code I had written to be able to fetch RSS feeds. The CL version worked well for the task.
In my CL project I thought to parse it manually, but I've abandoned the project after finishing the HTTP part. I've never tried using it, but you could have a look at treeparse in Anarki, if you haven't done already.
