5 ms·

>Basically, a "non-DSP, non-mainframe" version of C I feel like if you start going down that road, towards “commonly portable”, you naturally end up with one o

by setr 8y ago

>Basically, a "non-DSP, non-mainframe" version of C I feel like if you start going down that road, towards “commonly portable”, you naturally end up with one of the not-c variants (zig, nim, etc). ...and ifc, if you start writing a new language, you might as well toss in features from the last thirty years of language design. C is C largely because its so stupidly (and impressively) portable; if you aren’t drawing that benefit, its likely a case of the wrong tool for the job.

hamiltonkibbe 8y ago
I think in a lot of cases it’s the only tool for the job. I have a hunch that a significant majority of the machine instructions executed in a given second globally came from C source code, and a large portion of that is running on something “weird”. It’s somewhat funny, “commonly portable” C is portable across the most uncommon C execution environments.
- adamson 8y ago
  psst, your personal website is returning a 502
  - hamiltonkibbe 8y ago
    Thanks for the heads up!
carlmr 8y ago
>C is C largely because its so stupidly (and impressively) portable; if you aren’t drawing that benefit, its likely a case of the wrong tool for the job. I'm working in medium sized embedded systems (not embedded Linux, but also not the smallest embedded systems). I've only rarerly worked on 8 or even 16bit Microcontrollers. Most of what I work on is 8bit chars, 32bit, Little Endian normal Microcontrollers. I really don't need the portability, the targets are all the same, however they only have C/C++ compilers. And we can't use GC. Rust would be a very nice choice at least for the application code. I'm not sure how to write low level drivers in Rust, but with FFI I would just push that to the boundaries, and make at least 90% of the applications Rust. But there's no LLVM backend for most embedded processors I work with, and even if there is, the maturity might not be there, and no company would switch to that considering that the next target might not have a backend. We have to use C, because it's the only thing that we are offered. But for desktop applications I see no real reason to start something in C nowadays.
- pjmlp 8y ago
  Some microcontrollers do enjoy Basic and Pascal compilers as alternatives to C. https://www.mikroe.com/compilers https://www.mikroe.com/compilers But as you say, the company needs to give the option to developers.
int_19h 8y ago
The point is that we already have millions of lines of code written in this less-portable C dialect, and probably thousands more are written every year. So no, it's not the same as a new language (for which all that code would need to be rewritten).

by setr 8y ago

hamiltonkibbe 8y ago

I think in a lot of cases it’s the only tool for the job. I have a hunch that a significant majority of the machine instructions executed in a given second globally came from C source code, and a large portion of that is running on something “weird”. It’s somewhat funny, “commonly portable” C is portable across the most uncommon C execution environments.

adamson 8y ago
psst, your personal website is returning a 502
- hamiltonkibbe 8y ago
  Thanks for the heads up!

carlmr 8y ago

>C is C largely because its so stupidly (and impressively) portable; if you aren’t drawing that benefit, its likely a case of the wrong tool for the job. I'm working in medium sized embedded systems (not embedded Linux, but also not the smallest embedded systems). I've only rarerly worked on 8 or even 16bit Microcontrollers. Most of what I work on is 8bit chars, 32bit, Little Endian normal Microcontrollers. I really don't need the portability, the targets are all the same, however they only have C/C++ compilers. And we can't use GC. Rust would be a very nice choice at least for the application code. I'm not sure how to write low level drivers in Rust, but with FFI I would just push that to the boundaries, and make at least 90% of the applications Rust. But there's no LLVM backend for most embedded processors I work with, and even if there is, the maturity might not be there, and no company would switch to that considering that the next target might not have a backend. We have to use C, because it's the only thing that we are offered. But for desktop applications I see no real reason to start something in C nowadays.

pjmlp 8y ago
Some microcontrollers do enjoy Basic and Pascal compilers as alternatives to C. https://www.mikroe.com/compilers https://www.mikroe.com/compilers But as you say, the company needs to give the option to developers.

int_19h 8y ago

The point is that we already have millions of lines of code written in this less-portable C dialect, and probably thousands more are written every year. So no, it's not the same as a new language (for which all that code would need to be rewritten).