[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

Mike