ubercode5

And satisfactory, that's my newest obsession.

In general I disagree. In large codebases you're going to have a number of abstractions that you'll have to deal with by their nature. Flattening these can cause a scenario where you have a long function with clusters of lines of code organized in a block are doing different functionality that isn't clearly stated. This may include a comment at the start of each block discussing what the next few lines are doing. And without abstraction, the functionality later may not be cleanly decoupled. Debugging these types of functions also adds significant mental load trying to see the forest through the trees.

From the article it seems like the bigger issue might be debugging style. For me, when debugging those abstracted functions should be treated and trusted as black boxes until you have sufficient reason that function is the issue, and then dig into it and ignore the rest of the function. Trying to build a mental model by effectively flattening every function takes huge cognitive load, and only is feasible for small amounts of code. Once the codebase is large enough it's going to become impossible to do this.

It's possible to overdose on water.

It seems like the wrong success metrics are used here if this isn't an experiment. If they used something like "more clicks on articles" this change could appear positive from their end since people now have to click the articles to actually see if they want to read it.

I agree. However one additional thing to keep in mind in the COTS vs FOSS is if there is some bug that affects the company and requires attention. The company doesn't generally have the engineers on staff to actually change that software, and there's no guarantee that the associated FOSS community will prioritize the bug. With a COTS solution, you can pick up the phone and call the support team. Generally my company chooses COTS over FOSS because they want guaranteed support even if it costs more.

Note, some FOSS products also provide a strong support team to handle this exact thing, and in those cases they were usually the winner.

Edit: Looks like abakker posted the same idea simultaneously.

"If you’re not already familiar with the concept of technical debt" ohh how I envy thee.

This is right on money.

The test engineers as well as the implementation engineers also have a lot of experience within their specialized areas. This provides a lot of insight into expected results when running these different types of tests and scenarios.

Also, these tests are long duration. Multiple iterations of simulations can take years to complete.

It depends on your schedule, but prioritize time to study every day in your down time. You don't have to do a "night before the test cram session" all the time, just a little every day and within a few months you'll find yourself much more prepared.

I'm not sure where specifically you are referring to, but you can click on the "list view" under collections to remove the pictures and make it textual.

Speaking solely to the process of discovery of private communication: What happens when you lose trust in that process or feel that process has been subverted?

Do you have any resources to discover some of the events that you are referring to? I'm currently in Houston (albeit a bit south) and would love to find out more.

As much as I love C++, I wonder if there has been any work on rewriting this in another language, even Java. From my experiences developing parallel versions of C++ and Java, most of my Java errors arose from program logic, while C++ arose from memory management. Also, thread management and building tend to be less cumbersome within other languages. For academic purposes, a language where you can focus on the concepts would seem to be more useful than a language chosen for speed.

I would be interested to see a binary size comparison along with the speed comparison. Is there a trade-off of speed for byte size?