From: janis_papanagnou+ng@hotmail.com   
      
   On 08.10.2025 19:29, BGB wrote:   
   > On 10/8/2025 8:59 AM, Janis Papanagnou wrote:   
   >   
   > While a higher level language might be nice sometimes...   
   >   C++ is kind of a trash fire.   
      
   I'm not familiar with the meaning of the term "trash fire".   
   (If it's important to understand your post please explain.)   
      
   I can say a lot concerning C++; both, pros and cons. (But   
   not here and not now.)   
      
   > [...]   
   >   
   > Only real reason to deal with it is that some people around seem to   
   > think C++ is a good idea, and have used it to write software.   
      
   Well, I certainly don't think it's a bad idea; far from bad.   
      
   And back then, when I was seeking for a HLL with OO support,   
   and C++ became available - and even widely accepted - I was   
   quite grateful to be able to use it professionally.   
      
   >   
   > Granted, a few of my own language design attempts ended up with a   
   > different mess:  [...]   
      
   A sensibly defined language isn't something easily to create   
   or obtain! - Personally I'd have appreciated it more if more   
   designers of "own languages" have oriented their designs on   
   sensible existing and proven concepts. - There may be a   
   "market" for all these "own languages", I don't know, but I   
   also don't care much, given what I've seen or heard of yet.   
   (This isn't meant to be offensive, just to be clear, only   
   that I don't care much. As compiler writers don't care much   
   what I think.)   
      
   > [ attempt for a discussion on features of "own language"   
   >   snipped; not my business ]   
      
   > Full GC is undesirable because basically no one has managed to avoid the   
   > issue of timing and performance instabilities. Almost invariably,   
   > performance stutters at regular intervals, or the program periodically   
   > stalls (and at least over the past 30 years, it seems no one has   
   > entirely avoided this issue).   
      
   Well, some languages have no GC at all. Others even support   
   a couple of functions to control GC on various levels. It   
   may be triggered manually (on items, classes, or ranges),   
   or automatically (on demand, or depending on conditions; it   
   may depend on memory, time, heuristics, statistical behavior).   
      
   Pick your language depending on your projects demands.   
      
   >   
   > Refcounting is also bad for performance, but typically the timing issues   
   > from refcounting is orders of magnitude smaller (and mostly cases where   
   > some large linked list or similar has its refcount drop to 0 and is   
   > freed, which in turn results in walking and freeing every member of the   
   > list).   
      
   Tailor your application and language choice on the projects'   
   requirements.   
      
   > [...]   
   >   
   > Still, not really anything that fully replaces C though.   
   > One merit of C being, that it is C, and so all existing C code works in it.   
      
   (On a larger time scale that seems not to match my observation.   
   But okay, never mind.)   
      
   >   
   > Both C++ and other extended C dialects can have the advantage of being   
   > backwards compatible with existing C code (though for C++, "only   
   > sorta"); but the drawback of also being "crap piled onto C", inherently   
   > more messy and crufty than a "clean" language could have been.   
      
   Are you talking here about the relation of "C" with C++?   
      
   I certainly agree to what a "clean language" can be.   
      
   My opinion on that is, though, that the "C" base of C++ is part of   
   the problem. Which doesn't let it appear to me "C" to be "better"   
   than C++, but that the "C" base is part of C++'s problem. (Here   
   I'm not speaking about "C++"'s own problems that probably entered   
   about with C++0x/C++11, IMO. - Mileages certainly vary.)   
      
   > [...]   
   >   
   > Like, one can throw out the whole mess that is dealing with   
   > Multiple-Inheritance   
      
   Well, when I started with C++ there wasn't multiple-inheritance   
   available. Personally thinking its omission would be a mistake;   
   I missed it back these day.   
      
   I'm not sure what "mess" you have in mind. - Explicit qualification   
   isn't a hindrance. Weakening the independence of classes in complex   
   multi-level class-topologies is something under control of the   
   program designer. - So it's fine to have it with all design options   
   it opens.   
      
   > and all of the tweaky and weird ways that class   
   > instances can be structured (direct inheritance vs virtual inheritance,   
      
   I'm not sure what you are thinking here. - It's a notation to avoid   
   duplicate inclusions across "converging hierarchies".   
      
   > friend classes, ... and all of the wacky effects these can have on   
   > object layout).   
      
   Well, back then I wasn't a "friend" of the 'friend' feature. But it   
   also didn't stress me in any way. (The only aspect I was concerned   
   about a bit here was the uncontrolled access to class details; yet   
   it's under the programmer's control.)   
      
   >   
   > Comparably, at least with Single-Inheritance and interfaces, [...]   
      
   This insight came later. (Was it Java that served as paragon? I only   
   seem to recall that the GNU compiler suite supported C++ 'interfaces'   
   at some time; was it the late 1990's ?)   
      
   > [...]   
   >   
   > Also, it simplifies things if class instances are always by reference   
   > and never by value. So, structs retain the by value use-case, with   
   > structs being disallowed from having interfaces or virtual methods or   
   > supporting inheritance (which can be the exclusive domain of class   
   > objects).   
      
   Well, I can only say that it was nice to use objects ("instances")   
   in an orthogonal way like other [primitive, built-in] object entities.   
      
   (I knew the concept of "ref-only" [for class objects] from Simula.   
   But this distinction was something I never considered a nice concept.)   
      
   Janis   
      
   [...]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)