Re: ada paper critic

[David Marceau <davidmarceau@sympatico.ca>]

> have a look through this newsgroup on "implicit instantiation" and
> downward closures for coding (not speed) issues.
There is implicit instantiation in all languages.  
As you with in/import/include a package/class, you implicitly want to
instantiate the characterics necessary for a supporting package/class.
By ensuring a very limited scope to every instantiation of a
package/class, we can mitigate this issue.
If you don't want implicit instantiation make smaller packages with a
smaller number(0 even) of package public scope instantiated types.
IMHO when doing anything with more than one ada "task" however we do
want implicit instantiation but not too much.(Zen balance).
At the other extreme however if you make big packages with a lot of type
instantiations in it,
and then "with" that one big package later, IMHO your design is probably
not well conceived.
A well-conceived service will complete a service by having many classes
collaborate.
Only atomic services(set/get) can(but not necessarily) end up being
standalone(not collaborating with other classes)
and as a general rule if a service doesn't fit on one page it's probably
bad design 
because it has a higher complexity level(only rocket scientists and
cryptographers 
will be able to understand your code) and making it harder to document
and maintain in the long-term.

IMHO all languages need implicit instantiation, and in all languages,
developers should take care where they place it.
As a result, I don't see how implicit instantiation makes Ada any weaker
than any other language.

What do you mean about downward closures for coding issues?  Please
clarify this.



> 
> Look for "asynchronous abort" for speed of resulting code.
All languages have problems like this.
Please clarify how you think ada is inferior in this regard.
As it stands without a solid description and a solid example supporting
your argument, I can't agree with you.


> 
> Not quite sure what you mean about "stability of the resulting code".
Stability of the resulting code coming from Ada IMHO is higher because
that was the language designers intent.
In C/C++, efficiency & legacy code compilation compatibility were the
design intent.(the binary/assembler maps practically 1-to-1 with the C
language itself).
In C/C++ stability was more of an afterthought and more support added
later i.e. exceptions, smart pointers... :)
In Java, the JVM design had security in mind along with
platform-independence.  
Java sacrificed performance in the short-term to reach those design
goals.
Java's JVM performance has increased with Just-In-Time compilers 
however by doing so it compromised the JVM's "stability in the resulting
code".
In fact the JVM is screwing around with the "resulting code" whenever it
has idle time.  
What's that saying about "idle hands"..."devil's work"? :)
Going back to JIT performance it still doesn't and will never match
C/C++.  
Let's define total application execution lifetime as being app boot-up
time + app running time + app shutdown time.
Now let's say we wrote the same one-shot service app(console or gui
doesn't matter) in each of the following languages: asm, c, ada, c++ and
java.
Here how they line up starting with the fastest:
1)asm 
2)C 
3)ada
3)C++
4)java
Concerning Ada95 performance it may match C, however usually it is a bit
slower in order to make it more reliable than C and c++ and java.

It's true one may code badly in any language.  IMHO my bad coding for a
server app in Ada has a better probability of having a longer uptime
than C/C++ or java.
Longer uptime describes well what I mean by "definition of stability in
the resulting code" which I believe could be interpreted as part of the 
ada language designers' intent.

I hope this helps :)

Sant� bonheur,
David Marceau