* Re: Gurus - which lang. for this task? [not found] ` <3fuskb$hae@Starbase.NeoSoft.COM> @ 1995-01-23 18:09 ` Cameron Laird 1995-01-23 19:27 ` Robert I. Eachus ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: Cameron Laird @ 1995-01-23 18:09 UTC (permalink / raw) In article <3fuskb$hae@Starbase.NeoSoft.COM>, David Weller <dweller@Starbase.NeoSoft.COM> wrote: . . . >Let me suggest a solution, y'all can take it or leave it: >The language has these characteristics: > -- Recently ANSI/ISO standardized > -- Fully object-oriented, but doesn't mandate OO methods > -- Modular > -- Complete support for UniCode characters and UniCode IO > -- Very high-level language with efficient low-level support > constructs > -- Completely compatible with C, Fortran, or COBOL through > standardized interfaces for each language >There's more, but that pretty much answers the original poster's >questions. ... except for its suitability for prototyping. Ada has had a bad reputation in that regard. Does it still suffer from multi-day link operations? Under- stand, please, that I'm a "friendly", looking for reasons to learn more about Ada. . . . -- Cameron Laird ftp://ftp.neosoft.com/pub/users/claird/home.html claird@Neosoft.com +1 713 267 7966 claird@litwin.com +1 713 996 8546 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Gurus - which lang. for this task? 1995-01-23 18:09 ` Gurus - which lang. for this task? Cameron Laird @ 1995-01-23 19:27 ` Robert I. Eachus 1995-01-24 17:32 ` Anticipatory proxies for disaster (was: Gurus - which lang. for this task?) Cameron Laird 1995-01-25 2:07 ` Gurus - which lang. for this task? Robert Dewar 1995-01-24 19:15 ` Robert Dewar 1995-01-25 5:14 ` Gurus - which lang. for this task? Samuel Mize 2 siblings, 2 replies; 7+ messages in thread From: Robert I. Eachus @ 1995-01-23 19:27 UTC (permalink / raw) In article <3g0rc9$o4j@Starbase.NeoSoft.COM> claird@Starbase.NeoSoft.COM (Cameron Laird) writes: > ... except for its suitability for prototyping. Ada > has had a bad reputation in that regard. Does it > still suffer from multi-day link operations? Under- > stand, please, that I'm a "friendly", looking for > reasons to learn more about Ada. As one of those who fought taking this "feature" out of the language, I feel duty bound to answer this. At MITRE we found that whenever an Ada project start slipping due to "long link times," the problem was always traceable to major design flaws that would prevent completion of the project. (Since MITRE's main job is acting as a technical advisor to the DoD on procurements, we get to see a lot of projects in trouble.) In every case, where fixing things was possible (technically and otherwise), a few weeks spent restructuring the design brought the schedule under control. In particular not only did global recompiles drop from days to hours, they usually also went back to once per major build, and the programmers spent a lot less time fighting forest fires. So, if your Ada project has unacceptably long link times, C or Fortran is not the answer--in cases where this type of code switch was seriously attempted, the same design changes were needed. The answer is to find out why every compilation needs to with in (tranitively) several hundred library units. On one project we found a unit that was "withed" by over 600 units, and had over a hundred with clauses of its own. Argh! -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 7+ messages in thread
* Anticipatory proxies for disaster (was: Gurus - which lang. for this task?) 1995-01-23 19:27 ` Robert I. Eachus @ 1995-01-24 17:32 ` Cameron Laird 1995-01-25 2:07 ` Gurus - which lang. for this task? Robert Dewar 1 sibling, 0 replies; 7+ messages in thread From: Cameron Laird @ 1995-01-24 17:32 UTC (permalink / raw) In article <EACHUS.95Jan23142733@spectre.mitre.org>, Robert I. Eachus <eachus@spectre.mitre.org> reported on professional experience of his that I find so interesting I urged him to cross-post it to comp.software-eng. He has given me permission to do so. He wrote: . . . > As one of those who fought taking this "feature" out of the >language, I feel duty bound to answer this. At MITRE we found that >whenever an Ada project start slipping due to "long link times," the >problem was always traceable to major design flaws that would prevent >completion of the project. (Since MITRE's main job is acting as a >technical advisor to the DoD on procurements, we get to see a lot of >projects in trouble.) In every case, where fixing things was possible >(technically and otherwise), a few weeks spent restructuring the >design brought the schedule under control. In particular not only did >global recompiles drop from days to hours, they usually also went back >to once per major build, and the programmers spent a lot less time >fighting forest fires. > > So, if your Ada project has unacceptably long link times, C or >Fortran is not the answer--in cases where this type of code switch was >seriously attempted, the same design changes were needed. The answer >is to find out why every compilation needs to with in (tranitively) >several hundred library units. > > On one project we found a unit that was "withed" by over 600 >units, and had over a hundred with clauses of its own. Argh! . . . In his letter to me, he also explained: > You can quote me there if you like. This was the perfect example >of an operations research result. (It may take heavy duty statistical >analysis to reach the conclusion, but it is obvious in hindsight.) > > In this case what we found was that, in C, poor designs break when >the poor sod trying to maintain the makefile can't cope. In Ada, >since all that is automated/enforced you can get a lot more complex >before things fall apart, but the link times start growing >exponentially just before they do. (Fortunately in the Ada case the >break often occurs earlier in the project timeline. During detailed >design if the project is using a design method with executable >specifications.) . . . Follow-ups to c.s-e -- Cameron Laird ftp://ftp.neosoft.com/pub/users/claird/home.html claird@Neosoft.com +1 713 267 7966 claird@litwin.com +1 713 996 8546 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Gurus - which lang. for this task? 1995-01-23 19:27 ` Robert I. Eachus 1995-01-24 17:32 ` Anticipatory proxies for disaster (was: Gurus - which lang. for this task?) Cameron Laird @ 1995-01-25 2:07 ` Robert Dewar 1 sibling, 0 replies; 7+ messages in thread From: Robert Dewar @ 1995-01-25 2:07 UTC (permalink / raw) RObert (Eachus) answers a question about long link times by talking about excessive source dependencies. What's that got to do with link times. THe time taken to link is pretty much independent of how much you had to recompile. It is possible that the original questioner was being sloppy, and used long link times to refer informally to long build times, in which case the answer is reasonable I supposed. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Gurus - which lang. for this task? 1995-01-23 18:09 ` Gurus - which lang. for this task? Cameron Laird 1995-01-23 19:27 ` Robert I. Eachus @ 1995-01-24 19:15 ` Robert Dewar 1995-01-25 14:45 ` Ada link times David Emery 1995-01-25 5:14 ` Gurus - which lang. for this task? Samuel Mize 2 siblings, 1 reply; 7+ messages in thread From: Robert Dewar @ 1995-01-24 19:15 UTC (permalink / raw) First of all "suffering from multi-day linking operations" is a characteristic of an implementation not a language. Certainly it is clear that linking an Ada program should take no more or less time thank linking an equivalent C program, and certainly GNAT (and I would think lots of other Ada compilers) achieve this equivalence in practice. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Ada link times 1995-01-24 19:15 ` Robert Dewar @ 1995-01-25 14:45 ` David Emery 0 siblings, 0 replies; 7+ messages in thread From: David Emery @ 1995-01-25 14:45 UTC (permalink / raw) >Certainly it is clear that linking an Ada program should take no more >or less time thank linking an equivalent C program, and certainly GNAT >(and I would think lots of other Ada compilers) achieve this >equivalence in practice. I have two comments on this. Some of this discussion depends on how you define "link". By "link" in the following, I mean the step whereby you bind all of the previously compiled units to produce an executable program, including those checks required by the Ada language. Now, as Robert Dewar knows (but momentarily forgot ;-), there are some additional Ada semantics to this step, over and above the traditional linker. Specifically, the 'linker' must determine and build a proper order of elaboration. This often turns out to be a non-trivial computation. In a compiler that will remain nameless (you know who you are!), the algorithm to calculate the order of elaboration had an N**4 term in it (where N is the number of units). It took several years to isolate this problem, in part because the 4th-order term wasn't always the 'predominating factor', but it popped up at exactly the wrong times, i.e. when linking very large numbers of units. So, once you get past the required "link-time" Ada semantics, then linking should be identical to the times required by C and other languages for symbol resolution and construction of the binary image. GNAT has done some clever things to minimize the time spent on Ada-specific semantics... What Robert Eachus was referring to was a higher-level issue. Often, large link times indicate a proliferation of units, or a situation where determining the order of elaboration becomes complex. Anecdotally, such situations resemble other "metrics", such as coupling and cohesion, in that they MAY indicate a design problem. dave -- --The preceeding opinions do not necessarily reflect the opinions of --The MITRE Corporation or its sponsors. -- "A good plan violently executed -NOW- is better than a perfect plan -- next week" George Patton -- "Any damn fool can write a plan. It's the execution that gets you -- all screwed up" James Hollingsworth ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Gurus - which lang. for this task? 1995-01-23 18:09 ` Gurus - which lang. for this task? Cameron Laird 1995-01-23 19:27 ` Robert I. Eachus 1995-01-24 19:15 ` Robert Dewar @ 1995-01-25 5:14 ` Samuel Mize 2 siblings, 0 replies; 7+ messages in thread From: Samuel Mize @ 1995-01-25 5:14 UTC (permalink / raw) In article <3g0rc9$o4j@Starbase.NeoSoft.COM>, Cameron Laird <claird@Starbase.NeoSoft.COM> wrote: >... except for its suitability for prototyping. Ada >has had a bad reputation in that regard. Does it >still suffer from multi-day link operations? Under- >stand, please, that I'm a "friendly", looking for >reasons to learn more about Ada. 1) Modern compilers work pretty fast. If you're working on a slow platform, they will still take a while; so, if you expect to do code development on an 8086-based platform, one could use a near-assembler-language like C, then blame Ada for compiling slower. 2) FOR THIS ANSWER I'll define "prototyping" as rapidly building something, as a proof of concept or design sketch. I've found, once one knows Ada, that it works extremely well for this. You get the same trade-offs in building prototypes as you do building anything: it takes more time to write the code initially, it takes more compile time, you get more compile-time checks and spend less time debugging. The trick is to set up a code skeleton first, and compile it. Add a little functionality, compile it. Use a fast code/compile/test cycle. If you use enumeration types carefully, you can use 'image, 'value, and the text_io packages to crank out a quick-n-dirty command-line interface that will adapt itself as you add to the types. This can become an engine that is driven by a GUI in your second-generation prototype (UI + functionality). If you want to rapidly hack something that kind-of works, to show a UI or a general idea, you might do better in a non-Ada language. In this case I would recommend a UI builder of some sort, and whatever language it hooks to. Once Ada93 is well in place, that language may well be Ada. Samuel Mize - smize@starbase.neosoft.com ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~1995-01-25 14:45 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1995Jan12.143131.2083@midway.uchicago.edu> [not found] ` <3fh4l1$mpm@Starbase.NeoSoft.COM> [not found] ` <3fuskb$hae@Starbase.NeoSoft.COM> 1995-01-23 18:09 ` Gurus - which lang. for this task? Cameron Laird 1995-01-23 19:27 ` Robert I. Eachus 1995-01-24 17:32 ` Anticipatory proxies for disaster (was: Gurus - which lang. for this task?) Cameron Laird 1995-01-25 2:07 ` Gurus - which lang. for this task? Robert Dewar 1995-01-24 19:15 ` Robert Dewar 1995-01-25 14:45 ` Ada link times David Emery 1995-01-25 5:14 ` Gurus - which lang. for this task? Samuel Mize
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox