Live data from Hacker News

50 years of C, the good, the bad and the ugly [video]

streaming.media.ccc.de

51–60 of 257 posts

Re: 50 years of C, the good, the bad and the ugly [video]

#51
post #2

His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.

We can replace COBOL with a Java backend to keep the enterprise feeling going, but what would C's replacement be in this case?

C++ for starters, would already be an improvment, provided string, array and vector classes with bounds checking, get used instead of raw C pointers.

Alongside RAII for resource management.

Re: 50 years of C, the good, the bad and the ugly [video]

#52
post #41

A different take on the matter: I write code mainly artistically, and I found that C is one of the best languages available to code as a form of art. It allows to be both brutal and honest, or abstract and deceiving. Not many languages are so semantically powerful.

It’s mostly semantically very poor to be honest. C really is a nicer assembly in a lot of way. It’s extremely limited. You have branching logic, functions call, pointer arithmetic, a way to define data structures which are really memory layouts and that’s pretty much it. I guess you can appreciate that as an aesthetic statement but what you wrote would apply equally to any language with more complex semantics.

Re: 50 years of C, the good, the bad and the ugly [video]

#53

I maintain that C is fine and optimising compilers converting 'bad' C into dangerously broken binaries is not fine. We don't need to replace C to make it safe, we need to take the edge off undefined behaviour justified compiler rewrites.

I believe the main culprit is that the compiler guys want to optimize away Cpp templates, where programmer intent is not as explicit as in C.

C has enough UB of its own, no need to bring C++ into the picture.

Re: 50 years of C, the good, the bad and the ugly [video]

#54
post #41

A different take on the matter: I write code mainly artistically, and I found that C is one of the best languages available to code as a form of art. It allows to be both brutal and honest, or abstract and deceiving. Not many languages are so semantically powerful.

C++ should be even better in those categories.

This shouldn't be downvoted. C++ is a superset of C; it must be capable of being at least as "brutal and honest" and "abstract and deceiving" as C.

I would argue that C++ can be dramatically more deceiving than C --- see inheritance and operator overloading, just to name two.

Re: 50 years of C, the good, the bad and the ugly [video]

#55
He says something like

>"if you want to write new program in C now think long and hard and pick something else"

I would not use plain C to write enterprise backend servers. I happily use modern C++ for that.

For some very low power microcontrollers however I absolutely would. Amount of high quality free tooling and libraries beats everything else.

From a practical point of view: I've written enough firmware for very lowly microcontrollers like AT90USB1286. Runs like a charm (oldest for 10 years already), did not not require even single bug related update and zero complaints from customers. Changing the language in this particular case would bring no benefits but extra expense.

Re: 50 years of C, the good, the bad and the ugly [video]

#56
post #41

A different take on the matter: I write code mainly artistically, and I found that C is one of the best languages available to code as a form of art. It allows to be both brutal and honest, or abstract and deceiving. Not many languages are so semantically powerful.

Can you share some examples of your "art"? I'm trying to wrap my brain around the concept of writing code for any reason other than work or trying to build something.

Some background here: http://antirez.com/news/133

Re: 50 years of C, the good, the bad and the ugly [video]

#57
I often wonder why c did not deprecate the bad bits, like the dodgy string functions should at least be behind a switch to enable, like --enable-strcat or something. Even the printf bug when passing a single argument is easily fixed by requiring two arguments at a minimum, etc. Then leveling up the std library to force the use of bounds checked strings and buffers, again hiding the unsafe ones behind switches or unsafe keywords. This woukd allow backwards compatability, while making newer code safer by default.

Re: 50 years of C, the good, the bad and the ugly [video]

#58

Earlier quoted context omitted.

> Linux kernel is written in C Not exclusively in C, not anymore: https://docs.kernel.org/rust/index.html It might take another decade for a C-free build to be possible, though.

Only a decade? I don't think so. AFAIK Torvalds has also stipulated that any Rust code needs to be mirrored in C.

> AFAIK Torvalds has also stipulated that any Rust code needs to be mirrored in C.

Do you have a cite for this? I hadn't heard this at all.

Re: 50 years of C, the good, the bad and the ugly [video]

#59
post #41

A different take on the matter: I write code mainly artistically, and I found that C is one of the best languages available to code as a form of art. It allows to be both brutal and honest, or abstract and deceiving. Not many languages are so semantically powerful.

C++ should be even better in those categories.

Art is often about constraint, and mastery of simple tools.

I identify with @antirez's sentiment. I know both C and C++ very well. I find C definitely more artistic. C++ is utilitarian.

Prolog is the other language I code in "artistically". It too is quite simple and constrained, though it is on the opposite end of the high/low-level spectrum as C.

Re: 50 years of C, the good, the bad and the ugly [video]

#60

Earlier quoted context omitted.

C++ should be even better in those categories.

This shouldn't be downvoted. C++ is a superset of C; it must be capable of being at least as "brutal and honest" and "abstract and deceiving" as C. I would argue that C++ can be dramatically more deceiving than C --- see inheritance and operator overloading, just to name two.

C++ is not a superset of C, there are plenty of legal C constructs that will trigger errors when compiled with a C++ compiler.
Post reply on HN