I'm contemplating writing a long "from scratch" style book on another topic and I'm still not sure which language I should use. Using more than one (Java, Python,...) and generating multiple flavours of the book could be a good idea I think.
https://twitter.com/mountain_ghosts/status/11148630508075499...
I used to think so too, but tbh I think this will result in either a lot more work than you would like, or your audience are going to end up with one language that is being used ideomatically and the rest of the languages are not being used ideomatically.
On the one hand, people do buy the Java and C books. On the other hand, I think they eventually realize it's probably easier to learn an ML dialect and learn the "real" code.
This may or may not apply to the git book though, since doing it in Ruby is already not "idiomatic".
Obviously the Rust version is significantly faster, but the Ruby version is higher level and better expresses the concepts the book is trying to demonstrate without getting too bogged down in syntax, types, etc.
I don't know Ruby at all but I have read through part of the book and can follow the examples pretty easily. Plus, I think I'll get more out of the book if I just use his examples as guidelines and have to do some mental work to translate them into the language I'm using.
From what I understand, Ruby is highly accessible and has a standard library that covers what's used in the book.
Real programming languages introduce too much accidental complexity (memory management, type declarations, etc.) that usually have nothing to do with the subject matter. (Unless you’re writing a book about that particular language of course)
It will also look bad if you happen to choose a language/framework that will be dead 10 years from now, even if the core concepts of your book would stay relevant.
I know those were just examples, but that might hint at why ruby is a fine choice here. It has neither explicit memory management nor type declarations. It's pretty close to pseudocode already.
I'm probably old-fashioned, but it seems like too much "screen time".
I have about five 500- to 1000-page dead-tree compiler books, and many (most) of them have sat around unread for months or even a few years -- at first.
But over time I've managed to get through significant portions of them. That's probably because they are laying around near my couch. The sight of them reminds me why I bought them :) I find the paper books more ergonomic to skim.
In contrast, I feel like an e-book would just get lost on my iPad. This feedback might not be actionable but I thought I'd share...
obviously the lib folder requires a lot of git-specific knowledge but I didn't see any use of features that don't have exact or very similar equivalent in more popular programming languages.
I think the most "complex" might be things like Struct.new(*Inputs::ATTRS) where it's creating a new anonymous class from a list of attributes which becomes the class instance attributes (nothing crazy :) )
There's another reason git is a great choice as a large project to build: you can get something that works very quickly, and then just add to it. Because that is how git was developed. It's like Gall's Law, but evolving only additively. And although Linus was inspired by BitKeeper, it was stripped down to its nakednes, til no longer anything to take away (like Exupery).
Also why git's UI design is so terrible.
That is not at all the same thing as a hacky prototype just starting out on its journey towards accreting random code detritus.
But you're wrong to describe his prototype code as "hacky" - especially when I'm referring to the design - which really is pared down to the essentials. Even "streamlined" and "precisely suited to its purpose". It's also not "just starting out", in the sense that the design was informed by BitKeeper, just much simpler.
When you get your data structures right, the code is obvious (Brooks).
You're right to say "accreting". I'm not sure about "random", but you're wrong to call the code "detritus". The engineering on git is really top-notch, extremely performant, but only where needed; and with the most helpful error messages I've ever seen. It has many great aside features, like git diff --color-words. I'm not an git expert; I expect there's much more.
PS you're also right it's Saint-Exupéry, not Exupery.
I found Git's initial commit (https://news.ycombinator.com/item?id=8650483) which is a repost, linking to https://github.com/git/git/tree/e83c5163316f89bfbde7d9ab23ca...
But it's more complex than I recall, and is dated Apr 8, 2005; wheteas Linus thinks he did the very first version Apr 3. https://www.spinics.net/lists/git/msg24141.html
https://github.com/jcoglan/jit
If you'd really like to make a Java equivalent of any specific algorithm you can start even without a book.
I guess that anybody not versed in Ruby would first have to understand a lot of Ruby details first. The author mentions other efforts relatively similar to his, in other languages, like http://gitlet.maryrosecook.com/docs/gitlet.html which is node JavaScript.
edit: ruby gem: https://github.com/libgit2/rugged which has a native extension written in C to bind libgit2 functions to ruby methods.
Looks very interesting.
As someone who spent the first decade or so as an embedded software developer, I wanted to move into web based systems because its a "bigger world". I'm a couple of jobs into this bigger world now, and it just keeps getting bigger. I feel the need to keep my finger on the pulse of new tools and technologies, but I try to hold that in tension with the advice we get here to keep things simple, be pragmatic, don't adopt technologies or techniques just because google does. I've always fancied myself as a generalist, but this bigger world makes me feel a bit like Bilbo Baggins, "like butter spread over too much bread."
My point: I've been in both worlds and I feel more at sea working on internet based systems. I had more mastery over the embedded systems I worked on, than over the web based systems I work on now. So my experience is in support of the author's point that ...
"anyone with enough brains and patience to learn how to do any kind of computing is “smart enough” to learn things like this."
Moreover, I would suggest that the average full-stack web developer is probably over-qualified.
A few years ago I read an article on LinkedIn, about how a local development company he helped our neighbouring municipality switch from ASP Web-Forms to the first version of AngularJS and Web-API because it was a more modern tech that would make them future proof, especially in regards of hiring.
I laughed at it at the time, and sure enough, they’re in trouble now because AngularJS didn’t actually stick around for long enough for anyone to really learn it. Where as the newest versions of ASP .Net Core are actually being build in a format that is extremely similar to ASP web-forms.
I’d like to say that I don’t think you should actually use ASP web-forms if you can avoid it, because it is dated, but it still runs half the internet in my region of the world and it’ll probably continue to outlive a lot of trendy techs for the foreseeable future.
Our goal is that if something changes radically every few years, then it’s not really worth adopting to our generalist stack, because we can’t afford to waste resources re-learning React or Angular or X every two years.
Oh well, e-readers are okay too I suppose.
I'm trying it out and doesn't work very well on macOS (git add has issue with the lockfile, but all tests pass).
I might use it as it's a very easily customizable implementation of git.
If you're at all interested you should buy this.
This one shows the fundamentals of git in far less than 700 pages. In fact you can go through it and understand git in an hour or two. For me this seems much more worthwhile than seeing in depth how all the git porcelain commands are done.
[0] https://wyag.thb.lt/ [1] https://news.ycombinator.com/item?id=19386141
