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

41–50 of 118 posts

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

#41

Post by waiseristy »

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…

We’ve been really spoiled by modern compilers and operating systems which let you get away with large swaths of undefined behavior. You typically don’t know what is hidden from you

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

#42

Post by snickerbockers »

mlindner wrote: post #22
waiseristy wrote: post #20

The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at a fairly core level without too much effort. Please don’t start a C flame war either HN. I know I’m nerd sniping you all on this one

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.

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

I've done this before, never felt like C wasn't simple.

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

#43

Post by pjmlp »

Joel_Mckay wrote: post #39
mlindner wrote: post #15

Earlier quoted context omitted.

I'm not sure if I agree with any statement of the form "The use-case for Rust is not the same as foo ." for any foo where Rust is replacing a language that replaced foo . Rust is replacing C++ in several well documented places, however C++ itself was a replacement for C in many places. So by definition the use-case for Rust overlaps the use-case for C. Arguments like this sound like old arguments that were re-told to…

"C++ itself was a replacement for C" Actually, Cpp originally was a C template pre-compiler if I recall... just like Rust was. Note, people argue for years about various language merits. "there's nothing of note in the last 10 months" Indeed, still a pain to build, port, and package on some systems due to the poor project design required dependencies. There are papers pointing out the common fallacy of increased memo…

Because after losing Simula's productivity to BCPL, Bjarne Stroustrup promised to himself never to do it again.

So when he started at Bell Labs and all it had was C, he quickly got busy getting his high level tooling back.

Being a C preprocessor was the quickest way to achieve that goal.

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

#44

Post by rootw0rm »

mlindner wrote: post #22
waiseristy wrote: post #20

The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at a fairly core level without too much effort. Please don’t start a C flame war either HN. I know I’m nerd sniping you all on this one

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.

i have a C threaded producer that lives in a target process and exports data to a C# consumer in another process. (locks are shared between processes according to data in a predetermined memory segment. also, add a custom high bandwidth IPC protocol to that spec) ...it works beautifully. i did port the C to a mix of unsafe C# + atomic Windows intrinsics, but it's surprisingly robust.

I think your main argument here is that large C code bases can easily become unwieldy, and I agree with you on that. However, simple multithreading in C is simple. It's not a terribly difficult problem to solve.

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

#45

Post by mlindner »

snickerbockers wrote: post #42
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.

>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. I've done this before, never felt like C wasn't simple.

How big was the project and how many people were maintaining it? And were the people maintaining it the same people who started it? Perhaps I should have included a statement about coming in to work on a project that was already double digits old when you started working on it.

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

#46

Post by pjmlp »

ihatepython wrote: post #37
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.

It's never really necessary to write a multithreaded program. It's probably better to come up with a better architecture and communication method. In a corporate environment, just use Java or C# or whatever. It's a corporate environment, probably not that interesting. C is not necessary.

It isn't because most of us reach out to C++, when needed to step out of Java and C# among others.

Even modern drivers for Apple, Google and Microsoft platforms are written in C++.

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

#47

Post by mlindner »

ihatepython wrote: post #37
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.

It's never really necessary to write a multithreaded program. It's probably better to come up with a better architecture and communication method. In a corporate environment, just use Java or C# or whatever. It's a corporate environment, probably not that interesting. C is not necessary.

All that network hardware in use all over the internet was designed in corporate environments. I'd bet they almost all use C.

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

#48

Post by bhawks »

snickerbockers wrote: post #38
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…

No, the problem is not that modern CPUs want to be a PDP-11, it's that they want to be an 8086 for compatibility reasons. From the software's perspective, the ISA *is* the hardware. It doesn't matter if the CPU is internally recompiling everything to a RISC-like architecture with an arbitrary number of registers because there's nothing i can do to access that. If there's ever a radical new ISA which supplants x86 whe…

OP links to: https://queue.acm.org/detail.cfm?id=3212479

Which in the very initial paragraphs points out it is not about having a hidden set of registers to work with - it's about exploiting parallelism and the tension between a sequential programing language and massively parallel hardware architecture.

The ISA is not the hardware it's a 40 decade old abstraction that the hardware bends itself into to make your code run.

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

#49

Post by tomcam »

ihatepython wrote: post #37
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.

It's never really necessary to write a multithreaded program. It's probably better to come up with a better architecture and communication method. In a corporate environment, just use Java or C# or whatever. It's a corporate environment, probably not that interesting. C is not necessary.

> It's never really necessary to write a multithreaded program. It's probably better to come up with a better architecture and communication method.

Mind expanding on that?

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

#50

Post by mpweiher »

snickerbockers wrote: post #38
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…

No, the problem is not that modern CPUs want to be a PDP-11, it's that they want to be an 8086 for compatibility reasons. From the software's perspective, the ISA *is* the hardware. It doesn't matter if the CPU is internally recompiling everything to a RISC-like architecture with an arbitrary number of registers because there's nothing i can do to access that. If there's ever a radical new ISA which supplants x86 whe…

> From the software's perspective, the ISA is the hardware

Precisely! And because the weirdness happens below the ISA, all the mismatches Dave Chisnall describes apply to any other language just as much including actual machine language. So raw machine language is not a low-level language? .

Post reply on HN