Software bugs aren't inevitable

[Terry Hancock]

On Friday 16 September 2005 08:35 am, Michael Sparks wrote:
> Steven D'Aprano wrote:
> > But there is a difference: writing assembly is *hard*, which is why we
> > prefer not to do it. Are you suggesting that functional programming is
> > significantly easier to do than declarative?
> 
> But there is a difference: writing assembly is *hard*, which is why we
> prefer not to do it. Are you suggesting that object oriented programming is
> significantly easier to do than old style imperative?

The answer in both cases, is that it depends very much on what you're
trying to write.

> FWIW, IMO once you've learnt functional programming's idioms it certainly
> can be easier and more natural.

In particular domains of problem-solving, yes.

> The problem is the tools that make things
> like recursion efficient aren't available normally in mainstream languages
> meaning that most people simply don't get the practice.

There's also an assumption here (which I regard as a fallacy), that different
models of programming are equally intuitive. Some models, like OOP, draw
heavily on experience *outside* the realm of programming (in many cases,
you can successfully apply machine-shop experience to a programming problem
if the program is object-oriented -- in fact, ISTM, this is the *primary*
power of OOP, that it allows you to provide experience from the problem
domain to the process of writing a software program to work with that domain).

Functional programming (and I am no expert here), seems to me to draw
heavily on the problem domain *of* computer science. So naturally,
computer scientists think it's brilliant and intuitive.

But for those of us who primarily regard computers as tools for solving
problems in other domains -- such as image-processing, web-application,
handling business transactions, or simulating supernovae -- FP just doesn't
seem very natural at all.  In fact it seems completely backwards, perverse,
and twisted, as if the designer were simply trying to confuse and
obfuscate the problem instead of solving it.

Or at least, it frequently does.

> Essentially it's about expressiveness.

Yes, and expressiveness means keeping vocabulary and grammar for
different applications, not throwing one out on the basis that it
is somehow superior. If you *are* making the latter claim, then
the burden is on you to prove that your method is really that much
better.

> Think of it this way - we normally write left to write, however some
> languages read up and down. Neither is inherently better or easier
> than the other, but for some things *may* be more expressive. 

I *really* doubt that, actually. ;-)
But I heard what you meant.

> If you think about it being about choosing the most clear/expressive way to
> describe an algorithm, the argument may become clearer. After all, the
> recursive definition of some things is clearer than the non-recursive.

Yes.  I think all we're claiming is that the reverse is equally true.

In addition to this kind of elegance argument, there is also a pragmatic
argument that, with existing technology, it is sometimes much more efficient
to write an iterative solution than to insist on recursion. Even if it can
then be shown for particular cases that a recursive solution that is also
efficient exists, and even if it can be proven that, in general, all such
efficient iterative solutions have equivalent recursive solutions, it does
not defeat the simple point that the obvious iterative solution is faster
and more efficient than the obvious recursive solution.

Let's not forget that this started with an example of the Fibonacci series.

Who in their right mind would *actually* be trying to solve the Fibonacci
series for a practical programming application?  It's a toy, like the
"hello world" program.  I have no doubt that I can handle the extra burden
of understanding the cleverly structured "efficient recursive" algorithm,
versus the alternatives.  But I can also see that it *is* more of a burden
to understand it -- it causes confusion.

Now what happens when the complexity goes up ten-fold, and we add extra
bells and whistles to it that theoretical programs usually skip over, and
real world programs have in abundance?

At that point, I *really* want that core problem to be simple to understand.
Ideally, as simple as it can possibly be.

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