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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d1df6bc3799debed X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-93" Subject: Re: Not intended for use in medical, Date: 1997/05/12 Message-ID: <97051217065652@psavax.pwfl.com>#1/1 X-Deja-AN: 241174855 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU X-Vms-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" Newsgroups: comp.lang.ada X-Vms-Cc: CONDIC Date: 1997-05-12T00:00:00+00:00 List-Id: "John G. Volan" writes: >Looks like I read too much into that article in Ada Letters. I got the >impression that there is still a significant constituency in the real >time industry with serious reservations about OO-style inheritance. >Hopefully, it's a dwindling minority. But, to do them justice, we can >address their concerns thus: > > Patient: "Doc, it hurts when I do this." > Doctor: "Well, then don't do that!" > >In other words, tagged types and type derivation are useful tools that >have their place, but they are not necessarily the right tool for every >problem, and you are not necessarily forced to use them for everything. >Make an informed engineering decision, weigh the trade-offs: If the >overhead and dynamic dispatching and the indeterminacy of abstract types >are unacceptable to a real-time application, just don't use those >features. > I'm almost with you here - except for one possible problem. If a given language feature poses too much runtime overhead to be useful *and* requires non-trivial space in its support in the runtime kernel (or otherwise causes "other" features to compile inefficiently because of dependency on the inefficient feature), then you've got a case for why it would be "bad" to include it in a realtime language. Tasking had (and still has, for some) this same problem. If I've got a tiny little microcontroller to do some specific job and I've maybe only got 64k of memory to work with and no need for anything more complex than a cyclic exec, dragging around the tasking support could make it difficult or impossible to use Ada. Try finding a nice, small SBC to use as a microcontroller that actually has Ada targeted to it - if you find one, let me know. I'm still shopping for one that doesn't involve me putting together a home-brewed, cobbled-up compiler port that may or may not work. (Or is really too big for the job and/or comes with it's own realtime version of DOS, etc., etc.) Tasking thus shut Ada out of a sizeable segment of the market that is now served almost exclusively by C or even C subsets. Don't get me wrong - I like the fact that tasking is there and have used it effectively in realtime systems. But it would be nice to see some (dare I say it?) subset of Ada available that was targeted to some of these really small machines. MDC Marin David Condic, Senior Computer Engineer ATT: 561.796.8997 Pratt & Whitney, GESP Fax: 561.796.4669 West Palm Beach, FL Internet: CONDICMA@PWFL.COM =============================================================================== "I saw a bank that said "24 Hour Banking", but I don't have that much time." -- Steven Wright ===============================================================================