Someone told me back in high school that "C is just shorthand for assembly", which I think about a lot. Does anyone else feel that way?
“C is how the computer works” is a dangerous mindset for C programmers
11–20 of 387 posts
Re: “C is how the computer works” is a dangerous mindset for C programmers
#12People simply have to come to terms that modern computers are nothing like their beloved PDP-11.
Re: “C is how the computer works” is a dangerous mindset for C programmers
#13Wait until they learn that machine code is not exactly how the computer works either. The hardware is doing things to your code you might not expect.
Re: “C is how the computer works” is a dangerous mindset for C programmers
#14Re: “C is how the computer works” is a dangerous mindset for C programmers
#15Someone told me back in high school that "C is just shorthand for assembly", which I think about a lot. Does anyone else feel that way?
I think that goes way too far. Assembly is a completely different beast from C and way more complex. There is a lot stuff you can do with assembly that C can’t.
Re: “C is how the computer works” is a dangerous mindset for C programmers
#16Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting…
Last I checked UB was undefined by the standard, but compilers still need to define their behavior on each architecture.
Dictating that all architectures implement UB the same way would have significant overhead, since it would force programs that don’t rely on UB to run in emulation on all but one architecture (at best).
Re: “C is how the computer works” is a dangerous mindset for C programmers
#17The problem with the “C is an abstract machine” nonsense is that it’s just not how it works. I get that it’s what the spec says. But C compilers are super careful to compile structured assembly style code without breaking it, even though they don’t formally promise to do so. That’s because lots of large C code based assume structured assembly semantics and probably always will.
Re: “C is how the computer works” is a dangerous mindset for C programmers
#18Interesting this is less of blog post and more of an announcement that a blog post will not be written.
And yet a content-free post is gobbled up on Hacker News.
Steve Klabnik, of Rust fame, has a good history of writing insightful and interesting articles.
If you feel he isn't delivering value then feel free to output your own content instead of contributing to drive down the signal/noise ratio of HN's comments section with inane comments on other people's tastes.
Re: “C is how the computer works” is a dangerous mindset for C programmers
#19Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting…
Last I checked UB was undefined by the standard, but compilers still need to define their behavior on each architecture. Dictating that all architectures implement UB the same way would have significant overhead, since it would force programs that don’t rely on UB to run in emulation on all but one architecture (at best).
that's implementation defined
Re: “C is how the computer works” is a dangerous mindset for C programmers
#20To be fair, even assembly language isn't how the computer works (gets translated into micro code). Not to mention other integral components like the GPU that are coded in an entirely different model.
I think what's fair to say is: the "abstract C machine" tends to have a minimal amount of concepts on top of the machines instruction set, compared to other languages, and generally provides the least friction if you need to poke a memory address or layout a structure in a very specific way. It's just easier to say it's closer to the metal because that's a mouthful.