This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Scheme is too complicated



This touches on some really critical points.

> People want nice, simple languages for web scripting.  At *most* they
> want something like Perl or Python.. even Tcl is good enough in most
> cases.  A lot of the people doing web scripting are not particularly
> programmers, per se, nor do they need to be.  Languages like PHP work
> great for these people - it's easy to pick up the basics and do
> something useful.  Surely, there are those that may wish to do more
> complex things in this realm of programming, however, I think there
> are other things that may be the 'limiting factor' rather than the
> programming language - to wit, the realities of how an http server
> functions (persistent connections are a bit of a hack), SQL (ick), and
> the speed and time constraints with which an implementation must work.


Minor point: "simplicity" isn't important.  Perl ain't "simple" by any
definition, but it sure is successful.  As you say, it's ease of
learning.  Perl is excellent in this regard, because it borrows syntax
from other languages people might already know.

I think most of the non-programmers you're talking about learn by
modifying existing code.  Guile does have a disadvantage here, because
lisp code has a style that is different from most other languages;
what you might know about C isn't going to help you unravel a named
let.  I don't think this is fatal, and in some ways I think Scheme is
easier to munge than Perl.

What we need to do as a community is get Scheme off its pedestal and
into the gears.  We need to provide simple, readable examples of how
to use Guile for real-world programming tasks.  The Guile manual's
guided tour isn't going to start off with the factorial function; it's
going to start off with getpwnam(3), or find(1), or something like
that.


Major point: simple languages are a bad idea; ordinary users doing
everyday things actually need features typically omitted.

A simple language does not mean that the code you write in it is
simple.  Your application doesn't need to get very complex at all
before you begin to appreciate local variables, functions, and data
structures richer than strings.  When you need a feature missing from
the language, you have to work around it, which can complicate your
code quite a bit.


Two examples:

    A year or so ago, my friend Noel Cragg used PHP to whip up an
    entire ISP account and bug tracking system, in a weekend.  Clearly
    a success story for PHP (and Noel).  But he had to do some really
    gross trickery to report the (sometimes large) SQL query results
    back to the PHP code in a way it could handle.  If PHP had had
    reasonable datatypes, this wouldn't have been an issue.

    When Maciej started on turning FVWM into SCWM, he noticed that a
    lot of things got simpler, because Guile had real arrays,
    conditionals, variables, etc.  There was a lot of grunge in the
    FVWM configuration language that just went away.

In both cases, the "nice simple language" was actually in the user's
way.  It's a limiting factor immediately.

Here's the way the story has played out repeatedly in the past:

As a program with a simple scripting language ages, people inevitably
want to do something that doesn't fit inside the language.  The
maintainer certainly wants to accomodate the users, so he or she makes
a small extension to the language for the specific need, instead of
strengthening the language so that the users could have coded it
themselves.  Repeat this cycle for a few years, and you've lost your
original simplicity, and you are *still* in the trap of making little
extensions here and there, so your complexity is only going to go up.
And now it's almost too late to strengthen the language, because the
small extensions have complicated it so much.

Examples, off the top of my head: the POSIX Bourne shell, Perl, make,
sendmail, FVWM, the Tcl 8.0 Object API (Tcl itself is still quite
clean for its age).

My prediction is that PHP will either grow, in the same way, and in
response to the same pressures, or it will lose its users to something
which does.


And finally, I think a PHP->Guile translator would be pretty easy. :)