From: janis_papanagnou+ng@hotmail.com   
      
   (Sorry for the delayed reply; your ~450 lines post was too long for   
   me to consider a timely reply.)   
      
   On 09.10.2025 05:49, BGB wrote:   
   > On 10/8/2025 2:04 PM, Janis Papanagnou wrote:   
   >> On 08.10.2025 19:29, BGB wrote:   
   >>> On 10/8/2025 8:59 AM, Janis Papanagnou wrote:   
      
   >   
   > Throughout much of my life, C++ has been around, but using it has often   
   > turned into a footgun. Early on the code had a bad habit of breaking   
   > from one compiler version to another, or the ability to compile C++ code   
   > in general would be broken (primarily with Cygwin and MinGW; where   
   > whether or not "g++" worked on a given install attempt, or with a given   
   > program, was very hit or miss).   
      
   I used it early on on various Unix platforms; all had some details   
   different - like the way how templates worked in the development   
   environment - but nothing was really an issue; as with current   
   configuration settings this was covered and handled by the build   
   system.   
      
   It doesn't astonish me the least if you've faced specific problems   
   on the Windows platforms.   
      
   > [...]   
   >   
   > In most cases, it left C as a more preferable option.   
   > C can be made to do the same stuff at similar performance, with often   
   > only minimal difference in expressive power.   
      
   The problem is, IMO, rather that "C", in the first place, doesn't   
   compare to C++ in its level of "expressive power".   
      
   >   
   > And, the main "powerful" tool of C++, templates,   
      
   (IMO, the main powerful tool was primarily classes, polymorphisms,   
   also [real] references.)   
      
   > tending to do bad   
   > things to build times and result in excessive code bloat.   
      
   I recall that initially we had issues with code bloat, but I don't   
   recall that it would have been a problem; we handled that (but,   
   after that long time, don't ask me how).   
      
   >   
   > And, if one tries to avoid C++'s drawbacks, the result was mostly code   
   > that still looks mostly like C.   
      
   (That sounds as if you haven't used OO designs, reference parameters,   
   overloading, and so on, obviously.)   
      
   >   
   > Though, similar was often a problem in my other language design   
   > attempts: The most efficient way to do things was often also the C way.   
      
   IME, *writing* software in "C" requires much more time than in C++;   
   presuming you meant that with "most efficient way to do things".   
      
   (Saving a few seconds in "C" compared to C++ programs can hardly be   
   relevant, I'd say; unless you were not really familiar with C++ ?   
   Or have special application areas, as I read below in the post.)   
      
   > [...]   
   >   
   > Some amount of my stuff recently has involved various niche stuff.   
   >   Interfacing with hardware;   
   >   Motor controls;   
   >   Implementing things like an OpenGL back-end or similar;   
   >   Being used for a Boot ROM and OS kernel;   
   >   Sometimes neural nets.   
      
   "Nice. - I've done Neural Net simulations with C++ back these days.)   
      
   >   
   > Few traditional languages other than C work well at a lot of this.   
   >   
   >   
   > A usual argued weakness of C is that it requires manual memory   
   > management. But, OTOH, you *really* don't want a GC in motor controls or   
   > an OS kernel or similar.   
   >   
   > Like, if the GC triggers, and an interrupt handler happens at a bad   
   > time, then you have a problem.   
   >   
   > Or, if you have a 1us timing tolerance for motor controls and this gets   
   > blown because the GC takes 75ms, etc...   
      
   Sure, you should know where to use static memory, dynamic management   
   organized yourself, or "I-don't-want-to-care" and use GC management,   
   or a sensible deliberate mixture of that (if the language allows).   
      
   (I've never used GC with C++; is that meanwhile possible?)   
      
   > [...]   
   >   
   > Maybe C will be around indefinitely for all I know.   
      
   Not unlikely.   
      
   >   
   > Like, the passage of time still hasn't totally eliminated FORTRAN and   
   > COBOL.   
      
   There's obviously some demand. *shrug* - I don't care much. - My last   
   "contact" with FORTRAN was when one of my children was asked to handle   
   some legacy library code; my suggestion was to get rid of that task.   
      
   > And, C is far more commonly used than either.   
   >   
   > Unless maybe something can come along that is a better C than C...   
      
   There's so many languages meanwhile - frankly, there were already a   
   lot back then, four decades ago! - so I don't think the proliferation   
   will stop; I don't think that evolution is a good thing. It seems that   
   often the inventors have their own agenda and the success of languages   
   depends mainly on the marketing efforts and the number of fan-people   
   that got triggered by newly invented buzzwords, and an own invented   
   terminology [for already existing old concepts]!   
      
   > [...]   
   >   
   >> 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.)   
   >>   
   >   
   > Possibly.   
   >   
   >   
   > A new C-like language need not necessarily be strictly C based.   
      
   (There's a couple things I like in "C". But if I'd have to invent a   
   language it would certainly not be "C-like". I'd took a higher-level   
   [better designed] language as paragon and support the "C" features I   
   like, if not already present in that language.)   
      
   >   
   > My thinking would be likely keeping a similar basic syntax though,   
   > though likely more syntactically similar to C#,   
      
   (But the syntax is one of C's and descendants' problem, IMO. - Part   
   of what was described in existing "C-like" languages is either the   
   less-desired elements or deviations, but the latter will probably   
   just add to confusion if details are subtle. It's already bad enough   
   with subtle differences between different "C" standards it seems.)   
      
   > but retaining more in   
   > terms of implementation with C and C++.   
      
   (But weren't exactly these languages already [partly] invented with   
   such an agenda?)   
      
   >   
   > Would likely simplify or eliminate some infrequently used features in C.   
   >   
   > Possibly:   
   >   Preprocessor, still exists, but its role is reduced.   
   >     Its role can be partly replaced by compiler metadata.   
   >   Trigraphs and digraphs: Gone;   
   >   K&R style declarations, also gone;   
   >   Parser should not depend on previous declarations;   
   >   Non trivial types and declarator syntax: Eliminate;   
   >   ...   
      
   Sounds all reasonable to me.   
      
   >   
   > Possibly:   
   > Pointers and arrays can be specified on the type rather than declarator   
   > (so, more like C# here)   
      
   (Yeah, but mind the comments on effects of "subtle differences".)   
      
   > [...]   
   >   
   > Though, the harder problem here isn't necessarily that of designing or   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)