The Only Unbreakable Law [video](youtube.com)
youtube.com
The Only Unbreakable Law [video]
https://www.youtube.com/watch?v=5IUj1EZwpJY
106 comments
> They seem to regard all abstraction as simply unnecessary...
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
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.
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.
> You need some kind of abstraction if you want cheap extensibility.
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?
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?
It’s usually non-trivial to add later, so you have no choice but to essentially make a guess and hope it’s right. There’s basically no real alternative.
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.)
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.)
It is thought provoking at the very least. The perspective I saw his views on abstraction from is the perspective of the product itself. Imagine there is some perfect solution for the ultimate technology. It's a perfect whole, every operation has meaning and purpose, is as optimised as it could possibly be, the hardware and software blend seamlessly with no unnecessary redundancy and so on. Maybe such a thing is so advanced we'd barely recognise it woven into the very fabric of our biology and culture, who knows.
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).
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).
A law that doesn't make predictions isn't a law. A law that is not falsifiable isn't a law. It is an unscientific belief.
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.
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.
The more I think about this comment, the more I feel it is missing the point. They do expound a fair bit on the term “law” but even admit both that the title is a bit flippant (and not the one they originally wanted to go with) and that their formulation of the concept is not yet meeting criteria necessary to consider it a “law,” only that they believe there probably is an underlying law.
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. 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.
I agree with you general about the point of the article and the validity of Conway's Law, but I have a quibble:
> 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.
> 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.
Outside of the U.S.A. (notably in the U.K.) the computer science department is known as the informatics department. This makes the larger claim that the field's interest is information theory. Consider the information theoretic guarantees of total order broadcast and it's equivalence to consensus. Consider also the relationships between automata and languages, computational complexity theory, the relational calculus. Many proofs of correctness have been made over many matters in the field and these are expected to remain as true as the laws of physics.
This is kind of getting into weird semantics.
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.
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.
Thank you for the correction, I should have used softer language. My sample size is small but my edit link is gone. To clarify my meaning, I don't mean to contradict process being core to the field but rather that process is within what I consider a more broad scope for the theory of information. While we could talk about the process involved in proving the equivalence of an automata to a language it feels like a stretch to call the fact of their equivalence a part of the study of process itself.
If you're game, I'm curious what seems weird about the semantics?
Not just the map but the terms written on it. :D
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're absolutely right about information being a key part of computer science. I don't really know how to articulate the relationship between "process" and "information" but it makes sense to me to group them together, and I do like the name "informatics" to describe the science.
He spent a few minutes explaining how this isn't a scientific law. I think you missed it. Go 6 minutes in.
Doesn't Conway's law make predictions and isn't it falsifiable? You pointed it out yourself "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]"
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
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
Please spare us from truth-seeking and leave that to the philosophers.
In science/engineering we care about instrumentalism, not truth.
All models are wrong. Some are useful.
In science/engineering we care about instrumentalism, not truth.
All models are wrong. Some are useful.
> Please spare us from truth-seeking and leave that to the philosophers.
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.
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.
No. I am saying leave truth/truthfulness to philosophers.
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.
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.
> No. I am saying leave truth/truthfulness to philosophers.
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.
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.
No. I mean precisely what I said.
Science does not pursue truth. Philosophy does.
https://en.wikipedia.org/wiki/Instrumentalism
Science does not pursue truth. Philosophy does.
https://en.wikipedia.org/wiki/Instrumentalism
Philosophy divorced from experiment just devolves into navel gazing and batshit insanity.
And empiricism divorced from philosophical reflection fails to understand its own limits/biases.
It is still navel gazing batshit insanity, but if it works well enough nobody questions why it doesn’t work better.
It is still navel gazing batshit insanity, but if it works well enough nobody questions why it doesn’t work better.
So let me try to understand what you're saying here, and correct me if I'm wrong.
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."?
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."?
Yes. Something to that effect.
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_...
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_...
On a scale of 0 to 100, where 0 is no confidence and 100 is 100% certainty, how confident are you in your belief of this philosophy of Constructivism?
Sorry, I am unable to assign any meaning to your question.
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?
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?
Well, kind of. Models are inherently not absolute truths. Otherwise, they wouldn’t be models.
Or is there just a correlation between truthfulness and usefulness of a model...
> All models are wrong. Some are useful.
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"
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 have you chosen a system with a non-contradiction axiom?
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?
https://plato.stanford.edu/entries/dialetheism/
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?
https://plato.stanford.edu/entries/dialetheism/
https://recursion.is has a running list of quotes, one of those quotes is "True and False" - this is the central idea behind dialetheism and is an integral part to the Recursion Convergence Conjecture. I have already recorded audio for a video on the topic soon to be released on https://recursion.is/youtube
Let me generalise.
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.
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.
Yes. I fully agree with all of these points.
Why do you point these specific ideas out? I do not, yet, understand the purpose behind your words
Why do you point these specific ideas out? I do not, yet, understand the purpose behind your words
Well, that is somewhat peculiar…You seem to be agreeing with me disagreeing with you.
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.
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.
The insight you have given me today amazes me.
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!
[2] https://notes.recursion.is/Philosophy/It+is+what+it+is
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!
[2] https://notes.recursion.is/Philosophy/It+is+what+it+is
Well, I am glad you are finding my commentary helpful but I am still no closer to understanding the reasons for your arbitrary choices.
Why is it a “recursion conjecture”?
Why isn’t it a “Corecursion conjecture”?
Why is it a “recursion conjecture”?
Why isn’t it a “Corecursion conjecture”?
https://recursioncorecursion.is does not have the same marketing effect that https://recursion.is does :P
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
[3] https://notes.recursion.is/Philosophy/Origin
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
[3] https://notes.recursion.is/Philosophy/Origin
Truth is just that which corresponds to or is a reflection of reality. Anyone who thinks otherwise is thinking too hard.
The true nature of reality might be unknowable, but science is a means to move towards it.
The true nature of reality might be unknowable, but science is a means to move towards it.
And that's how you know someone got way too drunk on other people's ruminations without first hand experience.
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).
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).
And that’s how you know somebody has only second-hand experience of science - having never reflected upon, or examined the (very human) limits of the knowledge they have been given by others.
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…
https://en.wikipedia.org/wiki/Model-dependent_realism
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…
https://en.wikipedia.org/wiki/Model-dependent_realism
>What scientific procedure would you use to establish whether one working scientific model “matches” reality; while another working model doesn’t?
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.
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.
You haven’t really tackled the strongest interpretation of my question head on.
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.
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.
>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”?
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.
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.
>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.
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.
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.
Nice video. Conway's 1968 paper is a good find.
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.
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.
Perhaps it's a desperate attempt to defer the problem of what the organization should look like. The more nodes you have in your graph, the easier it will be to collapse it into something that maps to the organization you want?
Sometimes it feels like a desperate attempt to defer working on some part of the problem a team doesn't know how to solve. Usually some domain specific thing no one wants to think about. So onion layers get put in wrapped around that bit without actually solving it, just creating an abstraction by which the rest of the system will use the "magic". But often the abstraction overconstrains the domain specific magic through ignorance, so it all has to change when someone gets around to adding it. Seen this over and over.
Having watched Casey's Handmade Hero series since day-1, I've always found him to be highly skilled and insightful. While not a game developer myself, learning from his approach to first-principles software development and code optimization has paid dividends in my day to day work nonetheless.
I've found him passionate and smart. But rarely right.
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.
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.
Not to mention that the “S” in SOLID is closely related to what he is talking about here, namely that a software component ought to be related to only one specific source of changes – i.e. a box in an org chart – in order to minimize the risk of it being changed badly and consequently break something. This implies that you should have a connection between the org chart and the code, in order for the changes in the code over time to not constantly break the code.
With both Casey and Jon Blow I find that if I mentally prefix what they say with "When developing AAA games..." then they are almost always right. Much of it doesn't transfer far outside that domain.
What are you talking about? Neither one of them has ever shipped a AAA game.
I think it's charitable to read that as shipped a relatively performant game.
Actually the funny thing is that Braid's CPU usage was always kind of high for what it was doing. Not sure about The Witness.
The emperor definitely doesn't have any clothes though when it comes to either one of them.
The emperor definitely doesn't have any clothes though when it comes to either one of them.
The most bizarre part is that he took issue which the Liskov substitution principle which is just the intuitive definition of what semantic subtyping means. This isn't some crazy clean code "functions should have less than 20 lines" dogma, subtyping without semantic subtyping is just nonsensical.
> SOLID is over used and over-stated, but they were invented to stop certain set of problems.
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.
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.
SOLID is for long-term development and use software. Games are developed during a relatively short time, and then released, and then not changed very much. The next game is developed independently, as a separate project and effort. SOLID is meant to alleviate continous development where changes and new features are constantly needed. Game development does not easily fit in this mold.
Tell that to World of Warcraft. Really is hilarious just how goddamned clueless most of the comments in this thread are.
Please don’t misunderstand me; I really think that SOLID is good to follow. My comment was more meant to express understanding for people having doubts about SOLID in situations where the SOLID principles don’t give as much of an obvious benefit.
I would say it's more like a builder arguing against building codes. A high-quality building can certain be built without them, but sticking to some known formulas makes sure that everyone working on it is able to anticipate what others are going to do. It also makes sure that the building won't collapse, though this aspect doesn't really apply to software.
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.
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.
On the other hand, Casey's been working on Handmade Hero for almost a decade, and has what amounts to an overengineered debug room with less actual gameplay complexity than you'd find in any framework tutorial. Meanwhile actual game developers would pick up a framework, use all those abstractions and libraries Casey finds unnecessary and surpass Handmade Hero in an afternoon.
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.
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.
What's hilarious is that if you actually look at the code he's written for it, it's a horrible ball of spaghetti. The whole thing is a scam. Just because HE says "this is bad code" doesn't mean it's bad, and just because he wrote it, it doesn't mean it's good. Most people would find the clusterfuck he wrote unmaintainable, and the funny thing is that it doesn't even really DO ANYTHING YET.
The goal of Handmade Hero is to show how to do everything from scratch, not how to make a game as fast as possible using existing technology. I agree that the game is currently light on the gameplay side of things, but he said countless times that he doesn't like gameplay code and that he's an engine programmer. I don't know if you watched a lot of episodes, but actually, each hour of him programming is full of complicated stuff which is hard to follow, but he does that in the blink of an eye. Each time you think that you understood something, he starts doing something way more complicated and he always nails it. Look at how many programming streamers are able to speak 2+ hours continuously without any cut. Most of the youtubers have to look at their source code written before turning the camera on to be able to retype it during the video! Even for a simple Tetris or something!
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"
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"
He works on HH for about 2 hours per week.
That's still far too much time for far too little progress. Six hundred videos and counting, each over an hour in length. What is there to learn except how not to develop a game, much less (as I recall him claiming) a AAA quality game.
That's not true. He works on it offline, and honestly, even if he did only work on it 2 hours per week, it's STILL not as far along as it should be by now for a supposed game development "guru." You got hoodwinked.
I have no opinion on them as this is the first time I see them but their misrepresentation of Amdahl's law bothered me as their version makes it incorrect to the point of being useless. Here's how they present it:
Their attempt to simplify it makes the new version dangerously wrong if you take their word for it.
Less wrong:
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.
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.
Yeah his claims about good and bad are too unconditional and generic. He always looks at it from his specific vantage point and then declares something categorically bad which ticks me off cause its so dogmatic and lacking of contextuality.
The law holds for human orgs for a reason beyond "communication". No business unit that is asked to contribute to a project would allow its contribution to take a form different from a discrete, quantifiable module. The 5-person team in the lecture came up with a 5-pass compiler because none of the 5 people were willing to have an unquantifiable contribution indistinguishable from having not shown up to work in the first place.
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.
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.
[deleted]
An hour long video with comments turned off? A summary would be useful...
I would say just read Conway’s actual paper “How do committees invent”.
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.
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.
Towards the bottom of the thread there is a pretty reasonable summary.
https://news.ycombinator.com/item?id=30738878
https://news.ycombinator.com/item?id=30738878
Yeah.. I can understand this block on political videos or other sensitive topics but on this? Well if you can't take the criticism perhaps don't post it on youtube.
It's sad how bad Youtube comments are, but usually some good comments float to the top, and while neither high confidence of a comment author nor high number of likes of the comment give you a guarantee that it's right, often a comment will be a good lead - for example it could link to this HN conversation on the video.
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...
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...
I'm curious in how to use Conway's Law to be more effective. I can learn from Brooks and Amdahls to improve software, but how to apply Conway's?
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.
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.
The Morning paper did a summary of the paper mentioned in the video.
https://blog.acolyer.org/2019/12/13/how-do-committees-invent...
https://blog.acolyer.org/2019/12/13/how-do-committees-invent...
[deleted]
lede is buried at the bottom of challenger deep on this one
I think basic idea and architectures stay more or less the same for decades. Wrapping it out in some fancy terminology and calling those new does not mean "braking the law". It is like RPC vs CORBA vs DCOM vs /10000 other come and go standards which are essentially the same thing.
tldw?
conway's law: how it arises, why it's unavoidable, relationship w brooks' and amdahl's laws, how it explains complexity compounding over time in the form of integrating with past organization structure..
You care about this if:
- Software architecture matters to you
- Software performance matters to you
- Team and organizational performance matters to you
- Software architecture matters to you
- Software performance matters to you
- Team and organizational performance matters to you
It’s Conway's law.
holyyikes(4)
What is this clickbait garbage?
Casey's name should be in the title! I think a lot of HNers respect him.
Really?? I have no idea who he is, and this video didn't impress me at all.
With you on that. I had no idea who he was and definitely didn’t come out of that talk wanting more of whatever he is selling.
Incredibly trite and wildly overlong is how I would describe this.
Incredibly trite and wildly overlong is how I would describe this.
Conway's "law" is such a cop-out excuse for shipping shitty software... There's no such law of nature that says you must ship shitty software. Enterprises ship shitty software because the average tenure of their developers is 2 years, and they have no incentive to improve things beyond what's necessary to pay the bills.
I mean at the end of the day it boils to few things.
- 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.
- 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.
Greed and capitalism don’t explain it. We get shitty software from governments and research labs that have no competition and that get no rewards for shipping extra features.
> 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.
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.
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.