Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Two types of C programmers

utcc.utoronto.ca

Post reply on HN
Print view View original

121–130 of 225 posts

Re: Two types of C programmers

#121

Post by hgs3 »

preseinger wrote: post #91
gavinhoward wrote: post #82

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, measured over time

I agree that C the programming language does not help you avoid memory errors, however, saying it's impossible is too binary. People do make mistakes, whether it's copy editors missing a typo or professional chefs misremembering whether they stocked an ingredient. Projects written in C need longer periods of code review and testing, but they can be made right. The code that took us to the moon was written in assembly after all.

Re: Two types of C programmers

#123

Post by tialaramex »

kps wrote: 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 also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs.”

You can have a language where all the behaviour is defined but in my experience most programmers who whine about this in C are just as unhappy because what they actually wanted was DWIM. In a language with defined behaviour their program is wrong, which is their fault, whereas in C they can claim "obviously" it's the compiler's fault.

I like it when it's my fault, I just learned something, and early in my education I assumed everybody was the same but I rapidly learned that most people prefer to be told they're correct regardless, and a language which says "Nope, 4 - 5 is a negative value and this variable in unsigned, too bad" makes those people unhappy, whereas when 4 - 5 = mysterious program behaviour they can blame the compiler engineers instead.

Re: Two types of C programmers

#124

Post by atomicnumber3 »

fargle wrote: 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…

Dunno, I'm a self-professed "java" programmer even though at my current and prior job there is not a single line of Java code. (Current job is golang and python, prior job was python and scala).

But many of my side projects are Java and she is always first in my heart no matter where the money takes me.

Re: Two types of C programmers

#126

Post by haberman »

softirq wrote: post #113
haberman wrote: post #85

I am a C programmer. For me the language is a means to an end. I prefer to work on problems where both performance and code size is paramount. The kinds of problems where it makes economic sense to spend months or years of engineer time designing and implementing a solution that will compile to a 50kB binary. I think primarily about the kind of machine code I want to generate, and pick a language that best approximat…

How do you feel about Rust?

I was really positive on Rust for at least five years. But several experiences have led me to reconsider this position, most notably the difficulty using arena allocation: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html

This is one of the things that endears me to Zig: passing an explicit allocator around is a very common idiom in the language.

Re: Two types of C programmers

#127

Post by kps »

msla wrote: post #114
zabzonk wrote: post #109

Earlier quoted context omitted.

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

Counterpoint: https://wiki.osdev.org/System_V_ABI The System V ABI is closer to being a standard than some official standards are. C++ gets odd with name mangling, but the platform's C ABI is typically the tune every other language must dance to for its FFI.

> The System V ABI is closer to being a standard than some official standards are.

That brings back some unpleasant memories. What happens when a popular compiler decides that whatever they choose is the ABI, and the published spec be damned? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496

Re: Two types of C programmers

#128

Post by tialaramex »

jtorsella wrote: post #95
preseinger wrote: post #91

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…

The Rust compiler developers are well aware that it's not possible to write 100% correct code at scale, not least for their dependencies, LLVM provides Rust with ICE (cases where your program crashes the compiler) and with soundness holes where the LLVM behaviour is definitely wrong but it's arguably exactly why and so until LLVM developers decide why it's wrong and fix it, Rust has to either work around that or accept sub-par results.

Much of the Rust compiler is written in Rust and so has fewer problems.

Re: Two types of C programmers

#129

Post by asveikau »

preseinger wrote: post #91
gavinhoward wrote: post #82

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…

What you mean to say is you have no shot at correct C, and so the language scares you, and you believe since you can't do it nobody does.

It's true that the community at large writes lots of bugs. But that doesn't mean some people aren't productive with the language and write a relatively low number of bugs. There are some projects with better track records at this than others.

Re: Two types of C programmers

#130

Post by tialaramex »

kps wrote: post #104
preseinger wrote: post #91

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…

I assume this was a logic error, that is, the code as written was a valid C program that didn't do what you meant.

In that case this could have been caught with more careful unit tests, which would have exercised the erroneous condition, and potentially with fuzzing to excite corner cases. C is... not great for either of these.

Post reply on HN