Xref: loki.cf.ac.uk comp.lang.c++:223477 comp.lang.eiffel:18338 comp.lang.java.programmer:55526 comp.lang.java.tech:10219 comp.object:58087 comp.software-eng:50759 Path: loki.cf.ac.uk!yama.mcc.ac.uk!basilisk.pdc.nhs.gov.uk!peernews.ftech.net!telehouse1.frontier-networks.co.uk!azure.xara.net!xara.net!news-feed.inet.tele.dk!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!news-peer.sprintlink.net!news.sprintlink.net!Sprint!news.maxwell.syr.edu!newsfeed.internetmci.com!jump.net!grunt.dejanews.com!not-for-mail Date: Sat, 03 May 1997 22:11:08 -0600 From: Bertrand.Meyer@eiffel.com Subject: Avoiding the second historic mistake Newsgroups: comp.object,comp.software-eng,comp.lang.java.tech,comp.lang.java.programmer,comp.lang.eiffel,comp.lang.c++ Message-ID: <862714881.167@dejanews.com> Reply-To: Bertrand.Meyer@eiffel.com Organization: Deja News Usenet Posting Service X-Article-Creation-Date: Sun May 04 03:01:23 1997 GMT X-Originating-IP-Addr: 198.68.147.2 (outback.eiffel.com) X-Http-User-Agent: Mozilla/3.01Gold (X11; I; SunOS 4.1.3 sun4c) X-Authenticated-Sender: Bertrand.Meyer@eiffel.com Lines: 232 -- "Think Java. Write new applications in Java. Rewrite legacy apps with Java. Don't upgrade or downgrade. Sidegrade instead to a Java desktop device. Don't get hit with the PC's massively negative ROI. I don't understand why anybody would be programming in anything other than Java" Scott McNealy, Open Finance (a Sun publication), Spring 1997. Ten years ago or so, when object technology first captured the industry's attention, projects moved en masse to C++. This was not the right decision. Not that everything was bad with C++ (then it would not have attracted so many people); it was simply not appropriate for serious software engineering. C++ was a transition technology, useful to make C developers and their managers object-aware, but not appropriate for the development of durable, high-quality software systems. Interestingly enough, this was clear to many people; virtually every object-oriented expert would privately concede that C++ was an inadequate solution - but carefully refrain from saying so in public, for fear of appearing to go against the tide. This is happening again with Java. Once again we have an approach that has some major contributions to make but is hyped as the solution to everything - and is not. The contributions are clear enough. Java is good as a language to write applets, and (through its virtual machine) as a portable vehicle for executing programs written in various languages. Its dynamic aspects are also interesting for many applications. But Java is inadequate as a software engineeering language for enterprise applications. The deafening and at times indecent marketing campaign that has been running continuously for almost two years now (the quote at the beginning of this article is typical) conveniently overlooks the limitations of Java: - Unproven on large projects. Applets are great, but then what? - No multiple inheritance. (The marketing spin here is quite smart: trying to convince people that multiple inheritance is "bad", a contention for which not a single piece of concrete evidence has ever been published, whereas anyone who has practiced O-O development knows how important it is to be able to combine separate abstractions.) - No generic classes (forcing the frequent use of type casts, with disastrous effects on both performance and safety). - No assertions (even the modest "assert" of C++ has been removed). This means - let's be clear about it - that it is impossible to write serious reusable components in Java, because serious reuse requires that the components be specified. (See http://www.eiffel.com/doc/manuals/technology/contract/ariane) for a $500-million example of what happens when one violates this elementary rule.) It's great to devise fancy names, such as JavaBeans, but once the hype subsides who is going to trust a mission-critical development to "reusable" components who do not even document, let alone monitor, their own specification? - A neutered form of overriding (redefinition): when you redefine a routine, you cannot change its signature. This severely limits the application of polymorphism and other fundamental O-O techniques. (If A has e.g. a routine `copy' that takes an argument of type A, representing an object to be copied, its redefinition in a descendant class B must take an argument of type B - otherwise it makes no sense. The only solution in a no-signature-change language again appears to be the use of casts, removing the benefits of type controls.) - Violations of information hiding, hampering object-oriented principles (you can write a.x = value directly, i.e. modify an object field without going through the interface of the class!). - The confusing name overloading mechanism of C++ (what does a.f (x) mean if a and x are polymorphic and f is both redefined and overloaded for the corresponding types?). - The confusing syntax of C, replete with special characters and counter-intuitive conventions. - Inadequate tools and environments (as confirmed recently by a survey in ComputerWorld). - Major performance problems (a project we know gave up on Java after experiencing a tenfold performance degradation compared to C++). Of course the vendors promise that all will be fixed, and again the buzzwords are impressive, as with "Just in Time Compiling", but buzzwords don't make an application run faster. As one .sig found on the net (I believe from Roland Turner) states: "Java: the elegant simplicity of C++ and the blazing speed of Smalltalk". It is interesting to compare this with Eiffel: - Used in projects large and small for eleven years. - At the basis of large, successfully deployed commercial projects in banking, networking, telecommunications, health care etc. - Taught successfully for many years in universities around the world, because it is simple, clear and convincing. - Used by experienced programmers as well as managers, bankers, traders, engineers and specialists from widely different backgrounds. - The only approach that covers the entire lifecycle, from analysis to design, implementation and maintenance (no need for complex diagramming mechanisms such as UML). Avoids the split personality of many projects, where the analysis says one thing and the software does another, and no one understands both. - Widely cited as the most serious O-O language around (e.g. in the OMT book by Rumbaugh et al.: "Eiffel is the best commercially available object-oriented language", and scores of similar comments in the literature). - Offers a powerful inheritance mechanism supporting single, multiple and repeated inheritance in a clear and simple way. - Comes with thousands of proven reusable components, such as EiffelBase, EiffelVision (portable graphics), EiffelNet (client-server object communication), EiffelMath (numerical computing), WEL (Windows graphics), EiffelStore (relational database support), Matisse and Versant interfaces... - Makes true reuse possible through the application of carefully thought out reuse principles ("Reusable Software", Prentice Hall). - The only approach that can make reuse succeed on a truly large scale thanks to its built-in support for assertions (testable component specification, included in the components themselves and used to generate the documentation). - Runs on all major industry platforms, from Windows NT and 95 to all significant Unixes and VMS, with full source compatibility. - Run-time performance similar to C or C++. - Instant recompilation, independent of project size, thanks (in ISE Eiffel) to the Melting Ice Technology. - An amazingly powerful environment, whose browsing facilities have no equivalent for any language. - Built-in automatic memory management and garbage collection. - Interface to popular GUI builders through the Eiffel Resource Bench. (Why redo what already exists? Object technology is about leveraging software value, not doing everything differently.) - Interfaces to CORBA (soon to be released) and many other industry-standard products. - Backed (see http://www.eiffel.com/doc) by at least two dozen books in English, Italian, French, German, Russian, including in-depth descriptions of practical Eiffel projects ("Object-Oriented Applications", Prentice Hall). Extensive, award-winning on-line documentation at http://www.eiffel.com. - Now with support for multi-threading and (in SCOOP, to be released later this year) arbitrary concurrency. - Cheap personal versions (Windows, Linux), generous university packages (http://www.eiffel.com/services/university), affordable token-based licensing. Does this mean that one should drop everything else? Of course not. As Roy Phillips noted in a recent posting to comp.lang.eiffel, there is room and need for more than one language. Eiffel recognizes the presence and usefulness of both C++ (including C) and Java. Through its C++ interface and C++ wrapper (the recently released "Legacy++", see http://www.eiffel.com/doc/manuals/technology/cpp/index.html), ISE Eiffel provides clean encapsulation of C++ classes, in the same way that it provides encapsulation of C functions. Through its Java generation mechanism, slated for release later this year, it will allow Eiffel developers to take advantage of the Java VM and to combine Eiffel and Java code. But the forced march to Java in 1997 is no more justified than the mass conversions to C++ in 198. This time we don't have the excuse that we don't know; and no spacecraft hides, ready to rescue us, behind the comet. Can we as an industry learn from our mistakes? How many more Taligent-like catastrophes are needed, with Java replacing C++, to discover the obvious? Must we lose another ten years? No. One does not have to sacrifice the success of projects to the fashion of the day. That you can use a language to spin a fancy picture on a Web page does not mean you should use it to program your bank's market trading. There is money to be made now by choosing the right technical approach. Using Eiffel, you can bring your projects to completion faster and better. You can develop professional reusable components and sell them. You can underprice the competition on bids because you have a better technology. One mistake is good; we as an industry can learn from it. Two is one too many. -- Bertrand Meyer, ISE Inc., Santa Barbara (California) 805-685-1006, fax 805-685-6869, Web page: http://www.eiffel.com -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet