ted@grebyn.com (Ted Holden) (03/20/90)
Some of you will be pleased to know that this is, in all likelihood, my last Ada diatribe for 1990. Unlike Mr. Wolfe, who appears to be some kind of a JPMO point-man for USENET, I have other interests, and Ada has just fallen very low on my list of priorities. From: Nigel Tzeng, NASA >Oh yes...on the other front...executable size...we are sometimes space limited >on the size of the programs we can have in the on-board systems...how do the >C vs ADA sizes compare? >This information is important to know...otherwise we cannot make an intelligent >decision on which language to use in the future. NASA is trying to figure out >if they should adopt ADA as the single official language. Developers at NASA >need to know the hard data in order to decide whether to support such a stand. Good thinking. With enough work and most Ada features turned off, Ada speeds for some tasks should approach those of C. This has little or nothing to do with the BIG problems of Ada, which are philosophical/economic in nature and not easily amenable to technical solution. Executable size is a symptom of one such problem. From: Jim Harkins, Scientific Atlanta, San Diego, CA >(Bill Wolfe) writes: >> There is a great need for a single production programming language >> which supports good software and code engineering practices. >Yep, and there is great need for a single type of automobile. Any idiot can >see that not only is it extremely dangerous for a person to go from driving >a Hyndai Excel to a Ford Aerostar, as a nation we are wasting an awful lot >of time both in learning new skills and in designing automobiles that differ >in several respects. I think a good compromise would be the Ford Escort... This is a REAL good analogy, but I'm afraid Jim doesn't carry it far enough, simply because he can't conceive of it actually happening. Problem is, the Ada crew CAN. You have to put yourself in their shoes; they want to control the two extremes of programming, embedded systems and mainframe/database work, and everything in between and, hence, they need every feature in the world in their CORE LANGUAGE. Letting people make up their own libraries for applications (as per C/UNIX) would be too much like a free system. Logical consequence: "My only problem with Ada at this point is the cost ($ and hardware resources) of a compiler for my XT clone. Both IntegrAda and Janus require more memory than DOS 4.01 leaves available. This is BAD DESIGN. There is no excuse for a 551K executable in a PC (pass 2 of Integrada). Janus Ada requires > 580K available to run, and rumor has it that the Integrada compiler is a repackaged Janus compiler." From a recent comp.lang.ada posting. Everybody begins to realize: "Hey!, looks like Ada's the only thing I'm ever gonna have, so I'd better see to it that everything I ever plan on doing is part of Ada...", and we get Ada-9x, the language which will include all the great features that Ada left out. Kind of like quick-sand or one of those old Chinese finger traps... the more you struggle, the worse it gets. The good news is that, given the speed at which these things happen, Ada-9x is probably 10 years away. The bad news is two-fold: first, Ada-9x will probably break all existing Ada code and, second, the clunk factor will likely be so great (1,000,000+ bytes for "HELLO WORLD" might actually be achieveable), that no more working Ada code will ever be written afterwards. Total paralysis. Several times recently, Ada affectionados have posted articles concerning the national information clearinghouse for Ada-9x, including the phone-modem number (301) 459-8939 for Ada-9x concerns. This BBS contains 744 recent user comments on Ada in it's present state; true life experiences of actual Ada sufferers. These are grouped in bunches of 50 in zip files (e.g. 101-150.zip) and may be downloaded. For instance: complaint #0300 PROBLEM: Currently, to create and mature an Ada compiler, it takes from 3..5 years. For the new architectures of the future and rapid compiler development, the language needs to be expressed in terms that are easy to parse and to generate code. The definition should be revamped so that the grammar in Ada to conform to LR(m,n) for consistent/complete parsing rules -- the most efficient and accurate compiler techniques. Move more semantics to the grammar specification to rid the language definition of so many special cases. The solution proposed, unless I'm missing something, would break nearly all existing Ada code, hence it isn't likely to happen. Doesn't say much for the basic design of Ada either, does it? Add the time to finish the 9x standard and the 2 - 3 year time between first-compiler <--> compiler-which-anybody-can-stand-to-use, and you get my ten year figure for 9x. Sort of; there may never actually be a 9x compiler which anybody can stand to use. Here's the rub: a casual reading of the 744 little "problems" would lead one to believe that 1 out of every ten or so was a show-stopper, and that nine of ten are just people whining for new features. This would be a misinterpretation. In fact, it's probably all of those new features which are the big serious problem, given past history. The ten year problem, however, says that anybody figuring to use Ada starting now had best get used to the more minor problems (the 1 out of 10). These include: complaint #0237 We cannot adequately configure large systems as the language now stands. There are no standard means of performing the kind of operations on library units generally considered desirable. These include: - creating a new variant or version of a compilation unit; - mixed language working, particularly the use of Ada units by other languages; - access control, visibility of units to other programmers; - change control and the general history of the system. The inability to do these things arises out of a few loosely worded paragraphs in the LRM (in 10.1 and 10.4), which imply the existence of a single Ada program library, whose state is updated solely by the compiler. This can be an inconvenient foundation on which to build. The relationships between compilations in a project will be determined by the problem and the organization of work, and any automatic enforcement of a configuration control regime must come from a locally chosen PSE. Ada especially, as a language with large and diverse application, must have a separate compilation system which gives the greatest freedom possible in this area. IMPORTANCE: ESSENTIAL Ada was intended for use in large projects, involving many people, possibly at different centers. These are precisely the projects which will collapse if the programming support technology is inadequate. That is, Ada can't realistically be used for large systems. complaint #0150 Due to the availability of virtual memory, most minicomputer and mainframe programmers rarely consider the size of main memory as a limiting factor when creating their programs. In contrast, th size of main memory is a major concern of microcomputer programmers. The most widely used microcomputer operating systems, MS-DOS, does not have virtual memory capabilities. Without the availability of special programming techniques to get around this limitation, microcomputer programmers would have to severely limit the functionality of their programs, and, it would be impossible to create large, integrated information systems for microcomputers. One of most widely used of these programming techniques is the "chaining" capability provided in many programming languages. "Chaining" gives a programmer the ability to break down large integrated information systems into separate executable programs, and, then, when the system is operated, swap these programs in and out of main memory as the need arises. "Chaining", in effect, simulates virtual memory. Ada does not have the capability to chain programs. As a result, microcomputer programmers who use Ada must severely limit the functionality of their programs. Importance (1-10) 1 - Microcomputer programmers who use Ada will have to continue limiting the functionality of their programs. Current Workarounds Programmers must either limit the functionality of their Ada programs or use a proprietary CHAIN command supplied by the compiler manufacturer - which hurts portability. I.e., Ada can't be used for small systems: complaint #0021 PROBLEM: A high priority task may be suspended because it needs to rendezvous with a low priority task. That low priority task does not get scheduled promptly because of its priority. However this causes the high priority task to be suspended also. IMPORTANCE: (7) This problem makes the use of task priorities extremely difficult to apply correctly in a large system. It limits the ability to use task priorities to improve throughput in a system. complaint #0072 PROBLEM: The Ada priority system has proved quite inadequate for the needs of certain classes of hard realtime embedded systems. These are applications where a high degree of responsiveness is required. For example, there is a major conflict between the fifo mechanism prescribed for the entry queue and the need for the highest priority task to proceed wherever possible. complaint #0084 problem Ada tasking involves too much run-time overhead for some high-performance applications, including many embedded systems applications for which the language was designed. This overhead not only slows down the program in general, but may also occur at unpredictable times, thus delaying response at critical times. To avoid the overhead, real-time programmers frequently circumvent Ada tasking. The problem's exacerbated by Ada's lack of support for those who do try to use tasking in an efficient manner. There is no standard set of guidelines to programmers for writing optimizable tasking code, or to language implementors, for deciding which optimization to perform. Also, there is no simple way for a programmer who is concerned with writing portable high-performance code to check that optimizationsapplied under one implementation will be applied under different implementations. The consequences of Ada tasking overhead have not gone unnoticed in higher circles of government.A recent General Accounting Office report [1] noted that Ada has limitations in real-time applications that require fast processing speed, compact computer programs, and accurate timing control. All three of these requirements are directly and adversely affected by Ada's current tasking overhead. complaint #0278 PROBLEM: In the last 5 years, tomes have been written on the Ada tasking model. It is too complex and has too much overhead for embedded systems to utilize effectively. It also does not fit well with architectures found in embedded systems, e.g., multiprogramming/ distributed processing. The control mechanisms are not responsive to realtime needs. Applications programs are responsible for housekeeping on context switches where the process will not return to the previously selected context. The model does not support the well-known basic scheduling disciplines, e.g., preempt or nonpreempt and resume or nonresume, see Conway's Theory of Scheduling. The problems with tasking efficiency is not the maturity of the compilers, but in the underlying model defined in the language and the validation requirements for the compilers. importance: very high, one of the major goals for the Ada 9x current workarounds: Programming standards to avoid tasking or only initiate a single task and to not use rendezvous of any kind as they are too unpredictable and require too much overhead. Allow the ACVC not to test this section so that the application does not have to absorb a runtime system from a compiler vendor that has little experience with the applications. Or, write in a language like Modula-2 or object oriented C++ that does not interfere in the target architecture. i.e. Ada can't really be used for embedded systems, its original mandate. How about something simple like string handling? complaint #0163 Problem: Strings are inadequate in Ada. It is very frequently the case that the length of a string is not known until it is formed...after it has been declared. This leads to ugly, clumsy constructions (blank pad everything, keep track of length separately, play tricks with DECLARE's and constant strings, etc.). The obvious solution of writing a variable-length string package (see LRM, section 7.6) is unsatisfactory: you are lead to a limited private type because neither the standard equality test nor assignment are appropriate. (you want the both to ignore everything beyond the actual length of the strings) For limited private types, however, you have no assignment statement at all. We implemented such a package and found that using a procedure (SET) for assignment was error-prone and hard-to-read. This even for experienced programmers and even after getting beyond the initial learning curve for the package. How about something REAL SIMPLE, like argc/argv? complaint #355 PROBLEM: It is difficult, in a standard manner, to get at the operating system command line arguments supplied when the program is invoked. IMPORTANCE: (Scale of 1 - 10, with 10 being most important): <<8>> CURRENT WORKAROUNDS: Look up in vendor-specific manuals the method of accessing the command line parameters and access them differently on different operating systems. What about writing an OS in Ada (so that real "software engineers" won't have to screw around with UNIX anymore)? complaint #0186 It is difficult, if not impossible, to use Ada to write an operating system. For example, a multiprocessor naval command and control system might need basic software, comparable in complexity to a minicomputer network operating system, to support fault tolerance, load sharing, change of system operating mode etc. It is highly desirable that such important software be written in Ada, and be portable, i.e. be quite independent of the compiler supplier's Ada run time system. Currently, it would be very difficult to do this in Ada, because of the difficulty of manipulating tasks of arbitrary type and parentage. IMPORTANCE: 7. CURRENT WORKAROUNDS: Use operating systems written in C or assembler. Write the operating system as an extension of the Ada run time system - this is undesirable because it is non-portable and unvalidated. What about basic portability? complaint #0365 Problem: Implementation Options Lead to Non-Portability and Non-Reusability. Discussion: The LRM allows many implementation options and this freedom has lead to numerous "dialects" of Ada. As programs are written to rely on the characteristics of a given implementation, non-portable Ada code results. Often, the programmer is not even aware that the code is non-portable, because implementation differences amy even exist for the predefined language features. Further, it is sometimes not impossible to compile an Ada program with two different implementations of the same vendor's compiler. Another kind of non-portability is that of the programmer's skills, The user interfaces to Ada compilers have become so varied that programmers find it very difficult to move from one Ada implementation to another, Not only does the command line syntax vary, but so do program library structures, library sharability between users, compiler capabilities, capacity limits. etc. Importance: ESSENTIAL Current Workarounds: Significant amounts of code rewriting, recompilation, and testing must be done to get a given Ada program to compile and to run successfully using another compiler, if at all possible, even on the same host-target configuration. It is very difficult to write a truly portable Ada program. Another possible solution to porting an Ada program is for a customer to carefully choose a compiler to suit the given Ada program, or perhaps collaborate with a vendor to tailor the compiler to suit these needs. Significant amounts of programmer retraining must occur when a different Ada compiler is used. Somehow, all of this is beginning to remind me of a song I used to hear in the late 60's/early 70's (roughly paraphrased): "ADA! - KUH! - Yeah!, what is it GOOD for, absolutely NOTHIN!, say it again... ADA! - KUH! - Yeah..." And when I look at this stuff and think of the kinds of accusations BILL Wolfe and others like to throw at the C/UNIX nexus (some dummy might actually screw up a switch/break once every five years), I am reminded of the parable which Jesus told (Mathew 7:3) about seeing the mote in the neighbor's eye, but not the beam in one's own, although the application of the parable to this case almost seems like an understatement. Ted Holden HTE
stt@inmet.inmet.com (03/21/90)
In response to Ted Holden's "Last Diatribe": I am reluctant to respond since I would hate to cause Ted to violate his promise, but I felt a little bit of fairness was in order. Ada9X is intentionally a very open process, and encourages the reporting of all gripes, both serious and frivolous, about Ada83. This will certainly result in a lot of dirty laundry if there was a desire to claim that Ada83 was spotless. However, the point of Ada9X is precisely to address the problems, not to hide them. I am sure if you were to look inside the ANSI C standardization effort, you would have found large numbers of perceived problems with K&R C, and a standardization committee which did its level best to address as many as them as was practical. Similarly, the ANSI C++ standardization effort is just beginning, and it is destined to be a very interesting, heated, and hopefully productive process, with lots of dirty laundry, etc. Ada83 took a different approach from C and C++. It attempted to both break new ground from a language design and integration point of view, and rigorously standardize prior to a period of industry use. Languages which didn't standardize during their first years of use continuously evolved to address the gripes, meaning that presumably fewer gripes accumulated. Certainly C++ over the past few years has been a moving target. There were both good and bad reasons (in retrospect) for the early standardization approach of Ada83. Nevertheless, we are now at the stage of rounding up all of the big and little gripes which have accumulated during the past 8 years or so, and there are admittedly a lot of them, partly because the language has been rigidly standardized during this period of initial use. Of course, we didn't specifically ask for the list of good things about Ada, things which make it better for large-system development, for embedded-system development, for C3I development, for man-critical systems, etc., when compared to other widely available languages. We actually did receive a few unsolicited requests like "please don't change this, I like it the way it is". But by and large, most requests came from people who seriously want to continue using Ada rather than some other language, but have run into some problem or other which they would ideally like to see fixed. Just for reference, here are a few of the things which Ada83 tried to integrate into a single language. If you were to compare C, Pascal, etc. of 1980 with where languages are now, you will find that many of the ideas promoted by Ada83 have since been incorporated into C, C++, Modula-2, Concurrent C, etc, or are now being considered. Some of this was parallel evolution. Other changes in these languages were based directly on lessons from Ada's successes and problems. So here's the list: 1) Strong type checking across separate compilation, with a persistent program library structure. 2) User-defined data abstractions (private types) 3) Generic package/subprogram templates 4) Exception handling 5) Multi-tasking within the language 6) Synchronization primitives within the language 7) Inlined subprograms 8) Explicit separation between logical data structure definition and physical data representation definition 9) "Safe" pointers, with multiple heaps. 10) Complete array bounds checking, null pointer checking, scalar range checking, access-before-initialization checking, function-return-without- a-value checking, etc., carefully specified as part of the language definition. The net effect of all of these language features is that Ada is an excellent language for the building of large systems, providing excellent interface definition and control, and catching many errors at compile-time, and most remaining errors at run-time very close to the point of the defect. However, the size and sophistication of the language posed more problems for compiler-writers than was originally anticipated. In retrospect, the "let the compiler do it" and/or "just throw fancier instruction sets / more horsepower at the problem" attitudes had perhaps been taken too far (remember CISC was still king in the early 80's). We now know RISC is king, and small and fast is better than big and fancy. However, there is no denying by anyone who has used Ada, that its features do make interface control and debugging much much easier. Ada programmers don't want to return to the arbitrary address arithmetic of C, nor its single-level global name space. Watching the evolution of C++ is highly instructive, as it tries to incorporate exceptions, generics, concurrency, etc. It will be a real struggle to fit C++ 3.0 on an old-style PC. The challenge for the designers of Ada9X is to retain the existing features of Ada83, while achieving better run-time and compile-time efficiency. We believe this is possible by "simplifying through extension" and providing a small but complete set of additional safe low-level primitives. Simplifying through extension means removing special cases and limitations in the language, and unifying the capabilities so that all reasonable operations are applicable to all reasonable objects. This has the potential for both simplifying the compiler, and making the language more flexible for the programmer. Providing a small, complete set of safe low-level primitives may require no more than a carefully designed set of standard packages, with minimal additional linguistic support. "Safe" means that the new primitives should avoid introducing situations where random memory can be clobbered, or other "erroneous" unpredictable behaviour can occur. Ada83 is excellent at "damage control", where a bug in a program is detected at or very near its occurrence, before propagating failures to other parts of the program. Any new set of low-level primitives should preserve this important attribute. As a final point, the Ada9X process is attempting to address the compiler availability issue from the very beginning. There will be about three funded user/implementor teams, which will be paid to evaluate and implement the language changes as they are proposed. In addition, we anticipate structuring the changes so that those which address the most critical problems will be implemented first, as an incremental change to existing compilers, rather than as a major rewrite. This should mean that these most critical fixes will be available, at least for trial use, within the next few years. The more forward-looking changes may not be available until later, but presumably these are less critical today. S. Tucker Taft stt@inmet.inmet.com Ada9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138
chip@tct.uucp (Chip Salzenberg) (03/24/90)
According to stt@inmet.inmet.com (S. Tucker Taft): >I am sure if you were to look inside the ANSI C standardization >effort, you would have found large numbers of perceived problems >with K&R C, and a standardization committee which did its >level best to address as many as them as was practical. I quite agree with Mr. Taft. The ANSI C committee did receive a very large number of change requests. However, I believe that Mr. Taft's comparison with C misses Ted's point in quoting Ada complaints. No one I respect, certainly no one on the ANSI C committee, has ever claimed that C is the be-all and end-all of programming languages. It is useful for many purposes, but not all. Thus no one is surprised or dismayed when people request added features for C. However, the impression that I (and, perhaps, Ted) have of the Ada push by DoD is that the entire *purpose* of Ada is to be the be-all and end-all of programming languages. Everything from the proverbial enbedded systems in fighter jets to the also-proverbial mainframe database is to be written in Ada. So, you see, the DoD has set up Ada on a very high pedestal. Ted was merely pointing out that the users of Ada have found it to be unworthy of its hype. In fact, I would go so far as to predict (a hush falls over the crowd)... no one language will ever meet Ada's goals. To claim otherwise for Ada or any language is mistaken at best, fraud at worst. >By and large, most [Ada review] >requests came from people who seriously want to continue using >Ada rather than some other language, but have run into some problem >or other which they would ideally like to see fixed. I suspect that most people who "want to continue using Ada" would drop it like a hot potato if the DoD weren't looking over their shoulder by requiring it (or planning to require it). That's just a suspicion, mind you, but it's certainly the way I'd feel. -- Chip Salzenberg at ComDev/TCT <chip%tct@ateng.com>, <uunet!ateng!tct!chip> "The Usenet, in a very real sense, does not exist."