RE: scheme - my opinion

I'm going to be out of the country for a while, and I've been pretty hard on the Common Lisp proponents, so I'd like to summarize some that reflects my actual current thinking. After Reggie's last missive, I have to second something that Michael wrote a while back: whether we go with Common Lisp or Scheme, technically it's a win over the current situation. Although I still have my doubts over the management of a transition to something as big as Common Lisp can be managed, and see a relatively big risk in a fork in the development of the engine (ie, we end up maintaining our own version) because of the hugely detailed CL standard, I don't see any reason why it can't be managed. It's definitely going to require more work at the planning stage than Scheme, I think. I'll accept Reggie's (and others') judgement this should be (more than?) balanced by more rapid transition (and possibly later development), due to the availability of all the functions and keywords, and a better developed environment. Although I can't sympathize with Reggie's inability to imagine docstrings in Scheme :-), and think that call/cc is surely enough to counteract any de-Scheming effects of a `defun' macro, his point about lack of documentation for Scheme is really important. With a scarcity of good textbooks for the powerful features, they won't get used. Unless, say, call/cc really makes implementation of threads (eg) easier than implementing them for CLisp (or they have better performance on the less well-implemented platforms), which would be a big benefit, they'll just get dusty. That's not going to be true about objects! I don't think this is a killer point against Scheme; we can adopt standards for our own extensions, and modules from elsewhere, to minimize the documentation gap and implement objects and conditions. But this is definitely an advantage for CL. On balance, I do think "small is beautiful". While Reggie is right that a large environment providing lots of good software engineering tools makes for high productivity, it's not clear to me how many of the package maintainers will benefit so much from them. But the maintainers have to worry not only about the maintenance of the huge amount of XEmacs implemented at the Lisp level (where those tools will apply) but also about maintenance of the engine itself. Once we "OEM" a Lisp engine, we have to worry about the health of that project--- this is a very long-term commitment. Smaller engine means smaller risk. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091