Live data from Hacker News

Two types of C programmers

utcc.utoronto.ca

101–110 of 225 posts

Re: Two types of C programmers

#101
post #93

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/wh…

What type of projects do you work on?

A compiler/interpreter, build system, init system, version control system, among others.

It's all in a monorepo that has my "libc".

Re: Two types of C programmers

#102

Earlier quoted context omitted.

it's not possible for human beings to write correct C code, measured over time this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a high…

Oh wow, someone should alert the Linux kernel maintainers. Do you want to tell them that it’s impossible to write correct C code? And the rust compiler team, too. After all, if nobody can write safe assembly then whatever they’re doing is either unsafe or magically gets the computer to understand rust directly. Or are they relying on LLVM for their code generation? I forget what language that’s written in, but nothin…

i'm sure the linux kernel maintainers already know that it's impossible for them to write correct C code, no need to tell them

Re: Two types of C programmers

#103
post #98

C programmers are implicitly converted to the required type. Implicit conversions are one thing I don't like about C, or at least the way it ended up as int grew (maybe it would have been better if ANSI had picked unsigned-preserving, but maybe that's just grass-is-greener thinking). I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the…

I used to think implicit type conversions were bad in C, until I started programming in javascript.

Re: Two types of C programmers

#104

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/wh…

it's not possible for human beings to write correct C code, measured over time this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a high…

> it's not possible for human beings to write correct C code

It's not possible for human beings to write correct code.

The hardest bug I ever found in a C program, one that took cumulative weeks of work until a tractable reproduction was found, came down to a ‘Yes, different languages have different levels of expressiveness, and can preclude or expose different kinds of errors. You'll never have a stray pointer in Python, and you'll never OOM making an accidental copy in C.

Re: Two types of C programmers

#105
post #98

C programmers are implicitly converted to the required type. Implicit conversions are one thing I don't like about C, or at least the way it ended up as int grew (maybe it would have been better if ANSI had picked unsigned-preserving, but maybe that's just grass-is-greener thinking). I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the…

I used to think implicit type conversions were bad in C, until I started programming in javascript.

`5 - "2"` is 3, and `5 + "2"` is "52". Makes perfect sense! It could be worse, though; you could be doing Norwegian YAML.

Re: Two types of C programmers

#106

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/wh…

it's not possible for human beings to write correct C code, measured over time this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a high…

And yet C code runs the world. You might be right in theory but in practice C is the most successful programming language in history. At work we routinely deploy million+ lines of C in production running large international airlines and airports. And it works.

Re: Two types of C programmers

#107
post #104

Earlier quoted context omitted.

it's not possible for human beings to write correct C code, measured over time this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a high…

> it's not possible for human beings to write correct C code It's not possible for human beings to write correct code. The hardest bug I ever found in a C program, one that took cumulative weeks of work until a tractable reproduction was found, came down to a ‘ Yes, different languages have different levels of expressiveness, and can preclude or expose different kinds of errors. You'll never have a stray pointer in P…

Not true. Check out CompCert, seL4 etc.

Re: Two types of C programmers

#108
post #62
post #19

I appreciate the sentiment, but: - there doesn't have to be "two kinds". Trivially you can fit both "types" at once, I certainly feel that way. And if there are 100 programmers, there'd be about 237 other reasons to use a language. False dichotomy. - a better categorization might be "there are two kinds of C programmers: those who eventually start using rust and those that don't." which is at least of course absolute…

I disagree that enjoying C automatically means you will like Rust. If you are obsessed with safety, Rust will be a nice solution. But Rust is a much more complex language than C, which will turn many C programmers away.

I think you might not have read my bullet point that mentioned rust very carefully.

Re: Two types of C programmers

#109
post #5

I'd consider myself the former: I use C because it's the only viable option for what I'm doing - but most of the time it's nothing to do with C itself, but the various extensions and builtins of GCC. It's the inline asm, the control of registers, placement of code and data, control of inlining, etc, which are missing from all of the C "replacements". The replacements assume you are building a user application on top…

we don't have standard ABIs for either C or C++; we have conventions.

Re: Two types of C programmers

#110

Earlier quoted context omitted.

it's not possible for human beings to write correct C code, measured over time this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a high…

> it's not possible for human beings to write correct C code, measured over time I don't disagree [1], but remember that Rust can be unsafe too. Async is not a panacea, and it's confusing. And the `unsafe` escape hatch is still unsafe. > you have a professional obligation to use a higher-level language, with stronger guarantees Oh? So we have professional obligations now? For FOSS? News to me. I don't get paid for my…

Ask any experienced C developer and they'd all say "I write excellent C compared to all C programmers out there."
Post reply on HN