From: janis_papanagnou+ng@hotmail.com   
      
   On 15.10.2025 03:13, BGB wrote:   
   > On 10/13/2025 11:29 PM, Janis Papanagnou wrote:   
   >> (Sorry for the delayed reply; your ~450 lines post was too long for   
   >> me to consider a timely reply.)   
      
   (Now ~800 lines; it escalates.)   
      
   >>   
   >> 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:   
      
   > [...]   
   >   
   > Well, and for a given Cygwin install attempt, whether or not "g++" would   
   > work, etc, was a bit like playing roulette.   
      
   I didn't "like" Cygwin, but also never had any "roulette" experience.   
      
   >   
   >>> [...]   
   >>>   
   >>> 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".   
   >   
   > ?...   
   >   
   > I have yet to find much that can be expressed in C++ but is not also   
   > expressible in C.   
      
   You may adhere to another sort of expressiveness than I. (For me   
   assembler, for example, is not more expressive than "C".) It's all   
   about expressing "complex" things in easy ways.   
      
   > The main things that are fundamentally different, are things like   
   > Exceptions and RTTI, but even in C++, these don't come free.   
      
   Back then they said that exceptions come for "almost free" (or so);   
   I've never counted the seconds difference, since our project goals   
   and priorities were lying on other factors.   
      
   RTTI, OTOH, I rarely used in the first place. Part of it was due to   
   my design principle to avoid casts; here (WRT RTTI), dynamic casts.   
   This features wasn't often used in our projects.   
      
   > Though, if exceptions are implemented using an approach similar to VEH   
   > in the Windows X64 ABI, it is at least modest.   
   >   
   >   
   >>>   
   >>> And, the main "powerful" tool of C++, templates,   
   >>   
   >> (IMO, the main powerful tool was primarily classes, polymorphisms,   
   >> also [real] references.)   
   >   
   > These can be done in C via manually written vtables, and passing the   
   > address of a variable.   
      
   (Yes, and you can also do it in assembler. - But that's not the point   
   of using higher level structuring features. - Frankly, I'm so stumped   
   that you wrote such a strange thing that I suppose it makes no sense   
   to discuss that point further with you; our views, it seems, are here   
   so fundamentally different, obviously.)   
      
   > [...]   
   >   
   > We can do OO, just using a different approach, say:   
   > [...]   
      
   *shudder*   
      
   > It all works, and doesn't require significantly more LOC than it would   
   > have in 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.   
   >>   
   >> 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.)   
   >>   
   >   
   > Main limiting factor at present is that it is a harder issue to write a   
   > non-trivial C++ compiler.   
   >   
   > I could write C++ code, but then it isn't really portable outside   
   > running on my PC or similar.   
      
   (We've used it in professional contexts on various platforms for   
   different customers without problem. - I cannot comment on your   
   opinion or experiences.)   
      
   > [ snip "own compiler", speed and other topics ]   
      
   >>>   
   >>> 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.   
   >   
   > In my case, I don't have any descendants.   
   >   
   > Apparently they still exist in some places, mostly as languages that no   
   > one uses.   
      
   (In scientific areas FORTRAN is obviously still widely used. And   
   this is no "[geographically] local phenomenon" as I learned.)   
      
   > [...]   
      
   >> [...]   
   >   
   > Apparently the languages people are trying to push as C replacements are   
   > mostly Rust, Zig, and Go.   
      
   I've heard so. (But don't care much.)   
      
   >   
   > None of these particularly compel me though.   
   >   They seem more like needless deviations from C than a true successor.   
   >   
   > I guess the older generations mostly had Pascal and Ada.   
      
   Not sure what you are thinking here.   
      
   While I knew of Pascal programs used even in professional projects   
   (like in a nuclear reprocessing plant) but it never appeared to me   
   that it is well usable for larger real world programs; at least in   
   its standardized form back then; Pascal successors addressed these   
   shortcomings to some degree, though. And Ada is (I think still) used   
   in avionics, spacetravel, and some military areas. (Myself [an older   
   generation] I had never programmed in Ada, or "professionally" in   
   Pascal.)   
      
   > [...]   
   >   
   >>> [...]   
   >>>   
   >>> 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.)   
   >>   
   >   
   > [ ruminations about such new language snipped ]   
      
   >   
   >>> but retaining more in   
   >>> terms of implementation with C and C++.   
   >>   
   >> (But weren't exactly these languages already [partly] invented with   
   >> such an agenda?)   
   >   
   > [...]   
   >   
   > I am imagining something that basically does similar stuff to what C   
   > already does, and can ideally be used in a similar context.   
   >   
   > The main downsides is that C and C++ are more complicated than ideal in   
   > many areas. This has a detrimental effect on compilers.   
   >   
   > Not so much intending to make a language that tries to be more intuitive   
   > or hand-holding though. However, if it is possible to make provisions   
   > for things like static-analysis or bounds-checked arrays (in a way that   
   > ideally doesn't adversely effect performance), this can be nice.   
      
   I see.   
      
   > [...]   
   >   
   >>> [...]   
   >>>   
   >>> Java and C# had made 'char' 16-bit, but I now suspect this may have been   
   >>> a mistake. It may be preferable instead keep 'char' as 8 bits and make   
   >>> UTF-8 the default string format. In the vast majority of cases, strings   
   >>> hold primarily or entirely ASCII characters.   
   >>   
   >> I think we should be careful here! An Unicode "character" may require   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)