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,4f316de357ae35e9 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-08-26 10:54:07 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!nntp4.savvis.net!uunet!dfw.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: FAQ and string functions Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Mon, 26 Aug 2002 17:53:36 GMT References: <20020730093206.A8550@videoproject.kiev.ua> <4519e058.0207300548.15eeb65c@posting.google.com> <20020731104643.C1083@videoproject.kiev.ua> <4519e058.0208010629.5e6182ca@posting.google.com> <20020801194720.Q1080@videoproject.kiev.ua> <4519e058.0208020605.5ab7e092@posting.google.com> <3D4AAF63.72782659@san.rr.com> <3D4B2382.7030209@telepath.com> <3D4B2ACD.FDA29B9A@san.rr.com> <3D4B401E.3060802@telepath.com> <3D4B4477.500088B@san.rr.com> <3D4EA1AC.80D17170@s NNTP-Posting-Host: shell01.theworld.com Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.7/Emacs 20.7 Xref: archiver1.google.com comp.lang.ada:28421 Date: 2002-08-26T17:53:36+00:00 List-Id: Stephen Leake writes: > Robert A Duff writes: > > > "Randy Brukardt" writes: > > > > > I think your missing the Ada philosophy that something expensive should > > > look expensive. An unbounded array (as you put it) is going to be > > > expensive, and that expensive shouldn't be covered up in glossy syntax. > > > > IMHO, that philosophy is exactly the opposite of what high-level > > languages are all about. The parts of Ada that disobey this philosophy > > are the better parts. > > > > Here's an example: In Ada, one can write "A := B;". If they are > > integers, it's fast. If they are gigantic arrays, it could be a million > > times slower, or more. That's good -- assignment uses a single notation > > no matter how fast or slow. Contrast with C, where copying arrays uses > > a different syntax from copying ints. > > That's not a fair example. For assignment, the cost is clearly > proportional to the size of the data, which is easily visible in the > source. Not necessarily: procedure P(X: String) is Y: String_Ptr := new String'(1..X'Length); begin Y.all := X; -- How fast is this? The amount of data copied is probably a run-time calculated value (not "easily visible in the source"), and is different for each call to P. In fact, one call to P might take a million times longer than another. But anyway, what do you think is a fair example? My claim is that the philosophy Randy mentioned above is *not* a good language-design philosophy, and that Ada doesn't follow it very much. The cases where Ada follows that philosophy tend to be ugly, and the cases where that philosophy is disobeyed tend to be nice and clean. In fact, the only languages that truly obey the philosophy are assembly languages. To get the benefits of a high level language, I claim that you must give up the obvious correspondence between source code and efficiency that comes with low level languages. > Hidden memory allocation is not clearly visible (because it's hidden > :), but is expensive. I think the issue of memory allocation is not efficiency, but predictability of efficiency -- heap allocation/deallocation tends to be less predictable than stack allocation/deallocation. So it does make sense to avoid hidden memory allocation in a language for real-time systems. > A more valid example of hidden expense for assignment is a Controlled > type; Finalize and Adjust could be expensive. But even there, the > definition of the type clearly says "Controlled", so you are warned > that it might be expensive. I suppose, although you have to look into private parts to find that information, and at all the component types. And you have to know how your compiler does it -- compilers differ wildly in the cost of finalization. That's unfortunate, but I don't see how to avoid that problem in a high-level language. - Bob