Re: Implicit binding and ergonomics (was Re: ... too complicated)

[Erik <erik@msc.tamu.edu>]

On Fri, 13 Nov 1998, Tel wrote:

> 
> Would you share web references with us for beginner level scheme tutorial
> material that is freely distributable? I found it a bit hard starting
> but there is a lot of intermediate and advanced material out there.
> I'm having trouble getting other people started because there is nothing
> to point them at without spending a lot of time sitting with them and
> explaining. There are books but they are expensive :-( There is also
> R5RS but that isn't suitable for a beginner. I'm looking for ``getting
> started'' type material.

hmm... I'm not sure about freely redistributable, but 
http://www.cs.rice.edu/CS/PLT/Teaching/Lectures/Released/curriculum/
had quite a bit, and I have an "Introductory Scheme" document in latex
which is quite good.  I can't find where I got it originally, but I just
put it up under http://msc.tamu.edu/~erik/stuff/scmintro.tgz  I can't find
any copyright/license notice in it, except a copy of an email mentioning
putting it into the scheme repository, which I assume means it is OK to
redistribute.  Other than that, I checked the guile reference manual
and tutorial out from cvs, and even though they were somewhat dated, they
were quite helpful.

You are right that there is not a lot of up to date stuff specific to
guile, but a lot of the other scheme stuff is close enough (I even got a
good bit out of Mike Terry's Script-Fu Tutorial
http://www.soulfry.com/script-fu-tutorial/ )

I'm wishing some of the local bookstores carried books on scheme (I am
aware of Amazon, but I'm usually not home when the UPS man comes by, so it
can be a pain.)

> You can get an everything's global attitude in scheme by sticking a
> bunch of (define) statements at the top and use (set!) everywhere.
> It's no worse than C in this regard, and I actually quite like globals,
> they regularly get bagged but for getting stuff to work in a hurry or
> explaining something to a beginner, they do the job.

They most certainly DO have a place, and sometimes there's no better way
than to make global.  I was just pointing out that making everything
global means lexical scope is very simple, but most of us would consider
_always_ making _everything_ global to be poor programming practice.
Anything which limits scope makes understanding code more difficult, and
that's a price I'm willing to pay (especially if they'll give me a nice
way to get around it and make a global when I want to.)

> A language should not encourage a mode of thinking, it should ideally
> be transparent to all modes of thinking. I doubt that this is achievable
> but setting things up so that you can do the same job in a lot of different
> ways is a very healthy thing. The less you encourage railroad thinking
> the better IMHO.

I don't believe a language can be completely transparent to ways of
thinking.  The preconceptions and preferred practices of the language
designers will always come through.  That is, after all, why we have so
many good programming languages.  Different people like to program in
different ways, so they make new languages, and they use them.  I agree
that ideally a language would be agnostic with respect to programmer
thought processes, but I fear that attempting that in the real world would
create something designed by committee and bloated beyond imagining.

Personally, I notice that I tend to write big, huge functions, or put
almost everything in the main body of the program in perl.  In C I tend to
make a main() which fits on a single screen, or maybe two, without many
functions longer than that, and many only 10-15 lines.  I'm just beginning
to develop hints of a style in scheme, but it seems to involve very small,
compact functions frequently involving recursion (I don't use recursion
much in C or perl) and much less likely to be invoked for the sake of side
effects than in either C or perl.  Each of these has it's good points, and
places where it seems more appropriate than the other.

I'll stop blathering now.

Erik
erik@msc.tamu.edu