Kens is rather dishonnest there. There have been improvements in Arc's performances (including a few experimental ones with the 'compile keyword I added a few times ago) and accessing libraries is rather easy through mzscheme or the experimental FFI (it has to be improved, sure, but it's not that hard if someone wants to). The curently-developed arc2c should solve a good part of these problems, too.
Besides, Arc is too young to have lots of libraries programed in itself, but they're coming. What if, in 1991 (the year Python was released) someone said "Python is bad for exploratory programing : it does not have libraries" ?
You're right: Arc is just too young to have a huge (or even a medium sized) collection of libraries, because it takes a lot of time to write libraries to fetch web pages (BTW, look at http-get on Anarki), manipulate images and so on. We should talk about Arc in terms of what it will be able to become, not in terms of what it is today. In this view, the only real problem is the lack of a module system to support the construction of libraries.
He makes an important distinction in two kinds of exploratory programming, and just sort of is unlucky that he needs the second kind (whereas I'm happy, as I need the first kind)
I think there are two different kinds of exploratory
programming. The first I'll call the "Lisp model", where
you are building a system from scratch, without external
dependencies. The second, which I believe is much more
common, is the "Perl/Python model", where you are
interacting with existing systems and building on previous
work.
> accessing libraries is rather easy through mzscheme or the experimental FFI (it has to be improved, sure, but it's not that hard if someone wants to)
