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]

Re: Scheme is too complicated


Jay Glascoe writes:
...
> > Hmm.  I think your definition of slow and mine are different.  Could
> > you clarify what you mean when you say 'slow'?  How do you account for
> > the performance of Stalin?
...
> the functional guy is sleek and pretty, but those "vector->list" and
> "append" bits are performance killers. 

I think the issue is that a functional programming style makes for a
lot of copying (with some associated garbage collection).  Computers
work much more quickly on in-place algorithms, where no copying is
necessary.  And, deep down, (all?) computers are imperative.

However, programming in a functional style can lead to great
optimizations, because the behavior can be predicted before runtime
much better.  I imagine Stalin uses this to its advantage(?)
Distributed programming also benefits from this -- I'm sure there are
other benefits as well.

But Guile isn't compiled or optimized, so the advantages of functional 
programming are mostly stylistic/aesthetic.


As to the size of C/Perl/Guile programs, I think a lot of it has to do
with the libraries.  I find the various C libraries to not be able to
integrate themselves into the language very nicely at all.  Perl does
this much better, not to mention having so much functionality built
right into the language.  I also find that shell scripting (who's
library is the programs on my machine) works very nicely for me.  And
what could be shorter than an Awk script for a job which Awk is good
at?


But now I've gotten to thinking about libraries.

I'm not sure what the Scheme environment really is -- it's stuck in
the elegance of its mathematical roots.  But *practical* elegance is
to make a system whereby a programmer can work in a rich environment
while maintaining certain things:

  * Readable programs: both a matter of making all function calls as
    meaningfully named as possible -- where namespace-declarations
    *aren't* meaningful, but short descriptive names are; making the
    library functions fit well into the structure of the code the
    programmer is writing -- avoiding wrapping everything in lambdas
    and allowing the code to be structured as best fits the problem.

  * Transparent code: all aspects of the code can be inspected and
    understood, including the library functions.

  * Mnemonic: a rich environment means having a lot of functions.
    Remembering each one and the forms it takes will get difficult
    without some means of managing it.  Keyword arguments are (IMHO) a 
    great way of doing this.

  * Documentation: both reference -- a listing of functions and
    what they do; and concept-based -- what you want to do and the
    functions (and data structures) provided to help you do those
    things.  Optimally, closely integrated with the process of writing 
    code, e.g., a good Emacs environment.

I don't think Guile does particularly well on any of these.
Documentation, of course, we all know about and know how to fix.  The
other's aren't so obvious.  

There's two issues: what could a good library system in Guile fix, and
what could language extensions in Guile fix.  I wouldn't stand behind
language extensions -- when does it stop being Scheme and become some
little brother of Common Lisp?  But maybe there's a way to do these
things in Scheme and I just don't see it.


Readability: Scheme has a way of leading to long expressions.  When
you get down to it, any functional procedure will be made up of one
(long) expression.  That's hard for humans to parse.  I like the
highlighting that DrScheme does -- when you are at a open or close
parenthesis, it highlights (without being obnoxious) the expression
that is enclosed by that parenthesis.  The passive nature of the
highlighting is what makes it nice.  (The static code analysis that
DrScheme does is also nice, but I'm not sure it's helpful enough to
warrant the complexity of implementing the interface)

There might be other ways of representing the Scheme to make it more
readable.

But this is mostly a complaint about Scheme as a language, not the
libraries.  

Along the library side, it would be nice to think about the naming
system for all the library procedures and coming up with a consistent,
concise, and meaningful system for naming (this also helps mnemonics).
I wish I could give a concrete example, but I haven't really worked
with any complex libraries in Scheme.  However, what I haven't seen
that I think is important is that Guile should be viewed as including
not only the core language, but a set of modules which provide
commonly-used functionality.  These are too essential to the language
and it's practical use too simply be add-ons.

A rich set of datatypes could also be a powerful addition.  Make
dictionaries, not hash tables -- mostly that's just a matter of
terminology, but I think it's important.  As a programmer, I don't
care about the fact that hash tables use hashing, I care about the
fact that hash tables are a collection of values indexed by keys.


Transparent Code: Well, write as much of it in Scheme as possible.
If, for performance reasons, it isn't written in Scheme consider
providing a reference implentation which does the same thing as the C
(just slower).  

If/when debugging in Guile becomes pleasant, allow people to actually
use these reference implementations so that they can access everything
their code does to a fine degree of granularity.  For instance, if you
provide a bad hash function to a hash-table, the error (or worse: the
lack of error) might pop up inside some hash-table function.  Being
able to inspect the innards of that function will make it much easier
to find the bug.


Mnemonics: As with readability, some deep thought about the naming
system will help.  Also, keeping the number of functions to a minimum
is also important.  I think keyword arguments could be of great help
here.  They allow a very general function (with lots of parameters) to
masquerade as a less general function.  Also, argument order is almost 
always arbitrary (and thus hard to remember): keywords help solve
this.  I think they could be important enough to be used heavily in
Guile, even if it is (in effect) a language extension.

An object system could also help.  With dynamic typing, it seems so
close... all the compromises are there (space, time, lack of static
analysis), but the benefits are not completely reaped.  An object
system allows a function which can work conceptually for many
datatypes to actually do so, without cond statements (which are
ugly).


I guess, to me, it's a question of Guile being just a language (which
it is) or an entire environment (which it isn't -- at least yet).

My, I wrote a lot more than I was expecting to.


<------------------------------------------------------------------->
< Ian Bicking                 |  bickiia@earlham.edu                >
< drawer #419 Earlham College |  http://www.cs.earlham.edu/~bickiia >
< Richmond, IN 47374          |  (765) 973-2824                     >
<------------------------------------------------------------------->