From: cr88192@gmail.com   
      
   On 10/8/2025 8:59 AM, Janis Papanagnou wrote:   
   > On 08.10.2025 12:09, Bonita Montero wrote:   
   >> [...]   
   >>   
   >> C is really dangerous in that sense because you've to flip every bit   
   >> yourself. Better use abstactions you re-use a lot of times. In C there   
   >> almost no complex data strructures at all; like a vector in C++ or a   
   >> unordered map because it would be a large effort to  specialize your-   
   >> self that for every data type. Most C projects stick with simple data   
   >> structures which are less efficient. The "generic" types in C which   
   >> work work callbacks like with qsort() really suck since their perfor-   
   >> mance is better but still not optimal.   
   >> I think all developers who use C today are either forced to stick   
   >> with C though their job or are persons which think mostly on the   
   >> detail level and can't think in abstractions.   
   >   
   >> This is programming like in the beginning of the 90s.   
   >   
   > I disagree in the historic valuation; abstractions were known and   
   > used (and asked for) already [long] before. (Even your beloved C++   
   > came already a decade earlier, and its designer was influenced by   
   > even older abstraction concepts from the 1960's [Simula].)   
   >   
   > But there certainly always have been developers who stuck to older   
   > languages with less expressiveness in abstraction; obviously still   
   > today. About the (strange or also valid) reasons we can speculate.   
   > I would also speculate that many/most developers can not only think   
   > in abstractions but know (and can program in) other languages that   
   > provide abstraction concepts. (Or so I hope.)   
   >   
      
   While a higher level language might be nice sometimes...   
      C++ is kind of a trash fire.   
      
   Personally would rather have something more like a C/C# hybrid.   
      Or, sorta like C# but without the need for a garbage collector.   
      
   Also a language where one can get a usable implementation in a "sane"   
   level of effort. For C++, for a compiler written by an individual, it is   
   only really reasonable to get to a subset, like roughly early 90s C++   
   (with little/no chance of something like STL or Boost working).   
      
   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.   
      
      
      
   Granted, a few of my own language design attempts ended up with a   
   different mess:   
      T    foo;  //default / global lifespan for objects   
      T!   foo;  //automatic   
      T^   foo;  //reference counted   
      T(Z) foo;  //zoned   
      
   Where "T!" Local scope only, for certain patterns:   
      Foo! foo();  //local constructor   
      Foo  foo = new! Foo();  //basically the same.   
   Or, as a member, but may only be initialized in the constructor (else   
   'final').   
      
   Unlike the others, "T^" would need to be preserved in all uses of the   
   ref-counted object (converting to 'T' would lose the refcounting).   
      
   These could replace explicit new/delete with still needing to be careful   
   about how objects are used.   
      
      
   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).   
      
   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).   
      
   Zones can work OK, but depend some on being able to divide up the   
   program into discrete sections, at which point all memory in a given   
   category can be freed. Not all programs fit this pattern. Destroying a   
   zone can also be expensive (as it goes and frees all heap objects   
   associated with that zone).   
      
   ...   
      
      
   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.   
      
   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.   
      
      
   Where, the further one deviates from C, the more pain it is to move code   
   back and forth between languages.   
      
      
   But, a language resembling a C/C# hybrid could be close enough that the   
   pain isn't too unreasonable; and could sorta still resemble C++ as well;   
   but be a whole lot easier for writing the compiler.   
      
   Like, one can throw out the whole mess that is dealing with   
   Multiple-Inheritance and all of the tweaky and weird ways that class   
   instances can be structured (direct inheritance vs virtual inheritance,   
   friend classes, ... and all of the wacky effects these can have on   
   object layout).   
      
      
   Comparably, at least with Single-Inheritance and interfaces, class   
   layouts tend to be append-only. Interfaces are still special, but easier   
   to deal with (the interface can merely append its vtable pointer to the   
   end of the existing object).   
      
   so, say:   
      class Foo:IBaz1 {   
        public int x, y;   
      }   
      class Bar:Foo,IBaz2 {   
        public int z;   
      }   
      
   Might look like, for Bar, say:   
      Bar-VT   
      x   
      y   
      IBaz1-VT   
      z   
      IBaz2-VT   
      
   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).   
      
   ...   
      
      
      
   > Janis   
   >   
   >> But today's   
   >> machines are capable to handle more complex requirements and these   
   >> requirements need a more flexible language so that you can handle   
   >> that with less bugs than in a lanugage where you've to do every   
   >> detail by yourself.   
   >   
      
   One can also use JavaScript or Python, but there are reasons why these   
   are only used in some areas and not in others.   
      
      
   My compiler can also (more or less) natively compile JavaScript (and I   
   could maybe add a Python variant, if I really wanted).   
      
   A could in theory also revive a past dialect of my script language   
   (which kinda resembled ActionScript 3.0) and compile this natively.   
      
   But, there are reasons one would not want to write, say, kernel-level of   
   firmware level code, in JavaScript or Python.   
      
      
   Though, there are also cases where you would use a language like JS, and   
   C would make little sense.   
      
   Say, embedding blobs of C code into HTML would arguably have been a   
   worse option.   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)