Re: OO versus RDB

From: Adrian Hey <ahey_at_NoSpicedHam.iee.org>
Date: Sun, 09 Jul 2006 23:57:50 +0100
Message-ID: <YKGdnR-ZOL1uFCzZnZ2dnUVZ8qqdnZ2d_at_giganews.com>


Marshall wrote:

> There are disadvantages to insisting on purity in all things.
> Peter Van Roy does a good job of considering a variety
> of programming paradigms and comparing their strengths
> and weaknesses, and he has demonstrated that purely
> functional programming suffers from reduced modularity
> compared to imperative; this is beyond the usual, potentialy
> missing-the-point arguments about performance.

Personally I don't think PVR has demonstrated any such thing. IIRC his argument was that pure FP makes it difficult to some things that are easy in an imperative language, like instrumenting a "function" to see how many times it has been "called".

In the context of a pure FPL I think this this is meaningless, because as soon as you try to instrument a function it is no longer a function by definition (at least the definition used by the language in question), because expression evaluation has an observable effect other than yielding a value. (I.E. incrementing a counter).

So the program becomes ambiguous and it's behaviour (I.E. the counter value) might well depend on whether or not the compiler performed certain transformations (such as CSE).

I think most FP folk would argue that making it impossible to write ambiguous programs is a strength, not a weakness.

That said, if we take PVRs argument and apply it to actions (in Haskells IO monad say) then instrumenting an IO action to find out how many times it has been performed makes perfect sense to me. I think there are some Haskell folk who will want to shoot me for saying this, but I would agree with PVR that Haskell currently lacks modularity in this respect...

  http://haskell.org/hawiki/GlobalMutableState

But not all Haskell folk even agree that this is a problem, and even if it is, it's only a problem with one particular language, not pure FP in general.

Regards

--
Adrian Hey
Received on Mon Jul 10 2006 - 00:57:50 CEST

Original text of this message