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-7-bit X-Google-Thread: 103376,52fd60a337c05842 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-14 01:14:53 PST Message-ID: <3D09A3D9.FCFE2426@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: <3D095F70.8090001@telepath.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 14 Jun 2002 04:05:45 -0400 NNTP-Posting-Host: 65.92.168.142 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1024042129 65.92.168.142 (Fri, 14 Jun 2002 04:08:49 EDT) NNTP-Posting-Date: Fri, 14 Jun 2002 04:08:49 EDT Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sunqbc.risq.qc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:25929 Date: 2002-06-14T04:05:45-04:00 List-Id: Dale Stanbrough wrote: > > Ted Dennison wrote: > > > But if you want real numbers that mean something, get the compilers you > > would use if you were to pick that language, and compare their output > > for the types of code you will be generating. Speed has way more to do > > with the effort your compiler writers put into optimization than with > > the language. > > async abort is one counter example of this. The definition is such > that programs take a hit in efficiency (or so i have read in this > newsgroup). > > Just thinking about it, don't Ada's "non constructor" construcor > functions require you to build items on the heap, then copy them > into the variable, rather than bulding them inplace? > > ...and doesn't the fact that the only way to attach information > to an exception is via a string, requiring conversions to/from > the appropriate format just to find out what -really- went wrong? > > ...and doesn't the representation of holey enumerated types cause > a lot of run time processing? I don't remember seeing anything in the ada95 rationale or the reference manual mentioning "minimize run-time processing" as part of the ada language design intent. IMHO I believe this is a feature since the ada run-time deliberately sacrifices optimum execution speed in order to achieve higher-levels of reliability via many invisible implicit checks on stuff every time you call a different service. I grant java does some similar checks here but with the JIT tweaking code, certainty in execution behaviour is reduced. I grant the java exception handling similar to ada however the java threading/runnable and concurrency infrastructure are an after-thought because they are not part of the java language itself. In other words one of the best kept secrets on the planet is that ada run-time and exception handling is much richer than java in terms of depth and breadth when dealing with tasking and concurrency. As an example read in the ada rationale documentation what it has to say about tasks and you will see what I mean. Lots of stuff here. It shows much depth and breadth in terms of expertise went into the documentation. Warns the user of issues that may need to be dealt with in certain specified situations. Then read the java thread/runnable docs and you will find it much simpler and a joy to read. Just follow the recipe and everything will be fine :) Which one describes the more realistic scenario when concurrency is involved? IMHO ada. > > I could go on, but i can't think of any others (at the moment!) :-) > > Dale That's interesting IMHO these all ADA FEATURES and not ada bugs :)