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: <1169636785.504223.139630@j27g2000cwj.googlegroups.com> <45b8361a_5@news.bluewin.ch> <3pejpgfbki.fsf@hod.lan.m-e-leypold.de> From: Markus E Leypold Organization: N/A Date: Wed, 31 Jan 2007 11:24:23 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:KKPit1ug8u6P7CWbLu/R/33LO7U= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.207.215 X-Trace: news.arcor-ip.de 1170238772 88.72.207.215 (31 Jan 2007 11:19:32 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.tu-darmstadt.de!newsfeed.hanau.net!news-fra1.dfn.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:8807 Date: 2007-01-31T11:24:23+01:00 List-Id: Maciej Sobczak writes: > Markus E Leypold wrote: > >>> Sorry, but that's a misconception - I don't remember when I was the >>> last time I was messing with manual memory management in a regular C++ >>> code. I estimate that in my current programming I call delete (or free >>> or whatever) once in 5-10 kLOC. >> OK. I'll have to reconsider this statement. I usually couldn't trim >> down 'automatic' allocation to that extent, but that might have been >> my application area. What I remember though, is the difficulty to >> recover from exceptions in the presence of automatic (scope bound) >> memory management. (I hope I'm making sense here, else I'd really have >> to go back to my C++ mind and notes and try to retrieve the right >> vocabulary and reasoning and -- well -- I don't really want to have a >> C++ discussion in c.l.a. :-). > > Why not having C++ discussions on the list where people claim that C++ > sucks? :-) Because of the level of detail? Because I haven't really swapped in my C++-personality yet, I'm wary to do it and fear I'll slip up in public claiming the wrong things about C++? :-) Jokes aside, I feel a bit off topic with this and the fervour in this thread seems to have diminished somewhat anyway ... > >> But from what I remember in >> the 1997s to 1998s > > Most programming languages were terrible at that time, that's true. Not Ada 95 ... :-). Actually I think it was that time when history branched and Ada missed to become main stream, but that is not a historians claim only a personal impression. > >> (that was when there still were problems with STLs, >> exceptions and the string libraries in C++ and when there was no >> standard and Java was new), that this was one of the motivations that >> people shifted to Java (either from C++ or from C). > > Yes, I know that. And I will keep stating that this motivation > resulted from common misconceptions, further amplified by Java > marketing. Oh yes, misconceptions perhaps. But I'v only been talking about peoples motivations (which say a lot about their perceived problems). > I've even heard that Java is better, because it has a String class and > there is no need to use char* as in C++ (!). FUD can buy a lot. As far as that goes I have seen people getting tripped up really bad by string::c_str(). And I think you need it, if you don't program pure C++, which at that time nobody did. The implementation I saw there might have been strange/faulty though -- s.c_str() returned a pointer into some internal data structure of s which promptly changed when s was modified. The only "safe" way to use it was strdup(s.c_str()) and that is not threadsafe as anybody can see. I see "the need to use char* in C++" rumour as the result of people having been burned by similarly quirks at that time. > >> The other >> motivation was the "portable GUI" > > Yes. > >> which, I think, mostly disappointed >> the expectations. > > Still, GUI that sucks was better than no standard GUI at all for lost > of people. "portable" not "standard". There were always standard GUIs on Unix and on Win32, only they where not exchangeable. > Both C++ and Ada are in the same camp in this aspect. I'm > not claiming that these languages should have standard GUI, but not > having it definitely scared many. Let's say it the other way round: Java certainly attracted a number of people because of the "standard GUI". And since I firmly believe that a GUI does NOT belong into a language standard but rather in a separate standard for a runtime environment, I wonder a bit which kind of people those were. >> Of course I might be wrong. This is just teh impression I got "from >> the trenches" and I might be missing a mor global point of view. It >> perhaps does not apply today where C++ > > Well, there is still no standard GUI for C++, but the choice with > non-standard ones is quite impressive: I haven't been talking about the standard GUI here, but about the memory managment issues I hinted at earlier. I see, I've been jumping a bit here. > > http://www.free-soft.org/guitool/ > >> and the understanding of C++ >> has matured a bit > > Yes. Sadly, too late for those who already changed their mind. > >> (there is even an embedded subset of C++ which will >> annoy folks here no end :-). > I think that at the end of the day the embedded C++ will disappear > from the market as the "full" C++ gets wider compiler support on > embedded platforms. That is no question of compiler support, as I understand it, but of verifiability and safety. A bit like Ravenscar, but -- of course -- not as highly integer (ahem ... :-). > There will simply be no motivation for using subsets. But there will -- see above. > Subsetting C++ would be beneficial in the sense similar to Ravenscar > or by extracting some core and using it with formal methods (sort of > "SPARK++"), but I doubt it will ever happen. It already did (and perhaps died) http://en.wikipedia.org/wiki/Embedded_C++ >>>> The trend I see, is that GC is a must, clumsy pointer handling is out >>>> and types are an option for those that can understand them. >>> Indeed, looks like everybody is going in that direction. >> And certainly. Why should advances in hardware only buy more spiffy >> GUIs and not something to ease the everyday pain for the everyday >> software developer :-). > > The interesting thing is that memory management is *said* to be > painful. C++ and Ada are similar in this regard - the majority of the > regular code don't need manual memory management (local objects!) or > can have it encapsulated (containers!), so there are no problems that > would need to be solved. I disagree. The only-downward-closures style of C++ and Ada, which allows only to mimic "upward closures" by using classes, heavily influences the way the programmer thinks. Higher level abstractions (as in functional languages) would require full closure -- and since this means that memory life time cannot bound to scope any more, this would be the point where manual memory management becomes painful. Furthermore I've been convinced that manual memory management hinders modularity. > Reference-oriented languages have completely > different ratio of "new per kLOC" so GC is not a feature there, it's a > must. I wonder, if it is really possible to do OO without being reference-oriented. I somewhat doubt it. > But then the question is not whether GC is better, but whether > reference-oriented languages are better than value-oriented ones. Many > people get seduced by GC before they even start asking such questions. Value-oriented in my world would be functional -- languages which all heavily rely on GC. I also admit being one of the seduced, but that is not surprising since my main focus is not in embedded programming and in everything else it's sheer folly not to have GC. The arguments against GC often read like arguments against virtual memory, against high level languages as opposed to assembler, against filesystems (yes there was a time when some people thought that the application would best do allocation of disc cylinders itself since it knows its access patterns better than the FS). Regards -- Markus