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=3.2 required=5.0 tests=BAYES_00,RATWARE_MS_HASH, RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,433756934da4b72b,start X-Google-Attributes: gid103376,public From: "Paul Whittington" Subject: Another nail in Ada's coffin or an opportunity? Date: 1997/01/28 Message-ID: <01bc0d46$5a5409a0$24af1486@pc-phw> X-Deja-AN: 212829583 organization: INEL - AdaSAGE Development Team newsgroups: comp.lang.ada Date: 1997-01-28T00:00:00+00:00 List-Id: Last month I sent an email to the editor of Object Magazine regarding the misleading nature of one of his articles on Java technology. Well he published my email and a response from the author of the original article. The author makes some good points that require some good responses. This is an internationally distributed publication and as such is an oppurtunity for the Ada community to get some broad visibility. I encourage you to respond to the editor of Object Magazine at jwilliams@sigs.com. Below you will find my email to the editor followed by the author's response. In your December 1996 issue you published, "Why Java is a Key Technology for the Intranet," (by Nancy Nicolaisen, p.28) that perpetuates a dangerous common misunderstanding and shows an apparent lack of awareness. Let's begin with the title, "Why Java is a Key Technology for the Intranet". Java is not a key technology for the Intranet, or the Internet for that matter! The key technology here is the JVM and its associated standard libraries, of which there is no mention in the article. Java is just another upstart, nonstandard, ill-defined mutating computer language that promises to waste countless hours of software developers precious time, as we try to keep up with its inevitable changes, and provide the marketing machines with yet another banner to wave proclaiming a new generation of silver bullet products. No mention is made of the fact that it is entirely possible to implement JVM compilers for any number of computer programming languages. The fact is that JVM compiler implementations for languages other than Java has already begun, and products based on some of these compilers are already publicly available. As a case in point, consider the "ObjectAda for Windows:Professional Edition" product from Aoix, one of the largest companies in the object-oriented tools market (www.aonix.com). Along with a state-of- the-art native WIN32 compiler for Ada95, the world's first ISO-and ANSI-standard fully object-oriented computer language, the product includes a JVM targeting capability. There is also an effort underway to produce a Free Software Foundation GNU Ada95 JVM compiler, based on the current FSF GNU GNAT Ada95 compiler available for a wide variety of platforms. In the article you pose the question: " Why Bring Java Into the Enterprise Shop?" Why indeed? In your response you imply that Java is responsible for the important JVM features of portability, scalability, and multithreading. This is of course not true! These are characteristics of the JVM, not Java! Ada is more portable, more scalable, and has a far more complete, tested and M\mature multithreading model that Java, including complete thread-safe programming support with full guarding capabilities. In fact, during the thirteen-year history of Ada not only has the language matured into a complete robust, general purpose, object-oriented programming language, but the Ada market now provides compilers and tools that are as good as or better than those of the C++/Java languages seem to be slowly but surely migrating towards being a semantic replica of Ada95. Consider the semantic comparison chart (available at www.adahome.com/Resources/Languages/chart3.html) seen below. Studying this chart carefully makes me think that either Sun designed Java by starting with Ada95, know to support good software engineering characteristics, and modifying its syntax to be similar to C++ for marketing reasons, and modified it to support good software engineering characteristics. In either case, I'm left with the question, "Why did Sun spend, and continue to spend, [its] R&D dollars designing and developing a language that, through the investment of millions of taxpayer dollars including its own, had already been designed, developed, tested, matured, and fielded over the course of a decade or so?" Also in the article you pose the question "How many other application-development systems can give you these advantages (ORB bindings, support for the workstation class platforms, and the desktop) form a single code base?" Well Ada 95 can do all of this, as well as provide support for native code generation on may platforms including the JVM, bindings to native subsystems such as X-Windows, WIN32, ODBC, etc., and access to several extensive source code reuse libraries, none of which Java can do. In addition to all of this, research has shown that initial development and maintenance costs for Ada can be as little as half that of C, and by induction less than that of C++ and Java. In my seventeen years of programming I've used many languages, including various assemblers, APL, C, C++, Java Pascal, Modula-2, FORTH, and Ada, and I've yet to find a better language that Ada for its domain. I'm not a fan of big government, nor do I think that, in general, the federal government does things very well, but in the case of Ada I've found an exception, and it really gets my goat that we've spent millions of taxpayers dollars to develop and excellent technology that is being thrown out with the bath water. It's time for U.S. companies to start making software development decisions based on business-case analysis, and stop making them based on the opinion of some geek developer who thinks that the latest silver bullet written up in some industry [publication] is the right way to do things. To managers I say:show a little intestinal fortitude, get informed about the real costs and payoffs of competing software development technologies, make business decisions like you're supposed to, and tell your coddled guru to take a hike if "if doesn't work for him man!" To software developers I say grow up, start acting like the engineering professionals you say you are, keep yourself and your managers informed, and stop believing the silver bullet garbage already! Paul Whittington AdaSAGE Development Team Lockheed Martin Idaho Technologies Company United States Department of Energy The Author Responds: Many thanks for your well-researched letter. You make several excellent points, proving once again that in the area of technology, perhaps more than any other, there is ample room for intelligent people to respectfully disagree. Though Ada has many strengths, perhaps the most persuasive argument against it is the one you make, albeit obliquely, in your last few sentences. Although the language has been with us more than a decade, it has sparked little interest in the private sector. The population of fluent Ada programmers is small, and its aftermarket for tools and components wouldn't even register on the yardstick used to measure similar activity for mainstream languages such as C, C++, and Java. These combine to dampen optimism regarding the prospects for Ada's emergence as a key distributed technology. No project manager concerned with schedules and budgets willingly chooses a language that would require comprehensive retraining of a development team, and few projects can come to completion on schedule without the leverage of a vital and innovative tools-and-components aftermarket. Look at any successful programming language technology in use today, and you will find that it offers enterprise development these advantages. Though Ada was an elegant creation, the marketplace has voted against it. Clinging to it in the face of this reality will only narrow the prospects of development efforts reliant on it. Nancy Nicolaisen