From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_20 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 7 Jul 91 22:39:47 GMT From: netcomsv!jls@apple.com (Jim Showalter) Subject: Re: USE clauses (was: c++ vs ada results) Message-ID: <1991Jul7.223947.15897@netcom.COM> List-Id: chuck@brain.UUCP (Chuck Shotton) writes: >People never HAVE to learn the >right way to engineer Ada systems if they use a Rational, because the machine >covers up for all their stupid mistakes with life savers like incremental >compiles, etc. People make mistakes. Nobody is prescient. To believe that software development proceeds smoothly from requirements down through maintenance with nary a hitch or stumble is naive in the extreme. In recognition of this fact, modern software development methodologies stress iteration, feedback, experimentation, and evolution. It is the opinion of many, including myself, that these sorts of methodologies represent the right way to engineer large complex systems, including Ada systems. What do YOU consider the "right way" to engineer Ada systems? One major obstacle to such methodologies--especially in a compile-time bound language such as Ada--is recompilation overhead. Incremental compilation provides a way to eliminate this obstacle, yielding the benefits of an interpretive, dynamic language despite the static nature of Ada. It is interesting to me that many of the problems people have started to encounter with C++ are due to a lack of incremental compilation tools for that language. >I really don't think >you can argue that a Rational outperforms a Vax on a straight compile >from source. No, I can't. But I regard this as a largely irrelevant metric. I once performed a benchmark for a prospective customer in which I made a change to a low-level package spec using two different approaches. In the first approach, I simply programmatically edited the spec and then used batch compilation to make the library consistent. Despite the fact that the change was trivial (the addition of a new procedure), the recompilation impact due to transitive closure rules was horrendous, and the make-consistent time was quite long. I then made the same change using incremental compilation, which took 14 seconds. Solving for X, this gave the Rational Environment an EFFECTIVE batch compilation rate of 150KSLOC/minute, which is pretty darned hard to beat with a VAX... When Rational talks about the difference between knowledge-based smart compilation and traditional time-stamp based dumb compilation, this is the sort of thing they're talking about. For you to dismiss this feature as a triviality that adds nothing to programmer productivity, you'd have to claim with a straight face that programmers never have to make changes to low-level specs--and for you to make this claim you'd have to claim that programmers are omniscient. The prospective customer bought a Rational, by the way. And they are so pleased with it that they've placed additional orders. >I don't even want to start in on the hardware performance issues or Rational's >ca.1980 user interface/battleship keyboard from hell, etc., but I'd much rathe r >use DECwindows than a 2 foot tall VT100. Well, personally I LIKE the keyboard because it don't have to take my hands off it to use a mouse---all of the major operations that would be mouse items under DECwindows are wired directly to keys. But this is just personal style--kind of like the wars between the .vi and EMACS folks. In any event, if you want window s stuff for the Rational, you can certainly get it--they offer a windowing product that runs on Suns, PCs, Macs, etc. But more importantly, you are attacking the Environment for its user interface, as if that's all that distinguishes it from the tools available on a VAX, which is absurd. I notice in all of your Rational-bashing that not once do you mention Rational Subsystems. I find this rather amazing, since Rational Subsystems are the only product I'm aware of that allow architectural-level design capture and enforcement (not to mention integrated CM, build-and-release operations, and recombinant testing with dynamic binding). Did you ever actually USE them? If not, you're like a person beating up on a Ferrari because you don't like the gated shifter (user interface) without ever taking the thing out for a drive (subsystems). Fundamentally, the issue comes down to sizzle over steak. The Rational is a giant juicy steak chock full of vitamins and funtionality. The VAX has a better mouse. It's a no-brainer to guess which actually adds real value to real projects. >I just think that the technology >incorporated in Rationals is better suited for undisciplined or inexperienced >development teams and does little to increase the productivity of experienced >Ada developers working on interactive systems. Well, you must have worked with a different bunch of programmers than I did. Indeed, the best software development organization I've ever heard of (composed of highly disciplined and experienced developers) just loves the Rational and feels it greatly increases their productivity. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *