Re: Unpredictable programming

From: Bruno Desthuilliers <onurb_at_xiludom.gro>
Date: Thu, 29 Jun 2006 13:02:07 +0200
Message-ID: <44a3b32f$0$1615$>

Bob Badour wrote:
> When one uses OO, one naturally tends to have interacting state machines
> and to have more of these than when does not use OO. When one's
> application is naturally a very large state machine, one can decompose
> it into smaller state machines as an abstraction technique to break it
> up into human-manageable chunks.
> However, if one were truly abstracting a large state machine like that,
> one would tend to want to prove that the aggregate of the smaller state
> machines omits no states and introduces no new and unwanted state
> transitions etc. Nobody, as far as I know, practices OO in this way.

There are points in this that would deserve more attention that I can give now...


> If
> one has a tool that makes creating large state machines very easy, one
> will naturally tend to think of solutions in terms of large state
> machines and more importantly in terms of state transitions.


> Focusing on
> state transitions leads one to take a much more procedural and
> operational perspective than is often warranted.
> Declarative techniques allow one to specify solutions closer to the
> level of intent. A good declarative formalism causes one to think more
> about "what" than about "how",


> which naturally separates the concern for
> correctness from the concern for efficiency. Those of us who understand
> the relational model and SQL, understand that one can address the
> concern for efficiency separately, for example by creating indexes, by
> clustering data, and by automating the translation from the declarative
> language to the physical hardware.

May work for DBMS, but would it be that easy for a more general-purpose language ? (real question, not trying to make a point)

> The OO computational model is simply not as amenable to higher order
> transformations. The executable code more directly reflects the
> specification. For instance, optimizers do not combine object classes to
> transform a collection of possibly inefficient state machines into a
> single more-efficient state machine.

But would that really be - at least in theory - impossible ? (idem as above)


> However, a declarative set-level language specifies what to do at a much
> higher level often making the similar optimization a task of algorithmic
> choice rather than algorithmic replacement.

Are you thinking of something like query execution plan optimization here ?

> P.S. Please, don't think I am trying to discourage you from learning OO.
> Learn it. By all means. But learn it as it really is and not as some
> sort of mystic rite of passage. It is a computational model. One of
> many. Try to be as buzzword proof and as bullshit proof as possible by
> learning how to recognize and how to articulate computing concepts with
> precision and accuracy.

Bob, it's *really* a shame that you waste your time flaming and insulting peoples when you can also write such articulate and mostly sensible stuff. BTW, do I need to add that I globally agree on all you say here (with noted reserves), or was it obvious enough ?

Damn, I'll have to take back my claims about you being definitiveley dishonest now. Bob, I hate you.

bruno desthuilliers
python -c "print '_at_'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb_at_xiludom.gro'.split('@')])"
Received on Thu Jun 29 2006 - 13:02:07 CEST

Original text of this message