[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Trailing parens
> -----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
>
>