Wirth did it at least twice, with Medos-2 (1983) and later with various flavours of Oberon System.
7,392 karma · joined December 26, 2019
Wirth did it at least twice, with Medos-2 (1983) and later with various flavours of Oberon System.
Kublai Khan received an ornate letter signed by Marco Polo: "In Madrid, City of Lost
Things, no item remains where it was set. If one drops his key in the dirt, he may
never re-enter his home, and, even if he manages to stoop and recover the key, he may
rise to find a tulip garden where his house once stood. In complementary fashion,
things lost by others are forever turning up: A pocket watch on a coffee table. A fond
memory in your recollection. I even know of a prince who turned up in a prison cell.
When he appealed to the guards for his release, he failed to find the crown on his
head, and when he was asked his name, he searched his thoughts, but could not find it.
Indeed, the only hope now for the release of this prince of Spain is for you to send
back 300 ducats for his release. Of course, he will reward you handsomely once he is
out. Yours truly, Marco." Kublai Khan cocked an eyebrow and declared before his court,
"Hey, everyone: Looks like we're about to get ripped off by the guy who traded gold
for paper!" The court erupted in booming laughter.
— Italo Calvino, Invisible Cities 2: This Time It's Visible.That's the stuff I like to read about the historical endeavors. A fifty-threads nut doesn't average the distance between the grooves quite accurately enough? Then let's make a nut with six-hundred threads on it, and so what if it's foot long.
> Forcing them writing some specific bit-pattern may lead to suboptimal code generation.
So? Forcing them to compile "return 42;" as "mov eax, 42; ret" also leads to suboptimal code generation: a plain "ret", returning whatever is in rax already, is optimal. It doesn't generate the specific bit pattern for 42 but that's a small price for the improved efficiency, isn't it?
And almost nobody writes sentences like "I love her and she loves me back" with a comma before "and".
And since the cloud providers don't have the problem in your first sentence (even if the customers pre-paid, they're still easily identifiable), they never bothered to implement the solution from your last sentence. But seriously, the problem of accurate, real-time billing is not a new one, and it's been solved before several times already (e.g. RADIUS/Diameter of dial-up ISPs).
Well, what would come out of the outback once the rabbits are gone? Since we know the state of Australian wildlife before the rabbits, the answer is "nothing".
It has a rather weird interface, at least until C++ 17 when some of the deficiencies were patched somewhat.
Okay, other than <vector>, what are the good parts? Because as the sibling comments rightfully point out, migrating your codebase from C to C++ just to be able to use <vector> is not worth it.
The <map> is a sad joke played upon the C++ programmers by the standard committee.
> Sure, C++ has its own downsides
"Sure, getting your eyes gouged out has its downsides, but is it better to read that awful mess of macros in C instead?" The answer most people would give to this question may surprise you.
Then again, the original "Case for RISC" paper was misnamed; it's really "Case Against CISC": Patterson and Ditzel are very careful to never state what, exactly, do they mean by "RISC" they're supposedly advocating for, nor do they actually advocate for it — they mostly just criticize the current ISAs and the overall design approach to them.
It's a lose-lose situation, honestly.
Then the people who complained about cat -v went ahead and made better Unix, called Plan 9, in which moving (as opposed to merely renaming) a directory is impossible: instead, you're supposed to do mkdir && dircp && rm -r. Which is quite a choice, if I say so myself: there is simply no low-level primitive (syscall or 9p message) for moving files across directories, even on the same file server. Their version of mv can move files across the directories, but it's still done with internal equivalent of cp+rm.
Eh, when fork was invented, most (virtual) memory systems did not have the first clue about copy-on-write either. And honestly, it's really not that difficult to support — it's essentially hard links, just with slightly different semantics.
The "metadata is atomically copied" part would support very nicely the usual text editor's idiom of rename(2)ing a temporary file over the source after fully writing it out — you still need to accurately replicate the permissions and extended attributes. And just as shells are important enough programs to have fork(2) almost exactly suited for them, it would make sense to have copy(2), suited for the text editors.