"Not Rocket Science": The story of Monotone and Bors
graydon.livejournal.com
graydon.livejournal.com
Huge blast of nostalgia: Back in the summer of 2006 when I was learning git for the first time (and leaving svn in the process), there was all this uncertainty in the community about which VCS was the best... a lot of people weren't even sure that DVCS was a good idea at all! Even so, the Linux kernel had been using git for a year at the time.
At the time there were git, and mercurial, bazaar, bitkeeper and its controversies... and I distinctly remember reading about Monotone! I remember reading how it was the inspiration for git's DAG. I was intrigued but sadly never actually tried Monotone because I was already too blown away by learning git.
It's funny. Git completely changed the way I thought about coding. Made me really, really realize the value of good data structures, and what a waste of effort parsing is. As a direct result, I became obsessed with an idea in late 2006--this idea of a truly next-generation programming environment. This idea of a language+editor+VCS where the ASTs and entire edit history would be stored in git's DAG. [1] So I worked on that for a while, but never really got anywhere...
... and then in late 2012, along comes Rust, which fulfills the language part of this language+editor+VCS trifecta in my mind. And Rust was a personal project by Graydon! So I'm just realizing now that Graydon conceived not only my ideal language, but also my ideal VCS! So that's why my mind's blown.
In short, Graydon is a prolific badass.
[1] It's really a very old idea of course; as old as Smalltalk. I think Steve Yegge attempted it with his Grok Project. See also: Subtext, Lamdu, Projucer. As for the future, Chris Granger and his team may very well pull it off with Aurora.
Like you I discovered that Graydon was behind all these cool projects sort of by accident. He seems to keep a low profile.
Also, their "open source report card" is always hilarious: https://osrc.dfm.io/bors/
If it doesn't really, truly work, one reason could be that most corporate developers can barely write working code; writing test code that will hold the whole project up if/when it fails -- that's beyond what you could trust the average developer to write.
It may work well when you have a top-notch developer to write tests, or when the goals of the project are especially amenable to automated testing, but in the common case cause too much friction.
Edit: a more sinister reason that automated testing isn't used more, even if it might deliver better software, is that a lot of companies that are in the software business don't care much about defects. Many seem to care more about shipping features, even if those features are half-assed and buggy, than about shipping code that works. But, even so -- we're talking about no-brainers here. Even shoddy companies eventually adopt really obvious better practices, even if only by following the herd.
This is charmingly naive.
Don't worry about people stealing your ideas. If your
ideas are any good, you'll have to ram them down people's
throats.
-- Howard AikenThis article is claiming to have an idea so great that literally anyone can employ it and benefit from it, though, and that's an awfully high standard.