But then, are the system design principles periodic in some way? Does adding Y to one of the principles turn it into another? And if you add enough Ys, does it turn back into the same group again? Here, I find it's a resounding no.
Better to call it a Taxonomy of System Design instead.
/rant
just by it's ubiquity and success it has become a template for graphical design
Ironically, you are in a superstate between "can" and "should".
Cashing in on that global cultural awareness is just the kind of innovation a genius branding team needs.
It does annoy me when 'Periodic Tables of X' are just lists of color coded boxes, but I get it.
A billion+ people instantly identify police, but dressing like a cop is a crime.
1. Abstraction Lifting (Al) + Policy/Mechanism Separation (Pm): SQL states high-level intent with precise semantics, and logical operators are decoupled from physical operators.
2. Equivalence-based Planning (Ep) + Invariant-Guided Transformation (Ig): We apply algebraic rewrites that preserve semantics (e.g., join reordering, predicate pushdown) under stated invariants.
3. Cost-based Planning (Cm): We choose concrete physical operators and join orders using a cost model and so on..
If not, eeehhh
But that sounds far less grand...
Wouldn’t “Elements of System Design” have worked?
To clarify: this is indeed just a taxonomy of classic system-design principles. The periodic-table styling is a familiar metaphor; there is no claim that principles repeat periodically. The goal was to outline a mostly orthogonal set of design principles and highlight cross-domain connections across computer systems so it is easier to discuss designs precisely. Thanks for all the thoughtful feedback!
I strongly urge you to rename the project and most definitely update the body content of your README.md.
The best time was before you git pushed; the second best time is right now.
Aren't most bridges these days modular and made of prefab components assembled on site? Afaik that greatly sped up construction over the past few decades.
They're also modular in that there are built-in weakpoints designed to constrain failures without taking out the whole bridge. You can see that in action if you look at photos of the Bay Bridge after Loma Prieta. Collapsed sections, but most of the bridge stayed up.
It will produce beautiful and thoughtful-looking work to even those with a discerning eye, but keep picking at it and you’ll see that bias and unintentional deception is endemic.
It’s not that LLMs can’t be used thoughtfully, but that it is essentially a bird laying rotten egg solutions by default, and only through conscientious continued hand-held process, throwing away the rotten yolk regularly, can it be used, and even then with care and only in certain circumstances. But, as it’s crafted to in its very nature to deceive in order to provide what is desired, it will eventually fool even those that understand its nature, with larger and larger consequences.
I have seen disease and famine destroy, and I don’t want to prevent solutions, but this is a beast, a great deceiver; have we not learned by now the story that will be told now that Pandora’s box has been opened?
Great to see an attempt at describing this phenomenon. A great start to what will surely be an awesome resource.
You have to grow system designers the hard way. Lots of iterations, go off and write up a design, get feedback, repeat. And then dogfood the design, whoever designed it should also do the brunt of the implementation and maintenance. That forced contact with reality leads to well designed systems, and people who produce them consistently. A second order effect is a culture of valuing well designed systems, people clustering around good system designers. No one wants to be on the project that is too complicated or unlikely to work or a high maintenance burden.
edomyrots•6mo ago
jarulraj•6mo ago
culi•6mo ago