A Codebase Is an Organism (2014)
meltingasphalt.com
meltingasphalt.com
Both anabolism and catabolism are always operating, though at different rates depending on the environment and needs of the organism. The funny thing is that catabolic processes will happily tear down important parts of the system, forcing them to be anabolicly rebuilt. Things like bone and muscle mass. This seems wasted, but it has an extremely important purpose: uncontrolled anabolism is cancer.
I think the analogy to code is obvious. We've all seen codebases that have gotten out of hand (gotten cancer), and part of the reason they got that way is because the growth pressures had no countervailing teardown pressure. The market provides selective pressure in nasty ways: codebases and systems with cancer slow and die, and are replaced by younger codebases without uncontrolled growth.
How do we break that cycle? By encouraging catabolic activity culturally within our companies and codebases. Cleanup is incredibly valuable. Functionality that isn't being heavily used and is complicating implementation of new work should absolutely be on the chopping block. We don't have to be quite as aggressive as biological systems, but we shouldn't take their example lightly either.
This also provides insight into when cleanup doesn't matter: when the survival horizon of the organism is sufficiently short that cancer frankly doesn't matter. Startups shouldn't worry too much until they have product market fit. Once it's clear they'll be around for years more though, catabolic work will help ensure future health.
Coming soon: Diagnostic and Statistical Manual of Software Disorders.
This is especially true in monorepos. Code resuse has it's benefits, but left unchecked the dependency graph can turn into a huge highly-connected glob. Modules end up accidentally importing code they have no business importing because of sneaky transitive dependencies. The blast radius of even small simple changes becomes enormous, and testing/debugging becomes more and more complex.
A great way to keep this in check is to have apply code isolation in the test environment. When you checkout the entire repo for a build or test, its easy for these kinds of dependencies to grow unnoticed. But if you require build/test targets to explicitly declare what code they depend on (and only make that code present when running them), changes to the dependency structure must be explicitly acknowledged in code review. This is one of the core principles behind build tools like Bazel.
Not in my monorepo.
I have compile time boundaries between modules and I cannot make them particularly entangled with each other.
Maybe the problem you have in mind, is more likely to happen in dynamically typed languages? Where there's no compiler who can say "No."
I now believe that monorepos can only work well when there is a mechanical tool for ensuring correctness and that refactorings can be done atomically across the whole tree. Infact, it might be necessary to _only_ commit the refactoring operation to the tree and the source itself. That the whole tree is a blockchain of tree edit operations.
Isn't a compiler such a tool? I use a statically typed language, and if I would try to do this:
> everything can reach everything else
then there'll be compilation errors.
Ugh, too far :-/
The second is that the codeswarm link in the article is dead. This project on github is the closest thing I can find to any remnant of the project: https://github.com/rictic/code_swarm
https://blog.vivekhaldar.com/post/6972614229/large-computer-...
A galaxy could be thinking like a brain, except thoughts travel light years, are mainly dictated by GR (Light and Gravity), and take eons to actually occur.
I think it's clear that the only meaningful nature of scale in time and space for life is just the one we artificially put on it, because of our conscious experience.
LOTR and other fantasy explore this with the idea of trees having much wisdom having lived so long.
If we look at the total potential lifetime "clock cycles" of a system, and compare that number to systems that we know are considered intelligent and capable of thinking, it might shed light on the plausibility.
It takes information 100,000 years to cross the galaxy, and the universe is 14 billion years old (the galaxy is younger, but not enough to matter for this), so roughly a maximum number of 100,000 round trips could have possibly occurred in this "galactic brain".
Let's use a very conservative metric, such as how long it takes a human to blink in response to stimuli (about 100 ms), for our "human clock cycle". If a human lives for 80 years, that is about 2.5 billion seconds, or 25 billion clock cycles.
This is roughly 7 orders of magnitude (10s of millions) more than in the galactic brain. This gives the a very loose impression that a such system would probably have not have enough information flow or feedback loop cycles to "think" anything interesting.
Of course, this a very rough heuristic, but I think it is interesting and useful. The idea of unexpected or strange "thinking systems" is very cool and we should continue to explore it, but there are certainly some hard constraints defining the space of such systems.
My only rebuttal (if I'm to take an opposing position), would be that different organisms have different clock-cycles, an example would be organic life, hummingbird metabolism versus elephant or whale metabolism. I don't know if their brains are also faster, but since their reaction speeds do seem to be connected to their metabolic rate, it's probably the case.
Considering architecture, the way intelligence is being created through Machine Learning is through cellular units that carry large amounts of information digitally instead of oscillating analog signalling. In fact, I found that when building cellular automata, black-white automatas are elegant in theoretics, but when it comes to what will deliver the most complex/intelligent dynamics on a GPU, it is using each cell/pixel as a complex number, floating point, or vector of such types. The GPU can do so much with single units, so it makes sense to use its full potential.
It's possible that the encoding/signalling of galaxies is similar. Clock speed only has to be as fast as things you _can_ react to. Can a galaxy move fast enough to dodge an asteroid? Likely not.
It'd probably be enlightening to know more about how the brains of larger, slower animals such as elephants or whales operate. Their "clock speeds" might shed some light on what kind of parameter ranges life operates within.
EDIT: one more thing I thought of is that it's very possible that the living stage of the larger structures of our universe is simply young, adolescent in nature. Perhaps we are living at a time when the intelligent behemoths among us, or rather, that we are apart of, are of their first generation. I agree though, it's more unlikely to be seeing the head or tail of a distribution than somewhere in the middle. But we should not rule out young, large intelligences.
That's a fair point. I think the comparison would have a somewhat similar conclusion, perhaps not as dramatic though.
Either way, "clock speed" / "number of clock of cycles" is only one way to analyze such a system.
Another important aspect of an intelligent system is the computational complexity of each node in the system and their ability send "messages" back and forth. For a brain, we could look at the neuron. My limited understanding is that neurons are actually pretty complex from an information processing standpoint, despite the implied simplicity we see with artificial analogs such as the neural nets used in machine learning.
I can't imagine what sort of naturally occurring entity would be able to function as an analogous "node" of a galactic brain, or even what sort of messages could be used do to do complex information processing. Stars don't look like they could fulfill the role. In terms of "information processing" I don't think they really do much.
Anyways, it is all very interesting. It is probably possible to have a much larger and very different "thinking system" than what we find on Earth, although I'm not sure what it would look like. Bu I am skeptical that such a system could span the enormous distances between stars.
By the way, you should check out book The Black Cloud [1]! It is a fun science fiction story that explores this idea.
This one? - https://news.ycombinator.com/item?id=20219354
[0] https://hn.algolia.com/?query=brain%20speed%20light&sort=byP...
However, there are probably many other factors besides simply besides the number of "clock cycles" that constrain the circumstances under which such systems can form. For example: the computational and communicative capabilities of each node in the system. I can't imagine any "node" analogous to the human neuron that could form a thinking system spanning large regions of space. For example, stars don't seem to have any complex information processing or messaging capabilities.
That would be an awesome theme for a game. Be a cell, an insect, a tree/ent, a human, a planet, or a galaxy. Change the scale of time and space, watch civilizations rise and fall. It's an epic thought. Would probably be a very hard game to program though.
The galaxy overall doesn't exhibit a single one of these properties at a high level. Entropy is rising and there is no mechanism for mutation let alone replication.
Are you familiar with prions? Well, their form of reproduction _is_ nucleation.
How do people balance this? The “state of the art” still seems to be things like “have asserts turned on in the debug build” but a holistic approach where the application has different runtime contracts with regards to failures based upon who is using the app seems somewhat underutilized — I’ve done it piecemeal with application feature flags but has anything like this been done at the platform/language/framework level?
I knew it! I always thought maintaining my project was like doing a bonsai tree!
(Disclaimer: I have zero experiences of bonsai.)
We integrate with dozens of 3rd party APIs, making over 10M external HTTP calls per day. That leads to a lot of variability in runtime characteristics.
You don't program the system, you negotiate with it.