Re: OO versus RDB

Tony D wrote:
> Marshall wrote:
>
> > It may not be to everyone's taste. But I wouldn't agree that
> > it is a horror. It strikes me that SML is an example of
> > what I describe and it seems to be doing all right for itself.
>
> Hmmm... even there, the existence of imperative type variables has been
> the source of trouble, leading to changes between the definitions of
> SML '90 and SML '97 to cope. The question is, are the imperative
> features worth the trouble ?

I agree that imperative operations are a source of trouble. They make reasoning about programs harder, both for the programmer and for static analysis. That's why I say "functional by default." If you have a choice, go functional.

However, I don't wish to eliminate imperative operations alltogether. They are too valuable. There's also the little issue of data management: some jobs are inherently stateful.

> > 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.
> >
>
> Now this is interesting, as (to me) it flies in the face of intuition.
> If we have two languages, one of them being one where we can guarantee
> that no piece of code can have an unexpected impact on another, and the
> other language being one where we cannot offer that guarantee, it seems
> reasonable to me that the first would be a better choice for modular
> programming. Given that a purely functional language can offer that
> guarantee, what makes Van Roy decide that modularity is reduced in such
> languages ?

Consider functional approach to I/O. For example, Haskell's monads, or the similar approach in Mercury. One has to thread the I/O monad through all code that uses it; if one has a need later to add I/O operations to a module, and that module's use is several modules below the "lowest" one that uses I/O, all intervening modules must be updated. Not so in imperative programs.

I can highly recommend Van Roy/Haridi's "Concepts, Techniques, and Models of Computer Programming" as one of the least dogmatic, most thorough and well-reason examinations of various computational models as I have found.

> > Nonetheless, I think functional programming should be
> > the default choice, because it's the easiest to reason
> > about. I just don't think we should toss out imperative
> > entirely, because it has distinct value.
>
> Barring complications, I remain to be convinced of that value.

No worries.

Marshall Received on Mon Jul 10 2006 - 03:00:58 CEST