sprash

It was/is mostly the same practice except for the cases where it really counts. Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly. And there the possibilities are almost limitless. And thanks to the xcb library it's actually somewhat convenient to use.

Also certain types of power tools for mac probably need use Quartz directly as well.

Yes but the Nvidia NV-1 preceding the Vooodoo was much more impressive. Using NURBS you could display perfectly round objects. Also it had forward texture mapping which significantly improves cache utilization and would be beneficial even today.

It was just way harder to program for. Triangles are much simpler to understand than bezier curves after all. And after Microsoft declared that DirectX only supports triangles the NV-1 was immediately dead.

The original rc-style sysvinit scripts of arch were neither brittle nor buggy. Everything could be configured with "rc.conf" and writing own services was dead simple. All of this was possible with many orders of magnitudes of less complexity.

Example: Windows can only be resized when the client finished drawing the new resized window. Otherwise you would get "visual artifacts". So typical operations dealing with window management can not be async when the insistence on the nonsensical "every frame is perfect" mantra is upheld.

This also means low-performing clients can make the whole Desktop stutter/freeze and it is one of the many reasons the Wayland architecture is beyond idiotic. High responsiveness is obviously far more important than avoiding the occasional artifact.

> Why?

CLI applications typically read text from stdin and write text to stdout. The tcl model of "everything is a string" makes exactly the right abstraction to create GUI frontends for CLI applications rapidly and keep them simple at the same time.

Tcl/Tk to this day is the best tool to make GUI frontends for CLI applications. Besides that, in the past I used it in production for intranet database entry applications. It has since been replaced by Flask. In my opinion the higher complexity of the Flask version is no way justified and we should have kept the much simpler ~2k LOC Tcl/Tk solution.

It is obviously not dead but it should be dead: Almost all of the technical and economic progress made in the last century was achieved with macroscopic quantum effects. Particle physics spends a lot of energy and material resources to measure microscopic effects. The priorities are esentially inverted. At this point it is not even about discovery. Experiments are relegated to precision measurements. What practical use will it be if we know the mass/charge distribution/polarizability of some particles more precicely by a few percent? About nothing.

Playing around with 68k assembly is actually much more fun. These days all the logic is absolutely dwarfed by caches in terms of chip area. This means using RISC does not really make as much sense today as it did in the 80s. That's why the most popular architectures are still CISC (assuming ARM64 can not really be called RISC).

Personally I would be more interested in a fully orthogonal instruction set like 68k but without the insane addressing modes and a better binary format.