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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,fa07350fd81f7563 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,80e8e0df8032d89e X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,fa07350fd81f7563 X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 1994-11-02 09:29:49 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swrinde!news.uh.edu!uuneo.neosoft.com!blkbox.COM!not-for-mail From: harvey@blkbox.COM (Greg Harvey) Newsgroups: comp.lang.ada,comp.lang.c++,comp.object Subject: Re: Is C/C++ the future? (LONG LONG POST) Date: 1 Nov 1994 21:49:05 -0600 Organization: The Black Box, Houston, Tx (713) 480-2686 Message-ID: <39727h$nq9@blkbox.blkbox.COM> References: <383q62$k0v@truffula.fp.trw.com> <388a97$en1@dayuc.dayton.saic.com> <38jmof$111@truffula.fp.trw.com> <1994Oct25.234705.26530@sei.cmu.edu> NNTP-Posting-Host: blkbox.com X-Newsreader: NN version 6.5.0 #3 (NOV) Xref: bga.com comp.lang.ada:7454 comp.lang.c++:35080 comp.object:8134 Date: 1994-11-01T21:49:05-06:00 List-Id: Hi all! Thought I'd drop by with thoughts for the day. riehler@ajpo.sei.cmu.edu (Richard Riehle) writes: >>>In article <383q62$k0v@truffula.fp.trw.com> Brad Brahms, >>>brad@truffula.fp.trw.com writes: >BB>>>... I have yet to see any large Ada project finish without >BB>>>some other language, usually in the form of C-bindings, to help! ... >This is probably a fair characterization of many early Ada projects. One of >early complaints was that Ada compiler vendors would provide a validated >compiler with no platform-specific support packages. It became the chore of >the compiler user to build such packages, often necessitating the use of >pragma interface to C or assembler. Sometimes we even had to use the >machine code package, if the compiler vendor were generous enough to include >it. >This is not a language problem. It is an incomplete compiler problem... Well...not precisely. Let's get specific (other posters have already, so I'm going to summarize). To build a successful executable you need the following: 1. A language specification 2. A compiler that matches and implements that specification (exactly, if possible. ;) 3. A set of tools that combines the compiler output into a machine-specific executable (for discussion purposes we'll call this 'linking' though it must be smarter and more extensive than the thing called LINK.EXE that MicroSloth gives away for free.) 4. An additional set of tools that help you manage the job in general. Cross reference, CASE, version and configuration control all fall in this category. 5. A development platform, preferably with either intepretation or compilation and execution of your target source code. The ability to execute code on your development platform is nice but not essential. Note that compiling for the development platform may require a SEPARATE compiler and linker from that required for the target. 6. Development libraries which contain all the previously developed code which you wish to reuse in any way shape or form. These libraries tend to include (for Ada at least) both Unix/MS-DOS-style object libraries as well as the hunkier and better developed Ada library concept. The more of these libraries that are written in Ada and include the original Ada source code, the better. The higher level the routines you call or the more architecture dependent they are, the less likely they will be implemented/emulated/work on a development platform that is distinct from your target. (Rational taught Space Station this the hard way.) Note that BOTH development and target- executable versions of libraries are necessary if their architecture differs. 7. A delivery mechanism to install completed executables on the target. 8. Some amount of debugging support that is used to initiate execution and provide dynamic and static pathological examination. 9. Some mechanism for productizing and loading the completed product onto the final hardware device. Wshew...sorry about that, but it is important to put it all down in one place. Most people forget some or all of these details. Now, how does Ada rate? 1. Language--Top notch. Both 83 and 9x have lots of winning features. Neither is object-oriented in the sense that Smalltalk is object-oriented (or Simula, for that matter). 9X is object-oriented in the sense that C++ is (and then some). 9X isn't really Ada++ either. The reinventors acted more through sensible evolution than through destruction and redefinition. The language is the first to move some concepts such as tasking into the compiler, so some implementations on general purpose operating systems lose. 2. Compilers--Mixed bag. None are wholeheartedly terrific because Ada was one of the first languages to require quantum leaps (sorry...I promised myself I wouldn't do that) in compiler technology. Others have been more like black holes of compiler technology. Most compiler problems are not related to the ability to implement the language. Most are NOT due to language incompleteness (which has a lot to do with the linear algebraic concept of spanning the problem space.) Most compiler problems trace to difficulty in implementing advanced computing concepts on relatively unadvanced hardware/os. Many compiler problems have stemmed from trying to do the cheap job rather than the right job. Many other problems have stemmed from incompatible and non- portable interpretations of language features that all 'pass' ACVC. The ACVC has proven itself a filter of limited, but necessary, capability vis a vis testing Ada implementations. If anyone would like to hear about my experience putting together a Postscript 'ACVC' and what it did and didn't do for us, please feel free to drop me a line. 3. Binding/linking tools--Another mixed bag. For some implementations vendors rely on commonly available tools such as 'ld' in Unixen. For others, the top of the line link technology for the target environment was made available. (Well, I've always had a great deal of respect for tools like Plink-86 anyway...others have bemoaned being forced to use them.) For most platforms, linking technology ain't what it could be, but it ain't the Ada vendors fault. (Or is it...after all, Ada really does require quantum leaps in compiler technology, and this IS a related issue.) 4. General support tools--compared to each other, not bad. Compared to the ever exploding C/C++ development environment...Pfffffttttt. Now, lest some say: "Well, but Ada doesn't have the market penetration of C/C++." I point you to ParcPlace VisualWorks 2.0. 'Nuff said and OUCH! 5. Development platforms--Ok except for one thing: although this isn't strictly speaking JUST an Ada vendor issue, we gotta deal with it fair-handedly: Ada vendors seem to go out of their way to provide runtimes with differing features. This is likely to get worse with 9X annexability. Heaven help you if you want your Alsys Apollo-Domain runtime to do what your Vax-to-386sx runtime does. What...you'd even like to be able to install, activate, and deactivate extensions to the runtime? FORSOOTH! 6. Development libraries and target support of development libraries-- this area is poor, still, but not all the blame belongs to the vendors. Today, too many call specifications are written in C. This is bad for three reasons: C is a poor call specification language because it assumes the interaction between the callee (a program, presumably written in C) and the caller. It is also a poor call specification language because its syntax leads to very low levels of call abstraction. Finally, it is a very poor call specification language because both the reader and the implementor tend to ignore semantic and state issues across the interface since C is strictly functional. The best example of this is the creation of the FILE* holder for Unix I/O calls. File holds all the state and must be handed to each call and then kept sacrosanct by the user between calls (more pfffffttttt.) Besides it being simply a poor call specification language, it is very difficult to translate the very low level C concepts into higher level languages without providing a very poor call abstraction (in addition to the very poor one you get because you specified in C in the first place.) Folks, this is going to take some aggressive behavior. In short, join those standards committees and vote NO to C-based call specifications. Then join both the committees that do the C reference spec and the committees that do the Ada reference spec. Try to get them to do BOTH specs in the same book. Teach all those C-knowledgeable standards committee members that thinking in C breaks everyone else (including their C++ compatriots.) 7. Delivery mechanism to target--Not bad in most cases. Usually the goal is an operating system-specific executable. In the cases of embedded processors the goal is a loader/load image or an absolute image. Usually the link vendors rescue the compiler vendors. Not always. :) 8. Debugging--As before...most Ada vendors look pretty good until you compare them with the C/C++ market, particulary on the DOS/Windows side. 9. Productizing approaches--Usually stops at step 7 above. There is usually miniscule support for versioning, installation, or any of a host of other installation issues. Luckily, itz usually no worse than what the operating system provides standard. Sorry about the long post. Greg Harvey (harvey@blkbox.com)