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.
Documentation would be helpful. I think it would be nice if the docs did more than just describe the interfaces to the functions, though that would help. It would be nice if the docs were more developer oriented for the time being, so that interested parties (like myself) could figure out enough of what was going on to help a bit :)
Once I learned what and how things were going on, then I could start to work on libraries. Not to mention the virtual machine. ;)
Personally, of the other three, I would prefer the VM if it included erlang functionality. In second place would be the a2c, because I think it would optimize better than a native compiler, though I could be wrong. I've been amazed several times by what y'all have been able to do.
That being said, a native compiler would be really cool. It sounds more stable and standalone than a2c, and probably the right long term choice. It's also something I'd be interested in learning how to do.
The only other thing I think the community should do is start a good wiki for documentation. That and a good place to upload / download libraries, a la cpan. I don't think we want to include them all in git forever. It would be great if we could make a good centralized place to find libraries and documentation, instead of distributed across blogs and this forum.
There's kens' excellent http://arcfn.com , as well as the Anarki-only (help ...) : use (help function-name) for help on a specific function and (help "regular expression") to search function names and documentation.
re: native compiler: possibly a gcc front-end might work?
There is a wiki on github. For the moment I think putting all libraries on Anarki should suffice. When the libraries begin to proliferate (if this will ever happen) we could start thinking about something like cpan.
I'm very much in favour of the first one. Simple things like that can have a big impact on how people perceive a language. I even began writing an IDE in Arc as a staring point, but it got reprioritised.
Even better though would be if the Lisp community put down its stupid in-fighting and built a language-neutral easy-install environment; something that could edit and run Scheme, CL and any other dialect you might want to write. Imagine building Arc on an environment that's actually designed to have Lisps implemented on it, rather than trying to fake CL style lists in MzScheme and all that nonsense. Imagine if you could write back-ends to different architectures, making Rainbow and arc2c unnecessary.
That would be cool. As far as I know, s-exps are s-exps no matter which lisp they're written in. The general environment might need a good way of defining syntax so that it could be more helpful than just a text editor with REPL, but that sounds like something lisp should be capable of doing pretty well.
The only problem is that everyone would argue over which language to implement it in. How about we just start in arc, and let them all join us later?
Actually, it sounds like an extended DrScheme, which already supports several different languages of scheme in the editor. If the interface was improved a bit, and it was extended to handle CL and Arc, then it should suit admirably. Unfortunately, I don't know how the language selection feature works, so I don't even know if that's possible.
Arc is probably a good language to implement it in, because it has such a small core and is so flexible. I also think Arc's users are a bit more experimental and ambitious than most Lisp users. Consider the fact that Arc will probably have a shared-nothing garbage collector before any other dialect!
How do you post polls? I was going to ask which libraries we should work on first. Though some people think we should write programs first, and then figure out the necessary libs, I think that there are a great many libraries that are so basic and useful that anyone would want them. A math lib, for instance.
