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

71–80 of 118 posts

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

#71

Post by sacnoradhq »

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.

libuv enters the chat.

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

#72

Post by sacnoradhq »

mpweiher wrote: post #32
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.

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

Flame bait. Haha.

Let's not argue about religions online. The mullahs will arrest us for improper use of void.

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

#73

Post by simplotek »

sacnoradhq wrote: post #68

Null was a trillion dollar mistake. Pointers and pointer math were a 10 billion dollar mistake. Unchecked array access is a several billion dollar mistake. Goto has its place: consolidated resource error unwind cleanup. That's basically its only valid use except for mechanically-generated finite state machines. Beyond that, don't bother. Other programming languages use reference counting and lifetimes to manage resou…

> Null was a trillion dollar mistake.

I don't agree. Null is just a tombstone value. If you're dealing with specifying memory addresses, you either specify the address or point a value that tells you the variable is not pointing to an address.

If anything, conflating arrays with pointers was a bad idea. The language would be far better equiped to deal with memory safety issues if an array data type included info like total size, used size, and perhaps also stride length. Relying on tombstone values to delimit strings or arrays was just prone to blow up on everyone's face.

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

#74

Post by simplotek »

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 how C and C++ are used in the field.

Is it really that fundamental if you can setup your project to throw warnings/errors, and even use static code analysis tools to flag those?

I'd argue that it's far worse to work on a project that's not setup to detect those errors than to expect that sort of issue to be handled at the recruiting level.

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

#75

Post by simplotek »

mlindner wrote: post #15
Joel_Mckay wrote: post #7

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…

> Arguments like this sound like old arguments that were re-told to me by my father where people argued that C couldn't replace the use case for Algol at the University of Michigan MTS system.

The problem with those comments is that they are intellectually lazy, and use age as a proxy for "better". Language X can be designed with specific features in mind that offer interesting features that Language Y fails to offer, but that is not ensured by the release date, nor might that be an acceptable tradeoff when considering other factors.

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

#76

Post by AshamedCaptain »

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…

> Which is easily shown to be false given that hardware designers have had bend backwards and into contorted shapes to emulate the hardware environment that C was originally created to work against.

It may be a valid point, but value-less, since this basically implies that most hardware you are going to be able to buy today (ARM, x86, whatever) is going to be a fast PDP-11 (or at least it's going to present itself as one).

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

#77

Post by smitty1e »

jstimpfle wrote: post #55
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.

Classic confusion of simple vs easy.

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

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

#78

Post by AshamedCaptain »

bhawks wrote: post #53
mpweiher wrote: post #50

Earlier quoted context omitted.

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

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.

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

#80

Post by josefx »

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.

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

Post reply on HN