The Only Unbreakable Law [video]
youtube.com
youtube.com
They expound quite hard on the idea that abstraction is inherently bad, and I feel this is a poor choice of words, and perhaps a mistake. Abstractions have cost. In many forms, and especially if the abstraction is a poor one.
However… they don’t seem to differentiate between good and bad abstractions. They seem to regard all abstraction as simply unnecessary, only used because our brains cannot deal with the entire problem at once.
I think you could make this argument to some degree but it breaks down when you start to see where abstraction is worth the cost. As an example, let’s say I’m writing a service that needs a key value store. If I make a simple abstraction for it, with well-defined properties for exactly how it should behave, how data consistency should work, etc. then implement multiple backends, this is a good abstraction. The reason for this is because software doesn’t have fixed requirements. Some users may be running a small instance of something on their desktop or a NAS or what have you, whereas others may be running software on gigantic clusters and would benefit from using clustered key value stores that are much more difficult to setup for valid, unchangeable reasons, even if we were to get rid of the abstraction and fully integrate a distributed key-value store right into our program.
Also, requirements change temporally. Clang could’ve implemented everything with no abstractions, but when Clang was created it targeted older and fewer versions of programming languages. The abstractions have cost, particularly when they are bad; but not having abstractions would’ve costed far more, IMO. Extending and reusing software that has little abstraction is very difficult because there’s very few reliable boundaries you can work off of. Adding a new operator in Clang is probably still hard, but I’m sure it would be harder if you carried forward all of the abstraction and folded it down instead. You need some kind of abstraction if you want cheap extensibility.
So my conclusion is basically, abstraction is not bad. Libraries are not bad. Engines are not bad. They simply have costs that are not accounted for properly, and may cost more than the value they provide in many cases. Intuitively, we know this; It’s basically the knee-jerk software engineers get when they get into a build-vs-buy discussion. You feel the jolt. The library has an amazing feature list, but something tells you it won’t be so easy. That’s the hidden cost right there.
so does the need for cheap extensibility comes first, in which case you build up the abstraction to enable it? Or does abstraction get built up first, which gives you cheap extensibility, then users start needing it afterwards?
What if clang didn't end up being as popular as it did, and the effort it took for the "cheap" extensibility was never needed as no one actually extended it?
Of course, if it is trivial to defer an abstraction until later, then it’s better to do that. But it is almost definitely not for Clang operators, which cross cut almost every distinct unit of the program (lexing, parsing, etc.)
(This is also referenced at some point in the talk itself, though I can’t remember exactly where, but my take is that you can’t really fully understand the ideal architecture to solve a problem before trying to solve it, and in trying to solve it you must make architectural decisions.)
I would be surprised if the video author agreed with this statement. My understanding of his point is something more general and almost trivially true, i.e. a given set of abstractions can't solve problems the same way as a different set of abstractions. The strong version is a Venn diagram
┌──────────────────────────────┐
│ │
│ Implementations expressable │
│ by abstraction set A │
│ │
│ ┌──────────────────────┼───────┐
│ │ │ │
│ │ Implementations │ │
│ │ expressable by both │ │
│ │ │ │
└───────┼──────────────────────┘ │
│ Implementations expressable │
│ by abstraction set B │
│ │
└──────────────────────────────┘
Said another way, abstractions cut down the space of possible solutions.
Cutting down the space definitely has large upsides. If you're trying to build a nuclear plant, we probably want to weed out the cake-baking solutions. For especially large and complex problems with horrendously large solutions spaces, abstractions function as a way of compartmentalizing some of that solution space into manageable sub-problems. However, maybe there is a better set of sub-problems?
After a year hammering on some software development project, you probably have a much clearer idea of the problem's nuances than when first starting. Wouldn't it be great if we could perform low-cost rewrites? If you can hold the entire source code in your head and cognate about it, that's probably even possible. Could any one human hold all of Firefox in their head?
One point from the video stands out to me: abstractions might just be a necessary evil. They are effective tools for helping humans cognate about complex problems, which involves limiting our ability to cognate about potential solutions.
Anyway, I am reminded of the surprising solutions found by genetic algorithms and their ilk.
Our human limitations and abstractions limit our ability to approach this goal, so it's not so much that the idea of abstraction is bad because it's useful to actually get stuff done. But it's more that we should always keep in mind that abstraction itself is not the goal, it's just a tool we have to use to get there, because of human limits and I would also say natural limits (like computational efficiency etc).
Obviously such a thing of beauty is a hypothetical extreme. I can see this idea being useful on a smaller scale, like in organising a team, designing a product, or a piece of software, we should pay a lot more attention to where we draw boxes around our design space.
But I am kind of with you when it comes to the broader-sweeping implications. How far does this concept go, and what power do individuals have without some social techno-revolution to make any broader architectural changes to basically anything? I have a mobile phone that communicates via radio with centralised systems. These centralised systems exist to govern access and enforce payment for services, because that's how society itself is structured. Perhaps there's key value stores at various layers of this architecture. There is a store (again because money) where I can choose my own apps (because of human desire for freedom of choice) or view ads (money), all human constructs. (It's all becoming quite philosophical, another human trait.)
But is that the best possible solution for the problem of networked personal computer devices? Is mobile networked computing even an optimal solution for biological lifeforms, is it a technological evolutionary dead end or a precursor to some broader construct we're yet to discover, and if so then what do those superior structures look like from a design and organisational perspective? Perhaps on some alien world they have figured it out, and maybe their solution doesn't include radio communication or key value stores, or maybe it's something we wouldn't even recognise as technology, who knows.
What I take away from it is a call to think about why we're designing things the way that we do. Is there a way we can draw the design space differently and organise teams to consolidate or reimagine the problems they're solving in order to rule out truly unnecessary abstraction and keep only that which is necessary?
I can't imagine how it might look, but I am sure if someone figured out a more optimal way of organising hardware and software that served the infinitely variable needs of humanity securely and efficiently with less abstraction for the same or greater flexibility and that would continue to do so in perpetuity, that person would become rather rich (unless that solution made money obsolete, here we go again).
It's truly incredible to me that people, like the person in this video, can speak with such confidence about how, for example from this video, "if we look at an org chart for an organization, and we look at the structure of the products that it produces, we would expect them to basically just be collapses of each other [i.e. a homomorphism]". Also known as https://en.wikipedia.org/wiki/Conway%27s_law
A sincere person in search of truth asks questions like the following when they encounter a claim:
- can we think of circumstances where this law is not true?
- can we test this claim to show that it is true?
- can a test be devised which would falsify this claim?
- if this claim is true, what are the mechanisms of action for the claim?
- if this claim is true, are there any contradictions that would arise with other things we know are true?
Using the same metaphor used in this video, if the currently recognized law of gravitation (General Relativity) made predictions which were different than what is observed, then that law is wrong. And a scientist would adjust their law to reality and be more than willing to point out the gaps of explanation in our law of gravitation (which they do).
If we're serious about Computer Science (and Software Engineering) being a field in pursuit of truth, we should be as rigorous and critical as other fields of science and engineering when it comes to making claims.
In science/engineering we care about instrumentalism, not truth.
All models are wrong. Some are useful.
Is this a mischaracterization of a subset of your claim: "Scientists do not care if their models are truthful, but they do care that their models are useful."?
The Ptolemaic/geocentric models still work, even if the mathematics are a bit unwieldy.
Truth is a philosophical notion. It is not the concern of science.
I am aligned with model-dependent realism; or epistemic constructivism or thereabouts.
https://en.wikipedia.org/wiki/Model-dependent_realism
https://en.wikipedia.org/wiki/Constructivism_(philosophy_of_...
I don’t have confidence IN my beliefs. I have confidence in the usefulness of my mental toolbox.
On a scale of 0 to 100 how confident are you in your belief of this science?
What? Parent is litteraly saying don't trust a model that has no predictive power.
You're saying leave model evaluation to philosophers. Last time we did that we did that we had theory of four elements and phlogiston.
Every model has predictive power. Even the God model.
It predicts something existing; rather than nothing. Of course, it is a worthless prediction but it is a prediction.
I think you mean scientists. I.e., construct an experiment validate, etc.
God model the least possible predictive power imaginable.
Also, according to philosophers, God must exist because it's a perfect being. And a perfect being must exist because it is perfect. They are like people left in a sensory deprivation tank hallucinating random patterns into a sensible picture.
Science does not pursue truth. Philosophy does.
It is still navel gazing batshit insanity, but if it works well enough nobody questions why it doesn’t work better.
The true nature of reality might be unknowable, but science is a means to move towards it.
Of course scientists care about their models being close to/matching reality. Have you ever spent any amount of time in an university's lab?
Approximately everyone I've met in my alma mater cared about their models being close to reality (or as truthy as they can be).
What scientific procedure would you use to establish whether one working scientific model “matches” reality; while another working model doesn’t? Nobody has direct access to reality outside of their own theoretical paradigm of understanding.
It isn’t just me saying such “crazy” things…
See what model1 gives as a prediction for input X. See what model2 gives as a prediction for input X.
Input X in the world and compare what actually happened.
The models that more closely predict the observations are more likely to reflect reality (aka being closer to the truth).
You don't have direct access to reality. And yet if someone thinks F = ma isn't closer to the truth than F = ma^4 (for the usual symbols and approximations and blah blah, assume I'm aware Einstein existed) then they got way too drunk on other people's philosophies.
Most scientists I met and worked with care if their models are close to reality/truth. Epistemological uncertainty does not mean every model is equally untruthful.
If two different models/theories are observationally equivalent; if two (or more) different curves can be fitted to the same dataset which model is “more true”?
https://en.wikipedia.org/wiki/Observational_equivalence
https://plato.stanford.edu/entries/scientific-underdetermina...
And how do you go from “F=ma for the usual symbols…” to solving the symbol-grounding problem? Symbols are epistemic entities, not ontological entities.
https://en.wikipedia.org/wiki/Symbol_grounding_problem
The model works. That is all there is to be said about it.
If you begin asking questions such as “is the model true or not? Do the terms in the equation correspond to real world entities?” you are no longer doing science, you are doing philosophy.
You don't know which one is more likely to be true (all other things being equal). However, if all else isn't equal and you are well acquainted with a Mr Bayes you can probably do all sorts of fancy Mathematics to estimate which model is more likely to be true. Or just go with your hunch. Or find yourself a dataset that will invalidate one or both of your models.
Mind you, I don't think this is an issue for most subjects. How often do you get different functions that spew the same output in the all observable and theoretical instances?
>If you begin asking questions such as “is the model true or not? Do the terms in the equation correspond to real world entities?” you are no longer doing science, you are doing philosophy
Yes, people often do that when they are engrossed in a subject. Most scientists I met care about the subject they are working on and philosophise a lot about it. Some don't anymore, possibly because working in the academy should be considered a carcinogenic hazard by the World Health Organization.
When talking about scientists people sometimes forget that they are human, often driven towards the career by just wanting to know. They care if their models match / are close to reality to the best of their knowledge.
Do remember that we are talking about scientists, not science. Almost everyone I met in my short time in the academy fundamentally cared if their models closely matched reality. Most of them didn't get where they ended up at for utilitarian reasons, and lots of them are on a permanent state of annoyance at not being able to fill some forms with "I'm just curious" to get funds.
But you still need to tell Mr Bayes what your criteria are for model-selection.
So the output of your calculations is some scalar "truth-value" (higher is better) - what's your input?
In simpler terms: the truthfulness of your model is a function of... what ?
>Mind you, I don't think this is an issue for most subjects. How often do you get different functions that spew the same output in the all observable and theoretical instances?
In curve fitting? Practically all the time! It is a mathematical fact that infinitely many curves fit a finite dataset. So we pick curves that fit approximately, not exactly with the obvious underfitting/overfitting optimisation problem that needs solving in conjunction.
While this may hold true in almost every case. Just as truth is not absolute, neither is "wrongness".
Furthermore, there exists some model which is neither right nor wrong[1]
[1] https://publications.recursion.is "When all contradictions are resolved what will be left is - an unprovable truth"
Why didn’t you choose dialetheism?
Seems like an arbitrary choice… Could it be that you are culturally biased in the orthodoxy of Western philosophy dating all the way back to Aristotle?
There are systems of reasoning which don’t only concern themselves with Booleans (true and false). There are infinitely many non-Boolean types possible in type theory.
Human constructions/models have many other interesting and desirable qualities/properties beyond “truth” and “falsity”. Mathematicians/Logicians/Computer scientists are deeply interested in understanding those semantic properties.
Recursion is one of those properties studied. It is a foundational concept, not the be all - end all.
Convergence and divergence are another example of interesting semantic properties. They are studied in bifurcation theory.
https://en.wikipedia.org/wiki/Bifurcation_diagram
Whatever your conjecture you are only constructing a lens through which you are interpreting the world.
Why do you point these specific ideas out? I do not, yet, understand the purpose behind your words
From the yardstick of “specificity” my critique of your conjecture is precisely on the grounds that it is too specific; or not general enough.
In particular - the purpose behind my words is to understand why you are constraining thought/expression to merely recursive convergence and to the detriment of recursive divergence.
Why the arbitrary specificity?
In general - I don’t understand the purpose of your conjecture either.
My original paper was not titled Recursion "Convergence" Conjecture, it was titled "Quantum Recursion Postulate". I later realized I was incorrectly conflating popular use of the word "quantum" with "superposition". So, I re-titled my paper.
This felt like a good decision. Convergence is one of the central ideas to the paper-I want others to disprove the paper to converge on a solution. The focus of my paper was not quantum mechanics, nor was the paper describing only a small system. A understandable mistake for someone who has no formal physics background, and has only conversed with those who do.
Of course, this re-titling had the now obvious effect that I lost the diverging aspect of the paper. To further illustrate how I managed to damage the original meaning behind the paper, I will show you perhaps the only proof I have that my conjecture also includes divergence: "The more information considered, the more likely the solution"[1] "Once all is explained, there will always be more perspectives you can attempt to explain that which is already explained from. There will always be new layers to explain previous layers with. Seeking these new layers is what is important, as you can use them to help others understand what you already do. These others, which may want explanations, will stem from these new layers and only understand these new layers."[2]
Looks like I need to change one of my scripts (which I already recorded the audio for >.>) and re-title my paper to the "Recursion Conjecture". Thank you!
Why is it a “recursion conjecture”?
Why isn’t it a “Corecursion conjecture”?
Additionally, I admit that I was not aware of corecursion prior to this conversation. I have been referring to the two as the same concept this entire time. I do not have access to all that is knowable. I did not go to the same universities/* you did that taught this concept. To further illustrate this, "corecursion" has About 18,100 results on Google. "Recursion" has About 20,900,000 results. All YouTube videos on the subject have sub-1k views; since your comment, I have watched many of these videos.
I am prepared to say that corecursion is an integral part to the conjecture; just as important as recursion.
Lastly, it is my understanding that they are, in a way, each other. Ask yourself how you define both and then ask yourself what is the major difference between the two. Are you certain that your definition of both is absolute? Could it be that one could stem from the other in some case? I'll give you a hint, I am being entirely rhetorical. They do stem from one another. Where this stemming-process has *no origin*[3] in an *infinite* system - neither idea can be seen as the "top-level" idea. They are both crucial.
This conclusion may bother you, and I will release a more rigorous argument soon. Corecursion will be a/the topic of one/all of my future videos.
PS: This conversation allowed me to think I understand how type theory integrates with mathematics, to my own personal plague of not internally using concepts I don't think I fully understand
Like many have said in the past, computer science is not really “science” or even engineering. And if that’s true, then software architecture really isn’t science. It’s closer to a soft science if anything. There may not really be a meaningful definition of “law” and that degree of rigor may not be very easy to accomplish. After all, there’s hardly anything objective about it.
However, that doesn’t mean that observations about it are not interesting. I certainly think Conway’s law is interesting despite that it may not meet the criteria to be called a “law” in a harder science.
> Like many have said in the past, computer science is not really “science” or even engineering.
Computer Science is absolutely science, as much as physics is. Science is the ability to make precise predictive models of the world using math. Computer Science provides plenty of those. For example, by knowing the binary search algorithm we know that the time it takes to do a git-bisect is bounded by the log of the number of commits in a repo. We can also know what kinds of encryption keys could be discovered through brute force guessing given presently available hardware. We can precisely describe the kinds of coordination problems that can afflict concurrent processes (not just in computers) and the kind of mechanisms that can be used to avoid those problems. All of these add knowledge to the world of the same type as the laws of magnetism or gravitation.
Computer Science is the science of process. Software engineering is the application of that science to messy human problems, and is no less an engineering discipline than any other. Like other engineering disciplines there will always be room for heuristics and human judgment. Conway's Law absolutely falls into that.
The precision of any engineering discipline will always be limited by the precision of the softer sciences, as the phenomenon they describe are an ineradicable aspect of the engineering process.
For what it’s worth I hold a BSc from a large, reputable UK university in computer science, not informatics, so it’s not as universal as you suggest.
I do also hold an undergraduate degree from a French university in informatique, a contraction of “information automatique”. Both words are equally important in the name of that discipline, and the “automatique” part is very much about process.
But we are debating the map here, not the territory.
If you're game, I'm curious what seems weird about the semantics?
Not just the map but the terms written on it. :D
You could validate these claims by looking at org charts across various companies and looking at their software architecture and come up with some measure for how closely they resemble each other
The conclusion is slightly defeatist, but ultimately correct. At time 49:23, Casey says "But we have to do them right now, because we haven't figured out how to do it better."
[excessive modularity] is the worst form of [software development] – except for all the others that have been tried.
Like him bashing SOLID principles. It read like a man arguing against hammers, and instead suggesting using drills (which is fine if you need to drill a hole but bad advice if you want to hammer a nail). Like yeah, SOLID is over used and over-stated, but they were invented to stop certain set of problems.
The emperor definitely doesn't have any clothes though when it comes to either one of them.
The problem is, when was it ever shown they solve any problem? Where are the measurements showing less dev time or less bugs or better performance? Where even is an algorithm to show your software is SOLID? People can't even agree on what those mean.
Software has gotten a lot more complicated since the 1990's and from my experience, projects where design patterns are used effectively run a lot more smoothly than those where they're not used or not used effectively. It's great when you can open a project from 15 years ago and say "Actually, the code isn't too bad!" because the developers followed some rules of thumb.
I agree with Casey that these rules of thumb aren't going to lead to higher-quality software from the end user's perspective. I doubt that they're going to make it worse though, unless they're blindly followed.
There's something to be said for not wasting time on things that don't matter to anyone but yourself, and code aesthetics is often one of those things.
I'm curious to know what you think is unmaintainable in his codebase. Sure he uses alternative little-known techniques for say, memory management, but once you know what is going on, the code is pretty clear I think.
He posted an issue about the Windows terminal being slow, and proposed simple things to speed things up. What happened? The Windows Terminal team declared that what he proposed is an entire doctoral research project that would be a massive investment. He did the freaking thing in 2 days and said that it's "nothing" and "very simple". The team then apologized for being dumb and is now working on implementing his idea, that they described as "original" and "very valuable"
T(n) = b + (T(1)-b)/n
T(n): Time to run task for n parallel threads (workers)
b: Time it takes to run part of task that can not be parallelized
Therefore:
T(inf) = b
Their attempt to simplify it makes the new version dangerously wrong if you take their word for it.
Less wrong:
T(n) >= b + (T(1)-b)/n
T(n) >= b + (T(1)-b)/n + C(n)
This is not really "a more subtle improvement", "new version", or "refinement". It was known in the field in the 70s. That is, Brook's Law can apply to parallelized computation, not just to teamwork. Which OP observes but still doesn't make them see the errors in their previous assertion.
The case with software classes and components is different. None of those inanimate object care if their contribution is measurable, so the law does not apply as strongly with respect to them.
I took a glimpse what people here say about the video and I find too many criticisms to consider it reasonable to spend time watching the video...
This is one of those talks where I’m convinced the person is being paid by the second. By the time we had got to the third iteration of “before I tell you the thing I’m going to talk about let me (define what a law is/critique Harvard business review/give an irrelevant sidebar about the language of technical papers and the fact ‘Datamation’ still exists”) I totally had lost any and all interest.
I think the closest thing is Bezos's API mandate. This is an attempt to flatten communications across a vast organization, with the upfront cost that each team build and maintain an API.
https://blog.acolyer.org/2019/12/13/how-do-committees-invent...
- Software architecture matters to you
- Software performance matters to you
- Team and organizational performance matters to you
Incredibly trite and wildly overlong is how I would describe this.
- Entropy
- Capitalism
- Greed
To not be vague, user greed for features and less for performance cause increase in complexity. A complex system is by definition more chaotic and harder to optimize.
And Capitalism rewards doing just a bit better than competition. I.e. optimize your time on quickest things that gives most users satisfaction.
More specifically, capitalism doesn't reward the worker for doing software architecture better at all, just rewards the company. So the workers will naturally make the politically safe choice for software architecture and not care whether that is right, which means making it look like the org chart.