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: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) Subject: Re: C/C++ knocks the crap out of Ada Date: 1996/03/19 Message-ID: <4imqofINNn82@keats.ugrad.cs.ubc.ca>#1/1 X-Deja-AN: 143192228 references: <4i4cf2$crm@sun152.spd.dsccc.com> <4ikbar$g0k@tpd.dsccc.com> organization: Computer Science, University of B.C., Vancouver, B.C., Canada newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-03-19T00:00:00+00:00 List-Id: In article <4ikbar$g0k@tpd.dsccc.com>, Kevin Cline wrote: >In article , >AdaWorks wrote: > >Kevin Cline (kcline@sun152.spd.dsccc.com) wrote: > > > > > >: In fact there were several serious flaws in the Ada-83 language > >: that made development of hosted applications in Ada-83 more difficult > >: than developing them in C or C++. > > > > I would almost agree, except my view is that Ada 83 shortcomings were > > more in the category of incoveniences than "flaws." But we are dealing > > with the new Ada standard. > > > >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. > > 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. In 1983, C had no such interface either. The C language still has no interface to a terminal that is ``more advanced'' than line-at-a-time I/O. This is smart, IMHO. The comp.lang.c FAQ explains the rationale behind not including ways to do character input in the ANSI standard. That's what POSIX.1 is for: there is a POSIX interface standard for C as well as Ada. --