I got a warm "She is so smart! She thinks and feels exactly like I do!" moment when reading this post. The only diff is that in past years I have mostly stopped reading. I am curious how she has found many personally impactful books in past 5 years? I still appreciate good stories but don't anymore feel moved or my world view changed after reading one like it used to be when I was younger
Overall I agree with this comment. A determinist would take this position even further and argue that there is nothing left that we could be in control of - it is causes and effects and maybe some randomness all the way down. Even those things we think are our free choices.
Yes, that’s the ultimate argument against determinism. Either one actually sincerely believe in determinism and trying to convince someone else they are wrong about free-will are just displaying their inability to take their hypothesis to its full conclusion, or they are just trying to dispel their own doubts by bending other people opinions.
Europa Clipper mission was launched Oct. 14, 2024 and arrives to Jupiter in April 2030. Jupyter Icy Moon Explorer (juice) was launched Apr. 14, 2023 and arrives to Jupyter in July 2031. I admire people behind these space missions - lots of work for a reward that one must wait for so many years.
For me the comparison to monorepo made a lot sense. One of the main features of monorepo is maintaining a DAG of dependencies and use that to decide which tests to run given a code change. CRAN package publishing seems to follow same idea.
> One of the main features of monorepo is maintaining a DAG of dependencies
No, that's the opposite of a monorepo (w/continuous integration). A monorepo w/continuous integration does not maintain any list of dependencies or relationships, by design. Every single commit is one global "version" which represents everything inside the repo. Everything in the repo at that commit, is only guaranteed to work with everything else in the repo in that commit. You use continuous integration (w/quality gates) to ensure this, by not allowing merges which could possibly break anything if merged.
Maintaining a DAG of dependencies is a version pinning strategy, the opposite of the continuous integration version-less method. It is intended for external dependencies that do not exist in the current repository - which is why it's used for multi-repos, not monorepos.
But as I originally pointed out, you can have a monorepo where everything is version-pinned (not using continuous integration). It's just not the usual example.
A lot of monorepo strategies that I've seen involve maintaining a DAG of dependencies so that you don't need to run CI over the entire system (which is wasteful if most of the code hasn't changed), but only a specific subset.
Each component within the monorepo will declare which other components it depends on. When a change occurs, the CI system figures out which components have changed, and then runs tests/build/etc for those components and all their dependencies. That way, you don't need to build the world every time, you just rebuild the specific parts that might have changed.
I think that specific concept (maintaining a single "world" repository but only rebuilding the parts that have changed in each iteration) is what the author is talking about here. It doesn't have to be done via a monorepo, but it's a very common feature in larger monorepos and I found the analogy helpful here.
That's a cool thing to have, and I'm glad you found the analogy helpful, but I hope you understand the CI DAG you're talking about is not making anything more stable. It is just to cache build jobs. To make things more stable (what the post is referring to) you need a separate mechanism; in a monorepo w/CI, that's gating the merge on test results (which doesn't require a DAG). (And actually, if you skip tests in a monorepo, you are likely to eventually miss systemic bugs)
