N0v0id (Karl Voit) mentioned my post Learning the Right Tools and made an excellent point
If you want to be a good #engineer, learn (from) the best #tools: https://t.co/lDkkOk7En6
#Emacs #vim #PIM
— n0v0id (@n0v0id) January 2, 2016
One of the advantages of learning first class tools is that you also learn from them. I’ve found that to be the case on a couple of levels.
First, you learn how the great tools handle their UI issues. That may be as simple as a command line calling sequence or as complex as a multiple screen graphical interface. The good tools get this aspect mostly right and it’s worth paying attention to how they do it.
More important, perhaps, is that they give you a chance to see how to build great tools by examining their source code. I learned almost all my “tricks of the trade” by observing how the masters did it. Want to know how to write operating system code? Take a look at the Unix or Linux source code and see how guys like Dennis Ritchie, Ken Thompson, and Linux Torvalds do it. Interested in editors? Look at the Emacs source code. You will, I promise you, learn a lot.
In the case of Emacs, you get a bonus. You can read the code and if you want to try out an alternate algorithm or you want to add or change some functionality you can try it out in a scratch buffer without changing, or even restarting, Emacs itself1. If you like the change, you can add the code to your .emacs or init.el file and make it permanent. If your change is generally applicable, you can submit it as a patch. Almost for free you’ve become a contributor and, in the mean time, learned a lot about software engineering.
As I indicated in my original post, you can be content with using tools like Notepad and still get work done but if you want to be a great engineer, you’ll learn—and learn from—the great tools.
Footnotes:
Although the case could be made that since Emacs is a Lisp environment, you are changing Emacs itself even in this case. Perhaps I should say something like stock Emacs here.