From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,52fd60a337c05842 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-13 22:01:37 PST Message-ID: <3D0976BD.21FA7516@sympatico.ca> From: David Marceau X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17-10mdksmp i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: ada paper critic References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 14 Jun 2002 00:53:17 -0400 NNTP-Posting-Host: 65.92.168.142 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1024030579 65.92.168.142 (Fri, 14 Jun 2002 00:56:19 EDT) NNTP-Posting-Date: Fri, 14 Jun 2002 00:56:19 EDT Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:25922 Date: 2002-06-14T00:53:17-04:00 List-Id: > 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