Re: XML as a transition to s-expr

[Michael Vanier <address@hidden>]

> Date: Tue, 18 Dec 2001 13:59:44 -0500
> From: Paul Prescod <paul@prescod.net>
> 
> Bruce Lewis wrote:
> > 
> >...
> > 
> > I think the only thing standing between Lisp (at least Scheme) and the
> > most novice programmers is an hour with a halfway-decent tutorial.

No, there's much more to it than this.

> 
> I'm going to risk flamage and say that Scheme (not MZScheme or BobScheme
> but R5RS Scheme) does have usability problems. I came to that conclusion
> watching the DSSSL experiment. It looks to me as if you are going to
> replicate the experiment with BRL.
> 
>  * the parens are poor for error reporting. You could imagine a Lisp
> that would report syntax errors much more reliably:
> 
> (if (brl-related? message)    
>      "users.sourceforge.net"
>      "alum.mit.edu"
> if)

I agree.  In mzscheme you can use [] or {} as substitutes for () that have
to match their counterparts.  This improves the situation considerably.
But I wish there was a more comprehensive way to (optionally) specify end
markers in lisp (e.g. ".if" to end if).

> As it is, Scheme errors can be reported miles away from where you
> actually forgot a paren.
> 
>  * 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.

I don't see this as an issue.  Almost any decent editor will do
paren-matching.  Most people do find )))))))) at the end of functions
pretty distracting, but you learn to tune it out.

>  * the parens do not sufficiently denote "parts of speech". Consider the
> two examples described by this URL:
> 
> http://www.cs.utexas.edu/users/wilson/schintro/schintro_21.html#SEC21
> 
> if test1 then
>    action1();
> else if test2 then
>    action2();
> else if test3 then
>    action3();
> else
>    action4();
> 
> versus.
> 
> (cond (test1
>        (action1))
>       (test2
>        (action2))
>       (test3
>        (action3))
>       (else
>        (action4)))

You could write a macro which does this e.g.

(multi-if (test1 then action1)
     else (test2 then action2)
     else (test3 then action3)
     else (action4))

but I doubt anyone would use it.  After a while you just don't notice stuff
like this.

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

True.  And Common Lisp also has first, second, ... up to tenth.  First and
rest are better than car and cdr, but car and cdr can be composed to give
(somewhat pronounceable) names.  "cddr" is pretty awkward to say
(cuh-duh-der), but it's faster than "all-but-the-first-two-elements".  If
you don't like this, feel free to do this:

(define all-but-the-first-two-elements cddr)

> 
>  * most people learn procedural programming in high school. 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.

Your first point is the crucial one (more below).  The second one is
trivial; just use a vector.  You *can* program imperatively in scheme just
as well as in python.

> 
>  * 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.
> 

Well, you'll never get universal agreement in that community, so I see no
problem with using a particular implementation as long as it's well
supported.  Libraries are vital, but if enough people like the language
enough to want to use it, the libraries will follow.

So IMO the problem is having to learn a new programming paradigm.  All
evidence suggests to me that programmers are *incredibly* resistant to
learning new programming paradigms.  Sure, there are the weirdos like me
(and most of us on this list) who enjoy that sort of thing, but to most
people it's about as appealing as skydiving without a parachute ("You mean
all the tricks I've spent years learning are completely useless?  Screw
this!").  Even OO took, oh, twenty years to become mainstream, and OO is
much less of a mental stretch than functional programming.

Why is functional programming so hard for people?  I think it has something
to do with the fact that people believe that programming fundamentally is a
process of do-this-then-do-that-then-do-something-else, whereas functional
programming is much more declarative.  Instead of telling the computer what
steps it has to go through in computing a factorial, you tell it what a
factorial IS: it's the product of an integer with the factorial of the next
lower integer, unless the integer is zero in which case the result is one.
This takes time to get used to.  Also, almost everyone in intro CS classes
has done some imperative programming before, and once that mindset is
established it's very hard to dislodge.  They know how to compute
factorials one way, so why should they bother learning a different way to
compute them?  Isn't the only important thing to get the right answer?
Finally, concepts like recursion and functions-as-data are very foreign to
students who haven't seen them or missed them in other languages.  So
functional programming to most students means a whole lot more work for no
obvious benefit.  Telling them that functional programs are higher level
and easier to verify formally and debug doesn't help either, since none of
them have written large enough programs to realize what a bitch debugging
imperative programs really is, or how much benefit can be gained from
working at a higher conceptual level.

Mike