They are called progressives (or multi-focal – depending on whom you speak with).

Progressives come in a few «ranges»: near-range, mid-range and all-purpose. There are also «premium» options available, although I am not entirely sure how much different they actually are.

I have found that having two separate pairs of progressives (near-range for reading, laptop use and all-purpose for everything else) works the best. All of them can also be had as the transition variety and with different tint colours, thus obviating the need for a separate pair of shades.

In fact, when I first tried the near-range progressives some 5 years ago, it was an eye-opener in the almost literal sense of the word – the laptop screen flattened and became bigger despite obviously not changing its physical size. It was something that I had struggled with for a long time before the progressives entered mainstream. At high prescription numbers, the lenses for myopia start distorting the true shape of objects which creates mild to substantial visual discomfort, and near-range progressives fix that.

Another source of discomfort might be the suboptimal «Add» number on the script for progressives. This can be fixed by going to an optometrist clinic rather that a street optometrist (or find a reputable and good one first). If the «Add» is too small, the progressives will make little difference compared to conventional lenses, and, if it is too big, they will make it difficult to see in the distance.

Based on own subjective experience, I can't recommend the progressives enough, although a little bit of fine-tuning might be required (none in my case).

And, whilst compiling C and C++ the JVM / .NET CLR byte codes is very uncommon, both VM's have become very popular compilation targets for other programming languages.

The most enigmatic control flow statements in INTERCAL, however, remain PLEASE GIVE UP and DO ABSTAIN FROM – a most exalted celebration of pure logic and immaculate reason.

Even at the microarchitecture level, the hard part is not raw CISC-ness but irregularity and compatibility baggage. In that respect x86 was usually the uglier customer.

High-end x86 implementations ultimately scaled further because Motorola had less market pressure and fewer resources than Intel to keep throwing silicon at the problem, not because m68k was somehow harder to optimise.

Later high-performance m68k cores did what later x86 cores also did: translate the architected variable-length instruction stream into a more regular internal form. Motorola’s own MC68060 manual says the variable-length M68000 instruction stream is internally decoded into a fixed-length representation and then dispatched to dual pipelined RISC execution engines. That is not evidence of an ISA that was uniquely resistant to microarchitectural optimisation. It is evidence that Motorola used the same broad trick that became standard elsewhere: hide ISA ugliness behind a cleaner internal machine.

There is also a deeper point. The m68k ISA was rich, but it was comparatively regular and systematic at the architectural level. The m68k manuals show a clean register model and – notably – consistent condition-code behaviour across instruction forms. That kind of regularity is exactly what tends to help both compiler backends and hardware decode/control design. By contrast, x86’s biggest hardware pain historically came not from being «less CISC» than m68k, but from being more irregular and more burdened by backward compatibility.

Lastly, but not least importantly, CPU's were not the core business of Motorola – it was a large communications-and-semiconductors company, with the CPU's being just one product family within a much larger semiconductor business.

There was no clear understanding within the company of the rising importance of CPU's (and computing in general), hence the chronic underinvestment in the CPU product line – m68k did not see the light of highly advanced, performant designs purely because of that.

«More CISC-y» does not by itself mean «harder to optimise for». For compilers, what matters far more is how regular the ISA is: how uniform the register file is, how consistent the condition codes are, how predictable the addressing modes are, and how many nasty special cases the backend has to tiptoe around.

The m68k family was certainly CISC, but it was also notably regular and fairly orthogonal (the legacy of the PDP-11 ISA, which was a major influence on m68k). Motorola’s own programming model gives one 16 programmer-visible 32-bit registers, with data and address registers used systematically, and consistent condition-code behaviour across instructions.

Contrast that with old x86, which was full of irregularities and quirks that compilers hate: segmented addressing, fewer truly general registers (5 general purpose registers), multiple implicit operands, and addressing rules tied to specific registers and modes. Even modern GCC documentation still has to mention x86 cases where a specific register role reduces register-allocation freedom, which is exactly the sort of target quirk that makes optimisation more awkward.

So…

  68k: complex, but tidy

  x86: complex, and grubby

Since the advent of e-commerce, POS-networking and fraud detection systems in 1990's-2000's.

User-facing and authorisation path are highly latency sensitive. It includes tap-to-pay, online checkout, issuer authorisation, fraud decisioning, and instant payment confirmation – even moreso for EFT payments.

> […] 2-5 seconds more from card presentation to getting approval back.

This is the mid-1990's level QoS when smaller merchants connected the acquirer bank via a modem connection, and larger ones via ISDN.

Today, payments are nearly instant in most cases, with longer than one-second card payment flows falling into the exceptions territory or inadequate condition of the payment infrastructure.

It is quite likely that not allowing the misaligned access was also influenced by PDP-11.

Neither are RISC nor modern.

Maybe other CPU's have it as well, though I do not have enough information on that.

Linux does not page out code pages into the swap. You might be conflating page reclamation with swapping instead.

In Linux, executable «.text» pages are mapped[0] as file-backed pages, not anonymous memory, so when the kernel needs to reclaim RAM it normally drops those pages and reloads them from the executable file on the next page fault once they are accessed again (i.e. on demand) rather than writing them to swap.

In this particular regard, Linux is no different from any other modern UNIX[1] kernel (*BSD, Solaris, AIX and may others).

[0] Via mmap(2) in argv[0], essentially.

[1] Modern UNIX is mid-1990's and onwards.

Actually, fork(2) was very inefficient in the 1970's and for another decade, but that changed with BSD 4.3 which shipped an entirely new VMM in 1990 in 4.3-Reno BSD, which – subsequently – allowed a CoW fork(2) to come into existence in 4.4 BSD in 1993.

Two changes sped fork (2) up dramatically, but before then it entailed copying not just process' structs but also the entire memory space upon a fork.

The knowledge of Modern High German helps little to none as far as the comprehension of Old English is concerned. From a modern German speaker's perspective, Old English – with a relatively small number of exceptions – is gibberish.

It is not helpful because comparing English from 1000 AD with Modern High German is the wrong premise to start off with.

The correct and more interesting comparison would be with Old High German from around the same time although it did not indicate the umlaut in the spelling at the time (which would happen 400-500 years later) – even though the i-umlaut had already developed.

So «schön» was «scōni» (or «sconi») in OHG. Also, ö and ü developed from /o/ and /u/, so juxtaposing them with English ē is likely incorrect.

Most think that it came from TeX, which had -- (for an en dash) and --- (for an em dash, although I don't think I have ever observed it out in the wild outside TeX), but in fact, the habit well predates TeX and goes all the way back to typewriters where typists habitually hit two hyphens in a row to approximate an em dash. The approximated em dash was described in hard-copy manuscript preparation rules such as The Chicago Manual of Style.

So, if you have ever used a typewriter or TeX, you can claim an even richer than 20 years’ heritage of using the em dash.

> At a certain point though, something's gotta give, the compiler can do guesswork, but it should do no more, if you have to add more metadata then so be it it's certainly less tedious than putting pragmas and _____ everywhere, some C code just looks like the writings of an insane person.

There is not even a single correct or factual statement in cited strings of words.

C optimisation is not «hacks» or «witchcraft»; it is built on decades of academic work and formal program analysis: optimisers use data-flow analysis over lattices and fixed points (abstract interpretation) and disciplined intermediate representations such as SSA, and there is academic work on proving that these transformations preserve semantics.

Modern C is also deliberately designed to permit optimisation under the as-if rule, with UB (undefined behaviour) and aliasing rules providing semantic latitude for aggressive transformations. The flip side is non-negotiable: compilers can't «guess» facts they can't prove, and many of the most valuable optimisations require guarantees about aliasing, alignment, loop independence, value ranges, and absence of UB that are often not derivable from arbitrary pointer-heavy C, especially under separate compilation.

That is why constructs such as «restrict», attributes and pragmas exist: they are not insanity, they are explicit semantic promises or cost-model steering that supply information the compiler otherwise must conservatively assume away.

«metadata instead» is the same trade-off in a different wrapper, unless you either trust it (changing the contract) or verify it (reintroducing the hard analysis problem).

Godbolt exists because these optimisations are systematic and comparable, not because optimisation is impossible.

Also, directives are not new, C-specific embarrassment: ALGOL-68 had «pragmats» (the direct ancestor of today’s «pragma» terminology), and PL/I had longstanding in-source compiler control directives, so this mechanism is decades older than and predates modern C tooling.

… banks saw big, no, BIG $$$ and lost their minds. The transition was rather swift: between the very late 2000's and approximately 2015 (give or take a few years), the transition had been complete. Credit cards became a massively profitable and booming business for the banks, with all sorts of loyalty programmes and bonuses (at consumers’ expense, of course, as the banks also jacked up interest rates on revolving credits). Note that all of this took place before national governments stepped in to regulate the transaction fees.

This coincided with the growing allergy of Western governments to owning any critical infrastructure (including payment networks) and the rising trend of outsourcing as much as possible to the private sector. As it is easy to imagine, it did not take long for the national banks already being in bed with Visa/MC to convince their respective national governments to stop investments in maintenance and enhancement of domestic payment networks and delegate the payment processing to the cartel: «they can do it better than you do».

… all of which has led us to where we are right now. Technically, national payments are still alive, but they are more in the contained mode of operation and not in active use or development.

One day amounts to 24 hours.

Assuming no overtime, one day translates into 3x 8 hour shifts, or 3x engineers. Suddenly, $260k a year buys 3x engineers.

Now, assuming that the dark factory stuff can actually work as conjectured, it will work 24x7, 365 days a year, it does not require annual leave, sick leave, observance of public holidays etc. So $365k (adjusted for 24x7, 365) works out to be a cheap deal.