Re: Gurus - which lang. for this task?

Re: Gurus - which lang. for this task?

[Cameron Laird]

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

Re: Gurus - which lang. for this task?

[Robert I. Eachus]

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...

Anticipatory proxies for disaster (was: Gurus - which lang. for this task?)

[Cameron Laird]

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

Re: Gurus - which lang. for this task?

[Robert Dewar]

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.

Re: Gurus - which lang. for this task?

[Robert Dewar]

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.

Re: Gurus - which lang. for this task?

[Samuel Mize]

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

Ada link times

[David Emery]

>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
-------------------------------------------------------------------------