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.
[1, 2, 3].map { |i| i + 1 }
[i + 1 for i in [1, 2, 3]]
def plus(i):
return i + 1
map(plus, [1, 2, 3])
map(lambda i: i + 1, [1, 2, 3]) def f(&block)
block.class
end
f { } # => Proc
f(&-> { }) # => Proc
f(&lambda { }) # => Proc
f(&:something) # => Proc
lambda { }.class # => Proc (I think you get the idea)
method(:f).class # => Method
lambda { |i| i + 1 }.call(10) # => 11
(not that anybody would do what I do, most people just use blocks, some people use yield, few people use the &block argument, but that's exactly the same)
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.