XPost: alt.folklore.computers   
   From: cross@spitfire.i.gajendra.net   
      
   In article <10jjgju$5l5$3@dont-email.me>,   
   The Natural Philosopher   wrote:   
   >On 06/01/2026 16:12, Chris Ahlstrom wrote:   
   >> Waldek Hebisch wrote this post by blinking in Morse code:   
   >>   
   >>> In alt.folklore.computers c186282  wrote:   
   >>>    
   >>>>    Hmm ... look at all the GNU 'compilers' -   
   >>>>    FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,   
   >>>>    G++, even Algol-68. None are 'compilers'   
   >>>>    per-se, but to-'C' TRANSLATORS. So, 'C',   
   >>>>    pretty much All Are One And One Is All.   
   >>>   
   >>> No.  Compiler as first stage translate given language to a   
   >>> common representation.  This representatiton is different   
   >>> than C.  Ada and GNU Pascal have parametrized types, there   
   >>> is nothing like that in C.   
   >>>   
   >>>    
   >>>   
   >>> C++ (and some other languages)   
   >>> have exceptions, C do not have them.   
   >>   
   >> What about setjmp()/longjmp() ?   
   >   
   >Exactly. The problem with making high level 'features' in a language is   
   >people then don't see how they actually work.   
      
   What an odd take.   
      
   The point of programming is to write programs.  The point of   
   maintenance is to make sure those programs continue working over   
   time as technology and environments change.  C (and for that   
   matter Unix) were invented to make writing and maintaining   
   programs easier than the techniques that had been used up to   
   that point, not to elucidate the implementation.  This idea of   
   C as some kind of glorified "high-level" assembler hasn't been   
   true since we started to see optimizing compilers in the 1970s.   
      
   >One of the worst features of C libs is malloc() and free() where the   
   >underlying mechanism is opaque.   
      
   ...because it is utterly irrelevant to 99.99% of programs.   
      
   If you want to see how it works under the hood, go look up the   
   system interface.  But if done properly, that's independent of   
   the user application language.  Or, if you can, read the library   
   source if you want to see how `malloc` is implemented: this is   
   one of the benefits of open source software.   
      
   The claim that `malloc` is bad because it hides the details of   
   memory management is just silly.  stdio hides the details of   
   blocks, buffer caches, bus acceses, DMA, asynchronous descriptor   
   queues, IO devices and their access mechanisms, and so on, from   
   programmers.  Because, again, it's totally irrelevant for _most_   
   programs.  Is that similarly bad?   
      
   >auto allocation and garbage collection is even worse.   
   >   
   >Also operator overloading and weak  typing.   
   >   
   >You simply do not know where you are.   
      
   Most programmers don't know that stuff anyway.  Most have no   
   idea how their program is loaded into memory or starts running,   
   how the platform is initialized, the implementation of the sorts   
   of abstractions that the OS provides, and so on.   
      
   >It's all fearfully clever ins a smart alec sort of way but it makes for   
   >a lot of problems downstream...   
      
   Nonsense.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)