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 Path: g2news2.google.com!news2.google.com!fu-berlin.de!kanaga.switch.ch!news-zh.switch.ch!switch.ch!cernne03.cern.ch!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: How come Ada isn't more popular? Date: Wed, 07 Feb 2007 09:55:02 +0100 Organization: CERN News Message-ID: References: <1169636785.504223.139630@j27g2000cwj.googlegroups.com> <45b8361a_5@news.bluewin.ch> <3pejpgfbki.fsf@hod.lan.m-e-leypold.de> NNTP-Posting-Host: abpc10883.cern.ch Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: cernne03.cern.ch 1170838502 16165 137.138.37.241 (7 Feb 2007 08:55:02 GMT) X-Complaints-To: news@@cern.ch NNTP-Posting-Date: Wed, 7 Feb 2007 08:55:02 +0000 (UTC) User-Agent: Thunderbird 1.5.0.9 (X11/20061220) In-Reply-To: Xref: g2news2.google.com comp.lang.ada:9058 Date: 2007-02-07T09:55:02+01:00 List-Id: Markus E Leypold wrote: >> Sure. But for the sake of discussion completeness, you might wish to >> throw an example of a situation where scoped lifetime will not make it. > > Model-View-Controller in GUIs. Especially trying to adapt that to GTKAda. I will not repeat Dmitry's arguments here. >> Java programmer wrote a loop where he opened database cursors, [...] > I'm not surprised. GC'ing ressources that are bounded doesn't spare > you knowing about the way GC works. Exactly. That's why I say that the solution is incomplete. If you have to think about the mechanics of some solution, then that solution is not entirely/properly automated. > You're approach "I want it all, and if > I can't have both (memory management AND general ressource collection) > I don't want neither" is somewhat counterproductive. I find it counterproductive to apply different management strategies with regard to *implementation details* of different types. I prefer solutions which enable me to hide implementation details from clients (sotware engineering?). If clients have to treat different types differently just because their implementation details differ, then it means that these implementation details leak out in the form of distinct handling methods. I want to treat String and DatabaseCursor in the same way - that's the prerequisite for being productive for me. > But you might well continue to believe in your policy here. Thanks. :-) > I, > personally, find that it brings me a big step nearer to salvation if I > can have GC, even if I do only manual MM with it. After all: I don't > have this much other (external) ressources to care about and if I do, > it pays to have a careful look at their structure and then wrap some > abstraction around them. OK, I understand it. We just agree that GC is a valid solution for *some* class of computing problems. So why people claim that GC-oriented languages are general-purpose? > But your approach is, since somebody had problems > misusing GC in a specific case No, that's not the point. The point is that languages which are build around GC tend to drop the proper support for other types of resources altogether. It's not the particular programmer who misused GC in a specific case - it's language designers who closed themselves in the GC cage and cranked a language that fails to provide good support for wider class of problems. As I've already said, the ideal would be to have both GC and scoped lifetime. The problem is that there is no reliable industry experience with such a mix, unless we treat Boehm's GC as one. > As far as the usability of GC goes, it even helps with controlled > objects [...] > I just make sure to close (e.g.) the filehandle and let the > rest to the GC. Of course. But then it's up to the designer of the type to decide how to treat each component of that type - it should be implementation detail. This decision should not be put on the shoulders of the final user, which is now the case in mainstream GC-oriented languages. This is what is broken. >> There is nothing particular in scoped lifetime that would prohibit >> compacting heaps and there is nothing particular in GC that guarantees > > No. But without having 3/4ths of a GC anyway compaction is pretty > pointless. Why? If the goal of compaction is to avoid fragmentation, then what is pointless in having compacted heaps managed by scoped lifetime? >> it. It's just the statistics based on popular implementations, not a >> rule. > > Sorry, that is nonsense. There are garbage collectors that are > designed to be compacting. So what? This is exactly the statistics I'm talking about, that does not prove that GC guarantees compacting or that the lack of GC prevents it. > They are moving objects around. This is > absolutely deterministic and not statistical. By statistics I mean the number of language implementations on the market that choose to use compacting GC vs. the number of languages that use non-compacting heaps. :-) > Whereas manual > allocation and deallocation as in Ada or C will fragment the heap and > you have NO guarantee (only statistics) about the ratio of allocated > (used) memory and presently unusable hole. If that bothers you, then use non-fragmenting allocators. > Hows that about > reliability if you can't give space guarantees even if you know about > the memory your algorithms need, since unfortunately you cannot > perdict the exact sequence of allocations? I use non-fragmenting allocator and I get my guarantees. >> I can perfectly imagine compacting heaps managed by scoped lifetime. > > Yes you can do that. Since you're following pointers than and reqrite > them you might as well go the whole way and deollaocate unusable > memory while you're at it. Yes. Note that scoped lifetime does not preclude GC on some lower level. Scoped lifetime provides a hook for deterministic "good bye" action - there is nothing more to it. Even if that "good bye" action calls free/delete/whatever on some memory block, there is nothing that forces the runtime to return the given block of memory right back to the operating system. Actually, none of the self-respecting allocators do this systematically - instead they keep the memory around for a while in anticipation of future allocations. I have nothing against GC at this level, really (and I've seen such implementations - in fact, a fully standard-compliant implementation of the C language could provide *empty* free function and GC underneath; and fully conformant C++ implementation could just call destructors as a result of delete and leave the raw memory to GC). What I'm against is a GC "paradigm" that prevents me from having deterministic "good bye" hooks for scoped lifetime. The problem is that most GC-oriented languages I'm aware of do have this "issue". In other words, for me GC is acceptable as an implementation detail of the dynamic memory allocator. I don't care *how* the allocator deals with memory that I free in the same sense that I don't care *how* the operating system deals with files that I remove from the filesystem. What I care about are hooks and scoped lifetime is an obvious answer for this. >>> (3) What is often needed are upper limits not determinism and thos >>> upper limits can be guaranteed with GC or with an appropriate >>> collector. > >> This refers to memory consumption only, whereas I clearly stated >> deterministic *time* as a second (first, actually) goal. > > This refers to both, there are real time compatible GC > algorithms. I'm interested in what is their target audience. I would expect any decent RT system to *refrain* from using dynamic memory except in the initialization phase (so that the "mission phase" is performed with constant set of objects), in which case RT GC would be just an answer to the question that nobody asked. Experts might wish to correct me and elaborate on this. >> OK. What about refcounting with smart pointers? > > (1) It ties lifetime to multiple scopes (instead of one) With GC tracing pointers you have the same, just the tracing is hidden. > (2) its not > efficient Why? > (3) It stille doesn't work for the general case Neither does GC, as seen in examples. :-) >> I acknowledge that there might be some applications which are strictly >> memory-oriented. They are just not the ones I usually write. > > It also works for apps that are not "memory-oriented". I think you're > missing that e.g. filehandles are really simpler and differently > structured ressource from memory. A filehandle does not contain > references to memory or other filehandle. Memory does. That vastly > simplifies the problem of managing file handles indeed so much that > I'm convinced that you don't need buitlin support for this. Somehow this idea didn't work for database cursors, as already described. >> Sure. In other words, be prepared that with GC you have to >> handle/understand some parts of the sytem better. > > So? So the implementation details of *some* types leak out in the sense that they force me to understand their internal mechanics. I don't want to. I want to say this: declare Sql : Session := Open_Session("some parameters"); Str : String := "Hello"; begin -- ... end; instead of this: declare Sql : Session := Open_Session("some parameters"); Str : String := "Hello"; begin -- ... -- damn, I have to do *something* with *some* stuff here end; [about FP] >> The difference is that in languages with scoped lifetime the lifetime >> management is a property of the type (and so applies to all >> instances), whereas the "FP-trick" above is a property of the >> use-side. Which one is more robust and less prone to bugs? > > This is, forgive me, nonsense. I might want to use a file handle in a > scoped way here and in a free floating way there. What about readability and maintainability of such code? > And no -- the FP way is not "more prone to bugs" Unless you use a handle in a free floating way and find later that in production your code was called in a loop causing handles to pile up? I have the practical example (already described) that this way of thinking can lead to failures. The programmer wanted to use a database cursor in a free floating way. That was fine. Later his code was used in a loop. Ah, yes - his code was used in a loop written by another programmer, so his judgement about whether it's OK to use anything in a free floating way was misguided from the very beginning. > and as with > George Bauhaus I simply refuse this kind of discussion (FUD and > ContraFUD). OK. We will just stay unconvinced. :-) >> BTW - please show me an example involving 10 objects of different kinds. :-) > > All at the same time? Yes. > Well -- bad programming. I knew you would answer this. :-) -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/