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

Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

humprog.org

Post reply on HN
Print view View original

91–100 of 118 posts

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#91

Post by pjmlp »

tmtvl wrote: post #69
pjmlp wrote: post #58

Earlier quoted context omitted.

Only when there isn't a C++ compiler around, even if we restrict ourselves to the common subset, C++ has stronger type safety, while constexpr + templates are way better than macros.

Yeah, but if C++ is an option you can just as well skip over all the way to Rust, which is a better C++.

Except the small detail of missing tooling and ecosystem.

There are lots of scenarios where C++ is the only available alternative to C, with similar tooling level and libraries.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#92

Post by jstimpfle »

smitty1e wrote: post #77
jstimpfle wrote: post #55

Earlier quoted context omitted.

Classic confusion of simple vs easy.

Everything us easy when you know how to do it. But that learning curve...

Nobody said it's easy. Programming is hard. The statement is that the language is _simple_.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#93

Post by jen20 »

josefx wrote: post #80
mlindner wrote: post #22

Earlier quoted context omitted.

Write a multithreaded program guaranteed to have no data races in C and tell me that C is simple. C _looks_ simple, deceivingly so. As soon as you need to deal with a large project in a corporate environment on a code base aged in double digit years you don't think it's simple anymore. C is incredibly complex, unmanageably so.

> Write a multithreaded program guaranteed to have no data races in C and tell me that C is simple. I could port most of the multiprocessing based python scripts I have lying around to C without a problem. Multithreading can be easy when you have a few rules in place what threads can read/modify data at a specific point in time.

It’s even easier when a compiler enforces those rules.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#95

Post by tialaramex »

Gordonjcp wrote: post #87
tialaramex wrote: post #81

Earlier quoted context omitted.

Not quite. The modern hardware isn't actually a fast PDP-11 it's just capable of emulating one more efficiently than you would if people didn't insist on writing C. So it may be that your "clever" C algorithm which in your head translates into just six CPU operations, unfortunately on a real modern CPU is six hefty macro-ops that will take dozens of cycles to execute and repeatedly go to sleep waiting for main memory…

> So it may be that your "clever" C algorithm which in your head translates into just six CPU operations, unfortunately on a real modern CPU is six hefty macro-ops that will take dozens of cycles to execute and repeatedly go to sleep waiting for main memory, whereas the algorithm in a modern language that looked ludicrous to your C programmer eyes compiles to sixteen tiny ops the CPU can consume two at a time with no…

I can give you a smaller example if that helps.

Rust's u8::is_ascii_hexdigit is a predicate which decides whether the 8-bit unsigned integer is the ASCII code for a hexadecimal digit, that is 0 through 9, A through F or a through f.

Inside the implementation is exactly what a modern programmer would expect, a pattern match, it'll do a whole bunch of arithmetic operations on the 8-bit unsigned integer and get a true or false result. Your modern CPU can do that real fast, because it's all just arithmetic on registers.

If you go look at a C library isxdigit() function, sometimes (not so often these days) you will find it has a mask and a LUT, it's assuming that "just" looking up the answer in memory will be faster. Your modern CPU can't do that quickly. It must calculate the index into the LUT, and then read the appropriate memory, hopefully that's in L1 cache or something, if it needs to go to main memory that takes an eternity, and either way it means something else can't be in the cache because this LUT is taking up space.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#96

Post by tialaramex »

AshamedCaptain wrote: post #86
tialaramex wrote: post #81

Earlier quoted context omitted.

Not quite. The modern hardware isn't actually a fast PDP-11 it's just capable of emulating one more efficiently than you would if people didn't insist on writing C. So it may be that your "clever" C algorithm which in your head translates into just six CPU operations, unfortunately on a real modern CPU is six hefty macro-ops that will take dozens of cycles to execute and repeatedly go to sleep waiting for main memory…

> The modern hardware isn't actually a fast PDP-11 it's just capable of emulating one more efficiently than you would if people didn't insist on writing C. I'm not disagreeing with that. It's a valid remark. What I'm arguing is that it's a useless remark in practice. > So it may be that your "clever" C algorithm which in your head translates into just six CPU operations, unfortunately on a real modern CPU is six heft…

The C programmers do distort what makes sense, but they can't overcome practical realities.

For example have you noticed your CPU is multi-core? The PDP-11 wasn't multi-core, and C doesn't really do well for writing concurrent software. Practically though, despite Amdahl's law it makes sense to provide a multi-core CPU. Most C software won't be able to take advantage, but some of your software is written by people who either will put the extra effort in despite C or use a different language where it wasn't so hard.

Take another example, the 0-terminated string. This terrible C design is more or less omnipresent. And sure enough CPUs have features to enable this terrible data structure, because it's so omnipresent. But those features don't make a better string worse they just pull the C string closer to parity than it might be otherwise. Rust's str::len() is still much faster than C's strlen() even if your CPU vendor focuses entirely on the C market.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#97

Post by astrange »

tialaramex wrote: post #96
AshamedCaptain wrote: post #86

Earlier quoted context omitted.

> The modern hardware isn't actually a fast PDP-11 it's just capable of emulating one more efficiently than you would if people didn't insist on writing C. I'm not disagreeing with that. It's a valid remark. What I'm arguing is that it's a useless remark in practice. > So it may be that your "clever" C algorithm which in your head translates into just six CPU operations, unfortunately on a real modern CPU is six heft…

The C programmers do distort what makes sense, but they can't overcome practical realities. For example have you noticed your CPU is multi-core? The PDP-11 wasn't multi-core, and C doesn't really do well for writing concurrent software. Practically though, despite Amdahl's law it makes sense to provide a multi-core CPU. Most C software won't be able to take advantage, but some of your software is written by people wh…

NULL-terminated strings aren't bad because strlen() is slow. The performance tradeoffs are fine enough. They're bad because they have bad security properties.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#98

Post by astrange »

AshamedCaptain wrote: post #78
bhawks wrote: post #53

Earlier quoted context omitted.

It is rare to build general purpose computing hardware in lockstep with software. The two worlds are only bridged by the ISA interface. It'd be interesting to see what interface we'd choose today with multiple decades of hardware and software development.

> It'd be interesting to see what interface we'd choose today with multiple decades of hardware and software development A worse one? Not a couple days ago there were a couple stories about Itanium here on HN (a designed-from-scratch ISA that turned out to be practically worse than the much more ad-hoc x86_64). Even e.g. RISC-V (which is not entirely free of legacy) is practically 1:1 with ancient ISAs like ARM.

ARM is an evolving ISA. AArch64 is quite different from ARMv7, and has nicer security features than the other leading brand, who can barely manage to ship SGX.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#99

Post by astrange »

MYEUHD wrote: post #84
mlindner wrote: post #18

This entire article seems to amount to "I am used to C, thus I don't see the problem with C." which is a fine position to have, but it's a perspective unique to the writer and others like him. It doesn't apply to people learning new languages that aren't C. Also several statements about how C must be used because somehow it's closer to the real world/hardware than other languages. Which is easily shown to be false gi…

>C Is Not a Low-level Language: Your computer is not a fast PDP-11. https://queue.acm.org/detail.cfm?id=3212479 C is indeed a low level language. If you wanted a language that's close to the actual hardware you have, you'd have a different language for different hardware. (That's what assembly is) Meanwhile, C is simple and easy to write compilers for. Therefore, it gained popularity because of its portability

If you know how a CPU works, especially the bits outside decode and ALUs like cache coherency, I don't think you could call assembly "close to the hardware" either.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#100

Post by scotty79 »

Espressosaurus wrote: post #34
cycomanic wrote: post #21

Earlier quoted context omitted.

I would argue it's very easy to think one understands it. However I would wager most people who say they understand C don't really know many of the undefined behaviour cases and their implications.

The number of people I have interviewed that have used C and C++ for years and can't tell me what undefined behavior is is too damned high. I've had one or two, and only one of them could give me a coherent answer of what the compiler is allowed to do if it runs across it. In my experience it's only the language lawyers who actually know what to look out for, and there are damned few of them. Which is stupid since un…

> Which is stupid since undefined and unspecified behaviors are hugely important to ...

Why are they though? Should they be?

Post reply on HN