Re: WinNT ADA compilers comparison

[n_brunot@my-deja.com]

  "Robert I. Eachus" <rieachus@earthlink.net> wrote:
>      One simple example is "slow compilation times."  If your project
is
> making changes every day that require recompiling a substantial
fraction
> (or all!) of the source code, then the problem is not that Ada has
these
> nasty recompilation rules, it is that your design is not using
> information hiding correctly, and that the final code will almost
> certainly be unmaintainable.

In a software development company, making code changes is your dayly
job.
I talked about compiling, but above all, binding and linking time,
because as far as I know, we have to bind and link after the slightest
code change ...
I don't know if our code design is good, but we've been very
successfully maintaining it for more than 10 years, and hope to continue
...


>      Another example, and the one that you seem to be tripping over,
is
> proper use of generics.  There is noting wrong with generics nested in
> generics, and generic instantiations that instantiate other generics,
> etc.  But you need to know for each generic and each instantiation
> whether or not the compiler should do inlining, and where.
>


I wasn't talking about proper or improper use of generics in ADA, but
just noticing that Gnat executables are incredibly huge in comparison
with others compilers when you use generics.
We don't develop compilers and don't intend to do it, we just compare
available ones, and choose the one which best meet our needs ...
From the compiler user point of view, If everything else is equal,
providing 8 Mo executable is of course better than providing 40 Mo
executable

>      But isn't that an implementation detail you say?  Sure it is, and
> it is nice that the Ada language is designed so that changing those
> decisions can be done by changing a couple of pragmas in the source
> code.  But the decisions that can and should be delayed until later in
> the project do not include code size limitations and timing of key
> threads.  Those issues need to be thought out during the preliminary
> design process and communicated to all members of the team, not just
to
> the design team.
>

About preliminary design process, I think that everybody agree on what
should be done, and what anybody writing software must try to reach.
But unfortunately, theory is sometime not applicable in the real world.
I know some (a lot ?, all ?) cases where perfect theory would
indefinitely command to start again the project which therefore would
never get out the development team.


Sent via Deja.com http://www.deja.com/
Before you buy.