Don't be a hacker
Posted on 2016-09-24 Edit on GitHub
I've recently been working on improving the help functions for Emacs (e.g. describe-variable
). The particular file I've been looking at is [[https://github.com/emacs-mirror/emacs/blob/master/lisp/help-fns.el][help-fns.el]]
.
What really struck me is how hacky much of the functionality seems to be. The file is littered with regexps (a clear sign that data is being treated as stringly typed), comments on edge cases that don't work, and lamentations that such-and-such functionality simply isn't "good enough".
This is really surprising, since the data that help functions work with are from Emacs itself. "String typing" and other workarounds are often necessary for gluing together disparate systems or working with poorly-designed interfaces, but there's really no reason to do this when all the data comes from your own system1.
This leads me to a conclusion I've made for quite some time:
"Hacking" is not a satisfactory way of writing software
I was a math and engineering major. Briefly,
- Math
- the solution is correct
- Engineering
- the solution is not exactly correct, but I have carefully analyzed the margin of error and found it to be satisfactory
- Hacking
- it seems to work, and is mostly good enough for my current use case
Programming culture seems to value quickly putting together prototypes, which are then inevitably shipped as the final product. I don't understand this mentality. At first, I thought that it must be the business aspect that is applying pressure towards this end, but the phenomenon seems to happen with a lot of free and open-source software as well.
Prototyping is important, but it should be the first step, not the whole step. A real solution should tackle the problem at the right level of abstraction, solving it (or even the whole class of problems like it) in an elegant way. This takes time and comprehension, which the open source world should have in plenitude.
Footnotes:
I suspect the predilection for regexps is due to Emacs being viewed as a "text editor" whose "primitives" are strings, buffers, etc. Actually, Emacs Lisp has many data types, and strings are most often not the right data format to use until the final step of presenting data.