3 ms·

Oh boo hoo. Yes, C really sucks, but it exports a crummy and limited abstract machine which is fundamentally a PDP-11. The author might just as well complain,

by gumby 2y ago

Oh boo hoo. Yes, C really sucks, but it exports a crummy and limited abstract machine which is fundamentally a PDP-11. The author might just as well complain, in fact would better complain, that interfacing to machine code is painful. Just suck it up and put the OS interface (with the appropriate paradigms and affordances for your language) into your language’s standard runtime. That’s part of the work of writing a language. Whatever model you think should replace it will inevitably only be useful for some languages and as bad as a C interface (or worse) for others. The iAPX 432 was a notorious example — in hardware! Lispms, sadly, were another. It is irksome that some will consider C the “lowest common denominator”. It ain’t. It’s just a shitty, path-dependent valley in the possibility space. And as for shitty, well, I use the toilet every day, and it’s not the high point of my day, but it’s where we ended up (so far) as part of the mechanism by which we power our bodies and also get to enjoy yummies. No point I’m complaining about it, it simply is what it is.

bluetomcat 2y ago
> Just suck it up and put the OS interface into your language’s standard runtime. The OS interface is a huge and complex animal that provides crucial primitives for writing high-performing programs (async IO, memory management, timers, etc.). If you want your language to be practical for system-level programming, you need a 1:1 mapping between them. Crafting a runtime that abstracts those calls and presents a new world to the programmer adds another layer of complexity and will probably worsen the performance.
- gumby 2y ago
  > Crafting a runtime that abstracts those calls and presents a new world to the programmer adds another layer of complexity and will probably worsen the performance. But that’s what the article is calling for — claiming (correctly IMHO) that the C interface is pretty cruddy. Unfortunately whichever higher level interface you choose will be inappropriate for most languages that aren’t the implementation language. I didn’t mention the 432 by accident: its baked in “object-oriented” architecture turned out not only not to help but instead slowed down the whole processor for no gain. The only exception is when only one language is intended and there’s a tight coupling between silicon and that language (e.g. the lispm case).

by gumby 2y ago

bluetomcat 2y ago

> Just suck it up and put the OS interface into your language’s standard runtime. The OS interface is a huge and complex animal that provides crucial primitives for writing high-performing programs (async IO, memory management, timers, etc.). If you want your language to be practical for system-level programming, you need a 1:1 mapping between them. Crafting a runtime that abstracts those calls and presents a new world to the programmer adds another layer of complexity and will probably worsen the performance.

gumby 2y ago
> Crafting a runtime that abstracts those calls and presents a new world to the programmer adds another layer of complexity and will probably worsen the performance. But that’s what the article is calling for — claiming (correctly IMHO) that the C interface is pretty cruddy. Unfortunately whichever higher level interface you choose will be inappropriate for most languages that aren’t the implementation language. I didn’t mention the 432 by accident: its baked in “object-oriented” architecture turned out not only not to help but instead slowed down the whole processor for no gain. The only exception is when only one language is intended and there’s a tight coupling between silicon and that language (e.g. the lispm case).