Re: Unpredictable programming
Date: Thu, 29 Jun 2006 13:02:07 +0200
Message-ID: <44a3b32f$0$1615$636a55ce_at_news.free.fr>
Bob Badour wrote:
(snip)
>
> 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...
(snip)
> 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.
Idem.
> 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",
Indeed.
> 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)
(snip)
> 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