[plt-scheme] A Couple of Questions on DrScheme/Mzscheme

OK, this is probably a bit off-topic for the PLT list, so I apologize in
advance.

My subjective opinion ;-) is that if the syntactic issue was the only thing
holding scheme/lisp back, it would have been solved a long time ago.  In
fact, it *was* solved a long time ago.  There is an article on the
evolution of lisp by Richard Gabriel and Guy Steele (I don't have a link,
sorry) where they point out that the idea of designing algolish
(pascal-like) syntaxes for lisp is an idea that gets resurrected every so
often, only to be abandoned when the implementor finally realizes that
s-expression syntax is, indeed, better.  Dylan is one example where the
designers went all the way anyway, and the results are nice.  The drawback
AFAICT is that macro design becomes more complex.

I think the syntactic issue is a big entry barrier.  But beyond that, it's
the pervasively functional nature of scheme and lisp that puts off many
programmers (not me; I love the functional approach).  I believe it's
because it requires the programmer to learn to think in a new way, and most
people resist this, especially in the absence of extremely concrete
evidence that the new way is substantially better.  I believe it *is*
better, but I'm not sure I could convince a die-hard (say) java programmer
of this.

Mike


> From: MichaelL at frogware.com
> Date: Thu, 26 Sep 2002 14:31:59 -0400
> 
> Let me offer a subjective response to a subjective question.
> 
> I think many languages aspire to Scheme's/Lisp's power. Regardless, I think
> that Scheme/Lisp won't ever be a language for the masses. The reasons, I
> think, are related. Languages aspire to Scheme/Lisp because of their
> ability to abstract concepts. When, however, other languages adopt those
> abstractions, they give them clothing appropriate to the adopting language.
> In other words, they give them syntactic sugar--and I think that's very
> important.
> 
> Scheme/Lisp is able abstract so well because it's able to introduce new
> mini-languages very well. But it takes more effort to read a lot of code
> which is basically written in one or more mini-languages--especially since
> those mini-languages are rarely documented, etc. Note that my point isn't
> that you *can't* read or understand--just that it takes a lot more effort.
> As an example, I'd invite people to read a lot of Python-based web code vs
> a lot of Scheme-based web code. Python uses syntactic elements to signal
> the use of various things like for loops and lists. That in turn means you
> don't have to stop and think about many of the pieces quite as much. That
> in turn means that it takes less time/effort to understand a chunk of code.
> 
> I think I can even offer an example from within Scheme/Lisp. Think about
> creating old-style macros with back-quote--with and without the syntactic
> sugar:
> 
>   `(some a ,b , at c)
> 
>   (quote (list (quote some) (unquote b) (unquote-splicing c)))
> 
> Don't worry about whether or not the second version is a correct
> expression; it doesn't matter. The point is simply how much syntactic sugar
> can help you see the pattern of use immediately and easily. And the larger
> the pattern--eg, the larger the macro in this case--the more that sugar
> helps. Scheme/Lisp, of course, offer very little of that kind of help;
> back-quote is a rare example.
> 
> So on the whole I think that Scheme/Lisp require more effort from the
> programmer. I think that some people find that cost worthwhile, but most
> don't. And I don't think that's a problem that can (or maybe even should)
> be fixed from within the language; if you did, you wouldn't have Scheme
> anymore--you'd have Python.
> 
> So no, I don't think Scheme/Lisp will ever be wildly popular. To me the
> only goal would be to demonstrate to the *better* programmers what they get
> in exchange for the cost. Maybe they'll see it as a good trade (I do), and
> maybe they won't--but thinking that the masses should or would adopt
> Scheme/Lisp to me is a goal that will never come to pass.
> 
> Michael.
> 
>