Programming thread

[Strange Looking Dog]

I sincerely wish more focus was put on cooperative multithreading over preemptive. Most coders don't even know what a coroutine is. They're unfortunately easy to make sloppy code with, but applied correctly, the difference in code clarity is life changing.

Who says you need to preempt anything just add more cores

We're stuck in a future where processors and compilers of co-evolved while the languages have remained the same. Can you imagine what a processor optimized for Erlang or Java would have looked like?

From experiments I can tell you GC does impact throughput, both for the naive case and what your cores are saturated. As far as real time applications are concerned, though, I'd avoid a GCed language altogether, seems like asking for trouble. If you have soft real time requirements, i.e. pauses under a threshold, some new GCs become viable. I think ZGC is fully concurrent, or close to it. Azul has a proprietary GC called Z4 which is fully concurrent. I don't remember how they handle compaction.

So looking into it, ZGC is doing some very interesting and fucky stuff. It's essentially using virtual memory in order to reserve some bits in every reference for special use, and then to process those references if they are accessed during the mark phase —an otherwise a difficult case for concurrent marks. From the sounds of it they've even solved the issue of compaction, they set a bit in references that may need to be relocated, and simply remap those references when accessed, thus allowing the copy to happen in the background. This is unironically an incredible solution, but as you said previously, a turd with a mirror polish! Still though, the jvm is fundamentally imperative, and if it did not have to worry about those references mutating, it could use a much simpler scheme, and perhaps negate the need for a stop-the-world phase entirely.

 

[Anti Crusader]

I guess? Seems kind of silly though, if you're genuinely afraid of losing significant progress between commits, maybe it's time for a commit. If it's not that significant, what's the big deal?
This message brought to you by git gang; use it or you'll lose it

What's the big deal is that "big undos" are an annoyance, not a major problem, and I want to be distracted by as few annoyances as possible. "I want to go back 30 seconds" is not the same as "I want to go back 30 minutes", and no one here is suggesting that you shouldn't regularly commit code. Your "solution" is at least as annoying as the problem I have, so it's not a fucking solution. Tree undo is the solution.

git rekt

 

[Kosher Dill]

Your "solution" is at least as annoying as the problem I have

Ah, the national anthem of Git. All rise!

My big issue with Git (and to be fair, many systems, not just in source control) is that while it's rightly praised for its ability to handle the most complex 0.00001% of situations - Linus mucking around in the guts of a 50-way merge on a hotfix for the kernel or whatever - it just doesn't scale down very well to the least complex situations.

 

[Strange Looking Dog]

What's the big deal is that "big undos" are an annoyance, not a major problem, and I want to be distracted by as few annoyances as possible. "I want to go back 30 seconds" is not the same as "I want to go back 30 minutes", and no one here is suggesting that you shouldn't regularly commit code. Your "solution" is at least as annoying as the problem I have, so it's not a fucking solution. Tree undo is the solution.

git rekt

Git is a tree which you can undo so you must simply want a git but smaller; a tiny git that automatically records all of your typos and brainfarts for future use, I understand completely.

What would it look like if we could visualize the undo history of a program? A fractal monolith of trying and failing to type the right acronym to get autocomplete to catch on probably

Ah, the national anthem of Git. All rise!

My big issue with Git (and to be fair, many systems, not just in source control) is that while it's rightly praised for its ability to handle the most complex 0.00001% of situations - Linus mucking around in the guts of a 50-way merge on a hotfix for the kernel or whatever - it just doesn't scale down very well to the least complex situations.

I think it's mostly a user experience thing, you have all these various actions with very specific implications, and for example if you perhaps switch branch with uncommitted changes you'll lose them. It makes sense if you think about it, you are replacing project structure after all, but it's not exactly very friendly. I think a good wrapper smooths over the rough spots, and in my experience using it with various IDEs it does. Press button make commit, right click on thing make new branch, branch with uncommited changes get a warning, easy.
This is just kind of a general issue with open source isn't it? Beautiful theory and implementation without so much as a thought to the average user, tbf it's not much better with commercial products a lot of the time, but at least they theoretically have some motivation to actually suit the product to the common user


Elaborating on the ZGC thing, on windows you could pretty easily create the mirror mapping with one of the MapViewOfFile functions from Memoryapi.h, but I'm still not really sure how you'd go about catching dereferences of remapped references. I can sort of imagine doing something with signals —E.G. unmapping the mirrors of the heap before remapping and just catching the resulting SIGSEGVs with a handler, but I'm not sure how you'd then return to the function with the corrected reference though. libsigsegv seems like it might be a good starting point, and they even advertise it's utility in GC and custom paging systems in it's features. Seems like the issue beyond catching the fault would be to actually change the reference in whatever register/memory address it's been stored, and you'd need to interpret the offending op and correct the specific register or something, seems like an absolute nightmare.
Impressive those java people managed it, and hey maybe java's limitations worked in it's favor by making the problem scope more manageable

 

[Anti Crusader]

Git is a tree which you can undo so you must simply want a git but smaller; a tiny git that automatically records all of your typos and brainfarts for future use, I understand completely.

What would it look like if we could visualize the undo history of a program? A fractal monolith of trying and failing to type the right acronym to get autocomplete to catch on probably

If my editor handles this via git, fine. I don't care about the implementation details as long as it's fast. The important thing here is the UI needs to be good.

 

[Shoggoth]

If my editor handles this via git, fine. I don't care about the implementation details as long as it's fast. The important thing here is the UI needs to be good.

nigga just use Emacs

 

[Bongocat]

Of all the things I thought could derail a programming thread, "undo button" was not one of them

 

[Kosher Dill]

This is just kind of a general issue with open source isn't it? Beautiful theory and implementation without so much as a thought to the average user

Or at best, the average internet open source contributor. The further you get away from that use case, the bigger the clown shoes get.

 

[Bongocat]

This is just kind of a general issue with open source isn't it? Beautiful theory and implementation without so much as a thought to the average user, tbf it's not much better with commercial products a lot of the time, but at least they theoretically have some motivation to actually suit the product to the common user

Tech and math are unintuitive by their nature, so despite 'beautiful theory', you still need a lot of guard rails for the poor dude up at 3 AM slamming coffee to meet a deadline.

One of the biggest differences between paid and FOSS contributors is that paid contributors are obligated to actually listen to to feedback from non-techy users. Even if the feedback is unintelligible retard noises, you have to do something with it and figure out why they're complaining. Figuring that out, however, is a dirty task that requires time, money and people who are gifted in designing UX. Guess what FOSS doesn't have a lot of.

 

[Considered HARMful]

My big issue with Git (and to be fair, many systems, not just in source control) is that while it's rightly praised for its ability to handle the most complex 0.00001% of situations - Linus mucking around in the guts of a 50-way merge on a hotfix for the kernel or whatever - it just doesn't scale down very well to the least complex situations.

Disagree. Making commits is dead-easy, maybe even easier than with SVN which I used as a yardstick for some time due to my retarded mental inertia.

I think it's mostly a user experience thing, you have all these various actions with very specific implications, and for example if you perhaps switch branch with uncommitted changes you'll lose them.

Switching branches does not lose changes unless you're passing --force like mint chocolates. I agree that there are commands which may cause data loss, but basic git-checkout is not one of them.

 

[Kosher Dill]

Disagree. Making commits is dead-easy

As long as you never have to edit one, in which case God help you. But yes, making commits is so easy that you can do it anywhere, even places that make no sense.
I do think the most recent IDEs have finally wrangled most of Git's idiocy and come up with some sort of standard subset of functionality that will behave predictably and reasonably in uncomplicated use cases - albeit with a performance penalty. Couldn't tell you whether they all came up with the same subset or not.

 

[Shoggoth]

As long as you never have to edit one, in which case God help you. But yes, making commits is so easy that you can do it anywhere, even places that make no sense.
I do think the most recent IDEs have finally wrangled most of Git's idiocy and come up with some sort of standard subset of functionality that will behave predictably and reasonably in uncomplicated use cases - albeit with a performance penalty. Couldn't tell you whether they all came up with the same subset or not.

Making commits is easy, breaking your editing flow to do so is bad.

 

[Considered HARMful]

As long as you never have to edit one, in which case God help you.

Now you're moving the goalposts. Editing commits isn't in the universe of least complex situations (your words, not mine). Unless by editing commits you mean actually selectively moving diffs in and out of staging, but even then I'd rate git much higher than SVN due to git add -p.

 

[Kosher Dill]

Editing commits isn't in the universe of least complex situations

It absolutely isn't, but considering how common it is for starry-eyed "DevOps" departments to set up commit hooks that will throw a wrench in the works if things aren't just so (potentially much later down the line), that's a serious problem.
But yes, I suppose to speak with a higher degree of precision, another problem is that it's far too easy to be forced out of the "least complex situations".

 

[byuu]

I kinda hate git. I found myself way too often googling how to do X in git to find the obtuse command that will do what I want.
I don't have that problem with subversion or mercurial.

 

[Considered HARMful]

It absolutely isn't, but considering how common it is for starry-eyed "DevOps" departments to set up commit hooks that will throw a wrench in the works if things aren't

Sorry, I don't really follow what you're going on about. Are we talking about making commits or not? Because now suddenly some hypothetical DevOps has parachuted into the topic.

But yes, I suppose to speak with a higher degree of precision, another problem is that it's far too easy to be forced out of the "least complex situations".

This is asinine. Git has easily accessible features that e.g. SVN doesn't have (just like the mentioned git add -p). This has nothing to do at all with "least complex situations".

 

[Shoggoth]

I kinda hate git. I found myself way too often googling how to do X in git to find the obtuse command that will do what I want.
I don't have that problem with subversion or mercurial.

I read someplace that git was never meant to be used directly, but as a backend for more ergonomic clients. Can't attest to the veracity of this statement, but I can say using something like Magit is way more pleasant than cli git

 

[Kosher Dill]

Are we talking about making commits or not? Because now suddenly some hypothetical DevOps has parachuted into the topic.

Making commits is not, as far as I know, a problem at all.
I suppose my issues are really more with the way Git is commonly used than with the technology itself.

I read someplace that git was never meant to be used directly, but as a backend for more ergonomic clients.

I don't know if it was meant that way or not, but I think this is the way things ultimately will have to go, to smooth over the points where simple operations translate to disproportionate hassles "under the hood".

 

[Coffee Shits]

It absolutely isn't, but considering how common it is for starry-eyed "DevOps" departments to set up commit hooks that will throw a wrench in the works if things aren't just so (potentially much later down the line), that's a serious problem.
But yes, I suppose to speak with a higher degree of precision, another problem is that it's far too easy to be forced out of the "least complex situations".

I avoid commit hooks for this reason. Even with the most well-thought-out hooks there's a huge chunk of it based in opinion that just doesn't matter in the end to the compiler. Getting the computer to tell the human that his code isn't acceptable is the leading source of hour-long coffee breaks. It does more harm than good to team cohesion IMO.

Using git add -p to break up changes into the smallest possible commits is the correct solution, but it can take training that doesn't always take, either.

 

[Bongocat]

I read someplace that git was never meant to be used directly, but as a backend for more ergonomic clients. Can't attest to the veracity of this statement, but I can say using something like Magit is way more pleasant than cli git

That's true of a lot of tools. As much as linux people fetishize the commandline, it's a wildly inefficient and error prone way to use a computer. It's good to know how to use it when the situation calls for it, but it should not be a lifestyle.