Consider why the Internet works .... Cheers,
Alan ________________________________ From: spir <denis.s...@gmail.com> To: fonc <fonc@vpri.org> Cc: PiLuD <pi...@googlegroups.com> Sent: Wed, July 14, 2010 6:25:15 AM Subject: [fonc] automation Hello, This is a follow-up of some aspects of the thread titled "goals" on [fonc]. Big post: press <del> if you are in a hurry ;-) Recently, an article evoking the nearly incredible reliability of hardware systems (including processors) compared to software ones, reminded me of automation. In this domain, extremely complex machines are controlled by fairly big programs of various kinds (system, machine-specific, applicative) and simply work. This simple fact did not strike me at the time when I used to work in the field because I then saw only broken machines ;-). Still, it is astonishing when compared to the "state of the art" in other programming areas. How does that work? I think the answer is: automation programmers cheat. Instead of building and expressing models (mental images) of objects, they use physical, concrete, ones. My hypothesis is: perhaps hardware objects, I mean precisely machine parts, form kinds of ideal versions of what software objects should be. -1- they do not bug -2- they do not communicate Hardware objects do not bug the same way as software objects do. I cannot really point at the "qualitative" difference, but I guess you can intuitively get it. The only case when a hardware bug is similar to a software one, and thus is possibly "naughty" from the diagnosis point of view, is when it affects the object's relation to the control system. Hardware objects do not communicate like software ones. They can be physically connected like a motor and a tool arm, but this fact is a fact, part of their "definition". In a controlled machine, parts, actually only controlled ones, only communicate, in the digital system sense of the word, with the controller system. 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. To implement this in plain software, objects representing concrete ones should not talk and listen at all. No message! Object implementations typically have routines to compose and send a message, and to interpret & act according to a received message. This whole part of the object mechanics would not exist in a machine simulation, or not be used. Objects would be "communicationnally" passive. Instead, they could just do actions (procs in the pascal sense, commands in Eiffel slang) that read, put, change, data on their interface. Possible functions (queries) would only be for internal purpose. The whole interface would thus be a plain set of attribute data, on one hand, and a few actions directly launchable by the controller only on the other. In other words, the controller is the (only) messaging system. I recently read an often quoted post by Alan Kay using the word "mu" for what-lies-in-between (my words). The greek root "dia" would perhaps be nice as well, in this sense. A consequence of the here exposed view is the total absence of any direct dia between objects. Instead, objects kind of float in a dia milieu which is the controller itself; which only allows priviledged communication channels between given objects, and only through its control, via its "translation" (interpretation). Big-Brother-ware. This point of view draws the image of a model composed of a big & "flat" set of isolated objects, and a possibly huge controller instance. In fact, nothing prevents building sub-systems with their own sub-controller, thus forming a structured system. A complex machine often can be constructed as a set of sub-machines and indeed often is; for instance, a motor, a speed sensor, & a speed regulator form a sub-system unit which controller (the regulator) communicates with a higher-level one. Converse translation: if machines were built the way we commonly build our software systems, nearly none would ever work, I guess. Having their parts communicating directly -- provided this were possible, would explode their complexity. (this, I guess, mainly via creation of dependancies) I would like some feedback on whether you find this "paradigm" at least interesting. Certainly, it can only apply to a subset of programming topics; the sheer fact it requires a control cycle (I guess) limits its domain. Anyway, comments? Denis ________________________________ vit esse estrany ☣ spir.wikidot.com _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
