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

Two types of C programmers

utcc.utoronto.ca

Post reply on HN
Print view View original

191–200 of 225 posts

Re: Two types of C programmers

#191

Post by galaxyLogic »

lelanthran wrote: post #155
cat_plus_plus wrote: post #94

Earlier quoted context omitted.

C is not aligned with modern hardware and optimizing compilers are severely hampered by things like undeclared pointer aliasing.

> C is not aligned with modern hardware and optimizing compilers are severely hampered by things like undeclared pointer aliasing. Which language is? I mean, if you're going to parrot this line, surely you have an example of a language that is more closely aligned to hardware than C, right? I see this line repeated in every HN thread about C. It's not a new sentiment, but it is mostly wrong because the implication is…

A language can not be exactly aligned to every possible hardware variation at the same time of course. So C does dome abstracting from the hardware level but keeps the mental model of memory locations which can be pointed to by pointers.

Re: Two types of C programmers

#192

Post by lelanthran »

galaxyLogic wrote: post #191
lelanthran wrote: post #155

Earlier quoted context omitted.

> C is not aligned with modern hardware and optimizing compilers are severely hampered by things like undeclared pointer aliasing. Which language is? I mean, if you're going to parrot this line, surely you have an example of a language that is more closely aligned to hardware than C, right? I see this line repeated in every HN thread about C. It's not a new sentiment, but it is mostly wrong because the implication is…

A language can not be exactly aligned to every possible hardware variation at the same time of course. So C does dome abstracting from the hardware level but keeps the mental model of memory locations which can be pointed to by pointers.

> A language can not be exactly aligned to every possible hardware variation at the same time of course. So C does dome abstracting from the hardware level but keeps the mental model of memory locations which can be pointed to by pointers.

Sure, and I agree with you, but anyone complaining that the language which models hardware more closely than any other language, "doesn't model the hardware" should be prepared for the followup question of "Well, which other language in common use is closer to the hardware?"

It's really tiring reading the same old assertions in every thread about C; usually backed up by the same two or three sources that everyone has already read.

Re: Two types of C programmers

#193

Post by SleepyMyroslav »

kragen wrote: post #174
tialaramex wrote: post #163

Earlier quoted context omitted.

You're correct that 4 - 5 isn't undefined in C . But there's a good reason that Rust, for example, chooses not to make its built in integer types (either signed or unsigned) wrap on overflow. Wrapping is very easy for a typical processor to implement but in most cases overflow is a mistake, so you want to report it not silently give the wrapping answer instead when the programmer apparently hasn't considered overflow…

what i'm arguing is that c compilers exist primarily to support the base of existing c code and to run it correctly and with adequate performance, not out of some unhinged notion of 'competitiveness' or to entice people into writing new programs in it that is, i do think it's acceptable to have code that's harder to write and with worse performance, but not because of some hypothetical; rather, it's because that's ho…

I think you need to reevaluate what happens to code once optimizations are turned on. Especially if you can afford to do test guided PGO combined with LTO. There is nothing in common between how code is executed with optimization and what were programmers writing years ago. It is like 5-10 levels of functions are just gone and completely restructured by compiler. I do not see middle ground if people want to keep the performance. Old C++ and likely C that failed to optimize is just gone at the moment.

Whatever legacy code has to be "preserved" is likely to be specifically deoptimized to keep it in frozen state.

PS I come from gamedev and I really wish compilers left us control of what is going on there.

Re: Two types of C programmers

#194

Post by throwawaymaths »

gavinhoward wrote: post #190
throwawaymaths wrote: post #188

Earlier quoted context omitted.

Ok? The universe of all code that can be created by the zig compiler is strictly bounded for any given project at any given time, the halting problem does not apply. At worst, you can do an exhaustive search. The context that you're running the code in can ultimately be known, and the pointer can be set to the appropriate version based on calling context.

No, you can't do an exhaustive search. Say you're a library author. You distribute pre-built library files. You've already lost because the compiler does not know your clients' code when it compiles your library. I am not kidding when I say it's provably impossible .

"pre-built library files" are not a thing in zig right now, unless you use the c abi, which doesn't have async?

Even supposing zig had prebuilding someday, you would probably have to extern it using async directly declared in the callconv (.async is an option in callconv) and so yes, the compiler would know. It's just that currently zig has a lot of "let the compiler figure out". Maybe that's what's making you uncomfortable?

I'm pretty sure the zig compiler is finite and deterministic, so sophistry around the halting problem doesn't apply.

Re: Two types of C programmers

#195

Post by gavinhoward »

throwawaymaths wrote: post #194
gavinhoward wrote: post #190

Earlier quoted context omitted.

No, you can't do an exhaustive search. Say you're a library author. You distribute pre-built library files. You've already lost because the compiler does not know your clients' code when it compiles your library. I am not kidding when I say it's provably impossible .

"pre-built library files" are not a thing in zig right now, unless you use the c abi, which doesn't have async? Even supposing zig had prebuilding someday, you would probably have to extern it using async directly declared in the callconv (.async is an option in callconv) and so yes, the compiler would know. It's just that currently zig has a lot of "let the compiler figure out". Maybe that's what's making you uncomf…

Wat.

The Zig compiler is finite and deterministic, yes, but that's not the problem.

The problem is that user code is not finite nor deterministic.

Even worse, Zig's compiler may be deterministic and finite, but the language is not, by far. In fact, the language is one of the most infinite languages in existence because just the type system is uncomputable! [1]

(In this context, the word "undecidable" used by that source means "uncomputable".)

If the type system is uncomputable, then the type system will never be able to resolve all uses of function pointers everywhere.

The whole point of the Halting Problem is that you could have a finite and deterministic Turing Machine that runs other Turing Machines, and that finite and deterministic Turing Machine could run into situation where it never halts.

I never say this when people ask (because most people don't understand), but the real reason I don't like Zig is because of how infinite the language is, starting with its uncomputable type system.

This makes Zig one of the most unreasonable [2] programming languages in existence.

If you don't believe me, ask the Zig team how they plan to solve this problem. Don't ask them if they plan to solve it; ask them how.

Then if they reply, email me [3] with their proposed solution, and I will destroy it. I will do that no matter how many solutions they come up with because math says I will always win.

But if they say they can't, will you believe them?

[1]: https://3fx.ch/typing-is-hard.html#zig

[2]: https://fsharpforfunandprofit.com/posts/is-your-language-unr...

[3]: https://gavinhoward.com/contact/

Re: Two types of C programmers

#196

Post by kragen »

SleepyMyroslav wrote: post #193
kragen wrote: post #174

Earlier quoted context omitted.

what i'm arguing is that c compilers exist primarily to support the base of existing c code and to run it correctly and with adequate performance, not out of some unhinged notion of 'competitiveness' or to entice people into writing new programs in it that is, i do think it's acceptable to have code that's harder to write and with worse performance, but not because of some hypothetical; rather, it's because that's ho…

I think you need to reevaluate what happens to code once optimizations are turned on. Especially if you can afford to do test guided PGO combined with LTO. There is nothing in common between how code is executed with optimization and what were programmers writing years ago. It is like 5-10 levels of functions are just gone and completely restructured by compiler. I do not see middle ground if people want to keep the…

inlining code and most code-movement optimizations are among the many optimizations that don't require the kind of nasty tricks with undefined behavior that i'm criticizing, and it's been common practice for decades; c++ has depended on method inlining to get acceptable performance since the 80s

it's kind of a pain if you're stepping through the code in gdb but that's acceptable

turning off optimization entirely is still too costly for most cases

Re: Two types of C programmers

#197

Post by kragen »

GoblinSlayer wrote: post #176
tialaramex wrote: post #163

Earlier quoted context omitted.

You're correct that 4 - 5 isn't undefined in C . But there's a good reason that Rust, for example, chooses not to make its built in integer types (either signed or unsigned) wrap on overflow. Wrapping is very easy for a typical processor to implement but in most cases overflow is a mistake, so you want to report it not silently give the wrapping answer instead when the programmer apparently hasn't considered overflow…

C already has bad performance due to null terminated strings.

no

Re: Two types of C programmers

#198

Post by kristoff_it »

gavinhoward wrote: post #195
throwawaymaths wrote: post #194

Earlier quoted context omitted.

"pre-built library files" are not a thing in zig right now, unless you use the c abi, which doesn't have async? Even supposing zig had prebuilding someday, you would probably have to extern it using async directly declared in the callconv (.async is an option in callconv) and so yes, the compiler would know. It's just that currently zig has a lot of "let the compiler figure out". Maybe that's what's making you uncomf…

Wat. The Zig compiler is finite and deterministic, yes, but that's not the problem. The problem is that user code is not finite nor deterministic. Even worse, Zig's compiler may be deterministic and finite, but the language is not, by far. In fact, the language is one of the most infinite languages in existence because just the type system is uncomputable! [1] (In this context, the word "undecidable" used by that sou…

> If you don't believe me, ask the Zig team how they plan to solve this problem. Don't ask them if they plan to solve it; ask them how.

The Zig compiler has a counter that describes the maximum allowed amount of branching that the compiler can do while evaluating comptime code. The counter can be manually set to a higher value but all compilations will eventually fail if your comptime logic is too loopy. In practice the guideline is to not overuse comptime and instead create a dedicated build step for things like creating pre-computed value tables.

> Then if they reply, email me [3] with their proposed solution, and I will destroy it. I will do that no matter how many solutions they come up with because math says I will always win.

cringe

Re: Two types of C programmers

#199

Post by Spex_guy »

gavinhoward wrote: post #195
throwawaymaths wrote: post #194

Earlier quoted context omitted.

"pre-built library files" are not a thing in zig right now, unless you use the c abi, which doesn't have async? Even supposing zig had prebuilding someday, you would probably have to extern it using async directly declared in the callconv (.async is an option in callconv) and so yes, the compiler would know. It's just that currently zig has a lot of "let the compiler figure out". Maybe that's what's making you uncomf…

Wat. The Zig compiler is finite and deterministic, yes, but that's not the problem. The problem is that user code is not finite nor deterministic. Even worse, Zig's compiler may be deterministic and finite, but the language is not, by far. In fact, the language is one of the most infinite languages in existence because just the type system is uncomputable! [1] (In this context, the word "undecidable" used by that sou…

> If the type system is uncomputable, then the type system will never be able to resolve all uses of function pointers everywhere.

Can you elaborate on what you mean here, and the problems this might cause? Do you mean that some function pointers cannot be resolved to concrete functions? Or that the process of evaluating comptime may be infinite? Or some other problem where the compiler can't determine whether a function pointer is needed for a given function?

Re: Two types of C programmers

#200

Post by int_19h »

lelanthran wrote: post #156
rwmj wrote: post #41

Earlier quoted context omitted.

Operating systems don't "win" because they make the best technical choices ... or even because they are best for their users.

Maybe, but when all the winning OSes share a common characteristic then you cannot simply dismiss that characteristic as irrelevant to winning without some evidence that it is not relevant.

The winning characteristic in this case is "it was already there, and it was good enough". This is a recurring theme in the industry.
Post reply on HN