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

281–290 of 387 posts

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

#281

Post by pjc50 »

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.

Inter-linking is a superpower, as is having a very thin runtime that ships with most operating systems.

I realized recently that Python could have saved a decade by having a means to "interlink" modules allowing the use of python 2 modules in python 3. Much easier in the C world; there have been incompatible syntax changes and incompatible link changes BUT not both at the same time.

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

#282

Post by bjourne »

I know this article has been up a few times already on HN. What I think Steve is missing is that all modern computer hardware is designed around how C works! 40 years ago you might have had hardware in which there was a real mismatch between how it worked and C worked.

Not so much these days. How C works and how x86-64 assembly works is very similar. Of course, that is not the whole story and you could argue that how x86-64 assembly works is not how the "computer" works because it is a high-level abstraction of the CPU... But then what does it mean to talk about how the computer works?

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

#283

Post by yjftsjthsd-h »

rhinoceraptor wrote: post #215
rumanator wrote: post #70

Earlier quoted context omitted.

> This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous. If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you... You still decide that yes, what you want to do is to shoot yourself in…

OpenBSD has almost a singular focus on security, and even they have vulnerabilities. If they can't write safe C 100% of the time, what hope does anyone else have?

So... Is there an OS with zero vulnerabilities written in Rust/Go/Ada/anything that I should know about? If nobody's written safe Rust/Go/Ada/whatever 100% of the time, what hope do I have?

Now, I think that particular argument is poor. The more defensible version would be to look at the proportion of errors that occurred in C that would not occur in your language of choice, versus the number of errors that occur in this other language that would be unlikely to occur in C. And for completeness it would be good to do some sort of evaluation as to whether they were other gotchas like performance of the resulting code and programmer productivity. I expect that in the grand scheme of things, C is not the best option, but 100% perfection is an absurd goal post and makes it a lot easier for people to dismiss your argument.

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

#284

Post by jeffdavis »

saagarjha wrote: post #235
jeffdavis wrote: post #204

Earlier quoted context omitted.

The "right tool for the job" is a myth (EDIT: exaggerating; clearly it applies in some cases). Languages don't work together very well, so you need huge, thick boundaries between them, such as serialization/deserialization. Data types don't match up, GCs require special data formats and don't line up with the GCs of other languages, other runtime weirdness, etc. At minimum, you need lots of copying/transformation of…

> Rust seems to have this superpower (does dynamic dispatch a different way than C++, so can always work on unmodified structures). This isn't really true.

Can you explain?

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

#285

Post by ivankolev »

saagarjha wrote: post #271
twic wrote: post #260

Earlier quoted context omitted.

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

Does IntelliJ actually support C++?

Probably talking about CLion, their C/C++ offering.

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

#286

Post by ChrisSD »

jeffdavis wrote: post #204
stiray wrote: post #171

Earlier quoted context omitted.

What is profoundly pissing me off are bunch of hipsters on the internet that are using xyz language and are constantly trying to compare everything to C. We are faster, we are better, we are more portable, we have JIT, we have reflection... and so on. Who cares what your tool for solving the problem is. Use Java, use JS, use python, go, rust... whatever suits for the task. Why do you want to compare yourself to C. Ju…

The "right tool for the job" is a myth (EDIT: exaggerating; clearly it applies in some cases). Languages don't work together very well, so you need huge, thick boundaries between them, such as serialization/deserialization. Data types don't match up, GCs require special data formats and don't line up with the GCs of other languages, other runtime weirdness, etc. At minimum, you need lots of copying/transformation of…

To be precise, C does not have a defined ABI (the spec goes out of its way to avoid this). Platforms (OS+Arch) define a C ABI for their own tools. Since this ABI is required to interop with the OS APIs, this will usually become the de-facto standard for the platform.

This might seem like nitpicking but it's an important distinction because you can't assume that C data structures can be passed between different platforms (e.g. over a network or even stored in a filesystem).

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

#288

Post by jkoudys »

amiga_500 wrote: post #244
saagarjha wrote: post #228

Earlier quoted context omitted.

What are you comparing it to? I think C++ tooling is fairly decent. (By the way, what do you work on?)

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…

Lots of languages suffer there -- eg there's no reason you _couldn't_ be a really excellent PHP developer who specializes in WordPress sites, but it's an uphill battle to prove you're a good dev because there so many bad ones in that space.

For that matter, most of the so-so devs resumes that come across my desk will list "HTML and CSS" as skills. Even among experienced devs, being legitimately good with HTML or CSS is extremely rare. I'd give my eye teeth to have a dev on staff who was an actual HTML expert (knows the w3c docs, can write clear, correct, semantic html using the right tags, organizes and expresses their intent, etc.), but since the barrier to entry is barely above basic literacy, so finding one is tough.

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

#289

Post by aidenn0 »

jcranmer wrote: post #123

One of the blog posts I keep meaning to write is in the vein of "Why C is not portable assembly." Ironically, most of my points about C failures aren't related to UB at all, but rather the fact that C's internal model doesn't comport well to important details about machines: * There's no distinction between registers and memory in C. A function parameter that is "register volatile _Atomic int" is completely legal and…

Don't forget arithmetic operations that can detect various corner cases.

Writing something like:

  sum = x + y;
  if(sum
And then hoping the compiler will optimize your if statment to a single overflow CF check is a bit silly.
Post reply on HN