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!news.germany.com!news.belwue.de!kanaga.switch.ch!irazu.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: Mon, 05 Feb 2007 10:59:07 +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 1170669547 12171 137.138.37.241 (5 Feb 2007 09:59:07 GMT) X-Complaints-To: news@@cern.ch NNTP-Posting-Date: Mon, 5 Feb 2007 09:59:07 +0000 (UTC) User-Agent: Thunderbird 1.5.0.9 (X11/20061220) In-Reply-To: Xref: g2news2.google.com comp.lang.ada:8957 Date: 2007-02-05T10:59:07+01:00 List-Id: Markus E Leypold wrote: [I agree with what you say on historical perspective on language transitions and the probabilistic effects that languages have on newbies, so this part was cut.] > If you just do f(s.c_str()) and f _is_ properly behaved, that is, only > reads from the pointer or does a strdup(), everything is fine, but, I > note, not thread safe. I wouldn't exclude the possibility that the > resulting race condition is hidden in a nice number of C++ programs > out there. If you have a race condition because of some thread is modifying a string object *while* some other thread is using it, then you have a heavy design problem. This is absolutely not related to interfacing with C. > Your solution is thread safe, if the strings package is (which it > wasn't in the past). Strings package cannot make it any better, because the granularity of thread-safety results from the program logic, not from the package interface. String is too low-level (it's a general utility) to be thread-safe in any useful sense. That's why: a) it should not be thread-safe on its own, b) you still have a design problem. Interestingly, Ada doesn't make it any better. Neithe does Java. You always need to coordinate threads/tasks/whatever on some higher conceptual level than primitive string operations. [about closures] >> You can have it by refcounting function frames (and preserving some >> determinism of destructors). GC is not needed for full closures, as >> far as I perceive it (with all my misconceptions behind ;-) ). > > Yes, one could do it like that. Ref-counting is rumoured to be > inefficient Which relates to cascading destructors, not to function frames. > but if you don't have too many closure that might just > work. If you have too many closures, then well, you have too many closures. :-) We've been talking not only about performance, but also about readability and maintenance. ;-) >>> Furthermore I've been convinced that manual memory management hinders >>> modularity. > >> Whereas I say that I don't care about manual memory management in my >> programs. You can have modularity without GC. > > Certainly. But you can have more with GC. In a strictly technical sense of the word, yes. But then there comes a question about possible loses in other areas, like program structure or clarity. Being able to just drop things on the floor is a nice feature when considered in isolation, but not necessarily compatible with other objectives that must be met at the same time. > People who don't have GC often say that they can do anything with > manual memory management. And I say that this is misconception. I don't have/use GC and I don't bother with *manual* memory management neither. That's the point. In Ada this point is spelled [Limited_]Controlled (it's a complete mess, but that's not the fault of the concept) and in C++ it's spelled automatic storage duration. Today manual memory management is a low-level thingy that you don't have to care about, unless you *really* want to (and then it's really good that you can get it). And as I've already pointed out, in my regular programming manual memory management is a rarity. On the other hand, most languages with GC get it wrong by relying *only* on GC, everywhere, whereas it is useful (if at all) only for memory. The problem is that few programs rely on only memory and in a typical case there are lots of resources that are not memory oriented and they have to be managed, somehow. When GC is a shiny center of the language, those other kinds of resources suffer from not having appropriate support. In practical terms, you don't have manual management of memory, but you have *instead* manual management of *everything else* and the result is either code bloat or more bugs (or both, typically). Languages like Ada or C++ provide more general solution, which is conceptually not related to any kind of resource and can be therefore applied to every one. The result is clean, short and uniform code, which is even immune to extensions in the implementation of any class. Think about adding a non-memory resource to a class that was up to now only memory oriented - if it requires any modification on the client side, like adding tons of finally blocks and calls to close/dispose/dismiss/etc. methods *everywhere*, then in such a language the term "encapsulation" is a joke. An ideal solution seems to be a mix of both (GC and automatic objects), but I think that the industry needs a few generations of failed attempts to get this mix right. We're not yet there. >> OO is about encapsulation and polymorphism, these don't need >> references everywhere. > > Yes, but -- you want to keep, say, a list of Shape(s). Those can be > Triangle(s), Circle(s) etc, which are all derived from class > Shape. How do you store this list? An array of Shape'Class is out of > question because of the different allocation requirements for the > descendants of Shape(s). Why should I bother? Note also that I didn't say that references/pointers should be dropped. I say that you don't need them everywhere. That's a difference. > I've decided, if I want to deliver any interesting functionality to > the end user, my resources (developer time) are limited, I have to > leave everything I can to automation (i.e. compilers, garbage > collectors, even libraries), to be able to reach my lofty goals. I also leave everything I can to automation. It's spelled [Limited_]Controlled in Ada and automatic storage duration in C++. I cannot imagine reaching my lofty goals otherwise. ;-) > The point is to know when to optimise, not to do it > always. I didn't even mention the word "optimization". I'm taling about structure. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/