2. Even in a large standardized language like Common Lisp, many important things are missing: sockets, threads, and many more. And I don’t think R6RS will alleviate this problem that much. It does not address access to basic OS stuff: directories, sockets, etc. (Perl, Ruby and Python are different. They all rely on a benevolent dictator that imposes its view on the rest of the world. Just consider each Scheme impementation as a different language.)

3. Perl, Python, Ruby may have a lot of libraries, but they are not of equal quality. Also, if you decide to use a specific Scheme system, you will certainly have access to lots of libraries (Chicken has over 300 eggs – libraries). I am pragmatic guy. When I write Scheme code, I usually stick to a single implementation. (Why always target all Scheme systems anyway? I don’t have time to do that ;-) If you want your code to be as portable as possible, isolate the dependencies in specific modules.

4. I’m not sure this one is true. This may be true of some implementers, mainly those from academia, but all the Schemers I know would love to have more libraries.

Want to discuss these issues further? Join us at the next meeting of the MSLUG ;-) We will have one at the end of August.

It is with this spirit of deep devotion to Scheme that I reluctantly talk about some of Scheme’s _weaknesses_ as a development environment. Some that come to mind immediately:

1. A dizzying array of different Open Source and proprietary Scheme compilers and interpreters. I think it’s fair to say that none of them have really captured a majority of Scheme hackers. Scheme is a remarkably easy language to implement, which is a positive and negative thing.

2. Lack of some key features in the language specification (libraries, sockets, database access come to mind immediately) has meant that language implementers make up their own interfaces for these features. This makes it difficult to write portable libraries. Note that the SRFI effort (http://srfi.schemers.org/) and upcoming revision of the language (http://www.r6rs.org/) will alleviate this problem to some extent.

3. A lack of portable libraries for common development tasks. It’s worthwhile comparing single-implementation languages like Perl, Python, and Ruby. While there are tens of thousands of Perl modules on CPAN (http://www.cpan.org/) that will work on practically any Perl system, and hundreds if not thousands of Python and Ruby libraries in their respective repositories, the number of portable Scheme libraries available for download is probably in the low dozens, to be generous. This makes writing new Scheme applications a bit of a pain. The SNOW Project (http://snow.iro.umontreal.ca/), hosted here in Montreal, is helping a lot with this.

4. A general perception among Scheme hackers that these aren’t important issues. Fewer portable libraries, after all, means *I* get to write MORE SCHEME. Yay! There’s also rivalry between communities around different Scheme applications — doing things that are good for the _entire_ Scheme community is less attractive than doing things to promote Gambit, Chicken, Bigloo, Guile, Gauche, PLT, dot dot dot.

I don’t think Scheme is going away any time soon, but I wish that the fractured community could build things together better.