Hacker News Reader

Comment by quelsolaar | Hacker News Reader

I'm in the wg14, and I made a passionate argument against defer. C is all about simplicity and clarity, over conviniance. Defer, is an invisible jump, its much better using a goto, that clearly denotes a change in flow. In C everything should be as clear and as explicit as possible. Nothing should happen without the user explicitly saying so. This means more typing, and thats fine, there are plenty of languages that offer loads of syntax sugar if thats what users want, but only C offers clarity.

View on HN

Thank you so much for your work! Your comment made me happy and warm inside, as if there's still some order in this crazy world. As if there's still a few sane and robust things that we can attach ourselves to, knowing that they will not break.

How can we support/encourage you? (in case you need it)

Speaking up is a good start! The support is much apprechiated!

Did you get rid of longjmp() too? longjmp() is far more perilous for similar reasons and purposes.

Defer is useful for code clarity in many situations IMHO, and it's easy enough for a project or code QA tool to ban its use for those that don't like it.

And think he should push to get rid of terrible things like stdint and designated initializers too.

Surely <string.h> is the first standard header to execute?

If C is simple and clear why is it fraught with pitfalls? While C code can be nice and clear to read that doesn’t mean there less mental burden on the developer to keep track of everything going on.

I would argue that there is less mental burden, if you stay within some simple limits. C has a lot of complexity if you push its limits, mainly because it is so old and the limits have been pushed in ways they havent in other languages. C has to run on very strange platforms and has many many implementations, and so much code depending on it. This makes it very hard to maintain. If two large C compilers do things slightly different and very important software depends on those behaviours, then its very hard to make a "Clean" fix without breaking lots of software.

The argument against "Why dont they just fix X?" usualy commes down to: it would break millions of lines of code, make every C tutorial/book obsolete and force millions of C programmers to learn new things, not to mention that if we broke the ABI, we would break almost every other language since they depend on Cs stable ABI. Breaking C would literaly cost tens if not hundreds of billions of dollars for the industry.

Look at the move between Python 2 and 3. The cost of breaking bakwards compatibility have probably been astonomical, and then there is way less Pyton code being maintained then C code.

C operates on a scale that is almost unfathomable. A 1% perfomance degredation, in C will have ameasurable impact on the worlds energy use and co2 emissions, so the little things really matter.

C programmers claim some things that are simply not true: 1) simplicity - C is not a simple language, it is a language lacking advanced features which does not make it simple to use but it might be easier to create incomplete non-performant C compiler than compiler for better languages 2) performance - C naive/straight forward/clear implementations are not the most performant and most of the C programs are not highly optimised for performance, C compilers have had so much optimisation work done on them that they can actually generate decently performant code but if better languages received same level of effort as what C had they would be able to achieve better performance than C with smaller and safer code 3) clarity - C is not clear to read once structs and pointers are used and specially once it is optimised for performance...and then there is the preprocessor...which is a whole different language that is required to make any non-hello-world program even possible If I have to provide examples for any of the above you are either not a C programmer or you are an "advanced" C programmer that doesn't have to deal with large code bases and instead deals with small pieces and someone else takes care of the rest. I mean, just try to figure out what long int is on Linux without compiling a program and tell me that C is simple and clear language...and if you are still clinging on that lie then tell me what a struct looks like in memory so I can interface to it from another language...or even another C compiler...because C is simple and clear, right?

Not the OP, but you are conflating two very different ideas under a singular definition.

C is "simple" in the same way DNA is "simple". There is a small set of very straightforward rules, but that set provides immense flexibility. But it in no way means that any resulting object will not be complicated. Perhaps a better word than "simple" would be "non-complex", making the distinction between "complex" vs "complicated" systems.

By contrast, the features you refer to would increase the "complexness" of the language (I won't even dare use the grammatically correct word "complexity" here, lest we deviate into yet another trap of conflating definitions).

Which, I would agree with OP is, for better or worse, probably far outside C's goals as a language.

This has nothing to do with C, and everything with its intended problem domain.

You can get into pointer and memory errors in C++, Rust and Ada. All of them low-level system languages. Sure, those errors might be harder to produce, but not impossible, and definitely easy enough to still trip you up.

I programmed in all of those languages, except Rust (just don't like it). At least in C you pretty much now WHY (not necessarily where in the code) things went south, without consulting a thousand page specification or having to remember the myriad of language feature interactions that could have triggered those problems.

Moreover, C being small, it's a good on/off language. Try doing a code review for a C++/Rust/Ada code base which uses features heavily after not having touched the language for a year. I bet it is not as easy as C.

You know, some things in life are just hard. And low-level programming is one of those things. C is only honest about this.

Will promotion of arithmetic results to int be removed, since this is generally a force against simplicity and clarity?

I think this is the right approach. You can make C better without trying to compete with newer languages.

Yeah, why bother competing with newer languages on safety, that was never something that mattered on C's design.

> simplicity and clarity ...

It may be deceptive. Just look at how various compilers or even the same compiler with different options interpret the same C code.

> as explicit as possible

C is not assembler.

> Nothing should happen without the user explicitly saying so.

Umm, why is typing something like defer (and documenting what it does) different than typing something like goto (and documenting what it does)?

Frankly, not being comfortable with adding safe and efficient abstractions to a language will result in the death of the language (both for spoken languages and also for programming languages).

> Umm, why is typing something like defer (and documenting what it does) different than typing something like goto (and documenting what it does)?

Because goto is explicitly declaring a control flow where defer causes implicit control flow in code that does not explicity declare it. That's a meaningful difference that the OP was trying to specifically avoid regardless of whether you care about it.

Why is "defer" not considered "explicitly declaring control flow" if the documentation describes it correctly?

Because the control flow happens implicitly at the end of the block, not explicitly as with goto, loop, if-statements, etc. A deferred statement can also have arbitrary time and space complexity, so it's not like a variable going out of scope at the end of a block which is constant time. It furthermore requires invocation of all deferred statements while unwinding the stack upon calling exit(). See the details here:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2589.pdf

> Because the control flow happens implicitly at the end of the block

Why is this different than any loop in C? or function without a return? Wouldn’t it be more explicit and very minimal overhead to instead always use a goto at the end of a looping block?

Even tho C allows while loops (as a mistake - all control flow should be explicitly defined at the end of the block), why aren’t you - as a best practice - using an explicit goto and if block instead of while / for?

> Why is this different than any loop in C? or function without a return?

Because it's non-local control flow. Did you just ignore my whole comment where I pointed out where cases like exit() unwinds the stack, invoking deferred block in each caller up the call chain back to the root? Does for/while do that?

I really did read it, I just really believe that your biases are clouding your critical thought about this.

> invoking deferred block in each caller up the call chain back to the root

Yes if the caller writes N defers in the same function or across M functions then the code will run N defers.

Why is this any different than nesting N loops, in the same function or across M functions? It’ll still run N end of block control flow statements without them being “explicit”.

At the end of the day “explicit” typically is really just a replacement for saying “familiar with the previous documentation, don’t change things”.

Anyways, that’s all I can put into this conversation. Please just try to consider that you’re conflating familiarity with simplicity and leverage System 2 to really ask yourself if what you’re favoring is valuable to the group or just the NIMBY.

I honestly can't summarize the extra runtime complexity any more clearly than I already have. The original poster was very clear about keeping the runtime complexity down for various well-motivated reasons. They are correct that if you want more runtime support for high-level features, then C is perhaps not the language for you.

Reply on news.ycombinator.com