Software bugs aren't inevitable

[Terry Hancock]

On Thursday 15 September 2005 04:38 am, Jerzy Karczmarczuk wrote:
> is for me a biased view of the problem. Justified only by the fact that
> at the beginning of functional programming (sixties) nobody cared about
> the efficiency. Now, such languages as Clean, or good implementations of
> Scheme are very well optimized. OCaml as well, and Haskell is improving
> every 3 months. Functional languages did take off, but since a pure
> functionalism requires particular, quite sophisticated techniques in
> GOOD algorithm design and implementation, they are less adapted to the
> brutal world than C or Python. The reasons of relatively small popularity
> are much less technical than psychological, and this is KNOWN.

This is ludicrous sophistry. The technical reason for having ANY high
level languages is "psychological".  Computers are happier with binary
code, over ANY language that must be interpreted.  So, presumeably, would
some perfect intellectual being not limited by "mere psychology".

Programming languages are an interface to Human minds, so the argument
that one system of representation is easier to understand is an argument
that that system is *better* in that it is a better interface.
 
> (Terry Hancock formulated this plainly, he prefers dumb ways because
> he wants to solve problems, and he doesn't like to perform gymnastics
> with his brain. We have to accept those attitudes. But I believe that
> this is the effect of teaching standards; people don't learn high-level
> algorithm design when they are young enough...)

Clearly Jerry here believes that arrogance and intelligence must go hand
in hand: just for your education, there is a difference between *being*
intelligent and feeling like you have to *prove* it to everyone you meet.
I learned a long time ago, that there are plenty of *unavoidably* complex
problems out there, so that there's so need to make simple ones complex,
just to prove how clever you are.  You're darned right I avoid wasting
time on problems that don't require it.

As for the education claim, you are just *so* out of your depth ...
Humans learn to program about as early now as they can handle the subject.
Many working programmers today started learning to program in grade school,
most of the ones under 30 or so started in high school at the latest.

As a matter of observable fact, people tend to solve problems in certain
ways more naturally than others (and not necessarily the same way as
other people). There's nothing "more natural" about functional
programming than procedural.  In fact, it would appear that some
problems are more intuitive to solve one way or the other.

The FP camp (apparently) wants to advance the claim that FP will *always*
reduce bugs.  I find that very hard to believe. It seems to me that programmers
will always have an easier time reducing bugs in programs they *understand*
well.  While cleverness in algorithm design is always respected for the
intellectual prowess it demonstrates, it is almost always bad engineering.

"Keep It Simple Stupid" is just as good a rule in computer science
as in any other area of engineering -- and given the natural complexity
of CS, it clearly needs such admonitions more.

I don't avoid complex code because I *can't* understand it. I avoid it,
because complex code gets in the way of solving problems. You might argue
that FP code is simpler because it is shorter or encodes fewer conceptual
steps (within the FP framework), but this is just as false a measure, IMHO,
as Perl (or C) advocates' tendency to measure complexity in keystrokes
or lines of code.

Just because something involves fewer symbols doesn't necessarily make it
simpler. There's a correlation -- but other factors, like the amount of
time the reader is going to have to spend visualizing or stepping through
the process are just as important.

Rules like estimating project complexity in lines of code rely on
assumptions that the average level of understanding required to deal
with average lines of code are about the same. It would seem that in
practice this is true.

But that is tangential to this argument: if you insist on a difficult
methodology, then you are violating the assumption of the LOC estimation
model, and it will no longer be accurate. To the degree that FP makes
each LOC harder to understand, it is cancelling out any LOC savings it
makes.

So, when FP is intuitive AND reduces code complexity AND is reasonably
efficient, it's a good buy, and I'll use it -- but to argue that it
will *always* do so seems insane.

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com