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=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 border1.nntp.dca.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Ada platforms and pricing, was: Re: a new language,
 designed for safety !
Date: Tue, 01 Jul 2014 11:28:42 +0100
Organization: A noiseless patient Spider
Message-ID: <ly8uodcqzp.fsf@pushface.org>
References: <lmj8s6$hhp$1@speranza.aioe.org> <85ioo9yukk.fsf@stephe-leake.org>
 <ln6tlg$1vc$1@dont-email.me>
 <255b51cd-b23f-4413-805a-9fea3c70d8b2@googlegroups.com>
 <ln6uv9$bk8$1@dont-email.me>
 <b22db9fb-a73d-438a-8cfd-f0bb1db70eed@googlegroups.com>
 <MPElv.491358$1w1.428312@fx03.iad>
 <5ebe316d-cd84-40fb-a983-9f953f205fef@googlegroups.com>
 <ln7ngt$c8a$1@dont-email.me>
 <2100734262424129975.133931laguest-archeia.com@nntp.aioe.org>
 <lnn5ko$ner$1@loke.gir.dk> <lnn8ff$k42$1@dont-email.me>
 <lnq58f$du2$1@loke.gir.dk> <lnsqus$d4j$1@dont-email.me>
 <lntmdq$p1j$1@loke.gir.dk> <lo7c2h$ura$1@dont-email.me>
 <lo7pea$cm3$1@loke.gir.dk> <c0pv51Ff927U1@mid.individual.net>
 <5156oy7vhg99.17wu6q2ef45ke.dlg@40tude.net>
 <1d3612ad-f85a-489c-b4bc-0c23d5d67de3@googlegroups.com>
 <9vn9udxucq3n.1ejno042sc30t.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx05.eternal-september.org;
 posting-host="117da9042fa4d6f5956a9b8f72035635";
 logging-data="3258"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX18WIeM2MGs4Ce3RWA0BRceTOSZSzvlk358="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin)
Cancel-Lock: sha1:Cq9l7mElGG75Bx7kr5RxRkrqPis=
 sha1:9O4DWMR8PaL35k09HaLchBdK0iQ=
Xref: number.nntp.dca.giganews.com comp.lang.ada:187303
Date: 2014-07-01T11:28:42+01:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> For complex logic it is becomes almost impossible to structure the
> design along callback decomposition. It is no matter if callbacks are
> subprograms or full objects (procedural vs. OO decomposition), because
> the lines are already drawn. You cannot change anything. It is
> knitting standing on your head.
>
> Instead of the mess you wanted to put weight rather on the logic of
> the actions, their ordering and effects, than on the callbacks (I/O
> events).  For this the individual callbacks which are logically
> coupled and ordered need to be represented as such in the source code,
> visually close to each other, best of all, as a thread of control
> where events pushing the actions are actually irrelevant to the logic.

I think we must be arguing from different premises.

In the system I was involved with, which involved state machines,
callbacks, and events, we had very little control over the order in
which the callbacks occurred. You can't tell when a radar searching for
a target will detect it. You can't tell the exact time at which a
missile will leave the launcher after you've given the launch
command. You can't tell when the human in the loop will decide it was a
mistake and abort. And all of these external inputs were managed via
callbacks.

Of course, you can be sure (relatively) that a missile won't launch
before it's commanded to!