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-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: How come Ada isn't more popular? References: From: Markus E Leypold Organization: N/A Date: Fri, 09 Feb 2007 23:11:19 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:Gj7pYqGp2jpkVsXmfMgXNtSu4OA= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.200.144 X-Trace: news.arcor-ip.de 1171058766 88.72.200.144 (9 Feb 2007 23:06:06 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news-lei1.dfn.de!news-fra1.dfn.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:9217 Date: 2007-02-09T23:11:19+01:00 List-Id: "Randy Brukardt" writes: > Ray Blaak writes: >> "Randy Brukardt" writes: >> > I'm primarily interested in destroying the entire structure, and often I >> > need no destruction at all: the structures exist until the termination > of >> > the program. There's no point of earlier cleanup in such programs, and >> > surely no point in non-zero overhead to support such cleanup. I'm not > aware >> > of any zero-overhead GC algorithm, because the basic tenet of GC is that > you >> > can find all reachable objects: doing that requires some time and/or > space >> > overhead. >> >> I don't think anyone anywhere claims zero-overhead for GC. The whole point > is >> reasonable performance (in fact competitive with manual management) and a > much >> easier job for the programmer, in situations with highly dynamic >> memory usage patterns. > > That's the crux of the disagrement, I think. Yes indeed. > You claim that "highly dynamic memory usage" is the normal case; I So do I: Therefore my initial suggestion that list processing and support to do so efficiently matters for languages that want to play in the arena of application programming. > think it is *not* the usual case (or, at least, doesn't have to be > the usual case - languages like Java make it that unnecessarily). >> At any rate, one uses the tools that fit their needs. If you find yourself > in >> situations with stable data structures, then it sounds like you don't need > GC, >> plain and simple, or maybe even any cleanup at all. > > Right, but then why should it be a required and central part of general > purpose programming languages. There I disagree, but we know that. > Surely, it should be available as an option > for types that need it, but it certainly should not apply to all types. > > My programs tend to be plenty dynamic after all, but the dynamic is in the > construction of the data structures. Destruction of them is unusual, and > usually happens in a single operation (not piecemeal). And locals and > temporaries are on the stack - no action at all is required to destroy them > (you keep refering to this as "manual management", but there is nothing > manual about it -- the compiler does all of the work). > > Randy. I think we should find an application case (example), but we'd probably not agree wether it is typical. May I suggest XML processing? Regards -- Markus