"None of the deployments under consideration for this new initiative use that mechanism, that other deployments might is irrelevant to the internal product we are building"
In my space this is usually something like, "X won't work on POSIX make", being a reason not to add X to the build system. Well, it works on Ninja, and on GNU make, so it just won't work on POSIX make and the handful of deployments still using POSIX make just won't use X.
"We're not trying to build a perfect solution here" is not something said to assuage over-engineering or encourage sloppy work.
It's said to head off a specific complaint from a specific kind engineer who will object that the proposed solution won't work because it doesn't cover some obscure edge case which rarely comes up in production.
"We're not trying to build a perfect solution here" is saying "We acknowledge not everything will be covered, we're setting the requirements at the 90th percentile use case".
They aren't. This is a Windows quirk. Most IDE extensions which interface with git (or any other CLI program) from the CWD are "vulnerable" to the same attack.
This is why the upstream didn't take it seriously, this has been known for literal decades.
They are the wider community. Programmers working on behalf of corporate actors write open source code in the commons because their organizations have discovered competing on some parts of the stack isn't as viable as collaborating on parts of the stack.
I won't pretend to speak to specific numbers, but a huge amount of work and maintenance is from these programmers, or funded via the corporate actors which employ these programmers. Those actors are either on this list, or don't have a problem with this list.
What remains are the handful of truly independent contributors, which are a minority in terms of LoC (though they often have an outsized impact), and the peanut gallery.
Open source wasn't always this way, it would be a different discussion 30 years ago when independents were the only guys in town, but it is now.
A pointless distinction for OP's (heavy handed, LLM-generated) point:
>The database you are helping build for a trustworthy government does not stay in trustworthy hands. Administrations change. A registry that merely catalogs who you are today becomes, under a future government, a map of who to find.
This is an objection to driver license databases, to passports; they don't want face scans at airports, much less for banking or insurance. They want off-the-grid, untrackable anonymity. This is incompatible with much of modern life, at least in the mainstream.
You've already rejected elsewhere in the comments the style of problem these calculators are used for as either "more complicated than a high schooler is taught" or a "your teachers have wasted your time".
Which is fine, you have an idiosyncratic view of modern mathematical pedagogy (at least as it exists in the US). When you're a high school math teacher you can argue with your state dept. of ed. about it.
These calculators are also used at the undergrad level, fwiw, so the "high school level" (whatever limit you're putting on that, many high schools will accelerate students into undergrad stats and as far as Calc II), is not a factor in their use overall.
That rules out classes of problem which we want to teach, or falls back to using lookup tables which is more arduous and limits the number of problems which can be put on an exam.
Teaching students to use lookup tables at all is a largely pointless exercise. Teaching students to graph or use statistical functions on an advanced calculator transfers very well to other environments.
The compilation database[1] given to clangd needs to be complete, understood by the clangd argument parser, and capable of producing a build.
This starts to hurt bad when the compiler producing the build is not clang. If you try to use a compile database describing C++20 module compile lines for GCC, clangd will choke badly. If you're using MSVC flags that clang-cl hasn't been taught yet, clangd falls over. If you're using CMake to produce the compile database, it will leave out synthetic targets from the database and you will see errors because clangd cannot find the interfaces described by those targets. If you're not using CMake you need to configure bear or ninja or whatever to produce a compilation database for you. Etc, etc.
If you do not understand how the underlying language server is configured, what the input and outputs are, how it operates, you will run into errors you are unequipped to deal with.
Some languages are more severe than others on this. For example, in C++ your editor is not going to be able to make efficient use of the clangd language server without intervention from the programmer to understand and configure it. On the other hand, for Python the Pyright LS will be mostly fine without additional configuration.
Because the bar is low and part of the craftsman's job is to learn their tools. If everyone who wanted to use a computer needed to learn how language servers work, that would be a problem.
A programmer having to learn how language servers work isn't a pain point, it's their job. It takes a couple hours to learn. A couple hours to learn how to do part of your job isn't notable. Complaining about learning how to do one's job makes one unqualified.
It stops at the tools you use, "it's a tool you use every single day". If it's not a tool you use every day, you don't need to learn it.
If you don't use language servers, you don't engage with development environments which rely on them, you need not learn them.
If you're making chips on a Monarch 60 you don't need to learn shit about CNC. If you're pushing buttons on a Haas you do.
If you're coming from a Monarch and want to try pushing buttons on the Haas on the kids are using, you need to learn how CNC works. That's your job. If you want to switch from notepad to Zed, you need to learn how language servers work.
The context is a user adopting an editor that has LSP integration and is relying on the language server. That's why I said "it's a tool you use every single day".
If your tool is TextMate, you should learn how TextMate grammars work. If your tool is vi, you should learn how modal editing works. If your tool is Ed, you don't need to learn anything because "Ed is the standard text editor".[1]
You are a craftsman, learn your tools. Could you imagine the equivalent from other professionals? A machinist saying, "Understanding the differences and interop places between the DRO, hand controls, and CNC controls for the lathe can be a big confusing time hog."
It takes a couple of hours, and it's a tool you use every single day. Learning how it works is the price of entry, not a mountain to overcome.
Because then all entrants would fail the competition.
There has been no significant jump in capabilities such that a meaningful demonstration of general purpose or cryptographically-relevant quantum computing could be performed on "public hardware".
Presumably the organizers know this but still have incentives to drum up news about QC. So they ignore that problem and focus on how to obscure the fact this is a dog-and-pony show.
For fusion the bar is "economically viable", in the current discussion for QC the bar is "cryptographically relevant".
They are comparable in that to meet either criteria, a variety of unsolved engineering challenges need to be overcome. For both, some of those problems have no clear and obvious solutions to which a simple application of resources and time will achieve.
Currently unknown innovations are required, unknown unknowns lurk in the dark corners, and all projections are relying on the assumption such innovations will arrive in a timely fashion and the unknown unknowns will be harmless glitches.
Neither are likely impossible, but betting on timelines is a fools game. This isn't the NYT publishing man-made flight is a million years away 2 months before the Wright brothers flew at Kitty Hawk, waiting for the right conglomeration of otherwise sound engineering to materialize in one place. It's like saying level 5 self-driving cars are two years away, a perpetually delayed technology for which all problems are well known and no new innovations are imminent.