Live data from Hacker News

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

streaming.media.ccc.de

241–250 of 257 posts

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

#241
post #14
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.

C syntax is already way too rich and complex, not to mention the bazillions of gcc extensions required to compile the linux kernel. Namely, if it has to be "replaced", that would be with something with a much simpler syntax, which will require a bit more of finger power. We don't want to find ourself locked-in by very few compiler vendors (open source or not), that only because it is not reasonable to code a real-lif…

Doesn't Modula-2, Oberon or Ada fill your checkboxes?

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

#242

Speaker asks: "What can and should replace it?" (i.e. if you started a new project today, what language should you pick instead of C, because C would be the wrong choice). He goes on to list the following options (and says C++ does not count), but we'll only know far in the future which would have been the right pick: - Rust - Go - Zig - V - Nim - Swift - ...

None of them are the wrong pick. They're all better than C.

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

#243
post #205

Earlier quoted context omitted.

Moving goalposts, you were asking who said it, the language authors did. If they are right or not, it is another matter.

Regarding that matter, he was wrong. I wish he'd never written the garbage that is C. It's a stain on his reputation.

I'm willing to forgive those who move on to better ideas, but we are really stuck with this 50 years later. When most of PL land knows better than to keep digging in this hole.

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

#244
post #205

Earlier quoted context omitted.

That same document claims, "C's approach to strings works well" which, I mean I admire Dennis Ritchie but he's just wrong.

Moving goalposts, you were asking who said it, the language authors did. If they are right or not, it is another matter.

But Dennis doesn't express it as an ideal, and that document is written really late -- it's citing a 1991 document in the part you just quoted, so that's after C89.

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

#245

Earlier quoted context omitted.

If somebody's expecting something other than a C string then we unsurprisingly have gratuitous complications. If everyone agrees on the C string though, it just interoperates as-is. Code compiled for some 16-bit microcontroller can just shove the C string into its transmit buffer, and on the other end, code compiled for 64 bit big-endian Power PC receiver just uses it as-is.

C is the biggest mistake in the software industry since the beginning of software. The people that worship C only do so because they haven't seen the better paths the software industry could have chosen.

E.g. Donald Knuth hadn't seen better paths.

"I think C has a lot of features that are very important. The way C handles pointers, for example, was a brilliant innovation; it solved a lot of problems that we had before in data structuring and made the programs look good afterwards. C isn't the perfect language, no language is, but I think it has a lot of virtues, and you can avoid the parts you don't like. I do like C as a language, especially because it blends in with the operating system (if you're using UNIX, for example).

All through my life, I've always used the programming language that blended best with the debugging system and operating system that I'm using. If I had a better debugger for language X, and if X went well with the operating system, I would be using that."

Dec 7, 1993, Computer Literacy Bookshops Interview.

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

#246

Earlier quoted context omitted.

One of the main drawbacks of function overloading is that it can make code harder to read and understand. When the same function name is used for multiple different purposes, it is confusing for developers who are reading the code. This makes it more difficult to maintain and modify the code in the future, as developers spend extra time trying to understand the various function definitions and how they are being used…

> it is confusing for developers who are reading the code. … as developers spend extra time trying to understand the various function definitions and how they are being used. This is a similar argument to Hungarian encoding, IMHO. A decent LSP makes it trivial to see which function is being called. The other issue you mention is a problem with the debugger/compiler, not function overloading. > Even finding what file…

> A decent LSP makes it trivial to see which function is being called.

We're talking about replacing C here. Requiring everyone depend on a hefty LSP to make sense of source code is a big ask.

Source code is text. I firmly believe that all semantic information of a piece of source code should be expressed as text in said piece of code. I already see code where the language allows the programmer to omit types from variables for 'brevity', and the assumption then is that everyone working on that code is using a fancy enough text editor that can stick in extra labels to show the missing type information. Absolutely baffling to me how people find that acceptable in any way.

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

#247
post #144

Earlier quoted context omitted.

You’re whitewashing history if you think Pascal was superior to C. There was no conspiracy among compiler developers as you imply. Also you complain about semantic richness of C, but then only point to semantically rich languages you despise. A curious reader would wonder: why care about semantically rich languages then? An observant reader would wonder: so aren’t there times where semantic richness is not useful?

Pascal, at least the original specification, does have a few flaws. It was intended to run as P-code in a VM so you wouldn't expect it to be as good as running directly on the hardware. The successor to Pascal, which fixed it's problems, was Modula-2, which is vastly superior to C. Unfortunately by the time it came out and started becoming available, it was too late for it to compete fairly with C. Ada is comparable…

Pascal was and is continually evolving. A strong argument can be made that Object Pascal was the "successor" of Pascal, and that happened in 1985/86. After Apple and Wirth developed Object Pascal, Borland added the OOP extensions to their version soon afterwards. Turbo Pascal had quite a long run, and some are still using it. The Delphi dialect of Object Pascal came out in the early 1990s and Free Pascal came out in the late 1990s.

Many of the so-called issues with Pascal were resolved way back in the mid to late 1980s. In regards to Pascal's competition with C, this arguably evolves around AT&T and Unix. It's AT&T and their huge government, industry, and business influence that pushed C over the top.

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

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

The problem is that there isn't anything to replace C, that would be acceptable enough. C has become a quasi protocol, and used in exchanges between languages. One could argue it's better for newer languages to embrace and excel in interop with C, while providing more advantages, being safer in comparison, or greater ease of use. As is arguably the case with Vlang, Dlang, Nim, etc...

If anything, C may still be going strong for another 20 to 30 years.

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

#249
post #99

I'm trying to build a language that translates directly to C. I will just implement some features of the language in C, with some headers I can already find. It feels like it's the best way I want to do this. That way, a C compiler can do a lot of work I really don't want to do, C already has backends, optimizers, etc etc. All I want is a C-like language with native strings, hash map and list, tuples python indentati…

or Vlang (https://vlang.io/), which can compile to C, and has a C2V transpiler.

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

#250

Earlier quoted context omitted.

You really don't understand, but that's okay. C is a wonderful language, and that's the end of it really. You just try to think C as a language that SHOULD HAVE all the stupid bells and whistles you find convenient. Many of us more advanced coders have found that those stupid bells and whistles are, in fact, inconvenient. Casting to void is a powerful technique and the limits are literally endless. C is semantically…

C is a garbage language. It has a lot of undefined behaviour. It isn't safe. It isn't even strongly typed. It's only marginally better than a macro assembler. C programmers consider that a virtue but programmers who want to write safe, robust code, know C is garbage.

"One man's garbage is another man's treasure."
Post reply on HN