Live data from Hacker News

C meeting is over. C23 added:

twitter.com

331–340 of 363 posts

Re: C meeting is over. C23 added:

#331

C is the only sane language left. It never changes and it lets us write code that just works. We can focus on getting things done and shipping rather than learning new features and Googling compiler errors. Learn once, ship forever.

It’s also upwardly compatible so no messing with code from a deprecated version. Python 2 to python three has this issue. If I need to change my code to make it run on the latest language standard then that is a big red flag for me.

Well said, we should team up!

Re: C meeting is over. C23 added:

#332
post #228

Earlier quoted context omitted.

Huh? What do you think defines “regular C code that works”? Standards. Every compiler you have used operates at a bare minimum on the C standard. That’s why they are often advertised (if not GCC/Clang which are assumed to be up to date) as “C(89|99|11|17) compliant.” “Code that works” is code which is operates under constraints and guarantees specified by a standard, anything else is undefined or unportable.

I'll rather have code that runs on an actual computer than code that should hypothetically run according to a long document that costs 60 dollars to read.

Exactly. You get it 100%. We should work together.

Re: C meeting is over. C23 added:

#333
post #311
post #165

Earlier quoted context omitted.

Right, then comes the day another OS or CPU needs to be supported and some clever developers learn their lesson about language standards during a couple of late nights tracking down production issues.

Seems way more efficient to not care about standards and invest a couple late nights once every five years.

Exactly. You are the real MVP in this thread. We should team up.

Re: C meeting is over. C23 added:

#334
post #106

Earlier quoted context omitted.

Only the standards people care about standards. We (programmers) want to just get things done. We don't care about the standards. No one reads the standards. Also no one cares about portability. All computers have been the same for the last 20 years.

We, developers, care about standards, because we want to get things done once.

[deleted]

Re: C meeting is over. C23 added:

#335

C is the only sane language left. It never changes and it lets us write code that just works. We can focus on getting things done and shipping rather than learning new features and Googling compiler errors. Learn once, ship forever.

Ye the churn is crazy in many languages. I almost had a heart attack when the twitter post stated that "true" and "false" are keywords in C23. However that seems incorrect. On my last workplace we argued if we dared to use stdint.h, since it was so new and fancy. I was a proponent, but there is something calm over discussing whether to use 23 year old additions or not.

Sounds like a dream workplace similar to mine.

Re: C meeting is over. C23 added:

#336

C is the only sane language left. It never changes and it lets us write code that just works. We can focus on getting things done and shipping rather than learning new features and Googling compiler errors. Learn once, ship forever.

The effort required to do anything besides low level utils in C is immense. And once you have it working, how do you know it's correct? You have to carefully review it.

You could write and rewrite everything multiple times in a high level language with that much work.

C libraries break all the time. They change them whenever they want. The standard lib and language might be stable but the large frameworks aren't.

It doesn't seem at all suitable for large application programs.

I do sometimes worry that one day my Python code won't run and 5 year projects will become useless. But so far, popular language aren't showing any sign of going away.

Re: C meeting is over. C23 added:

#337
post #278

Earlier quoted context omitted.

C mandates that arrays have positive size. It's not really a discussion about what the target platform does, rather it's what the abstract C machine mandates.

Oh sure - malloc() returns a pointer to sequentially-addressable bytes, not a C array. So even if the size were greater than 0, it would prove nothing about C arrays.

> ... malloc() returns a pointer to sequentially-addressable bytes ...

malloc () doesn't return even that. It returns 'void *' which isn't of much use without a further upcast. The required upcast, and the rest that follows, is the coder's own idea of what happens.

Re: C meeting is over. C23 added:

#338
post #48
post #35

Earlier quoted context omitted.

The cppreference.com link says it removes "Representations for signed integers other than two's complement" - this could be pretty significant in making many previously implementation-defined programming patterns strictly conforming, but is it true? Doesn't seem mentioned in the Twitter thread.

This is the accepted twos complement proposal: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf It seems like a sensible simplification to me. Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code?

The AGC (Apollo Guidance Computer). This means we won't go to the moon anytime soon ;-)

Re: C meeting is over. C23 added:

#339
post #312

Earlier quoted context omitted.

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.

Portable by definition means it cannot capture every specific detail of every architecture out there.

The carry flag is not a specific architectural detail; it is part of the output from the prime example of a basic electronic circuit that is the digital adder.

Re: C meeting is over. C23 added:

#340
post #313

Earlier quoted context omitted.

Trying to win a pointless argument based on pedantic logic that misses the point.

Usually the typical answer when facts aren't appealing, the other way around apparently being pedantic matters.

Obviously one should always argue to the point instead of picking an interpretation that is easy to refute using "logic".
Post reply on HN