Live data from Hacker News

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

humprog.org

31–40 of 118 posts

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

#31

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.

I would be interested to see someone write a program in any language (other than ones specifically designed to combat this, rust…) using threading and guarantee it to be data/race safe. But, I’m not arguing with you. I honestly think that any corporate codebase after double digit years (and seven figure LoC) turns into a completely unmanageable mess. If it isn’t, it’s because of the team culture and pure rigor. Not t…

> I would be interested to see someone write a program in any language (other than ones specifically designed to combat this, rust…) using threading and guarantee it to be data/race safe.

I don't limit my statement to just C. The topic was C however so I mentioned C.

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

#32

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.

C is simple.

Writing C is simple.

Writing multithreaded programs is difficult and C doesn't help you with it.

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

#33
post #4
post #2

Unmanageable really has a context and depending on the use case sometimes C is the best option…

The use cases where C is the best option are probably limited to exotic platforms that don't have compilers for better languages. There aren't many targets were you can't at least use C++.

C still fills a niche nothing else really does in terms of being a lingua franca everyone can read that any language can talk to. The language is stable enough that code written today will probably have the same semantics far into the future, something C++ has been a lot more shaky about historically.

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

#34

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

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 undefined and unspecified behaviors are hugely important to how C and C++ are used in the field.

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

#35

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

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.

Undefined behaviour being weird and having bizarre implications is not a feature of C.

It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity.

And it is not forbidden by the standard, though discouraged.

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

#36

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.

You are confusing two different things, the simplicity of C itself, and the simplicity of using C for a certain problem.

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

#37

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.

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.

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

#38

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 where C's constructs prove to be a bottleneck, and that ottleneck only applies to C, you will finally see it fall to the wayside.

>These types of arguments feel like they come from people who don't realize how much the compiler reworks your code to make it act like it does what you told it to do.

I guess it's hard to argue against a vague undefined term like "rework" but i can assure you that the output of gcc largely resembles what i expect it to. If the compiler does something bizarre i will know about it because i actually do check the assembly.

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

#39

Earlier quoted context omitted.

The use-case for Rust is not the same as C. In general, C is a better option if you find you are escaping to macro defined Assembly or other memory ops (glib back-ported data structures for C highly recommended). Rust likes to keep unsafe operations organized, but is a persistent pain if a problem scope requires many "unsafe" operations. I'd wager Rust will end up like Boost... really cool.. but too chaotic to trust…

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 memory safety with the current Rust builds as well.

Of course, Rust may work fine for whatever you are building. =)

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

#40
Like others were made for JavaScript and PHP.

Had it not been for UNIX freebie, it would had been a footnote like so many others.

Outside UNIX clones and the few surviving embedded workloads without alternative, there is hardly a reason to reach for it instead of C++, which is also a UNIX child.

Post reply on HN