[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Trailing parens
> -----Original Message-----
> From: firstname.lastname@example.org
> On Behalf Of Michael Vanier
> Sent: Wednesday, December 19, 2001 2:02 PM
> To: email@example.com
> Cc: firstname.lastname@example.org
> Subject: Re: Trailing parens
> > Date: Wed, 19 Dec 2001 11:37:43 -0500
> > From: Paul Prescod <email@example.com>
> > IMO, human beings just prefer flatness to hierarchy and iteration to
> > recursion. I know that when I write Scheme (or really any language)
> > 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
> > mental resting point.
> So do I, but I think you've hit on a deeper issue that is a real
> (maybe *the* real problem) with teaching functional languages. IMO
> whole point, the whole advantage of learning functional languages is
> you can program at a higher level of abstraction, and thus make less
> for yourself (less code overall) and understand what you're doing
> 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
> 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
> of abstractions which build on each other. Each abstractive step is
> straightforward, but once you're up five or so levels of abstraction
> 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
> layered abstractions one becomes a much more proficient programmer.
> 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
> 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
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