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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: 11232c,59ec73856b699922 X-Google-Attributes: gid11232c,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-ArrivalTime: 2003-05-02 11:21:52 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.freenet.de!news-lei1.dfn.de!news-koe1.dfn.de!RRZ.Uni-Koeln.DE!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,misc.misc Subject: Re: Using Ada for device drivers? Date: Fri, 2 May 2003 18:21:51 +0000 (UTC) Organization: GMUGHDU Message-ID: References: <9fa75d42.0304230424.10612b1a@posting.google.com> <9fa75d42.0304240446.493ca906@posting.google.com> <3EA7E0E3.8020407@crs4.it> <9fa75d42.0304240950.45114a39@posting.google.com> <4a885870.0304291909.300765f@posting.google.com> <416273D61ACF7FEF.82C1D1AC17296926.FF0BFD4934A03813@lp.airnews.net> NNTP-Posting-Host: d2-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1051899711 3284 134.91.1.15 (2 May 2003 18:21:51 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Fri, 2 May 2003 18:21:51 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/831)) Xref: archiver1.google.com comp.lang.java.advocacy:63059 comp.object:62581 comp.lang.ada:36879 misc.misc:13912 Date: 2003-05-02T18:21:51+00:00 List-Id: In comp.lang.ada Kaz Kylheku wrote: : : Newsflash: ``Ada versus C'' is not interesting. Ada and C are much : more similar than they are different. If you don't think so, it's only : because you are too absorbed in the arcane details that separate your : favorite high level assembly language from the next one. Care to give some substantiation, or a pointer to some substantiation? Since you give no details, let me take this argument one step further. It doesn't make much difference what class of languages one uses, because it all runs on plain old sequential processors, even if there are many, and interrupts... See? If you look at some of the more recent non-EVAL languages (C++/STL, Eiffel, Ada 95) then, yes, certainly there are things in these languages that just cannot be done without EVAL, and therefore they could be said to be similar. But that view misses some aspects of the economic software world you mention. Choosing the right tool for the job, for one thing. Now make the job include distributed execution on heterogenous hardware, or changing operating systems. As to C vs Ada, how well defined are the distributed facilities of the languages in question? What does that mean for a large distributed application, running on not-just-one-PC-and-one-OS? Answer: There is no trace of "distribution", not even of concurrency, in C. I wonder how that distinct feature of Ada vs C can be discarded, economically. If you subtract, from the "non-C-class" languages, the facilities that make them run fast enough in not more memory than is available (FFIs, SETF like constructs), what remains? Languages that are very interesting but not necessarily viable for projects where non-EVAL languages are viable solutions. Why is it that Erlang stresses a feature that allowes speedy things to be written not in Erlang but linked to the resulting Erlang-program? : Writing UI in either Ada or C is a waste of productivity that could : only possibly be justified in a freeware project, or some : tax-dollar-supported researchy thing. (To be clear, I don't mean : *morally* justified, only economically). What is the alternative, in general? There are many cases where spending a lot of time on the UI is deemed extremely important, economically. Games come to mind, Office programs, Film+Music software, mobile gimicks. Can this be done using a quickly programmed (and dirty, in a sense) UI toolkits? Computer buyers are very sensitive to UIs. For the technical users, think of language syntax (interface to a language ;-), for the non-technical think of Word's animated paper clip, which is certainly of economical importance to the producers of Word. So there is economic reason to make these things both speedy enough and well fitting with the system's appearance. Can this be achieved in Tcl/Tk, for example? No. A whole industry makes profit producing user interfaces that are as fine tuned as budget allows and these budgets are most generous: Advertising, and marketing. For another economically important UI, how much time can justifiably be spent on the design of display UIs in ticket vending machines, in laundromats, in car navigation systems? What do you use in such systems? Georg