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

The Problem with C (2020)

cor3ntin.github.io

Post reply on HN
Print view View original

171–177 of 177 posts

Re: The Problem with C (2020)

#171

Post by pjmlp »

loup-vaillant wrote: post #118
pjmlp wrote: post #93

Earlier quoted context omitted.

The compilers might have them, yet the large majority doesn't care they exist. Unless devops plugs them into the CI/CD pipeline with -Wall -Werror, most people will keep coding as they ever did. Why do you think Google is sponsoring KSPP and pushing C cleanups of bad code, despite all review processes that the kernel has?

Goodness, I'm running a zero-warning policy with -Wall -Wextra all the time . They have removed tons of bugs in my code before I even touch the first sanitizer, they're my first line of defence.

Here a hard reality of how much people care,

https://blog.jetbrains.com/clion/2021/07/cpp-ecosystem-in-20...

You will find similar results in other surveys.

Re: The Problem with C (2020)

#172

Post by [deleted] »

bear8642 wrote: post #169
Koshkin wrote: post #155

Earlier quoted context omitted.

But K&R C was (aesthetically) more perfect. ANSI could not live with that, apparently.

You mean no function prototypes or just the idea that declarations defaulted to int? Only used ANSI so wondering what excellence of K&R C mean

[deleted]

Re: The Problem with C (2020)

#173

Post by Koshkin »

bear8642 wrote: post #169
Koshkin wrote: post #155

Earlier quoted context omitted.

But K&R C was (aesthetically) more perfect. ANSI could not live with that, apparently.

You mean no function prototypes or just the idea that declarations defaulted to int? Only used ANSI so wondering what excellence of K&R C mean

Both. Note that a huge amount of groundbreaking code had been written in K&R C before someone decided that it was "not good enough."

Re: The Problem with C (2020)

#174

Post by badsectoracula »

pjmlp wrote: post #140
badsectoracula wrote: post #138

Earlier quoted context omitted.

DBus is an IPC protocol, it is the first thing the specification[0] mentions, there isn't any way where it would make sense for it to be used in-process nor the spec provides for such functionality. Some higher level library could potentially provide an API for exposing and consuming (object) interfaces that can be accessed either in-process or out-of-process, though only the latter would really be using DBus and the…

2h30m before of your comment, I already acknowledged my mistake, you could have saved yourself some typing.

Oops, it was in another reply and i didn't notice it.

Re: The Problem with C (2020)

#175

Post by phendrenad2 »

unwind wrote: post #14

As a long-time C aficionado, part-time wanna-be language-lawyer, and just general supporter and fan, the fact that there is no C conference was interesting. I guess I knew that, because if there was such a conference I would have known, at least I would like to think that. On the other hand I've never been to a programming language conference (probably self-fulfilling by being primarily a C programmer at heart) so it…

I wonder if the reason for there being no C language conference is: It's generally accepted that C is "dead" or should become dead. In fact at C++ conferences you will see many anti-C talks:

* https://youtu.be/YnWhqhNdYyk

And also talks promoting proselytizing to C programmers and bringing them to C++:

* https://youtu.be/D7Sd8A6_fYU

And of course, now, Rust is supposed to supplant C.

Re: The Problem with C (2020)

#176

Post by BenjiWiebe »

BirAdam wrote: post #119
gk1256 wrote: post #107

C is a terrible language. You have to reinvent everything on it. The simplicity is just a lie. C++ on the otherhand is way simple to use and really straightforward. I like Zig too.

By “reinvent everything,” I believe you mean to say that you have to make your own linked-lists to have adjustable strings, and you have to create structs with function pointers to have objects… The simplicity is either in the language and tooling around the language, or it is in the code you read and write in that language. C chose to be simple in the language itself and not in the code. The single greatest praise t…

Why would you put function pointers in structs? The function still needs to be handed the struct when called (no 'this'), and every time you instantiate the struct you need to set the function pointers to the correct thing again.

It gains you approximately nothing, as far as I can tell.

Re: The Problem with C (2020)

#177

Post by jstimpfle »

pjmlp wrote: post #72
scoutt wrote: post #66

Earlier quoted context omitted.

Let's see what (and how it) lands in C2x. Of course, as any other language, C might be taken over in the future by a new generation and be bloated , too. But so far, it is contained. In any case, nobody can deny the amount of bloat in C++ has no parallel. > Naturally at this point one could ask why not just use C++ instead I might do, in a limited and simpler form, as I said before. Of course I am not developing some…

There is no denial about that, except most languages suffer from similar bloat. When people count the amount of pages on ISO C++, they forget to include the standard library on the process. Which on C's case it includes the expectation that POSIX is also available.

This is one example of bending over backwards to claim things that are obviously wrong, no useful discussion to have here.
Post reply on HN