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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7bcba1db9ed24fa7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-09 20:39:00 PST Path: archiver1.google.com!newsfeed.google.com!postnews1.google.com!not-for-mail From: michael.p.card@lmco.com (Michael P. Card) Newsgroups: comp.lang.ada Subject: Re: Death by analogy Part 2 (was Re: is ada dead?) Date: 9 Jul 2001 20:38:59 -0700 Organization: http://groups.google.com/ Message-ID: References: <3B460DA9.C2965042@ix.netcom.com> <9ff447f2.0107061757.34ca0723@posting.google.com> <3b47806a_4@news3.prserv.net> <3b48d27d_4@news3.prserv.net> <3B49C9A3.FB4EF7C1@west.raytheon.com> <3B49D87C.6B349412@PublicPropertySoftware.com> <3B4A0B87.B166655D@lmco.com> <3B4A2B3E.CD91C5DD@PublicPropertySoftware.com> NNTP-Posting-Host: 129.44.208.8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 994736340 31241 127.0.0.1 (10 Jul 2001 03:39:00 GMT) X-Complaints-To: groups-support@google.com NNTP-Posting-Date: 10 Jul 2001 03:39:00 GMT Xref: archiver1.google.com comp.lang.ada:9702 Date: 2001-07-10T03:39:00+00:00 List-Id: Hey Al (& everyone else on CLA) When you write >Management is the number one factor related to software productivity. I am inclined to agree. Good tools will not necessarily compensate for bad management, but I would argue that good management would equip their people with good tools! You also wrote: >The change in productivity from changing language is unlikely in most > cases to exceed 30% or so, according to what I have read That may be so in many environments (though 20-30 percent is still pretty significant IMO), but I think there are some cases where it may be more significant. For example, I was a member of the software team for the AN/BSY-2 combat system for the Seawolf class submarine. We had hundreds of software engineers working to develop over one million lines of Ada code for the combat system, which was fielded on embedded 68K micros with a custom built Ada RTOS. The US Navy viewed this effort as a true Ada sucecss story (see http://www.adaic.org/docs/flyers/sears.shtml). To quote Admiral Sears regarding Ada83: "There are limits to the size of software systems which we can feasibly build with the technology at hand. Ada provides the best intellectual control available today for managing the development of huge software systems, through its packaging concept, strong typing, and separate compilation support." Based on my experience building C++ systems which are MUCH smaller than the AN/BSY-2, I would say that Ada made all the difference for that program. We had good managers in place but if C++ had been used, the Seawolf would never have sailed because we could never have completed the job in a reasonable timeframe. It would have taken YEARS longer and cost much more, if indeed it ever could have been made to work. In your "language change scenario" you wrote: > Consider the firm that is developing software and surviving without > using Ada. For example, may they use Java, Cobol, or Fortran to do > things that are not too difficult with Java, Cobol, or Fortran, and > they are getting by ok. Why risk a big investment to change language? > No reason. Along comes a much bigger and more challenging development > opportunity, and they realize that Java, Cobol, or Fortran is not the > right way to go for taking on this bull by the tail. Would they now > be wise to invest $100k/year+ in Ada tools so that they can rise to > the occasion? If they do, the odds are stacked against them. I agree that in this scenario a language change adds to the inherent risk of a bigger job in a new problem domain. But, if they knew their existing tools wouldn't do the job, isn't there a third option here, i.e. hire a contractor to do the hard work in while training your best people and having them work alongside the contactor(s)? It seems to me that an approach like this could help a business bridge itself into a new technology without having to take the "fatal plunge" of going into a new business area while concurrently using a new technology with a completely unprepared staff. Finally, you asked: > No need to argue with my crazy logic. Just show me a bunch of > companies developing applicationsoutside of the military and embedded > systems markets in the 10-to-100-developer range that switched from > anything else to Ada and succeeded and are still committed to it today. > I'd be interested to know why and how. OK, but realize here when you say "outside military and embedded systems" you are excluding the main domains for Ada. That would be akin to me asking you to show me a bunch of defense contractors that switched from Ada to Java/C++ for million-line plus real-time applications that succeeded and are still committed to Java/C++ today! Anyway, I have no idea how many companies have switched from C/C++/Java to Ada, but I did find this article in eweek interesting: http://www.zdnet.com/eweek/stories/general/0,11011,2769111,00.html The interesting part (to me) is the passing reference to Ada for automotive systems: "Industrial advisory boards also agree, for example, recommending Ada or Modula-2 ("having fewer insecurities and better type checking") for writing the software underlying automotive systems. " That is not a problem domain I normally hear associated with Ada, though I did know someone who left the AN/BSY-2 program to join one of the American Big 3 auto companies doing Ada programming. Did GM/Ford/Chrysler switch from C to Ada for their embedded systems? I have no idea. If anyone out there does know, please share with us! Your closing statement >Programming languages mostly propagate organically using low-level >contagion. This is hindered by high $ price tag. seems correct to me, which is why I think compilers like GNAT and the $99 version of Aonix's ObjectAda are good things. - Mike