Re: XML as a transition to s-expr

[Shriram Krishnamurthi <address@hidden>]

Paul Prescod wrote:

> I'm going to risk flamage and say that Scheme (not MZScheme or BobScheme
> but R5RS Scheme) does have usability problems. 

That's not a particularly controversial statement.  If anything, it's
a significant understatement: in the eyes of this audience, R5RS
Scheme has no usability at all.  [R5RS is one of the standard Scheme
reports.  It provides a maximally spartan language.]

This is admittedly confusing to people who haven't been around Scheme
long enough, but the problem here stems from thinking of R5RS as a
programming language.  It's not.  It's a notation for expressing the
computational core of most computer science problems.  It has
virtually no useful built-in library support, and indeed refuses to
support anything it cannot thoroughly define.  (A frequently cited
example: it doesn't include FILE-EXISTS? because, in theory, this
predicate isn't very useful: the file may disappear between testing
for its existence and actually opening it.)  In that sense, R5RS is
also a useful benchmark in minimal language specification.

So, what good is a notation if it's not also a usable programming
language?  For those who want to process /etc/passwd, none at all.  So 
this standard has given rise to several actual languages that add the
stuff you need for day-to-day programming.  More on that in a bit.

>  * the parens are poor for error reporting. You could imagine a Lisp
> that would report syntax errors much more reliably:

I think Don Blaheta has addressed this well enough.  Also, the
source-correlating expander of DrScheme has meant that, in practice,
we have not received a single bug report about errors being reported
for the wrong location (and our users are not shy of reporting bugs).

>  * the Lisp community has an attitude, totally at odds with, let's say
> the Perl community, that you can get around this problem with the "right
> tools" that will do brace-matching for you. Python people have this
> attitude to some extent also, but I'll note that most editors (even
> Windows notepad) come out of the box configured to work okay with
> Python.

They come configured to work okay with Scheme, too.  I use vi quite
often, and when I do, I never invoke it -l.  The parens you're closing 
are all either on the same line or at the beginnings of previous
lines.  This is not too incredibly hard.

Anyway, I'm pretty impressed to hear that you can edit 5000-line Perl
programs without any help from the programming environment at all.
You fire up legacy Perl code you inherited and now need to modify, and
Notepad automatically does ... what, exactly?

>  * the parens do not sufficiently denote "parts of speech". Consider the
> two examples described by this URL:

That's why we encourage a consistent use of [...] for these kinds of
grouped terms: conditionals, LET, etc.  Works like a charm.

>  * car, cdr, cadr, cons etc. are not exactly newbie friendly names for
> core functions.

So use FIRST, SECOND, etc, which are all built in.  Problem?

>  * most people learn procedural programming in high school. 

And LOTS of people are learning Scheme now.  So?

>							      They don't
> learn the functional, recursive style. Scheme strongly encourages you to
> use the functional style. If you try to increment a counter and index
> into a Scheme list, you'll have terrible performance because they are
> implemented as linked lists, not stretchy arrays.

Oh, gee, yeah, those high school students, they're really running into
terrible performance problems with their mammoth codes, aren't they.

Students who are taught to program with indices and vectors and then
encounter Scheme will (a) either be turned around by their college
instructors or (b) look up "number" and "vector" in the manual.

>  * we've already discussed how important libraries are. "Scheme" can't
> become popular until I can download any random scheme and expect a rich
> set of libraries. Some specific Scheme distribution might become
> popular, I guess, but then you've got a fragmented community with books
> that apply to Scheme versus those that apply to the distribution, etc.

You have it backwards.  Each extended Scheme really is its own
different language.  When you find one you like, use it and be done
with it -- what the other extended Scheme systems are doing is of no
real relevance to you.  It just so happens that all these extended
Schemes have one thing in common: a person who wants to switch from
one to the other (just as one might switch from, say, Perl to Python
or Perl to Ruby) already knows the core of the language.  And the
textbooks by-and-large teach this core, so there's a large and growing 
number of books available as well.

Bottom line: the problems you're talking are typical concerns of
someone who spent more time thinking about Scheme than immersing
himself into one of the standard, well-supported, well-documented,
feature-rich extensions.  DSSSL was a pathological project, one whose
incompatibilities with Scheme made it impossible to leverage the great
work being done in the Scheme community.  Sorry about that.

Shriram