14 ms·

One of my favorite jokes on HN was in a typical language wars thread where a guy wrote "real men write in C....without the standard library." That still makes m

One of my favorite jokes on HN was in a typical language wars thread where a guy wrote "real men write in C....without the standard library." That still makes me laugh.

deleted 10y ago
[deleted]
LionessLover 10y ago
Happens every day when writing code for small embedded systems. :-)
- duozerk 10y ago
  To be fair, there is often some sort of limited version of the std lib available even for those (for example by the MCU manufacturer).
  - LionessLover 10y ago
    "Availability" doesn't mean much. There are plenty of all kinds of libs available on all platforms (who wants to program WiFi access for the embedded sensor from scratch, for example?). Doesn't mean it makes sense to put any of them into the current project. The stdlib is one of many and not that often the one that is put in. The libs I use on my embedded system are much more likely to be for some specific piece of sensor or I/O device (like the mentioned WiFi module), I rarely have need for what's in the stdlib. Of course, embedded systems vary far more than the PC and server stuff so you can easily find people who will say the exact opposite.
    - jotux 10y ago
      >I rarely have need for what's in the stdlib It has been my experience that people who don't know or use the C stdlib end up unknowingly re-implementing stdlib functions over and over again.
  - marssaxman 10y ago
    A freestanding C implementation doesn't have to include anything but a handful of headers with some macro and type definitions. It's not uncommon to get a manufacturer-specific library whose features are specific to the particular controller architecture, not related to those defined in the full C library. And it's not uncommon for embedded software developers to ignore those libraries, which are frequently terrible, and write everything from scratch.
ndesaulniers 10y ago
Sounds like writing kernel code.
- vardump 10y ago
  Well, except that in kernel you often can't use even many CPU features either in practice. At least if you use SSE2/FP/etc., you better ensure those FPU registers are saved and restored. But probably you don't want to do that in a IRQ handler! Save only SSE2 registers on an AVX system (higher 128 bits will be zeroed for currently executing usermode thread!) and receive "interesting" bug reports from the end users. If you refer to a vm page that's not present... well, bad things might happen. Etc.
TickleSteve 10y ago
Bare metal C code is what is running on 99.9% of the embedded devices surrounding you right now...
- vardump 10y ago
  Scary thought. I'd feel more at ease if it was Rust (or something analogous). Just disassemble/decompile some random firmware code... you wouldn't believe what one can find from those piles of err... binary dump.
  - TickleSteve 10y ago
    There is a lot of scaremongery around C.... don't believe it. If you know what you're doing (and you should) then C is the best tool for the job.
    - Profan 10y ago
      Best tool is a stretch, it's a tool. If we can get tools like Rust which have better memory safety guarantees while offering much of the same performance, then hell, why not? It's easy to see why just by looking at the hundreds of CVE's throughout the years, often caused by memory unsafe operations. Not that I don't like C, but there's many better alternatives out there. And this is coming from someone who stubbornly sticks to writing D in C-style, but knows what Rust brings to the table.
      - TickleSteve 10y ago
        OK, I'm biased as I've got over 20 years in embedded/real-time systems primarily written in C (and C++) and am currently architect for an embedded system containing ~million lines of code and rolling out to tens of millions of units.... (But I'm educated enough to also use Python, Clojure, C# and a variety of other systems). ...and C is currently the best choice for systems like this because of reasons not primarily to do with the language. Currently, if you suggest to use a language other than C you will be laughed out because the only available embedded guys are C based. Yes, momentum counts and C has massive momentum. There are also issues such as toolchains and tooling, familiarity, community, and of course the massive existing set of libraries, codebases and knowledge. Basically, C is 'good enough'. (although Rust is interesting and on the horizon, its a long way off yet). Although technically a better language, C's shortcomings are greatly exaggerated, for example memory management. In general this is not an issue in bare metal embedded systems as you don't have a heap, everything is statically allocated by design. There are many flaws in the C language (as in every language), but in day-to-day use, they are very easy to manage. So... don't believe the (bad) hype.
andrewmcwatters 10y ago
This is surprisingly easy, though! Funny, nonetheless.
rat87 10y ago
Obligatory link to the Story of Mel: http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html
- andreapaiola 10y ago
  Ah! I've thought instead to MEL (ancient Maya scripting language)
- andreapaiola 10y ago
  Maya the 3D software, not the people
cperciva 10y ago
As a FreeBSD developer, I have to disagree. Real men write the standard library.

One of my favorite jokes on HN was in a typical language wars thread where a guy wrote "real men write in C....without the standard library." That still makes me laugh.

deleted 10y ago

[deleted]

LionessLover 10y ago

Happens every day when writing code for small embedded systems. :-)

duozerk 10y ago
To be fair, there is often some sort of limited version of the std lib available even for those (for example by the MCU manufacturer).
- LionessLover 10y ago
  "Availability" doesn't mean much. There are plenty of all kinds of libs available on all platforms (who wants to program WiFi access for the embedded sensor from scratch, for example?). Doesn't mean it makes sense to put any of them into the current project. The stdlib is one of many and not that often the one that is put in. The libs I use on my embedded system are much more likely to be for some specific piece of sensor or I/O device (like the mentioned WiFi module), I rarely have need for what's in the stdlib. Of course, embedded systems vary far more than the PC and server stuff so you can easily find people who will say the exact opposite.
  - jotux 10y ago
    >I rarely have need for what's in the stdlib It has been my experience that people who don't know or use the C stdlib end up unknowingly re-implementing stdlib functions over and over again.
- marssaxman 10y ago
  A freestanding C implementation doesn't have to include anything but a handful of headers with some macro and type definitions. It's not uncommon to get a manufacturer-specific library whose features are specific to the particular controller architecture, not related to those defined in the full C library. And it's not uncommon for embedded software developers to ignore those libraries, which are frequently terrible, and write everything from scratch.

ndesaulniers 10y ago

Sounds like writing kernel code.

vardump 10y ago
Well, except that in kernel you often can't use even many CPU features either in practice. At least if you use SSE2/FP/etc., you better ensure those FPU registers are saved and restored. But probably you don't want to do that in a IRQ handler! Save only SSE2 registers on an AVX system (higher 128 bits will be zeroed for currently executing usermode thread!) and receive "interesting" bug reports from the end users. If you refer to a vm page that's not present... well, bad things might happen. Etc.

TickleSteve 10y ago

Bare metal C code is what is running on 99.9% of the embedded devices surrounding you right now...

vardump 10y ago
Scary thought. I'd feel more at ease if it was Rust (or something analogous). Just disassemble/decompile some random firmware code... you wouldn't believe what one can find from those piles of err... binary dump.
- TickleSteve 10y ago
  There is a lot of scaremongery around C.... don't believe it. If you know what you're doing (and you should) then C is the best tool for the job.
  - Profan 10y ago
    Best tool is a stretch, it's a tool. If we can get tools like Rust which have better memory safety guarantees while offering much of the same performance, then hell, why not? It's easy to see why just by looking at the hundreds of CVE's throughout the years, often caused by memory unsafe operations. Not that I don't like C, but there's many better alternatives out there. And this is coming from someone who stubbornly sticks to writing D in C-style, but knows what Rust brings to the table.
    - TickleSteve 10y ago
      OK, I'm biased as I've got over 20 years in embedded/real-time systems primarily written in C (and C++) and am currently architect for an embedded system containing ~million lines of code and rolling out to tens of millions of units.... (But I'm educated enough to also use Python, Clojure, C# and a variety of other systems). ...and C is currently the best choice for systems like this because of reasons not primarily to do with the language. Currently, if you suggest to use a language other than C you will be laughed out because the only available embedded guys are C based. Yes, momentum counts and C has massive momentum. There are also issues such as toolchains and tooling, familiarity, community, and of course the massive existing set of libraries, codebases and knowledge. Basically, C is 'good enough'. (although Rust is interesting and on the horizon, its a long way off yet). Although technically a better language, C's shortcomings are greatly exaggerated, for example memory management. In general this is not an issue in bare metal embedded systems as you don't have a heap, everything is statically allocated by design. There are many flaws in the C language (as in every language), but in day-to-day use, they are very easy to manage. So... don't believe the (bad) hype.

andrewmcwatters 10y ago

This is surprisingly easy, though! Funny, nonetheless.

rat87 10y ago

Obligatory link to the Story of Mel: http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html

andreapaiola 10y ago
Ah! I've thought instead to MEL (ancient Maya scripting language)
andreapaiola 10y ago
Maya the 3D software, not the people

cperciva 10y ago

As a FreeBSD developer, I have to disagree. Real men write the standard library.