Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

streaming.media.ccc.de

Post reply on HN
Print view View original

101–110 of 257 posts

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

#101

Post by matheusmoreira »

KerrAvon wrote: post #76
sirsinsalot wrote: post #34

Earlier quoted context omitted.

Anyone discouraging a particular tool without actual context of the problem being solved gets zero respect from me. It's a massive red flag that they don't know enough to be useful. C is great for the things C is great for, however small that range may or may not be now and in the future. Any other stance is reductive and misleading.

Exactly what, in the year 2023 C.E., is C great for? I’ve been writing C since 1991 and I can’t think of anything where I wouldn’t start a new project in some other language. There are many interesting choices of varying maturity in the low-level systems programming space: Zig, Rust, Crystal, D, Swift (if the standard library ever gains support for system-level programming). Even the “better C” subset of C++ will all…

> Exactly what, in the year 2023 C.E., is C great for?

Writing readable code. I'm a huge fan of Zig and Rust too but at the end of the day they just aren't C.

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

#102

Post by bonzini »

fncslothouber wrote: post #89
KerrAvon wrote: post #76

Earlier quoted context omitted.

Exactly what, in the year 2023 C.E., is C great for? I’ve been writing C since 1991 and I can’t think of anything where I wouldn’t start a new project in some other language. There are many interesting choices of varying maturity in the low-level systems programming space: Zig, Rust, Crystal, D, Swift (if the standard library ever gains support for system-level programming). Even the “better C” subset of C++ will all…

Memory safety / security is important for a subset of all possible applications. It is not important for _all_ applications. If I use a micro controller to control a string of leds I do not care about security/memory safety. But I do care about being as close to the metal as possible, and being able to understand the compiled code.

To control a string of LEDs, something like Forth (or some other p-code virtual machine) is going to be just as good as C. PIC microcontrollers have always had BASIC as an option for example.

But many microcontrollers these days will likely have a TCP/IP stack, perhaps even crypto, even if it is to control a string of LEDs via MQTT or Modbus TCP.

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

#103

Post by Ygg2 »

pantalaimon wrote: post #26
pjmlp wrote: post #16

Earlier quoted context omitted.

It won't go away, but just like it happens with COBOL, Fortran, and PL/I, you won't see anyone dreaming of coding C until the end of their working days. Or maybe they will, given how much consultants in those languages happen to be paid, as no one else wants to touch them.

But coding C is actually fun!

Sure. But debugging sure isn't. Null, null terminated strings, data races, segfaults...

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

#104

Post by WalterBright »

WastingMyTime89 wrote: post #67
sn41 wrote: post #61

Earlier quoted context omitted.

> that’s pretty much it. Only if you ignore 1. variadic arguments as in printf, 2. function pointers which are a very elementary (type-unsafe) form of closures, 3. a nice way of casting to void 4. setjmp and longjmp goodies (?) which allow you to code up co-routine libraries and exception handling mechanisms I'm sure there are more such facets I am missing. The elegance of the specification may be questionable, but t…

There is no elegance there. Casting to void is not a plus. That’s just C having no proper type system. Function pointers as an elementary form of closures, come on, what’s next? Closures are defined by capture. It’s nearly as fun as pretending C as coroutines because of setjmp . How can a statement like C being semantically poor even be seen as controversial? For god sake, we are talking about a language which semant…

Much of what you say is true. But I came to C from Pascal. Pascal circa 1982 was unusable without all the numerous extensions each vendor tacked on. C worked out of the box. I could get things done in C without constantly fighting the Pascal and Fortran compilers of the day. This was true despite the terrible C compilers of that time.

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

#105

Post by Wadajot »

fjfaase wrote: 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.

> that happens to be programmed in Fortran.

SciPy is a highly optimized library and Fortran is faster than C for some tasks:

https://stackoverflow.com/a/146186/3383640

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

#106

Post by ptx »

fncslothouber wrote: post #89
KerrAvon wrote: post #76

Earlier quoted context omitted.

Exactly what, in the year 2023 C.E., is C great for? I’ve been writing C since 1991 and I can’t think of anything where I wouldn’t start a new project in some other language. There are many interesting choices of varying maturity in the low-level systems programming space: Zig, Rust, Crystal, D, Swift (if the standard library ever gains support for system-level programming). Even the “better C” subset of C++ will all…

Memory safety / security is important for a subset of all possible applications. It is not important for _all_ applications. If I use a micro controller to control a string of leds I do not care about security/memory safety. But I do care about being as close to the metal as possible, and being able to understand the compiled code.

If people rely on the LEDs working correctly or if the controller has any kind of connection to another system (which could be leveraged by an attacker to penetrate deeper into the network) it seems to me that security and memory safety would still be important.

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

#107

Post by jacquesm »

FpUser wrote: post #88
jacquesm wrote: post #5

Great talk. Borland should have rated a mention though, their C compiler really popularized C development on Windows.

It is a real shame Borland went form the company providing best and affordable development tools ever to some big enterprise would have been but nobody needed it and to oblivion.

Yes, it is. Philippe Khan also strikes me as an all around sympathetic guy and a true serial entrepreneur in the original sense of the word.

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

#108

Post by titzer »

WastingMyTime89 wrote: post #52
antirez wrote: 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.

C would be a better language if it really lived up to its old ideal of being a "portable assembly language". That stopped being true as compilers started optimizing undefined behavior (e.g. signed overflow). Instead of a "+" in the source code yielding an honest-to-goodness hardware add instruction, it could be "optimized"--i.e. constant folded, CSE'd, strength-reduced, value-range-analyzed, among others--by an optimizing compiler in ways that completely ignore what the hardware instruction actually does upon overflow. That meant the C language became more like a vague suggestion of assembly and it became pretty much impossible to code to the machine anymore.

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

#109

Post by menaerus »

Conscat wrote: post #100
camel-cdr wrote: post #92

Earlier quoted context omitted.

How so? To me, operator overloading seems like a non feature, that at best create more ambiguity.

Without it, you cannot express arithmetic wrappers or simd wrappers. So far, no language with any users has managed to provide adequate arithmetic and simd types built in, despite several attempts like Odin and CosmiC/HolyC. I'm not sure it's even possible to design such types that satisfy everyone, and they must be extensible somehow because satisfying anyone is a moving target. Note how terrible doing any amount of…

Also without operator overloading, it wouldn't be possible to implement lazy evaluation, which along with the use of expression templates happens to be one of the most crucial aspects that any linear algebra library will want to take advantage of in order to generate the most optimal code.

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

#110

Post by WalterBright »

Decabytes wrote: post #8
fjfaase wrote: 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.

I think it will go when we have a sufficiently popular and useful systems programming language that will replace it. It has to be a language that isn't just C with some extra bits, which is why SafeC and CheckedC aren't more popular. I actually think the closest language will be Zig. It's a much simpler language than Rust and people who like C really value that simplicity. It also removes a lot of Cs baggage that mak…

D (in betterC mode) is C but with proper arrays, modules, advanced metaprogramming, member functions, lots of memory safety features, compile time function execution, nested functions, etc.
Post reply on HN