Email or username:

Password:

Forgot your password?
Björkus "No time_t to Die" Dorkus

>

"… not to be all "conservation of energy" here but when someone tells you they've eliminated complexity, it usually means the complexity is now someone else's problem. …"

THAT'S RIGHT YOU TALK TO 'EM TEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEF!!!!!!!

cohost.org/tef/post/2503472-co

mastodon.social/@tef/110919398

13 comments
Björkus "No time_t to Die" Dorkus

Incidentally, this is one of the central points of the Go article that keeps getting posted to HN and causing a flamewar each and every time from
@fasterthanlime; Go reduces complexity and makes things "simple" by just making it your/someone else's problem.

And it's absolutely not any better in terms of workability or final product.

Björkus "No time_t to Die" Dorkus

@fasterthanlime Ostensibly, this is also one of C's chief issues. It's not simple; it just took the hard bits and says

"Go Fuck Yourself"

every time you want to try to address them in any meaningful fashion. We've fixed some of that in recent versions, but like... it's a running theme that we either just paper over complexity, or -- in the worst case -- shove all that complexity raw into the user's hands and tell them to figure it the hell out themselves. And it's brutal and often not helpful because a lot of that complexity comes from implementation-defined or undefined/unspecified characteristics that are under-documented or not at all documented.

@fasterthanlime Ostensibly, this is also one of C's chief issues. It's not simple; it just took the hard bits and says

"Go Fuck Yourself"

every time you want to try to address them in any meaningful fashion. We've fixed some of that in recent versions, but like... it's a running theme that we either just paper over complexity, or -- in the worst case -- shove all that complexity raw into the user's hands and tell them to figure it the hell out themselves. And it's brutal and often not helpful because...

jubilee

@thephd @fasterthanlime
I'm having fun lately discussing things that C and C++ and LLVM never even fucking tried to handle in a consistent way but we're probably going to have to because we don't want to just gloss over things that matter in, say

proofs of soundness of concurrent operations?

the C++ memory model is effectively incomplete when held up against things programmers actually write.

Dani (:cxx: modules addict)

@jubilee @thephd @fasterthanlime For dumb people like me: what do you mean with "incomplete memory model"? Mind to expand on that?

jubilee

@DanielaKEngert @thephd @fasterthanlime there are C/C++ programs that you can write today that have no coherently specified behavior if they involve concurrency. and technically it doesn't matter to the languages... because it only matters due to a "vendor extension".

a very old vendor extension that is used pervasively in high-performance code and effectively either makes the model incoherent when used OR means LLVM is miscompiling vast swathes of code and probably so is every other C compiler for x86.

Dani (:cxx: modules addict)

@jubilee @thephd @fasterthanlime Thanks.
So you're talking about " no coherently specified behavior" and potentially "miscompiling vast swathes of code". I still can't see what exactly you mean, what is missing, how this should be fixed, and how the fix fits into a (hopefully improved) memory model. And why does this affect only x86?
There must be a reason why a vendor extension is just that and not the standard.

Noratrieb

@jubilee @thephd @fasterthanlime even after the C++ memory model was _released_, people didn't realize that nontemporal stores are problematic because they didn't see them on their threads yet

jubilee

@nilstrieb @thephd @fasterthanlime yeah also the CPU had fewer actual write-combining buffers it could be retiring simultaneously.

but the CPUs have gotten more powerful at that sooooooooooo

Martin Uecker

@thephd @fasterthanlime I disagree. Not trying to solve all problems in one place is essential for keeping complexity manageable. So C not doing this is exactly right.

Joshua Barretto

@thephd I've stopped chasing simplicity in favour of a sort of 'oneness' that I've seen emerge from good software: where the ends are all neatly tied up, where the semantics of components are clear and cognizant, where there's a sort of ineffable harmony and you just *know* by looking at it and understanding it that it's going to pass any unit test you throw at it. Neither complex nor simple, but sufficient for the problem domain. Type systems help a lot with getting there, but aren't essential.

Joshua Barretto

@thephd It usually takes at least 2 or 3 rewrites / major refactors of a system to get to this point, but damn if it isn't worth it.

Tshepang Mbambo

@jsbarretto
what are some codebases you would recommend reading that fit this description
@thephd

Joshua Barretto

@tshepang @thephd Less codebases and more individual components, or abstractions. I had this feeling when working on @veloren's AI code: after several months of experimentation and false starts, we hit upon a combinator API that ticked all of the boxes and felt 'right', and so far that's been consistently the case: it's easy to modify and provides a near-perfect balance between restriction and expression.

Go Up