* Re: THAAD Study on Ada Viability [not found] ` <wQCX5.1696$bw.107780@news.flash.net> @ 2000-12-13 22:41 ` Singlespeeder 2000-12-13 23:43 ` Ken Garlington ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Singlespeeder @ 2000-12-13 22:41 UTC (permalink / raw) What I find fustating about ADA is the IDE. I know it was the first language supposed to have one from the start but frankly working in defense it's still DEC ada 83 and the DEC LSE while the rest of the world moves on. Even ADAGIDE is a great improvement (I've even taken to developing on a PC under ADAGIDE then FTPing back to VMS for final builds, formal testing etc). Some of us aren't interested in a pure Ada IDE and like the way Microsoft started to integrate all their languages in Visual Studio. There's no reason why a third party couldn'e develop Visual Ada to go with the suite. Hey, if someone's doing it for COBOL... Then of course ACT looks good, and there's always jGrasp... Has anyone got any stats on how many errors are down to environment not language? You know, the kind that an IDE helps you spot as you're writing. The point is though that the defense industry isn't going to upgrade the development environment and move their development wholesale onto these suites. Instead they'll stick with overstretched VAX/VMS machines, and an environment that may have been hot in 1983 but doesn't cut it in the 21st century - certainly not when trying to meet their 21st century timescales. If Ada is dead within the defense industry I believe that it's not the fault of the language. Rather it's the fault of the IDE, and the unwillingness of the buyers of defense products to move with the times. Ada has shown itself to be capable of moving on, the decision makers in the Pentagon who mandated not just the language but the toolset have not. Nick Wallis singlespeeder@32sixteen.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-13 22:41 ` THAAD Study on Ada Viability Singlespeeder @ 2000-12-13 23:43 ` Ken Garlington 2000-12-14 12:33 ` Robert Dewar 2000-12-14 14:32 ` Marin David Condic 2000-12-13 23:52 ` David Botton 2000-12-14 12:31 ` Robert Dewar 2 siblings, 2 replies; 21+ messages in thread From: Ken Garlington @ 2000-12-13 23:43 UTC (permalink / raw) "Singlespeeder" <singlespeeder@btinternet.com> wrote in message news:918u24$8ms$1@neptunium.btinternet.com... : The point is though that the defense industry isn't going to upgrade the : development environment and move their development wholesale onto these : suites. Instead they'll stick with overstretched VAX/VMS machines, and an : environment that may have been hot in 1983 but doesn't cut it in the 21st : century - certainly not when trying to meet their 21st century timescales. I dunno... my company (Lockheed Martin Aero) is moving off of VAXen and onto other platforms as fast as possible (including legacy programs). We are also using far more IDEs and upper CASE tools than before. : If Ada is dead within the defense industry I believe that it's not the fault : of the language. Rather it's the fault of the IDE, and the unwillingness of : the buyers of defense products to move with the times. Ada has shown itself : to be capable of moving on, the decision makers in the Pentagon who mandated : not just the language but the toolset have not. To the extent that Ada is no longer being used in the defense industry, I'd say it was due to the issues originally raised in the NAS study a few years ago, and generally supported by the THAAD study. In particular, since (at least for the projects I support) the "decision makers in the Pentagon" have gotten out of the language/tool mandate (with a few interesting exceptions), it's hard to blame them for the use of obsolete systems! ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-13 23:43 ` Ken Garlington @ 2000-12-14 12:33 ` Robert Dewar 2000-12-15 2:45 ` DuckE 2000-12-14 14:32 ` Marin David Condic 1 sibling, 1 reply; 21+ messages in thread From: Robert Dewar @ 2000-12-14 12:33 UTC (permalink / raw) In article <dQTZ5.7717$bw.686086@news.flash.net>, > I dunno... my company (Lockheed Martin Aero) is > moving off of VAXen and onto > other platforms as fast as possible (including > legacy programs). We are also > using far more IDEs and upper CASE tools than > before. Hmmm! If even Ken Garlington's environment is moving away from Vaxes, that surely is the beginning of the end for these machines :-) Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-14 12:33 ` Robert Dewar @ 2000-12-15 2:45 ` DuckE 2000-12-15 2:46 ` DuckE 2000-12-16 18:50 ` Robert Deininger 0 siblings, 2 replies; 21+ messages in thread From: DuckE @ 2000-12-15 2:45 UTC (permalink / raw) I couldn't find a copy of the official announcement, but I believe Compaq has stopped producing VAXen altogether. SteveD "Robert Dewar" <robert_dewar@my-deja.com> wrote in message news:91aem6$jhf$1@nnrp1.deja.com... > In article <dQTZ5.7717$bw.686086@news.flash.net>, > > I dunno... my company (Lockheed Martin Aero) is > > moving off of VAXen and onto > > other platforms as fast as possible (including > > legacy programs). We are also > > using far more IDEs and upper CASE tools than > > before. > > Hmmm! If even Ken Garlington's environment is moving > away from Vaxes, that surely is the beginning of the > end for these machines :-) > > > > Sent via Deja.com > http://www.deja.com/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-15 2:45 ` DuckE @ 2000-12-15 2:46 ` DuckE 2000-12-18 19:31 ` Robert L. Spooner 2000-12-16 18:50 ` Robert Deininger 1 sibling, 1 reply; 21+ messages in thread From: DuckE @ 2000-12-15 2:46 UTC (permalink / raw) "DuckE" <nospam_steved94@home.com> wrote in message news:ZAf_5.149027$U46.4839329@news1.sttls1.wa.home.com... > I couldn't find a copy of the official announcement, but I believe Compaq > has stopped producing VAXen altogether. > Which, I might add, is why we moved from VAXeln Pascal to Ada95. It was an easy move. > SteveD > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-15 2:46 ` DuckE @ 2000-12-18 19:31 ` Robert L. Spooner 2000-12-19 16:05 ` Robert Dewar 0 siblings, 1 reply; 21+ messages in thread From: Robert L. Spooner @ 2000-12-18 19:31 UTC (permalink / raw) We have been moving from VAXELN/VAXELN Ada (83) on the KAV30 VME VAX hosted on VAX/VMS to VxWorks/GNAT on 68060 and now/soon PowerPC hosted on Sun/Solaris for similar reasons. After years of DEC^H^H^HCompaq saying "buy from us, you'll have a migration path," they ported neither the operating system nor the compiler to the alpha and Ada95. VAXELN Ada was retired. We could have gone to an alpha vme board with VxWorks, but it was only supported under Digital unix and the lab didn't want to support two versions of unix - we already had Sun workstations here. (At least they had GNAT develop a version of Ada 95 for the alpha under VMS.) So we went from one cpu and file system for host and target to separate ones (eventually VxWorks worked with a unix file system through NFS.) It made life more difficult. WindRiver is just now coming out with an operating system with address space protection - something VAXELN had over ten years ago. Bob DuckE wrote: > > "DuckE" <nospam_steved94@home.com> wrote in message > news:ZAf_5.149027$U46.4839329@news1.sttls1.wa.home.com... > > I couldn't find a copy of the official announcement, but I believe Compaq > > has stopped producing VAXen altogether. > > > Which, I might add, is why we moved from VAXeln Pascal to Ada95. It was an > easy move. > > > SteveD > > -- Robert L. Spooner Registered Professional Engineer Associate Research Engineer Intelligent Control Systems Department Applied Research Laboratory Phone: (814) 863-4120 The Pennsylvania State University FAX: (814) 863-7841 P. O. Box 30 State College, PA 16804-0030 rls19@psu.edu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-18 19:31 ` Robert L. Spooner @ 2000-12-19 16:05 ` Robert Dewar 2000-12-19 18:01 ` Larry Kilgallen 0 siblings, 1 reply; 21+ messages in thread From: Robert Dewar @ 2000-12-19 16:05 UTC (permalink / raw) In article <3A3E6626.E1EB9369@psu.edu>, "Robert L. Spooner" <rls19@psu.edu> wrote: > (At least they had GNAT develop a version of Ada 95 for the > alpha under VMS.) Note that the ingrediants for GNAT on Vax/VMS were always in place, so this would have been a practical port, but neither DEC nor any actual user was willing to fund such an effort, so it never happened, and is certainly not going to happen now! Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-19 16:05 ` Robert Dewar @ 2000-12-19 18:01 ` Larry Kilgallen 0 siblings, 0 replies; 21+ messages in thread From: Larry Kilgallen @ 2000-12-19 18:01 UTC (permalink / raw) In article <91o10t$k9$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > In article <3A3E6626.E1EB9369@psu.edu>, > "Robert L. Spooner" <rls19@psu.edu> wrote: > >> (At least they had GNAT develop a version of Ada 95 for the >> alpha under VMS.) > > Note that the ingrediants for GNAT on Vax/VMS were always in > place, so this would have been a practical port, but neither > DEC nor any actual user was willing to fund such an effort, > so it never happened, and is certainly not going to happen now! This seems to bring up a significant difference between Ada and Java. The DEC folks backed away from Java on VAX because of a requirement for IEEE floating point, which is not in the VAX hardware. Experiments at emulation were S-L-O-O-O-W. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-15 2:45 ` DuckE 2000-12-15 2:46 ` DuckE @ 2000-12-16 18:50 ` Robert Deininger 1 sibling, 0 replies; 21+ messages in thread From: Robert Deininger @ 2000-12-16 18:50 UTC (permalink / raw) On Thu, Dec 14, 2000 9:45 PM, DuckE <nospam_steved94@home.com> wrote: >I couldn't find a copy of the official announcement, but I believe Compaq >has stopped producing VAXen altogether. CPU production stopped a couple of years ago. The last order date for new systems was the end of Sept. 2000, IIRC. The last delivery date is the end of this month. Real development of the VAX CPUs stopped quite a few years ago. The last generation of VAX systems were basically new packaging for older CPUs. Alpha development continues, but for the most part the alpha systems don't support the hardware that VAXes do. In many cases, embedded systems don't port easily from VAX to alpha. --------------------------- Robert Deininger rdeininger@mindspring.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-13 23:43 ` Ken Garlington 2000-12-14 12:33 ` Robert Dewar @ 2000-12-14 14:32 ` Marin David Condic 2000-12-15 16:44 ` David Gillon 1 sibling, 1 reply; 21+ messages in thread From: Marin David Condic @ 2000-12-14 14:32 UTC (permalink / raw) Ken Garlington wrote: > "Singlespeeder" <singlespeeder@btinternet.com> wrote in message > news:918u24$8ms$1@neptunium.btinternet.com... > : The point is though that the defense industry isn't going to upgrade the > : development environment and move their development wholesale onto these > : suites. Instead they'll stick with overstretched VAX/VMS machines, and an > : environment that may have been hot in 1983 but doesn't cut it in the 21st > : century - certainly not when trying to meet their 21st century timescales. > > I dunno... my company (Lockheed Martin Aero) is moving off of VAXen and onto > other platforms as fast as possible (including legacy programs). We are also > using far more IDEs and upper CASE tools than before. > One of the things to note about defense systems is that they differ dramatically from similar commercial systems in terms of their longevity. A given missile or avionics system can easily be around in some stage of development/maintenance for 20..30 years. (How old is the B52 bomber?) You pick a target processor, development platform, compiler, toolset, etc. in the year 2000 and you may make your first production delivery in 2010. You have to live with those choices because to change over to the latest/greatest technology means a huge cost in regression testing and re-validating the system. I don't think defense companies are against moving to modern tools - as your example of LMA illustrates. I think they just have a harder time doing it than commercial endeavors might. We kind of know that instinctively because we're insiders. Those outside the defense community may not be aware of it. MDC -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-14 14:32 ` Marin David Condic @ 2000-12-15 16:44 ` David Gillon 0 siblings, 0 replies; 21+ messages in thread From: David Gillon @ 2000-12-15 16:44 UTC (permalink / raw) To: Marin David Condic Marin David Condic wrote: > One of the things to note about defense systems is that they differ dramatically > from similar commercial systems in terms of their longevity. A given missile or > avionics system can easily be around in some stage of development/maintenance > for 20..30 years. (How old is the B52 bomber?) The B-52 is the classic example of programme longevity. Design started '49, first flight '52, entered service '55, production completed '70s, currently planned retirement date 2040.... -- David Gillon BAE SYSTEMS Avionics Rochester, Kent, UK ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-13 22:41 ` THAAD Study on Ada Viability Singlespeeder 2000-12-13 23:43 ` Ken Garlington @ 2000-12-13 23:52 ` David Botton 2000-12-14 12:31 ` Robert Dewar 2 siblings, 0 replies; 21+ messages in thread From: David Botton @ 2000-12-13 23:52 UTC (permalink / raw) To: comp.lang.ada The ACT GUI is GLIDE an e-macs based cross platform IDE that has far more features and flexability. AdaGIDE is intended more for student use (although there are many in addition to yourself using it for far more). David Botton ----- Original Message ----- From: "Singlespeeder" <singlespeeder@btinternet.com> > ADAGIDE is a great improvement (I've even taken to developing on a PC under > Then of course ACT looks good, and there's always jGrasp... ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-13 22:41 ` THAAD Study on Ada Viability Singlespeeder 2000-12-13 23:43 ` Ken Garlington 2000-12-13 23:52 ` David Botton @ 2000-12-14 12:31 ` Robert Dewar 2000-12-14 14:35 ` John English 2000-12-14 14:36 ` Ken Garlington 2 siblings, 2 replies; 21+ messages in thread From: Robert Dewar @ 2000-12-14 12:31 UTC (permalink / raw) In article <918u24$8ms$1@neptunium.btinternet.com>, "Singlespeeder" <singlespeeder@btinternet.com> wrote: > What I find fustating about ADA is the IDE. This is a little peculiar, *the* IDE? there are of course many such ... > I know it was the first language > supposed to have one from the start Nope, that's reinventing history. To what are you referring? > but frankly working in defense it's > still DEC ada 83 and the DEC LSE while the rest of > the world moves on. Only a small part of the Ada world is still using DEC Ada 83 and DEC LSE. Yes, a significant part, but if you have the view that all DoD projects are using this combination, you have a very narrow view of the Ada world. > Even ADAGIDE is a great improvement (I've even >taken to developing on a PC under > ADAGIDE then FTPing back to VMS for final builds, > formal testing etc). AdaGIDE is a nice tool for students, but there are many IDE's out there (GLIDE, GRASP, SNIFF, APEX ...) for serious development use. Sounds like you are not familiar with any of these. It really sounds like your problem is not the state of Ada and its IDE's but rather the state of the particular development environment you find yourself in. > Then of course ACT looks good Well thanks for the comment, but I have no idea what it means in this context, are you referring to the use of GLIDE as your IDE? > The point is though that the defense industry isn't > going to upgrade the development environment and > move their development wholesale onto these suites. > Instead they'll stick with overstretched VAX/VMS > machines. Again, an amazingly narrow viewpoint. You are assuming that the environment you work in is the one used throughout the defense industry, but that's entirely incorrect. Very few defense projects are still using VAX machines. > If Ada is dead within the defense industry I > believe that it's not the fault > of the language. Rather it's the fault of the IDE, > and the unwillingness of > the buyers of defense products to move with the > times. *Some* buyers of defense projects, please do not assume your experience is typical of all projects. >Ada has shown itself > to be capable of moving on, the decision makers in >the Pentagon who mandated > not just the language but the toolset have not. Individual programs may have mandated specific tool sets, but the "Pentagon" never did anything of the kind. Even early in Ada days, many different environments, IDE's, architectures, and Ada compilers were in use, and only a fraction used Vax'es and DEC Ada 83. Now the fraction using this obsolete technology is much smaller (yes, of course we know that Ken Garlington is stuck in such an environment :-) but he is the first to know that that does not mean everyone else in defense is similarly stuck. An interesting indicator here is that it would be technically quite straighforward to port GNAT and its IDE to a Vax, but there has never been any serious commercial interest in doing so, from DEC or from any user. Whereas there has been interest in porting GNAT to all kinds of other architectures in defense contexts, including not only standard architectures (including OpenVMS/Alpha, which is of course supported by GNAT) but also non main-stream architectures such as the 750 and the i960. I am talking here strictly about interest from the defense community -- your community :-) Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-14 12:31 ` Robert Dewar @ 2000-12-14 14:35 ` John English 2000-12-14 15:05 ` Marin David Condic 2000-12-14 14:36 ` Ken Garlington 1 sibling, 1 reply; 21+ messages in thread From: John English @ 2000-12-14 14:35 UTC (permalink / raw) Robert Dewar wrote: > In article <918u24$8ms$1@neptunium.btinternet.com>, > "Singlespeeder" <singlespeeder@btinternet.com> > wrote: > > I know it was the first language > > supposed to have one from the start > > Nope, that's reinventing history. To what are you > referring? Presumably the APSE. However, it's not even history -- just a dimly remembered legend passed down from generation to generation and being embellished as it goes... :-) ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-14 14:35 ` John English @ 2000-12-14 15:05 ` Marin David Condic 0 siblings, 0 replies; 21+ messages in thread From: Marin David Condic @ 2000-12-14 15:05 UTC (permalink / raw) I remember the APSE from years and years ago. My recollection was that there were some vague documents trying to lay out requirements without actually dictating what the system would look like. Way too fuzzy for anybody to take it seriously. I recall there was at least one command line interface design presented at some SIGAda - back when we were all still using glass teletypes. (It had Ada-like syntax and was waaaay too verbose to be typed at a command line!) I guess the whole thing died from lack of interest and a realization that human/computer interface designs were changing way too fast for anything to be standardized. There are a few things that I wish *were* standardized across all development environments. Little things like file naming conventions would be nice. I don't know that the world is any more ready for a common Ada development environment now than they were back in 83. But some standardization that made it easy to move a big wad of source code from one development environment to another would be A Good Thing (tm). MDC John English wrote: > Presumably the APSE. However, it's not even history -- just a dimly > remembered legend passed down from generation to generation and being > embellished as it goes... :-) -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-14 12:31 ` Robert Dewar 2000-12-14 14:35 ` John English @ 2000-12-14 14:36 ` Ken Garlington 2000-12-15 10:05 ` Tarjei T. Jensen 1 sibling, 1 reply; 21+ messages in thread From: Ken Garlington @ 2000-12-14 14:36 UTC (permalink / raw) "Robert Dewar" <robert_dewar@my-deja.com> wrote in message news:91aejd$jgr$1@nnrp1.deja.com... : Individual programs may have mandated specific tool : sets, but the "Pentagon" never did anything of the : kind. Well, IIRC they did try (the Navy with the ALS/N, the Air Force with AIE), but most program managers wouldn't take on the risk. : Even early in Ada days, many different : environments, IDE's, architectures, and Ada compilers : were in use, and only a fraction used Vax'es and : DEC Ada 83. Now the fraction using this obsolete : technology is much smaller (yes, of course we know : that Ken Garlington is stuck in such an environment : :-) but he is the first to know that that does not : mean everyone else in defense is similarly stuck. Actually, we are gradually getting ourselves "unstuck" (at some cost), in part because almost no one provides tools for this environment anymore. Unfortunately, the development environment obsolescence issue has people so frightened that they want to move away from anything with a "military" history -- including Ada. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-14 14:36 ` Ken Garlington @ 2000-12-15 10:05 ` Tarjei T. Jensen 2000-12-15 13:24 ` Marin David Condic 0 siblings, 1 reply; 21+ messages in thread From: Tarjei T. Jensen @ 2000-12-15 10:05 UTC (permalink / raw) Ken Garlington wrote >Actually, we are gradually getting ourselves "unstuck" (at some cost), in >part because almost no one provides tools for this environment anymore. >Unfortunately, the development environment obsolescence issue has people so >frightened that they want to move away from anything with a "military" >history -- including Ada. But the civilan stuff is even more frightening with regards to obsolescence. They frequently do things that requires you to rewrite parts of your software. The cost is just as horrific and more often. E.g. powerbuilder, Oracle forms. I would not like to pay <insert vendor here> to maintain their C++ compiler for 30+ years because some project is using it. In fact, I'm pretty certain that I would have a hard time getting the vendor to understand the issues and keep that compiler supported. If I were into long life projects I would want Ada. I would know that there is an industry that understands the issues of long life cycles, safety critical software, etc. To me that means safety and assurance. Greetings, ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-15 10:05 ` Tarjei T. Jensen @ 2000-12-15 13:24 ` Marin David Condic 2000-12-15 14:19 ` Ken Garlington 0 siblings, 1 reply; 21+ messages in thread From: Marin David Condic @ 2000-12-15 13:24 UTC (permalink / raw) "Tarjei T. Jensen" wrote: > I would not like to pay <insert vendor here> to maintain their C++ compiler for > 30+ years because some project is using it. In fact, I'm pretty certain that I > would have a hard time getting the vendor to understand the issues and keep > that compiler supported. This is seldom a real problem with any compiler. Presuming you have purchased a compiler that is beyond being someone's Science Fair Project, you aren't going to be turning up show-stopping bugs at every turn. By the time most projects are at some kind of "First Release" phase, in many cases you want to freeze the version of the compiler anyway (at least for embedded sorts of things this is rather common) so that from a configuration management and verification viewpoint you can work from a known quantity and be able to reproduce things properly. I'd definitely take new releases of a compiler for some time into a 30 year project, but well before the 30 years were up, I'd have frozen the compiler, the OS and the rest of the development platform - until some external reality forced me to move on! :-) MDC -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-15 13:24 ` Marin David Condic @ 2000-12-15 14:19 ` Ken Garlington 2000-12-15 17:14 ` Marin David Condic 0 siblings, 1 reply; 21+ messages in thread From: Ken Garlington @ 2000-12-15 14:19 UTC (permalink / raw) "Marin David Condic" <mcondic.nospam@acm.org> wrote in message news:3A3A1B96.208E7FF2@acm.org... : "Tarjei T. Jensen" wrote: : : I'd definitely take new releases of a compiler for some time into a 30 year : project, but well before the 30 years were up, I'd have frozen the compiler, the OS : and the rest of the development platform - until some external reality forced me to : move on! :-) Yeah, we thought we were going to do that with our VAXen. After all, that's the approach we had used on every previous program. However, there's some ugly consequences: (a) it runs at cross-purposes with another popular corporate trend - standardizing on a single (yet evolving) platform to reduce cost; (b) it makes it even more difficult to attract quality software engineers to the project; and (c) it assumes that you're also going to be able to freeze your target architecture (e.g. MIL-STD-1750, MIL-STD-1553...) which is also no longer realistic. : ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: THAAD Study on Ada Viability 2000-12-15 14:19 ` Ken Garlington @ 2000-12-15 17:14 ` Marin David Condic 0 siblings, 0 replies; 21+ messages in thread From: Marin David Condic @ 2000-12-15 17:14 UTC (permalink / raw) Maybe those are the "external realities" I alluded to? :-) Here's the way I see it: The importance of freezing of the environment is in direct proportion to the cost of verification. If you cobble something together that computes loan amortization on a Windows platform and basically all you do is "smoke testing" then hand it off to your customers, there isn't much to worry about. If you spend millions (billions?) of dollars going through various stages of testing for an embedded product that *must* work without error, changing the environment means going back and spending that same millions of $$$ to re-validate the system if, for example, you change compilers, processors, communications hardware, etc. Wellllll..... *maybe* you can eliminate *some* of the testing, reducing it to just demonstrating the same functionality you had before and lack of errors in the software. But it could still cost *a lot* to do. Now sometimes, the economics of it become ridiculus. If your chip maker decides to shut down production due to lack of interest, what are you going to do? Open up your own silicon foundry? Guess you're going to have to buy a different processor and start revalidating your software. :-) Of course you might freeze versions of a compiler even on fairly short-lived and non-critical projects just because it is working "good enough" and you don't want to take the chance of introducing new bugs. MDC Ken Garlington wrote: > Yeah, we thought we were going to do that with our VAXen. After all, that's > the approach we had used on every previous program. However, there's some > ugly consequences: (a) it runs at cross-purposes with another popular > corporate trend - standardizing on a single (yet evolving) platform to > reduce cost; (b) it makes it even more difficult to attract quality software > engineers to the project; and (c) it assumes that you're also going to be > able to freeze your target architecture (e.g. MIL-STD-1750, MIL-STD-1553...) > which is also no longer realistic. > : -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ====================================================================== ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <3A2F612B.D82B76A5@BMW.de>]
[parent not found: <90nq6h$3l9$1@nnrp1.deja.com>]
* Re: THAAD Study on Ada Viability [not found] ` <90nq6h$3l9$1@nnrp1.deja.com> @ 2000-12-14 12:53 ` Robert Dewar 0 siblings, 0 replies; 21+ messages in thread From: Robert Dewar @ 2000-12-14 12:53 UTC (permalink / raw) In article <90nq6h$3l9$1@nnrp1.deja.com>, n_brunot@my-deja.com wrote: > Today, NO Ada 95 compiler can fully replace our 5 > year old Ada83 compiler without severe regression. > This is a fact ... and so compiler availability is > a real concern. Well it *might* be a fact, but I doubt you have the data to support the claim. For example, you certainly are not a customer of ACT or ACTE, so your statement certainly does not include GNAT Professional. Perhaps you are a customer of OCS, Rational, Greenhills, Aonix, Irvine, DDC/I, ... (sorry if I forgot any), and can thus make a fully informed statement for other compilers, but I doubt it :-) One thing that tends to happen with large legacy codes is that they have been kicked, tuned, pushed, and generally molested over the years to work well with some legacy compiler and to circumnavigate bugs in the old compiler. Then when you port to ANY other compiler, you find five things: 1. Errors in the program that were not apparent in the earlier use -- a very common case for example is missing pragma Elaborate statements. 2. Implementation dependent stuff that happened to work in some older compiler and works no longer. 3. Stuff that works only because of bugs in the old compiler which are corrected in the new compiler. 4. Performance issues. Sometimes these are indeed significant differences in performance. Other times they simply reflect the fact that code has been tuned to meet the particular behavior of another compiler. One really nasty case we had of performance degradation turned out to be a program which read the value of an environment variable in the inner computational loop of the program -- it read the same variable over and over again -- and apparently VADS cached the result so this rather peculiar programming decision did not have much impact. When we moved the read out of the loop, all was well again. 5. Finally you may indeed run into some problems and bugs in the new technology. How much of a problem that is will depend on how easy it is to work around these problems, and how easily problems that cannot be worked around can be fixed. That is of course a function of the support you get from your vendor. Certainly there are no bug free Ada 83 compilers. Even DEC Ada, which I think most people would consider to be one of the best Ada 83 compilers has many bugs (we found quite a few serious ones as we ported GNAT to VMS -- for example, there were some tests in the DEC test suite that we failed because the test was expecting the wrong thing :-) Milage may vary of course, but our general experience is that in porting large legacy codes at this stage with GNAT Professional, although we certainly get some cases of 5 (bugs in GNAT), they are usually relatively easily dealt with, and the more serious problems in moving to GNAT are in categories 1 and 2. (elaboration problems are often very annoying, and are almost entirely a matter of incorrect code that happened to work before). Certainly there are some cases where performance problems and other bugs are significant and require work, but in most cases, this is not the most significant porting issue (although this presumes support from us, and it is not so much of a surprise that Nicolas Brunot runs into more troubles trying to do serious work with the public version of GNAT). Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2000-12-19 18:01 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <NBBBJNOMKDIAJALCEFIJCELGEAAA.rleif@rleif.com> [not found] ` <90lj4s$8h7$1@nnrp1.deja.com> [not found] ` <wQCX5.1696$bw.107780@news.flash.net> 2000-12-13 22:41 ` THAAD Study on Ada Viability Singlespeeder 2000-12-13 23:43 ` Ken Garlington 2000-12-14 12:33 ` Robert Dewar 2000-12-15 2:45 ` DuckE 2000-12-15 2:46 ` DuckE 2000-12-18 19:31 ` Robert L. Spooner 2000-12-19 16:05 ` Robert Dewar 2000-12-19 18:01 ` Larry Kilgallen 2000-12-16 18:50 ` Robert Deininger 2000-12-14 14:32 ` Marin David Condic 2000-12-15 16:44 ` David Gillon 2000-12-13 23:52 ` David Botton 2000-12-14 12:31 ` Robert Dewar 2000-12-14 14:35 ` John English 2000-12-14 15:05 ` Marin David Condic 2000-12-14 14:36 ` Ken Garlington 2000-12-15 10:05 ` Tarjei T. Jensen 2000-12-15 13:24 ` Marin David Condic 2000-12-15 14:19 ` Ken Garlington 2000-12-15 17:14 ` Marin David Condic [not found] ` <3A2F612B.D82B76A5@BMW.de> [not found] ` <90nq6h$3l9$1@nnrp1.deja.com> 2000-12-14 12:53 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox