Live data from Hacker News

C meeting is over. C23 added:

twitter.com

301–310 of 363 posts

Re: C meeting is over. C23 added:

#301
post #161

Earlier quoted context omitted.

I'm really starting to believe that there's a cohort of modern programmers that only see programming languages in terms of the high level syntactical features they provide. The logic of it is something like: I write the code, I run a command written using similar code, scenes deleted, my program runs and my IDE tells me if there are problems in my code. This is sometimes defined as the difference between developers a…

It was already irrelevant when using MS-DOS with Turbo Pascal/Modula-2/Basic compilers, or Mac OS (originally written in Object Pascal/Assembly). It was UNIX industry adoption, followed by GNU Manifesto that made to more relevant than it should ever have been.

So, it's not relevant, but then it's more relevant?

Well, sure, merit and popularity rarely align, and one with enough technical culture can always imagine a better world.

Re: C meeting is over. C23 added:

#303
post #186
post #107

Earlier quoted context omitted.

In C it's possible (and, to some level, very much encouraged) to write your own things to replace whatever built in thing you don't like for whatever reason, be it speed, size, portability. C not having fancy built-in structures means programmers are more careful about choosing simple ones, which dramatically cuts down the amount of completely pointless generated code. -O3 can optimize registers and maybe memory read…

> C not having fancy built-in structures means programmers are more careful about choosing simple ones Resulting in linked lists everywhere which have pretty terrible performance characteristics. You should be worried about those way before the occasional vector push reallocation cause you any problem. (And you can specify initial capacity so there is that)

I don't think I've ever used a linked list in 12 years of embedded C programming.

Re: C meeting is over. C23 added:

#304
post #245
post #240

Earlier quoted context omitted.

What is C's abstract model for NEON?

A simple c library: https://github.com/projectNe10/Ne10 You have not yet shown an argument for why c is not a portable assembly.

Access to CPU-specific flags like the carry flag. When doing a multiple-precision addition, if the CPU carry bit is inaccessible, then it must instead be compared to the result to see if it overflowed, which takes 3-5 more instructions per limb or worse on modern superscalar processors that are serial in terms of data accesses.

Re: C meeting is over. C23 added:

#305
post #184

Earlier quoted context omitted.

Adding so-called fat pointers to C that could be bounds checked would probably instantly eliminate a large fraction of all security issues. Of course, you can emulate these yourself, it's just a struct but not everyone does.

C99 introduced variable-length array parameters and variable-length array pointers together with variable-length arrays (VLA). These take another parameter or variable as a length-parameter. These became optional in C11 together with VLAs (for some reason) but are supposed to again become mandatory in C23. However (yet, for some reason) the pointers can (in the latest published draft, still) only be inside procedures…

Compilers can already do this:

https://godbolt.org/z/jMMa8n48r

Yes, putting them into structs is a missing feature. It is not in the draft because no compiler can do it and their is no implementation experience. I am working on it.

Re: C meeting is over. C23 added:

#307
post #153

Finally C catches up with Algol 60 boolean types, it only took 60 years. Maybe in another 60 it will get proper strings and arrays.

C has had a true Boolean type for over 20 years now, since C99. This time around they're merely dumping the backwards-compatible _Bool/_True/_False syntax + keyword-like #defines in , and replacing it all with proper keywords.

That said, it would be nice if C caught up with Algol 68, seeing how that's the one many of the concepts (and the corresponding keywords) are taken from. Let's start with first-class functions...

Re: C meeting is over. C23 added:

#308
post #247
post #237

Earlier quoted context omitted.

It follows that the Web made JavaScript unavoidable, then nodejs made it available everywhere else. Likewise UNIX made C unavoidable in systems programming for timesharing servers, eventually like JavaScript outgrew the browser, certain people wanted to run C in their microcomputers.

I don't disagree with you on C being popular because of UNIX. I do disagree if you believe this is the only reason why it still enjoys popularity. And you are selling the UNIX authors short if you think they chose C just for the fun of it.

The UNIX authors didn't choose C; they made it, specifically to make UNIX. And, much like the original UNIX itself, it was a hack - because they were trying to make do within the limits of their hardware. So, some of the syntax is the way it is because it was simpler to parse, for example. And some of the semantics was originally "because PDP does that".

As for why C has staying power, that's solely a function of its early success. There's nothing about the language itself that isn't better provided for by some of its historic competitors (e.g. Modula-2). But there's a self-reinforcing loop here, where all new hardware platforms start with C as a basis because it lets you write all the existing code; and conversely, using C is the way to ensure that your code will work even on future platforms.

Re: C meeting is over. C23 added:

#310
post #37

Based on another thread - I think the following topic should be an interesting one for HN to chew on: If someone wanted to write systems type of programming (whether it be embedded or Unix tools or even writing a library), should they go for C (C23) or Rust today?

There's also Zig to consider here, and it arguably competes more directly and explicitly with C than Rust does.
Post reply on HN