I'm kinda sad "databases" got excluded. On the one hand, I get excluding SQL & ACID; but B-trees I'm disappointed to see not make the main list¹. They're such a fundamental datastructure, and I continue to run into programmers who do not understand how a B-tree works. (E.g., that it is inherently ordered/sorted, and what sort of operations it makes fast. I'm willing to lower the bar so that "how it works" isn't required.) But I think there's a lot of practical stuff in relational algebra, too: in particular, the notion of a "key" — I also find programmers who do not understand this — and the various normal forms and why you want them. Practically speaking, I think something like 99% of engineers are going to touch these topics in a "a user of them" sense.
While I wouldn't include ACID either I think, but I think you do want something like this: https://jepsen.io/consistency — then you can talk about it when you have to work with aaS cloud systems don't obey anything on that list, at all.
Also I think you're going to have to work to convince people that floating point was a good idea. (I agree, but I doubt that agreement is universal.)
(¹I know it's like on a "good ideas" sublist in the excluded section. But it's such a good idea I'd've pulled it out to the main list.)
Personally, I'd include the Relational Calculus, or even the Paxos algorithm. But I'd also include Neural Nets knowing what I know now. But I wouldn't include Quantum Computing yet -- not until it's proved to work.
Is there a line between research/discovery and engineering? Binary numbers and Boolean algebra is discovery, while IEEE floating-point numbers are engineering. Choosing digital over analog is engineering, while inventing the transistor is discovery. Serial over parallel for networks and busses -- engineering. Turning machine & halting problem -- discovery. Von Neumann architecture -- engineering. Combinatory logic -- discovery. LISP -- engineering. Public key encryption -- discovery. Graphical UIs -- engineering.
But there are fuzzy areas, like hashmaps. Discovery or engineering?
Tho perhaps it's pointless, or worse, elitist to even make this distinction.
If philosophy is the art of forming questions, this article is pure philosophy.
I am trying to think like the author.
Buy I don't know why virtual memory is separable from memory protection: one necessitates the other.
Aren't call stacks data structures in the same way as lists? What's special about arrays as you can find equivalence between this idea.
The first job is to understand taxonomic distinctions between ideas, but there's no consideration of taxonomic equivalence. For example you can derive one good idea from a combination of others.
For example, I'll add for no:
- Interrupts/Events/Signals
- Caches
Are these subsumed by processes?
When does a loop rise to the status of a process?
Is I/O a good idea, or intrinsic?
To me the question of goodness should expand to add truth and beauty, then a new academe of philosophical computing can be launched.
What is conspicuous about that? Arbitrary precision integers are useful/necessary in some situation but I don't think there are very many programmers that need them very often.
While I wouldn't include ACID either I think, but I think you do want something like this: https://jepsen.io/consistency — then you can talk about it when you have to work with aaS cloud systems don't obey anything on that list, at all.
Also I think you're going to have to work to convince people that floating point was a good idea. (I agree, but I doubt that agreement is universal.)
(¹I know it's like on a "good ideas" sublist in the excluded section. But it's such a good idea I'd've pulled it out to the main list.)