5 ms·

How is it different? Why do you draw the line at I/O function?

matheusmoreira 5y ago
Because it doesn't really matter how the program calculates mathematical functions as long as the result is correct. Whether it's a function or an instruction, it's inconsequential. I/O on the other hand is a lot more interesting. They're a very common source of undefined behavior, bugs and interception via custom shared objects. I'd rather the compiler touched them as little as possible. Actually I'd rather not use them at all. I find system calls to be much more ergonomic.
- innocenat 5y ago
  What about datetime, random, system, etc?
  - matheusmoreira 5y ago
    They're all system calls that are better served by using operating functions directly. I'm not sure how the compiler could possibly optimize those away though. Maybe the random function could become a very untrustworthy instruction?
    - _kst_ 5y ago
      Random number generation generally isn't handled by system calls. It's just computation. (Some languages do provide support for hardware [pseudo-]random number generation. C doesn't.) More generally, using system calls directly for things like getting the current time makes sense only if you don't care about portability. C can support both portable and non-portable code. Both are important. I get the impression that C is too high-level, and assembly language is too tedious, to fully support your requirements. I sympathize with your situation, but it's not one that most programmers share.
      - matheusmoreira 5y ago
        > I get the impression that C is too high-level, and assembly language is too tedious, to fully support your requirements. Definitely seems that way to me as well. Still, if I bend C enough it turns into something that's almost what I want. I just wish GCC had a couple more flags to control code generation in these surprising cases.
- _kst_ 5y ago
  For me, it doesn't matter whether printf("hello\n") works via a call to printf or a call to puts. If those 6 characters I specified are written to standard output, I don't care how it was done. Of course I care if I want to use the value returned by printf, but if my code uses that value the optimization isn't performed. I think the semantic gap between assembly language and C is much wider than a lot of people realize. I wonder if a language somewhere in the middle of that gap would be useful to some people. (It probably wouldn't be useful to me.)

Because it doesn't really matter how the program calculates mathematical functions as long as the result is correct. Whether it's a function or an instruction, it's inconsequential. I/O on the other hand is a lot more interesting. They're a very common source of undefined behavior, bugs and interception via custom shared objects. I'd rather the compiler touched them as little as possible. Actually I'd rather not use them at all. I find system calls to be much more ergonomic.

innocenat 5y ago
What about datetime, random, system, etc?
- matheusmoreira 5y ago
  They're all system calls that are better served by using operating functions directly. I'm not sure how the compiler could possibly optimize those away though. Maybe the random function could become a very untrustworthy instruction?
  - _kst_ 5y ago
    Random number generation generally isn't handled by system calls. It's just computation. (Some languages do provide support for hardware [pseudo-]random number generation. C doesn't.) More generally, using system calls directly for things like getting the current time makes sense only if you don't care about portability. C can support both portable and non-portable code. Both are important. I get the impression that C is too high-level, and assembly language is too tedious, to fully support your requirements. I sympathize with your situation, but it's not one that most programmers share.
    - matheusmoreira 5y ago
      > I get the impression that C is too high-level, and assembly language is too tedious, to fully support your requirements. Definitely seems that way to me as well. Still, if I bend C enough it turns into something that's almost what I want. I just wish GCC had a couple more flags to control code generation in these surprising cases.
_kst_ 5y ago
For me, it doesn't matter whether printf("hello\n") works via a call to printf or a call to puts. If those 6 characters I specified are written to standard output, I don't care how it was done. Of course I care if I want to use the value returned by printf, but if my code uses that value the optimization isn't performed. I think the semantic gap between assembly language and C is much wider than a lot of people realize. I wonder if a language somewhere in the middle of that gap would be useful to some people. (It probably wouldn't be useful to me.)