2019-10-13
If you don't test it in your automated testers, it's broken
A while back I tweeted:
The Go developers keep breaking Go's self-tests when you have gccgo installed. Since they don't install it on almost any of their automated builders, I don't think they really care and so I'm done dealing with it myself. It's time to uninstall gcc-go.
I could file yet another Go bug report about this breakage due to gccgo that could as well have been filed by an automated machine, but I've lost all my interest in being a human machine for the Go developers. Building with gccgo present can and should be checked automatically.
(I don't actually use gccgo; I had it installed basically only out of curiousity.)
As a preface and disclaimer, I'm not picking on Go here in specific, because I think this is a general failure. It's just that I know the specific cases with Go and they make for a good illustration. The various incidents with gccgo are one of them, and then recently there was an issue when running tests in a terminal instead of in a situation where there was no terminal.
There's a saying in programming that if you don't test it, it doesn't work. Let me amend that saying; if you don't test it in your automated builders or CI, it doesn't work. This is true even if you have tests for it, and in fact especially if you have tests for it. If your CI is not running those tests, you are relying on the fallible humans making changes to remember to do testing in an environment where those tests will trigger.
(The problem with having tests for it that aren't being exercised by CI is that such tests are likely to give people a false sense of confidence. There are tests for it, the CI passed, and therefor the tests pass, right? Well, no, not if some tests are skipped by CI. And don't count on people to keep straight what is and isn't tested by CI.)
As these two examples from Go show, making sure that your CI triggers all tests is not necessarily trivial, and it's also not necessarily straightforward to guess whether or not CI will run a test. For that matter, I'm fairly sure it's not easy for your CI maintainers to keep up with what the CI environment needs in order to fully run tests, and sometimes doing this may require uncommon and peculiar things. It was perfectly reasonable to add tests to Go that ran to verify its behavior when it was talking to a terminal and it was perfectly reasonable for Go's automated builders and CI system to run builds not using a terminal (or a fake of it), but the combination created a situation where something obvious broke and wasn't detected by builders.
Magic is fine if it's all magic: why I've switched to use-package in GNU Emacs
A while back I tweeted:
I revised my .emacs to use-package for all of the extra packages that I'm using (not yet for stock Emacs things, like c-mode settings). It was mostly smooth and the result is cleaner and easier to follow than it used to be, although there is more magic.
Since I deal with my .emacs only occasionally, I think clean and easy to follow is more useful than 'low magic'. In practice everything in my .emacs is magic when I come back to it six months later; I'm going to have to remember how it all works no matter what I use.
Use-package (also) is the hip modern way
to configure Emacs packages such as lsp-mode (which I've switched to). For example, if you search around on the
Internet for sample .emacs, discussions of configuring things,
and so on, you'll most likely find people doing this with use-package.
This is one advantage of switching to using use-package; going with
what everyone seems to be using makes it easier to find answers to
questions I may have.
(For this purpose it doesn't matter whether or not use-package is in wide use among the general population of GNU Emacs users. What matters is what people write about on the Internet where I can find it.)
Another advantage of use-package is that it makes my .emacs easier
to follow. Use-package forces grouping everything to do with a package
together in one spot and it makes a certain amount of configuration and
setup easier and shorter. I'm not sure it reduces the amount of things
I need to learn to set up hooks and add keymappings and so on, but it
feels like it makes them more accessible, straightforward, and easier
to read later.
The theoretical downside of use-package is that it is magic (and that dealing with it requires occasional magic things that I don't understand even within the context of use-package). Normally I shy away from magic, but after thinking about it I decided I felt differently here. The best way to summarize this is that if you only deal with something occasionally, it's all magic no matter what.
Sure, I'm immersed in my .emacs now and sort of understand it
(for some value of 'now'). But I don't deal with it very often, so
it may be six months or a year or more before I touch it again. In
a year, I will almost certainly have forgotten everything to do
with all of the various things that go in your .emacs, and that's
the same regardless of whether or not I use use-package. That
use-package is more magic and requires learning other things won't
really matter then, because it will all be magic to me unless and
until I spent the time to re-learn things. And if something breaks
and I have to fix it, again it will all be magic either way and
I'll at least start out with Internet searches for the error message.
(Also, in the sense that there are lots of use-package examples to crib from, using use-package is the lazy way. I don't have to really learn how things work, I can just copy things. Of course this is how you get superstitions.)