On 14/07/2010, at 11:25 PM, spir wrote: > Hello, > > > [...] > > Imagine we build a simulation model of a machine in plain software terms. > Translating the above points into the general programming world, using OO > metaphor, in my view leads to: > -1- objects do their job, do it just correctly, and do only that > -2- objects do not communicate with each other, instead they are controlled > > The first point is just restating a good OO design rule, probably; but it is > certainly not commonly applied. Software objects instead often do more than > just-their-job according to their theoretical role in the model. In > particuliar, they are often sources of information (computed in funcs) for > other objects, and conversely often command other objects' actions. > What if they did not? This means for me is there is a dependancy (coupling) > level exactly equal to 0 between objects. Automation programmers get it by > force. A correct simulation forces the "modeller" to define software objects > that way. Which leads to the second point. > > An OO machine simulation would introduce a special object I call > "controller". In a real machine, the whole software part is that control > instance (gross simplification). Concretely, it is the archetypical case of > an event-driven control cycle. To simplify the picture again, the program > typically just reads in all input data mirroring the current machine's state, > processes it according to clauses that express the machine's logic, and > produces output commands to various machine parts. Control clauses are > commonly as complicated as "if condition then action". > The whole program is mainly a set, or rather a hopefully correct and > consistent system, of such clauses. It can be very big, but compared to > ordinary software its complexity level is fairly low; ==> machine > reliability. This, if I'm right, is due to the above stated points. > Automation programmers are not magicians.
Have I completely missed the boat, or are you simply describing a state machine? Perhaps my understanding of what a state machine is is incorrect. This is essentially what I refer to when I talk about "planck size" of algorithms. You can't get any simpler than a certain size and therefore not only is it incredibly understandable, it simply won't break. Erlang springs to mind at least somewhat in that because each part is designed with the assumption of failure in built, failure is "managed" and therefore systems are very robust. no? Julian. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
