They aren't breaking up NOAA just for the sake of privatization, reliable weather reporting also makes it harder to ignore Climate Change.
From Project 2025 "[NOAA offices] form a colossal operation that has become one of the main drivers of the climate change alarm industry and, as such, is harmful to future U.S. prosperity."
I somehow missed the comments on this post. I think I need to respond not just to this but to the other (completely valid) criticisms in the comments here. And because you bring up what I think is a more interesting problem, you're the comment I'm replying to.
The anger I think stewed for a long time but was in it very nearly since the beginning of this project two years ago (I stopped working on it for quite a while).
First, my anger was directed at C++. std::map forced to be a Red-Black Tree for one. And I had originally written a lot about that anger in the first draft. I had written about how if this paper had baked in the oven a bit longer, they would've had C++11 to work with. I wanted to try to write a Modern C++ version of the code but that goal was what kept me from touching the project for over a year. I had gotten sick of C++ as a whole both at work and in my personal projects. And by the time I got back to it, the discussion on C++ no longer felt like it had a place in the post if it were to have the structure it ended up having.
On the rewrite, I found myself getting more and more frustrated by the original paper itself. The methodology felt flawed yet I felt I had to keep it. I said in the aside how the read of the paper gave this impression that they wanted to shill Go with this paper, like this was going to be its big debut as a language until it failed pretty much every test thrown at it. I don't know how this turned into Google Hate. Or at least, I don't remember. Maybe something about the current state of the world or an impression of Google company culture based on the tone of the paper. Maybe I just didn't want to be angry at Hundt specifically.
Much like the original paper, this post should've spent more time in the oven. But after spending so much time on it, it also felt like I just needed to get it out there so I could be done with it.
Someone else mentioned the acrylic, I'm going to mention Scarlett Sparks' Open Source Knitting Machine if part of the fear is actually investing in the machine
https://github.com/ScarlettSparks/KnittingMachine
Anecdote/Tangent: Roku TV wins an award for worst input switching UX. From Home, you have to go into Settings (the quick settings accessible from the remote aren't enough,) then scroll down the Inputs menu and then select your input. At least with LG, inputs are directly available from the Home menu.
C++ has an absurd amount of UB to the point where there's an entire thought exercise devoted to how malicious a compliant compiler can be (Hell++.) There are things that are allowed and even common in C but UB in C++ (union type punning,) and things that people reasonably can assume would work but are UB anyway (signed integer overflow.) Then you have weird edge cases like assigning the return value of a two argument std::max involving temporaries to a reference. There are so many UB foot guns, no reasonable developer can be expected to keep track of them all.
Needed this post and this comment. And hopefully I'm not misreading either. Halfway through my greenfield redesign that I claim is catharsis because I was too scared of breaking things before they got better. I hope that I can put that redesign to rest and actually make progress with the original code.
Does reading a dozen papers on different algorithms to accomplish a specific goal count as scavenging. Asking for me because I've gone down a rabbit hole with recent work. Not trying to be antagonistic or humble brag either. Actually not sure what I'm trying to accomplish with this question.
I don't think you're misunderstanding, it's a strange choice to make even if the example here loses context to make it easier to make the point. It wasn't code that anyone currently here wrote and because it worked with the old compiler, nobody really touched it.
I believe the nodes are pushed into the list before adding connections but I don't think that changes the point you're trying to make. That said, one's intuition is different from another's and I don't think it's unfair to assume that pushing into a vector of lists won't cause every existing list to be copied. For that to be the actual behavior is kind of disgusting.
It may make more sense to create pointers here but that's a larger change to deal with and ensure correctness versus just swapping the vector out for another list. I don't claim to like that solution but it seems to me like legacy C++ code in general is fragile enough as it is, the less I have to change to fix bugs the better.
I mentioned it in a side note that I trimmed because there were so many that it spilled into the footer (faster to trim the article than to fix the CSS,) but Microsoft is the only implementation of the big three that doesn't mark the move constructor here as nothrow. The standard doesn't require it so it's valid for MSVC to do things the way they do, it just creates problems like this that would arguably be harder to find the cause of if one had to build code for multiple platforms.
I did a double take on this because I wrote a blog post about this topic a few months ago and came to a very different conclusion, that the results are effectively identical on clang and gcc is just weird.
Then I realized that I was writing about compiling for ARM and this post is about x86. Which is extra weird! Why is the compiler better tuned for ARM than x86 in this case?