XPost: alt.folklore.computers   
   From: invalid@invalid.invalid   
      
   John Ames  writes:   
   > Peter Flass  wrote:   
   >> Actually, many systems programming languages have no I/O, the idea   
   >> being that non-OS programs call the OS to do the I/O, and the OS   
   >> interacts directly with the hardware.   
   >   
   > "Systems programming" usually implies implementation of an OS, though,   
   > and IIRC that was the sense that Kernighan was using. You can't excuse   
   > limitations by "oh, the OS handles that" when your program *is* the OS.*   
   >   
   > * (Obviously, there's a certain point in any HLL where Deep Magic has   
   >   to handle interfacing between language constructs and bare metal, but   
   >   the higher up the "threshold of minimum abstraction" is, the less   
   >   suitable it is for systems programming in the first place.   
   >   
   >   Of course, there's also the problem where seemingly *any* language   
   >   that's not designed for systems programming will ultimately get   
   >   pressed into service for systems programming  *somewhere...*)   
      
   Also, the “call the OS” part of userland programs has to be represented   
   somehow in whatever language they are written in. C made that partially   
   independent of the underlying OS in the sense that the stdio.h functions   
   work much the same on a range of platforms (but it does make some   
   assumptions about the OS’s underlying IO model). As well as improving   
   portability, it means a bit less re-learning for programmers as we   
   migrate around platforms.   
      
   --   
   https://www.greenend.org.uk/rjk/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)