From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Things that OO programming lacks Date: Mon, 17 Nov 2014 09:44:43 +0100 Organization: cbb software GmbH Message-ID: <160lx4e9clifl.1kcusbxaei4r0$.dlg@40tude.net> References: <87389olqie.fsf@ixod.org> <10d9w.55626$8w1.22302@fx12.iad> <150er0b62wsh3$.1xabmp81w5kdw.dlg@40tude.net> <1azsoc77wjhmi$.1grmnnlq033tz.dlg@40tude.net> <5yzci4a8snfg.1dfsqjyvneeym$.dlg@40tude.net> <1dwdgby88eh21$.k3nspjj0mme0.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: nyHeW7QjJmC1odUjK4LkDA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:23453 Date: 2014-11-17T09:44:43+01:00 List-Id: On Sun, 16 Nov 2014 20:33:21 +0000, Simon Wright wrote: > "Dmitry A. Kazakov" writes: > >> On Sun, 16 Nov 2014 17:54:06 +0000, Simon Wright wrote: >> >>> "Dmitry A. Kazakov" writes: >>> >>>> I didn't list event-driven AKA data-driven paradigm in my list of >>>> paradigms, since it is so horrific, that nobody should seriously >>>> consider it as useful. >>> >>> The event-driven approach to (real-time) software is the only way to >>> build such systems: any other way is bound to lead to confusion and >>> disaster. >> >> On the contrary, real-time software requires predictability, which >> leads to rather to polling-based architectures oriented to the worst >> case scenario. > > My experience is with relatively soft real-time (I mean, the > requirements from the system engineers were mostly quite a bit broader > than was easily achievable). Even so. I try to explain why I believe that event-driven is bad as a paradigm. The fundamental problem with events is that they are not composable. You can split an event into new events, but you cannot join events. Where they came from, in physical processes, you can always combine events because in the Newtonian physics time and values are continuous. Thus you can group things into a process vector at will. This is not so in digital computing. Let you have two signals X, Y and want to produce Z=X+Y. This is a trivial task in procedural, functional OO decomposition (not in relational one). With events, when X and Y are sampled (asynchronously), digitized (stochastically) and propagated through the system layers ([bounded] random delays), this does not work. You immediately run into a race condition. So even tasks considered trivial in other paradigms are hard problems in the event-driven one. P.S. Nonetheless, most of a hardware is event-driven and of software middleware frameworks have an event-driven architecture. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de