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

131–140 of 257 posts

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

#131

Post by rightbyte »

KerrAvon wrote: post #83
rightbyte wrote: post #43

Earlier quoted context omitted.

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

Ye well Linux is moving from GNU C89 to GNU C11 so maybe it is time for me to move on.

I don't think there is any reason to choose C89 over C11 other than fear of new compiler bugs and compatibility with old compilers?

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

#132

Post by wiseowise »

AlexeyBrin wrote: post #60
siftrics wrote: post #54

Earlier quoted context omitted.

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.

C++ is a sane defaults superset of C.

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

#133

Post by GeorgeTirebiter »

jokoon wrote: 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…

Have you looked at Nim? https://nim-lang.org/

or Zig? https://ziglang.org/

or D? https://dlang.org/

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

#134

Post by sph »

MrLeap wrote: post #120
sph wrote: post #113

Earlier quoted context omitted.

Perl and Ruby are very expressive. Python on the other hand feels like a scripting language designed by a 1990s corporate Java developer. /unpopular-hot-take

I mostly agree with this. I'll come to python's defense though. Python is a gorgeous language wearing an ugly hat. The hat has __multiple out of place brims__, all of which are about two underscores wide.

It's not a hat, it's a snake that swallowed a Java engineer :)

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

#135

Post by lelanthran »

KerrAvon wrote: post #81
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.

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.

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

That's an extraordinary claim indeed; if people outside tech were going to call bullshit on EULAs as a liability shield, they would've done so in the last 50 years of software sales.

Reliability or the lack thereof has never been an impediment to some piece of software getting popular, but to me, you appear to believe that people want more reliability from software than they have been getting thus far.

Your belief is at odds with reality.

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

#136

Post by 3836293648 »

AlexeyBrin wrote: post #60
siftrics wrote: post #54

Earlier quoted context omitted.

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.

C is not a superset of C either. C++ is a superset of a C version, even if they then went on to add stuff that wasn't added to the other

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

#137

Post by antoniuschan99 »

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.

What are your goto sources of knowledge for C? I’m learning it to write embedded stuff and so far it’s mainly the k&r book, one from no starch press, and a udemy course. Thanks!

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

#138

Post by tuatoru »

sph wrote: post #134
MrLeap wrote: post #120

Earlier quoted context omitted.

I mostly agree with this. I'll come to python's defense though. Python is a gorgeous language wearing an ugly hat. The hat has __multiple out of place brims__, all of which are about two underscores wide.

It's not a hat, it's a snake that swallowed a Java engineer :)

The name came from the author's love of Monty Python's Flying Circus, so perhaps it's an experiment in low-key absurdist humor or surrealist art. Like chindōgu[1].

1. https://en.wikipedia.org/wiki/Chind%C5%8Dgu

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

#139

Post by doodlesdev »

sirsinsalot wrote: post #34
hgs3 wrote: post #28

Earlier quoted context omitted.

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…

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.

C is a great language to program a PDP-11 in the 1980s. And that's it. There are SO MANY alternatives for so many different use cases nowadays, it's just hard to justify using C anywhere whatsoever.

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

#140

Post by Someone »

menaerus wrote: post #124
Someone wrote: post #115

Earlier quoted context omitted.

> without operator overloading, it wouldn't be possible to implement lazy evaluation I don’t understand that. You can have functions that return promises that then can get passed to other functions returning promises, and leave it either to the compiler or to an expression evaluator you write (that ideally runs at compilation time as much as possible) to optimize away anything not needed. For example (pseudo-code) ve…

Of course, you can do it that way as well. However the problem with promise approach is that it is introducing extra dynamic memory allocations beneath and these cannot be optimized out or elided. At least, not to my knowledge. With expression templates and operator overloading you're basically avoiding exactly that as much as possible.

Where do you see dynamic memory allocations being needed in that example? I only see locals that a good compiler can fairly easily optimize away.

Also, there’s a simple bijection between expressions with operators and two-argument function calls:

  a + b * c
  +(a, *(b,c))
  plus(a, times(b,c))
Because of that, I don’t understand why operator overloading should give better optimization opportunities than function calls.
Post reply on HN