Re: Unpredictable programming
Date: Wed, 28 Jun 2006 23:01:06 GMT
Message-ID: <SSDog.3465$pu3.83910_at_ursa-nb00s0.nbnet.nb.ca>
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 >>true: >> >><quote> >>(OO) is a >>computational model comprising a collection of features useful for >>constructing large unpredictable state machines from small >>predictable state machines >></quote> >>
>
> Hi Bruno and all,
>
> (I originally write this deep in some other thread but it will probably get
> missed. I should have started my own thread, please ignore the other one,
> sorry about that :-)
>
> 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.
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 simulation.
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.
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.
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. Received on Thu Jun 29 2006 - 01:01:06 CEST