3 ms·

i'm a C programmer, not for any great love of the syntax, but because i cross-compile for embedded hardware with limited resources and there aren't a lot of opt

i'm a C programmer, not for any great love of the syntax, but because i cross-compile for embedded hardware with limited resources and there aren't a lot of options. there are also other use cases for C. since it is close to the metal, it is a good fit for security-sensitive, heavily-audited codebases, because there are fewer layers of abstraction to audit and a smaller attack surface. manual memory management makes it a good fit for performance-sensitive applications, real-time encoding, signal processing, etc., because a garbage collector isn't competing for CPU time. there's a lot of overlap between all these use-cases, though, and most of it comes down to the fact that C: * is compiled, * has manual memory management, * is a relatively small language with a relatively small standard library, * (and of course, we can't ignore the network effect) is ubiquitous. so, when i see a document to introduce me to a new language, and it claims to be written for C developers, the first thing i am going to look for is some information about the language so that i can judge whether it is even remotely suitable for the contexts in which i would normally write in C. i read "foreword", "introduction", "culture shock", and "running a j program", looking to answer some questions like: is it compiled or interpreted? if interpreted, how complex is the interpreter? if compiled, does the compiler use LLVM or some other intermediate AST? is it garbage collected? can the garbage collector be turned off? how does performance compare? the only passage that tried to answer "why should i bother?" is a couple of sentences in the foreword: > To begin with, for the productivity. J programs are usually a fifth to a tenth as long as corresponding C programs, and along with that economy of expression comes coding speed. Next, for the programming environment: J is an interpreted language, so your programs will never crash, you can modify code while it's running, you don't have to deal with makefiles and linking, and you can test your code simply by entering it at the keyboard and seeing what it does. all of that is true of python too, but that doesn't mean python can do what i do with C.

yiyus 6y ago
I think you are misunderstanding the intention of the book. When you see a book titled "Japanese for English speakers", what it means is that it builds on your knowledge of English to teach you Japanese, not that its goal is that you replace your usage of English with Japanese. Certainly, the book will not include a justification of how you can use Japanese to speak in London and New York as you can do with English, and probably it won't even bother explaining you why learning Japanese may be a good idea. And, yes, you probably could learn Chinese instead, but that is not the point.
bgorman 6y ago
> it is a good fit for security-sensitive, heavily-audited codebases, because there are fewer layers of abstraction to audit and a smaller attack surface. C is a language that has a reason for existing. However C exposes programs to categories of errors that are not even possible to represent in other languages. In my opinion security code should be as error proof as possible, and C is definitely not a good language to accomplish that goal in. (I used to be a professional C programmer)
- woodrowbarlow 6y ago
  security code should be as _provably_ error-free as possible. C's strength in this regard is not due to any syntactical strengths, but due to how few layers exist between the code and the hardware. it's not the only option, maybe there are even some better options these days from a purely technical standpoint, but C is used in heavily-audited security-sensitive applications despite its syntactical/design shortcomings because it keeps you close to the metal.
  - avmich 6y ago
    > C's strength in this regard is not due to any syntactical strengths, but due to how few layers exist between the code and the hardware. Any language compiling into native code has this advantage. You perhaps meant that in C the programmer actually codes closely to how it's going to look like in native code. That could be an advantage; but for that C brings disadvantages, which come from one actually having to code like this - there is no other way. The question what's more important - language constructs which are closer to actual hardware or language abstractions which prevent certain bugs from appearing - isn't that clear.

yiyus 6y ago

I think you are misunderstanding the intention of the book. When you see a book titled "Japanese for English speakers", what it means is that it builds on your knowledge of English to teach you Japanese, not that its goal is that you replace your usage of English with Japanese. Certainly, the book will not include a justification of how you can use Japanese to speak in London and New York as you can do with English, and probably it won't even bother explaining you why learning Japanese may be a good idea. And, yes, you probably could learn Chinese instead, but that is not the point.

bgorman 6y ago

> it is a good fit for security-sensitive, heavily-audited codebases, because there are fewer layers of abstraction to audit and a smaller attack surface. C is a language that has a reason for existing. However C exposes programs to categories of errors that are not even possible to represent in other languages. In my opinion security code should be as error proof as possible, and C is definitely not a good language to accomplish that goal in. (I used to be a professional C programmer)

woodrowbarlow 6y ago
security code should be as _provably_ error-free as possible. C's strength in this regard is not due to any syntactical strengths, but due to how few layers exist between the code and the hardware. it's not the only option, maybe there are even some better options these days from a purely technical standpoint, but C is used in heavily-audited security-sensitive applications despite its syntactical/design shortcomings because it keeps you close to the metal.
- avmich 6y ago
  > C's strength in this regard is not due to any syntactical strengths, but due to how few layers exist between the code and the hardware. Any language compiling into native code has this advantage. You perhaps meant that in C the programmer actually codes closely to how it's going to look like in native code. That could be an advantage; but for that C brings disadvantages, which come from one actually having to code like this - there is no other way. The question what's more important - language constructs which are closer to actual hardware or language abstractions which prevent certain bugs from appearing - isn't that clear.