I wrote a short book recently [1] and went through a similar process. Started writing using Markdown & Pandoc but soon realized that Markdown isn't a very good fit for longer technical documents. As an example, support for asides aka admonition blocks is nonexistent. I switched to Asciidoc + Asciidoctor and the process was much more productive.
If I understand correctly, the gitbook toolchain isn't freely available. Nor does gitbook address any of the limitations of Markdown that prompted me to switch to Asciidoc.
Pandoc is a powerful tool but it has some serious limitations. Nothing more sophisticated than it's own flavor of Markdown is supported. "Simple" things like internal references to anything other than headings are impossible. I had to abandon it after realizing how restricted its ReST parser is compared to the official Docutils.
I used to be a SuperMemo user for several years and accumulated more than six thousands items. It has advanced algorithms. Both Anki and Mnemosyne are based on the algorithm of SuperMemo 2(its version is 16 now). And there are several pieces of articles about human memory on its website which are very helpful.
But about a year ago, I gave up Supermemo. Because it's really buggy and bloated. I was so worried about my data that I used to back up my data into a zip file every day. Then I decided that I shouldn't trust a buggy closed source software like SuperMemo to protect my data. If it died, I would have trouble converting my data to other formats.
When I was considering the alternatives, I chose Mnemosyne instead of Anki. Because Mnemosyne seems cleaner, and its author is doing some research on human memory which made me think that its algorithm could be better than Anki.
Unfortunately there's no sign of progress on the Mnemosyne research project, it looks unlikely to ever happen at this point. It uses the same algorithm as Anki (SM-2) as its base. Not to say they are equivalent though - both (especially Anki) add many refinements to the basic algorithm.
Congrarulations, the Racket team! It's really a joy to use Racket. Racket is elegant, powerful and fast. Everybody should try it. It's extremely easy to install and setup. And whenever you have any question, a fantastic community is there waiting for you.
A composer doesn't necessarily sit down and decide to "make music". A composer often has some sort of goal in mind, and yes, they will indeed seek out the best instrument for the job. The criteria may very well even include such things as "how skilled am I on the instrument"; someone may just noodle around on a keyboard or a guitar for something that may end up on another instrument entirely, for reasons of familiarity, or because the instrument has useful characteristics. For instance, a piano is a very useful instrument to write for a symphony orchestra, because even though it may not sound like any instrument that will be in the final composition, it's pretty hard for one person to play two flutes and two trombones at the same time, whereas the piano makes it easy to play at least the same notes, so you can hear the harmony.
Similarly for painting; you're looking at a world of difference between watercolor and oil (just to pick two examples), and what you chose depends on the goals.
I'm not sure your metaphor was as useful as you'd like.
Those analogies don't work. Paintings use multiple colors, and many pieces of music use multiple instruments; but for most programs, it's far simpler to use just one language. And if one is going to develop a large program over the span of many years, it's good to think carefully about what language to use before diving in, as that decision is not easily changed.
To be fair, maybe this blog post is getting more attention than the author expected. Regardless, I don't think it makes a great case for "Why __? Use Racket!".
The case I'd make: The shiny new feature X in today's fashionable new lang Y? Racket probably does this, does it elegantly, and has done it for awhile.
CSP is just one example. It's great that Go is helping popularize it.
Also I'd headline it as, "Intrigued by __? Also try Racket!".
Racket draws on a lot of PL research (which is why it probably already has feature X) but is also very practical. It's easy to install and use on all platforms. There's also a wonderful community.
About the only thing it lacks is a BFD/cult leader phenom such as some companies and langs have. ;)
Also, when in a debate or argument with someone, focus on your end goal. Which is more important - winning the argument (or saving face) or getting your objective achieved?
The same way you learned to code: by doing it a lot. You might need to practice extra hard, and it might be extra frustrating, because you might have less talent in that area, but it is just a matter of going out and doing it, and then doing your best to learn from your mistakes.
Not saying that the reading materials and so on are bad, they are just useless without actual experimentation.
