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

81–90 of 257 posts

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

#81

Post by KerrAvon »

pjmlp wrote: post #16
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.

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.

C has enough actual fans that I bet it never really goes away, but it won’t be useable in professional contexts after a while other than for maintenance, because people outside tech will start to call bullshit on the EULA liability shield.

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

#82

Post by andsoitis »

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

- ...

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

#83

Post by KerrAvon »

rightbyte wrote: post #43
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.

> you won't see anyone dreaming of coding C until the end of their working days. I do dream about that. Just being able to tag along while some programmers learn their Xth framework as a language. Maybe someday I might concede and move on from C89 to C99.

If I may ask, what projects do you work on where C89 is still useful? Embedded ROMs for tiny processors in some niche segment?

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

#84

Post by Koshkin »

siftrics wrote: post #54
nikbackm wrote: post #48

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.

Operator overloading is the one thing that makes C++ strictly better than any language that does not allow it.

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

#85

Post by Koshkin »

hgs3 wrote: post #28
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.

C is the best abstraction for many problem domains and that isn't going to change. I understand why folks coming from higher-level languages would dislike it, but for anyone coming from assembly it's a godsend. The speaker discourages C for new projects, but that says more about the problem domains they work in than C itself. C is what it is because the hardware and assembly language are what they are. Folks who want…

> C is the best abstraction for many problem domains

It's really not, though. What C is an abstraction of is computer architecture as it existed by the late 1960s.

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

#86

Post by Koshkin »

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…

> C.E.

There.

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

#88

Post by FpUser »

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.

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

#89

Post by fncslothouber »

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…

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.

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

#90

Post by enedil »

sn41 wrote: post #61
WastingMyTime89 wrote: post #52

Earlier quoted context omitted.

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.

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

Closure is not an anonymous function. It "encloses" variables that were in scope at the point of closure creation. Therefore function pointers cannot serve that purpose as is.
Post reply on HN