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.

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.

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.

[1]: https://clang.llvm.org/docs/JSONCompilationDatabase.html

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.

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.

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.

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]

[1]: https://www.gnu.org/fun/jokes/ed-msg.html

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.

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.

"Good news, we added a debugger"

"CMake has a debugger? Who would ever want that?"

Sigh.

Working on CMake has taught me a lot about the futility of pleasing everyone.

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.

It is exceptionally unlikely CRQC will be achieved in our lifetimes, if ever. The closer example is economically-viable fusion power production, which today has better odds than CRQC but remains solidly in the "maybe" zone after decades of global investment. Even though fusion weapons had been achieved half a century beforehand.

The bombs were actually relatively easy problems, in the scheme of things.

It is never wise to listen to people who's jobs and funding are connected to the development of a technology on when that technology will arrive. The answer is always "soon".

Many new school HDLs are working in this space and they couldn't be farther from the "representative of what digital circuits are constructed from" idea. Often they're high-level programmatic generators, very far from describing things in terms of actual PDK primitives.

Clang says "we don't need them", GCC says "we'll ship them in libstdc++", and MSVC says "you are supposed to provide them".

I didn't know about that when I was working on finishing import std for CMake and accidentally broke a lot of code in the move to a native implementation of the module manifest format, so everything got reverted and put back into experimental.

This was wrong, mostly because C++ compiler flag semantics are far more complicated than in Fortran, you live and you learn. The bones of most implementations is identical to Fortran though, we got a ~3 year head start on the work because of that.

Ninja already had the dyndep patch ready to go from Fortran, CMake knew basically how to use scanners in build steps. However, it took longer than expected to get scanner support into the compilers, which then delayed everything downstream. Understanding when BMIs need to be rebuilt is still tricky. Packaging formats needed to be updated to understand module maps, etc, etc.

Each step took a little longer than was initially hoped, and delays snowballed a bit. We'll get there.

Modules solve the problems of text substitution (headers) as interface description. It's why we call the importable module units "interface units". The goals were to fix all the problems with headers (macro leakage, uncontrolled export semantics, Static Initialization Order Fiasco, etc) and improve build performance.

They succeeded at this rather wonderfully as a design. Implementation proved more difficult but we're almost there.

There's no current effort to standardize what a package registry is or how build frontends and backends communicate (a la PEP 517/518), though its a constant topic of discussion.

[1]: https://github.com/cps-org/cps

I agree with both of you, there's some interesting tricks here for how a website builds anti-bot protection, but the AI sloppification is framing it as a consumer protection issue but not delivering on that premise.

It is a reasonable criticism that the post does not deliver a "so what?" on its basic framing.

You generally do not want to simulate or describe raw gate-level netlists. Both languages are capable of that. Old school Verilog (not SystemVerilog) is still the defacto netlist exchange format for many tools.

It's just aggravatingly slow to sim and needlessly verbose. Feeding high-level RTL to Verilator to do basic cycle-accurate sim has exceptionally fast iteration speed these days.