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: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1014db,3d3f20d31be1c33a X-Google-Attributes: gid1014db,public From: abo@minkirri.apana.org.au (Donovan Baarda) Subject: Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Date: 1997/07/07 Message-ID: #1/1 X-Deja-AN: 255167045 References: <33957A33.1C31AB44@oma.com> <865898351snz@nezumi.demon.co.uk> <339ED54C.215A5F85@oma.com> <5noc8u$a8m$3@miranda.gmrc.gecm.com> <33A032AC.2D8BA85C@oma.com> <5nrn86$cvo$3@miranda.gmrc.gecm.com> <33A1CBBB.B0602EC@oma.com> <5o2uls$ku3$2@miranda.gmrc.gecm.com> <33A6ADDA.2099EEB9@oma.com> <33A7D2DE.545B@polaroid.com> <33A9338D.10BB@polaroid.com> <33B09D64.E7F99DA3@saguarosoft.com> <33B16CBB.417A@gdesystems.com> X-Server-Date: 7 Jul 1997 05:07:43 GMT Organization: Minkirri Internet Access Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.c,comp.lang.c++ Date: 1997-07-07T05:07:43+00:00 List-Id: In article , you wrote: > >> Particularly with a language as old as Ada. I know Ada 95 is more >> recent, but bolting OO onto a procedural language is always a >> compromise compared to starting with a clean slate. > >Depends on. In the case of Ada95, this was not much of a "compromise" >as it was simply extending a couple bits of what was already in Ada83. >What many people (for some reason) don't seem to realize is that Ada83 >had the concept of "class", had inheritance and allowed for the >extension of _behavior_ in type derivations. Adding in dynamic >binding and state extension was pretty natural. > Can you inherit from an INTEGER? Subtyping is not the same thing. Is there a parent class to INTEGER and FLOAT that can be used by a class that manipulates either? > >> Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2 >> does in 40 reserved words and 81 syntax rules. The only things missing >> from modula-2 that are in Ada are generics, exceptions, and operator >> overloading. > >And tasking and unconstrained types and ... This is pretty silly. >No, it's _very_ silly. > Modula-2 had tasking. I'm not exactly sure what you mean by unconstrained types, but if you mean unconstrained array types, modula-2 didn't have them exactly but it did have unconstrained array parameters. However, I do belive that being able to make a type out of them is a neat idea. > >Neither is particularly innovative. In fact, no computer language >really is. But, the things in Ada that were "important" in "proof for >everyday useage" were not in M2: Tasking, Generics, Exceptions, and >(possibly) overloading. > Generics and Exceptions were a pretty important step. However, I don't believe they were fully understood at the time Ada83 was implemented, and there are now nicer implementations of these two concepts. >> A complete inheritance heirachy > >Presumably ala' Eiffel or some such. Why? Seems a big shrug. > It makes a difference in OO because you can make something that manipulates OBJECTs, and know that it can be fed anything because everything is inherited from OBJECT. A complete heirachy of numeric types is useful for the same reason. ABO