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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e5bfa021bc026369,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-26 06:36:23 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!fr.ip.ndsoftware.net!proxad.net!usenet-fr.net!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: Mike Brenner Newsgroups: comp.lang.ada Subject: Personality Conflict was: why Ada is so unpopular ? Date: Mon, 26 Jan 2004 09:31:48 -0500 Organization: none Message-ID: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: melchior.cuivre.fr.eu.org 1075127536 82795 80.67.180.195 (26 Jan 2004 14:32:16 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Mon, 26 Jan 2004 14:32:16 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: X-Mailer: Mozilla 4.79 [en]C-20020130M (Windows NT 5.0; U) X-Accept-Language: en X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.3 Precedence: list List-Id: Gateway to the comp.lang.ada Usenet newsgroup List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: archiver1.google.com comp.lang.ada:4816 Date: 2004-01-26T09:31:48-05:00 In addition to the responses given, on the thread "why Ada is so unpopular", we must remember that it never was popular, and that during the "Ada mandate", it was never mandated. However, the responses I read in this thread did not address the primary problem with Ada, namely more personality conflicts than a small project could handle. Here are some political symptoms which fell out of those personality conflicts: A. It has been impossible for those of us at the bottom of the heap (users of Ada) to effectively communicate with those at the top, who control what changes go into the language, and who decide what support to give to whom. B. There is no central email address where we can submit suggestions for language changes. The people who accept formal requests for suggestions do so only from "country delegations" who do no listen to our posts in Ada email lists. C. There is not central email address where we can submit Bug reports. Therefore bug reports are only selectively accepted by the manufacturer of "supported versions", making it impossible to know the scope and impact of the bugs, or to measure the improvement of the language over the years. D. Because of these personality conflicts which led to this situation where there is no where to effectively email suggestions or bug reports, some things have gone awry with the language itself. D-1. The design of some packages and features had too little input. For example, the design of text_io, the lack of common support for the most common operating systems (DOS and Unix), and unsigned numbers. D-2. The lack of ability of the people at the top to counter their prevailing belief that "semantics" has nothing to do with "efficiency". As a result of this false belief their decisions, their manuals, and their features are implemented in inefficient ways. The 3 most egregious examples of this inefficiency are: (a) Static variables don't remain static when generically instantiated. (b) Constraint_error is raised by assuming a fictitious overflow when a signed number is moved into an unsigned number and vice versa, instead of just putting the bits into the other field without checking anything. (c) Some unchecked_conversions are required to generated code. To solve this, a new definition of the word "semantics" must be created which includes how fast something runs as part of its "meaning". Other languages have been doing that for years, for example, making the time-complexity of a function a part of its runtime library documentation, mandating inlining of certain types of code, and stating that certain type changes (casts) shall not use run-time code but be totally compile-time operations. Just because somebody has the opinion that those kinds of requirements are "not semantics", does not mean that Ada should not have efficiency-oriented requirements. At a minimum, that conflict should have been put aside by saying, "okay, we'll tentatively agree with you that efficiency is not part of the type of semantics you are talking about, but we still insist that certain operations be done at compile time"! It could have been a win-win situation, and will have to become so to achieve a future success. Examples of this kind of compromise in the "meaning" of "semantics" include the subject of Procedural Semantics. In Procedural Semantics, we would define the meaning of certain Ada constructs in terms of the code those constructs generate. This would contribute greatly to solving the technical aspect of this personality problem, by permitting some constructs (tail recursion, unchecked conversion, instantiating static variables, and moving integers from an to unsigned integers) to be defined as being implemented by no code at all (assuming the proper copy optimizations are possible). Yes, I realize that solving the technical portion of a personality problem addresses only the tip of the iceberg, D-3. Ada today is still being judged by bugs in the DOS version of gnat in the text_io package, bugs which could probably have been fixed with a few minutes of work by someone who knew anything about that package. E. Some of the strongest discussions on the Ada discussion lists have centered around the least important issues (in particular capitalization and indenting). Yet people have been blackballed, blacklisted, and threatened with job loss because of these personality-related issues, and the effect has not been lost on the community as a whole. F. As a result of all of those and other issues, many programmers who love Ada took jobs in other fields, leading to a situation where there are not as many cheap intern-salary labor who can analyze the impact of change, design, code, or test in Ada, as there are in competitor languages. For example, I have been offered several Ada jobs over the last few years, but at Intern wages. Who can afford to quit a real job for an 80 percent salary cut combined with moving away from the coasts? And, then, there is the problem of how a company could formulate Ada work in a very tiny market. G. Finally, there are also personality conflicts at higher levels. The people who administered the "Ada Mandate" that never mandated anything ensured that a major backlash would occur against that imaginary mandate, and the backlash occurred, but the Ada community had no answer to it. Now most programs are mandated to not use Ada. While this violates Software Engineering principles, no one cares, because software engineering is just what the powerful people in control of the money believe until they are replaced by other powerful people. And "power politics" is just another name for personality conflict. CONCLUSION To succeed in the nineties, Ada would have had to come up with a killer app, but that would have failed without eliminating the personality conflicts and having a central repository of suggestions and bug reports. To succeed now, Ada will still have to come up with: a. a killer app, b. a central suggestion-collecting web page, c. a way to eliminate the personality conflicts within the Ada community, d. a means of defining efficiency in a tiny but important set of Ada constructs, e. a means of implementing standard software engineering principles instead of indenting rules. f. a way to eliminate the conflicts with its former and potential future customers,. g. a way to win on both the reliability and the efficiency measurements. It's now happening yet, but it could still happen, because Ada is still the best design language, the least buggy way to code, and the easiest language in which to conceive bug free implementations out of all strongly-typed languages.