RE: Trailing parens

["David Simmons" <address@hidden>]

> -----Original Message-----
> From: owner-ll1-discuss@ai.mit.edu
[mailto:owner-ll1-discuss@ai.mit.edu]
> On Behalf Of Michael Vanier
> Sent: Wednesday, December 19, 2001 2:02 PM
> To: paul@prescod.net
> Cc: ll1-discuss@ai.mit.edu
> Subject: Re: Trailing parens
> 
> 
> > Date: Wed, 19 Dec 2001 11:37:43 -0500
> > From: Paul Prescod <paul@prescod.net>
> >
> > IMO, human beings just prefer flatness to hierarchy and iteration to
> > recursion. I know that when I write Scheme (or really any language)
I
> > often consciously flatten my code by defining local variables or
> > creating functions.
> >
> >   (let* ((first (expression-to-calculate-first))
> >          (icap (expression-using-first)
> >
> > I only defined "first" to flatten the structure and give the reader
a
> > mental resting point.
> 
> So do I, but I think you've hit on a deeper issue that is a real
problem
> (maybe *the* real problem) with teaching functional languages.  IMO
the
> whole point, the whole advantage of learning functional languages is
that
> you can program at a higher level of abstraction, and thus make less
work
> for yourself (less code overall) and understand what you're doing
better.
> The price you pay is that you have to be able to understand the new
> abstractions you create.  Languages like C which have hardly any
> abstractive power force you to write code which is trivially easy to
> understand on the micro-level, but which consequently requires a huge
> amount of code to do anything on the macro level.  So it's a classic
> trade-off: more thinking, less working vs. less thinking, more
working.  I
> prefer the former but I'm dismayed to find that nearly all programmers
> prefer the latter.
> 
> When I first read SICP, I noticed that the code is structured as a
series
> of abstractions which build on each other.  Each abstractive step is
> pretty
> straightforward, but once you're up five or so levels of abstraction
it
> gets quite difficult; you feel like your head is going to explode.
> However, it was clear to me that once one gets good at dealing with
these
> layered abstractions one becomes a much more proficient programmer.
But
> it's hard work!  And most people don't want to work hard when they can
> write code in a flatter hardly-any-abstractions style that is easy to
> understand on a line-by-line basis.  The penalty is that they are
going to
> end up with much more code and spend much more time debugging than
> proficient scheme users will.  Pay me now, or pay me later.

I agree here, but would suggest a different reason as to why. Most
programmers are focused on solving a domain specific problem. They spend
their energy and thought on the problem in it domain, *not* on the
problem of expressing the problem to the computer via their language of
choice. 

That's why people want/desire languages that make it easy to express a
problem for a given domain; then the implementation language becomes
"transparent" and they can think in terms of the problem itself not how
to express it. 

Ignoring economic/job-skill factors, once a person has invested in a
language and is comfortable to the point where it is largely transparent
for them, it is very difficult to get them to change languages unless
they both find a problem where their current choice of language is
fairly weak/opaque, and an alternate language is available which is very
similar or almost identical to their established language
comfort/skillset but also happens to be transparent in the required
area. I.e., why Java was a much more nature step for C/C++ programmers
than scheme or Smalltalk is/would-be.

-- Dave S. [SmallScript LLC]

SmallScript for the AOS & .NET Platforms
David.Simmons@SmallScript.com | http://www.smallscript.org

> 
> Mike
> 
>