Re: Bob's 'Self-aggrandizing ignorant' Count: Was: What databases have taught me
Date: 30 Jun 2006 02:02:05 -0700
Bob Badour wrote:
> Adrian Alston wrote:
> > "Bruno Desthuilliers" <onurb_at_xiludom.gro> wrote in message
> > news:44a2b543$0$6509$626a54ce_at_news.free.fr...
> >>What bother me here is not about OO being born from needs for simulation
> >>- FWIW, at least part of Bob's assertion seems perfectly and obviously
> >>(OO) is a
> >>computational model comprising a collection of features useful for
> >>constructing large unpredictable state machines from small
> >>predictable state machines
> > Hi Bruno and all,
> > I have lots of C programming experience but I'm pretty new to OOP can you
> > please help.
> > I can understand how objects are a sort of state machine but I thought OO
> > programs should be predictable. What's this unpredictable bit about? I know
> > about simulations but I write regular non-simulation apps. Ok the world
> > around the program may be hard to predict but just how are my "OO" programs
> > suppose to be unpredictable?
> > Thanks in advance.
> Keep in mind that this is cross-posted to comp.databases.theory, and I
> post from the perspective of c.d.t
> Unless you are writing simulations or chaotic attractors, your programs
> are supposed to be predictable.
Note that predictability depends on the problem you're trying to solve, not on how you solve it. I'm thinking specifically of an example of two programs, one written in C++ (an imperative language that supports OO), the other in PROLOG (a declarative language) that both generate identical output.
> The unpredictability of simulations comes from the interactions among
> many interacting state machines, the potentially large set of boundary
> conditions and sometimes from the complex or chaotic equations used. The
> whole purpose of the simulation is to discover what would happen in
> various situations. If that were predictable, one would not need a
> 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.
Yes, this is both a good characterisation of OO, and of the types of
problems it is good at solving.
> 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.
I try to.
The study of (imperative) algorithms is an interesting field. Proving algorithms correct can sometimes take pages of formal, inductive proofs. Some concise, useful and powerful algorithms are implicitly imperative in nature, and trying to write them in PROLOG seems unnatural, inefficient and painful.
> Further, as Dijkstra notes, the tools we use affect the way we think. 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.
Yes, all that is usually true.
> 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.
> As Aho et al noted way back when in the dragon book (on compilers),
> algorithmic replacement arguably offers the greatest opportunity for
> performance optimization and is almost never done because of the
> enormous difficulty involved. Thus, if the optimizer could recognize a
> bubble-sort, it could replace it with a quick-sort. However, I suspect
> the task of recognizing the equivalence of any two arbitrary algorithms
> is probably close to the complexity of the halting problem.
However, in certain domains I choose C++. I may spend lots of time away from the code editor developing highly tailored imperative algorithms that are provably correct, and then carefully implement to get the best possible performance. This can be justified in some areas of systems programming where you are confident that the problem is well defined, you've done a proper analysis, and your tailored solution will stand the test of time.
> 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.
I agree with all that you say, and think there are lots of OO
programmers who need a good swift kick up the backside.
However, I don't think declarative approaches will ever completely
displace imperative approaches. But let's see more declarative code
However, I don't think declarative approaches will ever completely displace imperative approaches. But let's see more declarative codethan we have now.
There seems to be a lack of science going on. For example, what work has been done to determine whether a given algorithm is best represented declaratively or imperatively? In my (limited) reading on comp.object, I haven't seen anyone discuss such an important question. Instead everyone seems to hand wave with all too generic, meaningless statements.
David Barrett-Lennard Received on Fri Jun 30 2006 - 11:02:05 CEST