It might be just me, but I think key bindings should definitely not be easily configurable or even changed across release. They should.be standard, pervasive, and set in stone.
For those who really want configurable key bindings in Firefox I think there are already a couple of extensions that do this for you.
This is a really important principle of making APIs that people don’t really talk about. There’s a fine balance between hardcoded literals and full-gui options menu.
I think this principle might fly under some people's radar because it has been a solved problem for decades.
Even Makefiles don't require changes to the file to be configured. They take environment variables as input parameters, an approach that directly and indirectly permeated into high-level build systems. One example is the pervasive use of the VERBOSE flag.
After all these years I only had to tweak build config files by hand when I wanted them to do something that they were not designed to do. All build tools I know don't require it. The ones linked with IDEs already provide GUIs designed with this in mind.
Fair enough.
Because you’d have to stash your modifications to be able to switch branch.
OP said nothing about stashing, only committing WIP commits to feature branches. I don't think none of your remarks apply, because if you really need stuff from the WIP commits you can also cherry-pick them or checkout specific files.
git switch and git restore were introduced way back in 2019. I don't think they count as new.
When you have 1000+ Cypress tests, for example, it takes time to run, plain and simple.
It's one thing to claim that tests need time to run.
It's an entirely different thing to claim that the time it takes to run tests is proportional to test coverage.
More often than not, you have massively expensive and naive test fixtures in place that act as performance boat anchors and are massive bottlenecks. Thousands of tests run instantly if each test takes around a few milliseconds to run. For perspective, the round trip of network request that crosses the world is around a couple of hundreds of milliseconds. A thousand of sequential requests takes only a couple of minutes. If each of your tests takes that long to run, your tests are fundamentally broken.
I think it's not exactly money, but avoiding a scenario where their business can be held hostage by a company which in practice is trying to force them into a commercial license.
Notice that AWS is far from being alone in this move, as the massive support around Valley shows.
Why do you think test times are proportional to coverage rates?
If anything, I thing Stack Overflow replaced Usenet as the source of informal technical advise.
Never heard of Experts Exchange beyond the jokes.
I think I’m gonna use Bazel anyways
Last time I checked, Bazel barely supported externa libraries and had zero support for shared libraries. Admittedly that's been a while, but those are pretty basic features to be missing.
IDE integration is also critical, and Bazel has nothing to show for in this regard.
Lastly, most of the benefits that Bazel advertises can be had with CMake by simply switching it's generator to something like Ninja, which is trivial and supports compiler cache tools such as ccache right out of the box.
Additionally to note, when doing CMake stuff, it’s generally best to stick to the modern way of doing things
I'd add that the so called Modern CMake is well over a decade old. There is no excuse for people to choose to be miserable.
Personally I prefer calling "Modern CMake" as simply CMake, and the old way of using CMake as "you're doing it very wrong, invest 5 minutes going through a tutorial."
I think this was focused on maintaining code. Replacing C-style arrays with std::array can be a daunting task, depending on how the project is structured.