7 points by pg 3 hours ago | link | parent | on: Why Arc
is bad for exploratory programming
Obviously what I meant is that the core language is tuned
for exploratory programming.
Also, I disagree with his criteria. Speed isn't really
important for it. And dynamic typing, which he omits, is
very important.
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)
Arc is now offically a Lisp! When detractors try to say "the number of libraries available sucks!", somehow the name of the language comes out instead of "the number of libraries available"!
If arc could seamlessly access PLT scheme's libraries that would be a good start. I know from first hand experience that there are a number of ways to access PLT scheme from arkani and arc. But, there are two big issues. First there are type differences between fundamental types (lists gah). This means there can be a lot of work to convert between PLT scheme and arc, not impossible but time consuming. Secondly, there is no nice way to pull in a PLT library and just use it in arc. Of course this could be implemented - it's just not there yet.
There are two choices I see going forward immediately. Arc and the arc community starts implementing their own libraries or we find a way to use PLT scheme's libraries (ok maybe sbcl if you are using arkani).
I know there is additional information somewhere in the forum on type differences when coercing data between scheme and arc - specifically '() nil (list) aren't equivalent. Worse come to worse - see the source.
