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!news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!130.59.10.21.MISMATCH!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: Thu, 08 Feb 2007 10:04:33 +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> <66tzxy44ou.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 1170925473 20492 137.138.37.241 (8 Feb 2007 09:04:33 GMT) X-Complaints-To: news@@cern.ch NNTP-Posting-Date: Thu, 8 Feb 2007 09:04:33 +0000 (UTC) User-Agent: Thunderbird 1.5.0.9 (X11/20061220) In-Reply-To: <66tzxy44ou.fsf@hod.lan.m-e-leypold.de> Xref: g2news2.google.com comp.lang.ada:9128 Date: 2007-02-08T10:04:33+01:00 List-Id: Markus E Leypold wrote: I will cut ad-persona ramblings and your suggestions about my competence, and try to restate major points. >> I prefer solutions which enable me to hide implementation details from >> clients (sotware engineering?). If clients have to treat different > > I fail to see how using no GC helps you in that, whereas using GC as > it is today hinders you. You probably didn't read my previous posts in detail. I claimed that mainstream GCed languages put so much faith in the GC concept that they drop scoped lifetime altogether. *This* hinders me from solving my problems in a uniform way. I'm not happier with "no GC" and having GC is irrelevant to my problems. What is relevant to my problems is scoped lifetime and this is missing from mainstream GCed languages. Got the point? >> So why people claim that GC-oriented languages are general-purpose? > > Because they can write all kinds of programs with them? Assembly language has this property as well. Actually, computational completeness can be achieved with two instructions only, but I don't consider it as a valid argument for being general-purpose. >> The point is that languages which are build >> around GC tend to drop the proper support for other types of resources >> altogether. > > As if manual managment could be called proper support in this respect ... Then I will restate it again: the world is not partitioned between GC and manual management. As I've already pointed, you will not find manual management of anything in my regular code and since I'm also not using GC, then your view must be incomplete. // warning: this is not Ada { Session sql(oracle, "some-params"); string name; sql << "select name from persons where id=7", into(name); cout << name << '\n'; } Do you see *any* manual management of anything in the above? I stare at this code and I don't. Do you see GC here? I don't. Then please stop building your arguments on the presumption that only these two options are possible. Do you require from the user the understanding of implementation details of any of the above constructs? I don't. We (software engineers) call it encapsulation. > Big words, but given the choice between > > 1) Manual ressource management > 2) GC with (according to you) imperfect support for other kinds of ressources > 3) The hypothetical system you propose should exist The point is that you are not given only these choices. > Heap(s) -- I even resent the plural here -- are not about scoped but > about indeterminate lifetime. And a "compacted" heap has all the > unpredictability (in timing) as that of a garbage collector and would > provide garbage collection almost for free. Yes. My point is that compacting abilities are not restricted to GC. > People don't know how GC works, > don't know what it does It does not matter. What does matter is that not having scoped lifetime doesn't work. If you want to sell GC without scoped lifetime, I won't buy it. >>> 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. > > There are, as I can see, no non-fragmenting (heap) allocators for > unpredictable allocation patterns. There are. Write on a piece of paper all the reasons that in conjunction lead to heap fragmentation and think how to get rid of at least one of them. That's actually easy. > Apart from the fact that there are no nonfragmenting > allocators being shipped with, e.g. Ada. So do it yourself. Wow: Avoid > compacting GC, get more work, do it by hand. You can see why that > doesn't attract me. You see, the point is that in Ada or C++ I *can* and *know how* to improve anything I want based on the foundations that these languages give me (even if that means work), whereas in languages that have no support for scoped lifetime there is simply no foundation on which any improvements might be built on. Wow: Prevent people from achieving their goals, so they have less to do. You can see why that doesn't attract me. >> Note that scoped lifetime does not preclude GC on some lower level. > > You admit it, finally? Admit what? Scoped lifetime does not preclude GC on some lower level. The lack of scoped lifetime sucks, no matter whether GC is provided or not. > Unfortunately GC is no implementation detail, since you see wether > there a free() or dispose() calls in the source. You admit it, finally? Then look again at the snipped I provided above. Do you see *any* free() or dispose() calls in the source? I don't. We call it encapsulation. > Yes, but smart pointers where YOUR better answer to GC. No. My answer is scoped lifetime. Look again at the snipped above, there are no smart pointers in sight. Smart pointers are useful as a solution for resource management built on top of scoped lifetime in cases where the resource is not tied to a single scope. I use them, but *very* rarely. > You were > dissatisfied with GC. I'm dissatified with languages that provide GC *instead of* scoped lifetime. The focus should be put on "addition", not "instead". > File handles are in my view not > supposed to be handled by GC since they are structurally and > semantically different from memory. They should be closes explicitely. Bingo. But do you explicitly operate on all file handles that your program manages? Then you must be using some extremeley low-level language. Consider a class ConfigurationData (or whatever). Do you have to explicitly dispose of it? Hm... That depends on what ConfigurationData has *inside*. If it's bound to some file handle (say, using simple persistency scheme based on filesystem), then yes. This means that your reasoning has to be transitively closed based on the relations between implementation details of all dependent entities. Do you call it encapsulation? Consider another complication. A team that is responsible for ConfigurationData ships the 1.0 version of the package with in-memory database as a backend. They specify the interface. Some time later they ship 2.0 with files as backends. The specs didn't change (wow! that's what encapsulation is supposed to look like, no?), so according to software engineering practices you are not obliged to change anything in your code. Oops. Where's encapsulation? > No. You just need to stick to the rules. Close your ***** filehandles > manually. All the time. Thank you for clearly describing this paradigm. No, I'm not convinced. > If you want to be smart, though, it pays to think about the > interaction with underlying system (the implementation). I don't want to be smart. I want to be productive and have less bugs in my code. I noticed that scoped lifetime allows me to achieve this more effectively than without it. > I didn't do that, so I can't defend against it. Perhaps your friend > simply is not the Java software engineer he wants to be. I never did > have that problem ... -- so can I stop now defending my approach to > programming against errors other people have committed in another > language because they didn't read the JDBC reference manual? Should the user of ConfigurationData read the JDBC manual? Should he ever need to be aware that JDBC is used *somewhere there* deep in the bowels of ConfigurationData? > Reusing code in another context without re-viewing it, was what cost > the ESA that famous Ariane 5 launch. Good point, but where's encapsulation here? What about decoupling implementation from specification? > Reviews, reviews, reviews. Understand what you use! Then maybe we should drop this decoupling altogether? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/