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

“C is how the computer works” is a dangerous mindset for C programmers

words.steveklabnik.com

Post reply on HN
Print view View original

251–260 of 387 posts

Re: “C is how the computer works” is a dangerous mindset for C programmers

#251

Post by z92 »

shadowgovt wrote: post #183
oconnor663 wrote: post #25

My favorite take on the severity of the UB problem, https://blog.regehr.org/archives/1520 : > Tools like [Valgrind] are exceptionally useful and they have helped us progress from a world where almost every nontrivial C and C++ program executed a continuous stream of UB to a world where quite a few important programs seem to be largely UB-free in their most common configurations and use cases...Be knowledgeable about…

> Be knowledgeable about what’s actually in the C and C++ standards ... turns out to be an extremely tall order; the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format. At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." At which point the imme…

> most other answers will raise an eyebrow from me

Portability. A C library can be trivially linked with any other language. But one will be hard pressed using a python library form Ruby, for example.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#252

Post by otabdeveloper2 »

pdimitar wrote: post #219
amiga_500 wrote: post #207

Earlier quoted context omitted.

C++ should only be used as a last resort. It's complex, development is slower, the tooling is poor, some universities have stopped teaching it. It's very hard to hire good C++ devs, and they are typically not cheap. I manage a c++ team btw. Our app has to be fast.

As your parent said, this is also an answer I can understand. Still, have you guys looked at alternatives -- and seriously evaluate them? Rust, Zig, Nim, D, others? If you tell me "we can't afford to, we have too much work" then that's also a valid answer (for a while at least).

> C++ has a standard that's too long and hard to understand, so let's use a language without any standard whatsoever instead!

Good lord, if that's the kind of human capital that's involved in making next-generation languages, then I have no doubt what will still be used to write serious software in 2080.

(Hint: not Rust.)

Re: “C is how the computer works” is a dangerous mindset for C programmers

#253

Post by saagarjha »

chrisseaton wrote: post #248
saagarjha wrote: post #245

Earlier quoted context omitted.

Reads? I think so; I believe the bad part is when you try to use it.

No, it is undefined behaviour. Check the spec.

I couldn't find the verbiage for that. The standard seems to have this under undefined behavior:

> The value of an object with automatic storage duration is used while it is indeterminate.

But reading the value without using it seems fine?

Re: “C is how the computer works” is a dangerous mindset for C programmers

#254

Post by throwaway_pdp09 »

saagarjha wrote: post #243
throwaway_pdp09 wrote: post #191

Earlier quoted context omitted.

> [reading memory} always will behave precisely and consistently What is the point of not making it UB? You can't AFAICS possibly rely on any useful way on it behaving 'precisely and consistently' so just make it UB anyway?

I think this lets you copy it around, e.g. when you have a struct that you have partially initialized.

That makes sense, finally. Thanks.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#255

Post by saagarjha »

steveklabnik wrote: post #108
cryptonector wrote: post #78

Earlier quoted context omitted.

But is Rust a more faithful model of HW? I'm happy to accept that C sucks (it does) and that Rust and others are superior (they are). But if you stop at the quoted statement, you've not said much. I upvoted the submission blindly, then read it, then un-upvoted it. TFA is not useful. It would have been better to not write TFA at all. There already are many many very good articles about how Rust is better than C.

I don't really understand why Rust is in this discussion at all. This isn't a post about Rust. (And Rust is not really any better than C in this regard. At least, in a vacuum. I guess you could make the argument that it's better because fewer people have false beliefs about it, but that's not an argument I'm making, either in the blog post nor here.)

Probably the obvious reason: that anything you write that has even the most tangential relevance to Rust means that people will think you're talking about Rust…

Re: “C is how the computer works” is a dangerous mindset for C programmers

#256

Post by amiga_500 »

saagarjha wrote: post #247
amiga_500 wrote: post #244

Earlier quoted context omitted.

I think java has very good tooling. Java's main issue is the barrier to entry is lower because it has good tooling, which means really bad, inexperienced programmers can write bad code, and have more tooling to bail them out, allowing them to continue down that path until they have a huge ball of mud. There ought to be some kind of phrase for this "the tooling curse". GDB isn't bad, IMHO, but the inability of IDEs to…

> the inability of IDEs to deterministically parse templates / index code without huge problems is problematic. More like the inability of text editors to parse templates; most IDEs rely on a full compiler backend that can usually figure things out.

But it shouldn't require a full compilation.

The ultimate result, given the slow compile times of c++, is that you cannot know in your editor if your code is correct.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#257

Post by cozzyd »

z92 wrote: post #251
shadowgovt wrote: post #183

Earlier quoted context omitted.

> Be knowledgeable about what’s actually in the C and C++ standards ... turns out to be an extremely tall order; the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format. At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." At which point the imme…

> most other answers will raise an eyebrow from me Portability. A C library can be trivially linked with any other language. But one will be hard pressed using a python library form Ruby, for example.

Indeed. C++ is relatively portable too (or at the very least, can be made to hide behind a C ABI in many cases) and it seems like Rust is as well. Whereas, if you have a library written in python that you want to leverage, you're forced to include a python interpreter. This sucks.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#258

Post by mark-r »

mpweiher wrote: post #22
beervirus wrote: post #4

Earlier quoted context omitted.

> Basically, the overall thrust of this series has been this: C is not the hardware, it’s an abstract machine. But that machine runs on real hardware, and abstractions are leaky. If you go too far into “purely only the abstract machine,” you may not be able to accomplish your tasks. If you go too far into “C runs directly on the hardware,” you may be surprised when a compiler does something that you didn’t expect. Se…

> C is not the hardware, it’s an abstract machine Not sure whether it is controversial or, not, but C is very much not an "abstract machine". There are languages which define an abstract machine, and the implementations then have to map that abstract machine onto the hardware, making sure to faithfully reproduce the semantics of that abstract machine. Squeak Smalltalk is an example of this, the VM provides the abstra…

C does define an abstract machine, but you are expected to map that abstract machine to the underlying hardware rather than to simulate it. The mismatch between the abstract machine and the hardware is where the problems come from.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#259

Post by chrisseaton »

saagarjha wrote: post #253
chrisseaton wrote: post #248

Earlier quoted context omitted.

No, it is undefined behaviour. Check the spec.

I couldn't find the verbiage for that. The standard seems to have this under undefined behavior: > The value of an object with automatic storage duration is used while it is indeterminate. But reading the value without using it seems fine?

The 'object' in this context is the storage location, not the value you read from it. You're 'using' the 'object' when you read from it.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#260

Post by twic »

saagarjha wrote: post #247
amiga_500 wrote: post #244

Earlier quoted context omitted.

I think java has very good tooling. Java's main issue is the barrier to entry is lower because it has good tooling, which means really bad, inexperienced programmers can write bad code, and have more tooling to bail them out, allowing them to continue down that path until they have a huge ball of mud. There ought to be some kind of phrase for this "the tooling curse". GDB isn't bad, IMHO, but the inability of IDEs to…

> the inability of IDEs to deterministically parse templates / index code without huge problems is problematic. More like the inability of text editors to parse templates; most IDEs rely on a full compiler backend that can usually figure things out.

Not in my experience. IntelliJ can't even figure out where a make_shared call goes.
Post reply on HN