Re: Scheme is too complicated

[Jay Glascoe <jglascoe@jay.giss.nasa.gov>]

On Sat, 31 Oct 1998, Ian Bicking wrote:

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

yeah, for instance, the Scandinavians (?) are absolutely mad about Erlang. 
comp.lang.functional FAQ:  "Erlang is a dynamically typed concurrent
functional programming language for large industrial real-time systems."

but what I really want is a high-level (very or not ;) language for gluing
my C extensions together, i.e. "Guile".

I admit to being willfuly dense (just a tad) in my last couple posts about
functional style.  But the thing is, even if I said functional programming
was absolute bollucks, I wouldn't be putting down Scheme.  That's one of
the great things about Scheme: it provides a 100% support for both
imperative and functional coding styles (and even this weird, slippery CPS
thing). 

> 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?

awk rules!

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

I'm not sure I follow.  In python I can do

import math
def area(r):
    return math.pi pow(r, 2)

In Guile I would *like* to do, i.e

(uses-modules (core math))
(define area (r)
  (* math:pi (expt r 2)))

(and maybe I can?  I have no idea how Guile's module system works.)

what can be more meaningful than "pi"?  However, the math library also has
an "e" for Euler's number.  Obviously, I don't want math to throw "e" at
my current namespace, but math.e <-> math:e, are great. 

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

let's just hope all those functions are kept in appropriate modules ;)

>   * 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.
> ...
> Documentation, of course, we all know about and know how to fix.  The
> other's aren't so obvious.  
> 

yep

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

hey!  you're talkin' to the guy who's been obssessed with auto-resizing
hash tables for the last month or so.  My hash tables are oozing with
doo-dads, quirks and gizmos that the user can fiddle with.  It was
designed by committee ;) 

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

I'm sure some whiz-bang elisp hacker can whip up some special Guile mode
for emacs.

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

If these modules were shareable objects ('*.so' on my machine) then you'd
never notice whether it was in Guile's core or not.

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

hmm?  (define make-dictionary make-hashtab) ...
a rose by any other name...
Could you further clarify your statements on hash tables/dictionaries?
I'm absolutely starved for feed-back.

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

I've found that Guile C extensions are pretty readable (relative to
Perl/Python extensions, Tcl? I have no idea)

> ...
<more stuff snipped, time to go home>

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

	Jay
	jglascoe@jay.giss.nasa.gov