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

291–300 of 387 posts

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

#291

Post by saagarjha »

jeffdavis wrote: post #284
saagarjha wrote: post #235

Earlier quoted context omitted.

> 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?

Rust has both static (based on monomorphization, similar to a template instantiation in C++) and dynamic (based on vtables, similar to inheritance in C++) dispatch: https://doc.rust-lang.org/1.8.0/book/trait-objects.html. Both Rust and C++ are moving in the direction of encouraging static dispatch.

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

#292

Post by jeffdavis »

lliamander wrote: post #272
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…

A really thought-provoking argument. I suppose that when it comes to choosing "the right tool" the important thing is to optimize globally across the problems that your organization will be solving. But if you want to be able to optimize both globally and locally, well that's just an engineering problem! Two examples spring to mind: 1. Lisp. Lisp's metaprogramming facilities allow you to build the language into the s…

Lisp is an interesting point. I guess the argunent is that it's the right tool for every job?

Unix is a reasonable example of a polyglot environment, but at a high cost. Lots of serialization/deserialization through text. That has a high cost in terms of bugs, complexity, lines of code, and inefficiency.

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

#293

Post by continuational »

lliamander wrote: post #272
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…

A really thought-provoking argument. I suppose that when it comes to choosing "the right tool" the important thing is to optimize globally across the problems that your organization will be solving. But if you want to be able to optimize both globally and locally, well that's just an engineering problem! Two examples spring to mind: 1. Lisp. Lisp's metaprogramming facilities allow you to build the language into the s…

Those programs communicate by serialization and deserialization, usually in bespoke, poorly documented data formats.

Unix doesn't put a strong emphasis on protocols. It just says "everything is text, except when it's not". It's not very helpful.

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

#294

Post by aidenn0 »

jcranmer wrote: post #226
jeffdavis wrote: post #217

Earlier quoted context omitted.

"There's no "bitcast" operator that changes the type of a value without affecting the value." Technically, you are supposed to use unions for that, though it's a pain. The PostgreSQL codebase is compile with -fno-strict-aliasing so that a simple cast will get the job done, but obviously that's technically out of spec.

Actually, the guideline I've heard is that memcpy should be used, since memcpy has the magic property of copying the bytes without affecting the destination type. Unions are only legal in C99 and newer (although C99 erroneously includes this in its list of undefined behavior--this was fixed in C11); C89 and any version of C++ don't permit this behavior.

I keep hearing this rumor, but C99 did not erroneously include unions-as-type-punning in a list of undefined behavior. The normative language is unclear, but clarifications were added1][2].

1: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_257.htm

2: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm

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

#295

Post by tspiteri »

ncmncm wrote: post #268
tspiteri wrote: post #157

Earlier quoted context omitted.

Your code is int x; if(x == 0) foo(); if(x != 0) foo(); That is reading the uninitialized value twice. Since it is unspecified, it does not have to be consistent, so you could get the same behavior as non-zero for the first reading, and zero for the second reading. Changing your code to: int x; if(x == 0) foo(); else foo(); will give different output (same if you use !=).

A good optimizing compiler will just elide the whole code block.

Only if there was UB, and the point is that there probably isn't. (I'm not really knowledgeable on the C standard, so I might have misinterpreted something.)

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

#296

Post by dagw »

goatlover wrote: post #276
cozzyd wrote: post #257

Earlier quoted context omitted.

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.

Julia lets you run Python, R and Fortran libraries.

Only if you have a complete Python/R environment installed.

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

#297

Post by geofft »

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.

This is literally the reason I most recently wrote some C, but - do you really need linking? You can pretty easily use a Python library from Ruby by writing a little loop in Python that accepts JSON input and produces JSON output, and calling that as a Ruby subprocess.

It's fairly rare that you actually need to be in the same process. (The thing I wrote was a wrapper for unshare(), so it did strictly need to be in-process, but that's an unusual use case.) Even if you want to share large amounts of data between your process and the library, you can often use things like memory-mapped files.

And there are some benefits from splitting up the languages, including the ability to let each language's runtime handle parallelism (finding out that the C library you want to use isn't actually thread-safe is no fun!), letting each language do exception-handling on its own, increased testability, etc.

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

#298

Post by geofft »

ken wrote: post #290

Should I learn Verilog to understand “how the computer works”?

MIT 6.004 has students construct a minimal CPU (basically a simplified Alpha processor) out of logic gates, precisely to teach them "how the computer works".

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

#299

Post by lliamander »

jeffdavis wrote: post #292
lliamander wrote: post #272

Earlier quoted context omitted.

A really thought-provoking argument. I suppose that when it comes to choosing "the right tool" the important thing is to optimize globally across the problems that your organization will be solving. But if you want to be able to optimize both globally and locally, well that's just an engineering problem! Two examples spring to mind: 1. Lisp. Lisp's metaprogramming facilities allow you to build the language into the s…

Lisp is an interesting point. I guess the argunent is that it's the right tool for every job? Unix is a reasonable example of a polyglot environment, but at a high cost. Lots of serialization/deserialization through text. That has a high cost in terms of bugs, complexity, lines of code, and inefficiency.

> Lisp is an interesting point. I guess the argunent is that it's the right tool for every job?

Yup, that's more or less the argument, though the argument need not only apply to lisp.

> Unix is a reasonable example of a polyglot environment, but at a high cost.

I'd rather say that Unix is an example of how to effectively drive down the cost of a polyglot environment to a point where it is outweighed by the benefits.

Now, of course the cost is still there, but I would argue that beyond a certain scale you cannot optimize globally on a single runtime (perhaps not even with something like lisp) and so the cost of global consistency is outweighed by cost of being unable to optimize locally.

To put it more succintly, you could not build a system as complex as Unix in a single language[1]

[1] Although Ala Kay's work at VPRI suggests you can, if you choose a sufficiently expressive base language. But even that may have it's limits.

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

#300

Post by PeCaN »

Jasper_ wrote: post #206
vardump wrote: post #189

Earlier quoted context omitted.

Microcode on x86? Don't forget to also greet our friends such as RDTSCP, CPUID, RDMSR, POPCNT (on some models) etc. Also remember to check ENTER, BOUND, etc. out in the museum vitrine. But yeah, microcoded instructions are relatively rarely executed.

I can't find any evidence that RDTSCP is microcoded. That would defeat the whole purpose of a high-performance counter. Any source?

Agner Fog's instruction tables list it as issuing ~23 fused uops (a bit more or fewer depending on generation) and a throughput of 1 per ~32 cycles. That seems like it could be microcoded.
Post reply on HN