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: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: adaworks@netcom.com (AdaWorks) Subject: Re: C/C++ knocks the crap out of Ada Date: 1996/03/20 Message-ID: #1/1 X-Deja-AN: 143431613 sender: adaworks@netcom8.netcom.com references: <4i19mg$vkt@azure.dstc.edu.au> <4i4cf2$crm@sun152.spd.dsccc.com> <4ikbar$g0k@tpd.dsccc.com> followup-to: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu organization: NETCOM On-line Communication Services (408 261-4700 guest) newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-03-20T00:00:00+00:00 List-Id: Kevin Cline (kcline@sun132.spd.dsccc.com) wrote: : In article , : AdaWorks wrote: : >Kevin Cline (kcline@sun152.spd.dsccc.com) wrote: : > : > : I suppose every language design error could be classified as an : inconvenience, since there is almost always some workaround available. : But the following missing features in Ada-83 were serious problems : when developing hosted applications and directly led to the rejection : of Ada by the marketplace: : 1. Inability to pass a function or procedure as an argument. : This went far beyond an "inconvenience" for those of us attempting : to use event-driven GUI libraries. There was no portable : work-around for this problem. OK, Kevin, I'll give you this one. There were some non-portable workarounds, but this was a shortcoming of Ada 83. The new ISO Ada standard supports the ability to pass a function of procedure as an argument. However, for the next one: : 2. No standard interface to any OS facility more advanced : than line-at-a-time input/output. Also very difficult to : work around, particularly if trying to produce a portable program. The only thing wrong with this was including it in the "core" of the Ada 83 definition. Text_IO was never intended to be more than it was, a universal scrolling, left-to-right and downward I/O package. The issue with all the I/O packages was portability. It still is. Nothing in the Ada 83 design precludes the creation of I/O packages for other terminals, operating systems, and I/O devices. In fact, such packages abound. How do you think people use Ada for the huge range of operating systems on which applications have been deployed? The Ada predefined I/O packages were not intended to be platform-specific. The language designers expected compiler vendors to provide packages for I/O on their targeted platforms. Many compiler publishers fell short in this area. This was especially true of "checkbox" compilers supplied by some of the hardware vendors. Once again, the ISO 1995 Ada standard updates the facilities of the I/O packages, but portability is still a concern. Therefore, interfaces to specific operating systems is outside the scope of the core language, as it should be. Richard Riehle adaworks@netcom.com BTW, a "checkbox" compiler is one which satisfies the minimum standard for validation so the vendor can check the box on the procurement request for validated Ada. This practice created additional problems for Ada since the hardware vendor was only interested in getting a collection of computers in the door, not in seriously supporting Ada. To avoid lawsuits, I'll not post the names of such vendors, but they know who they are. RR -- richard@adaworks.com AdaWorks Software Engineering Suite 27 2555 Park Boulevard Palo Alto, CA 94306 (415) 328-1815 FAX 328-1112