From: cr88192@gmail.com   
      
   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:   
   >>   
   >> 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.)   
   >   
      
   https://en.wiktionary.org/wiki/trash_fire   
      
      
   >> [...]   
   >>   
   >> 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.   
   >   
      
   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).   
      
   By the time I switched mostly to MSVC on Windows, I kept running into   
   other issues that made C++ a less desirable option (such as being harder   
   to process with automated tools, being harder to do any sort of FFI   
   generation, etc).   
      
   Or, later, that going much beyond a limited subset (like EC++ but with   
   namespaces and similar re-added) is a problem (and that pretty much no   
   real C++ code works with an EC++ style subset).   
      
      
      
   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.   
      
   And, the main "powerful" tool of C++, templates, tending to do bad   
   things to build times and result in excessive code bloat.   
      
      
   And, if one tries to avoid C++'s drawbacks, the result was mostly code   
   that still looks mostly like C.   
      
   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.   
      
      
      
   The only real exception I have found to this rule basically being in   
   relation to some features I have borrowed from languages like GLSL and   
   Verilog. But, some of this stuff isn't so much making the language   
   "higher level" as much as "being easier to map to ISA features and   
   optimize".   
      
   Say:   
      vd[62:52]=vs[20:10];   
   Being easier to optimize than, say:   
      vd=(vd&(~(2047ULL<<52)))|(((vs>>10)&2047ULL)<<52);   
      
   Though, Verilog itself, not so much... Works well in an ASIC or FPGA,   
   not so much on a CPU.   
      
   Though, as can be noted:   
      Bit-ranges are required to be constant at compile time;   
      When used with normal integer types, both bounds are required.   
      
      
   OTOH, GLSL offers nice and efficient ways to deal with SIMD.   
   Well, and also having some types for bit-preserving casts.   
   Or ability to specify endianess and alignment for individual struct members.   
   ...   
      
      
   >>   
   >> 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.)   
   >   
      
   Yeah.   
      
   They have either tended to not amount to much, or converged towards more   
   conventional languages.   
      
      
      
   >> [ 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.   
   >   
      
   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.   
      
   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...   
      
   Though, in some contexts, ref-counting may still be too big of an ask.   
      
      
      
   Typically, one may also need to deal with things like a hardware memory   
   map or possibly dealing with manual translation between multiple address   
   spaces via page-table walking, etc.   
      
   So, language design should not preclude this stuff.   
      
      
   Some features are useful in some contexts but not others:   
   For example, "__int128" is very helpful when writing FPU-emulation code   
   for Binary128 handling, but has a lot fewer use-cases much beyond this.   
      
   Or, like:   
      exp=vala[126:112];  //extract exponent   
      fra=(_BitInt(128)) { 0x0001i16, vala[111:0]};  //extract fraction   
   ...   
      
   But, then it becomes a drawback if one needs #ifdef's to deal with more   
   normal C compilers.   
      
      
      
   >> [...]   
   >>   
   >> 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.   
   >   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)