4 ms·

I maintain an Emacs package[1] that focuses on user interaction and hooks deeply into the internals of Emacs in potentially fragile ways (e.g. it sometimes need

I maintain an Emacs package[1] that focuses on user interaction and hooks deeply into the internals of Emacs in potentially fragile ways (e.g. it sometimes needs to actually inspect the call stack in order to determine the correct behavior). For a long time, I had no way to test it in an automated fashion because it was an interactive package, so each release required me to laboriously test its functionality to make sure I hadn't broken anything. Beyond just the time required for manual testing, the mere need for manual testing discouraged me from making releases in a timely fashion. The manual testing also meant that my package was only tested on a single Emacs version (i.e. whatever I was running at the time). Then I finally figured out how to simulate user interaction using Elisp[2], and used this to add a test suite to my package. My tests have caught a number of regressions, especially in older versions of Emacs that I no longer use but still want to support. In addition to being faster, development has been much easier and less stressful for me because I know I can experiment and rely on my test suite to catch almost any regression I introduce. And the stress factor is important, since this is an open source package that I maintain for free, and if it was too stressful, I would probably just stop working on it. Was adding tests to this project a 10x improvement? I don't know, but it sure felt qualitatively like a silver bullet to me. [1]: https://github.com/DarwinAwardWinner/ido-completing-read-plus https://github.com/DarwinAwardWinner/ido-completing-read-plu... [2]: https://github.com/DarwinAwardWinner/with-simulated-input https://github.com/DarwinAwardWinner/with-simulated-input

the_af 7y ago
You have a point and automated tests are definitely a big deal. However, as Wikipedia summarizes about "No Silver Bullet": > "While Brooks insists that there is no one silver bullet, he believes that a series of innovations attacking essential complexity could lead to significant improvements." So I'd say your experience doesn't contradict his point. Automated testing is not an orders of magnitude improvement, and software projects continue to fail or be flawed at an alarming rate, but it definitely helps! (like Brooks also said of high-level languages).
- OrangeMango 7y ago
  Automated testing existed at the time Brooks wrote his essay. In "The Soul of a New Machine", published 5 years prior, engineers arrived in the morning and examined the results of the automated tests that ran overnight, looking for regressions and improvements in the microcode for the new processor. The author treats this sort of behavior as standard engineering work, something all serious engineering professionals do and have been doing for as long as such a thing was possible. Not new, not novel. What we have now is the result of refinements and improvements, perhaps it is a series of innovations. You are right - automated testing doesn't refute Brooks.
omaranto 7y ago
This is off-topic in a discussion of silver bullets, but what advantages do you see in ido-style completion over icomplete? They feel very similar to me and icomplete is built-in, so I went with that.
- rcthompson 7y ago
  I feel like ido is just a more fully-explored version of the same concept. For example, if you use C-. and C-, to rotate the list in icomplete, that rotation is not preserved if you then continue typing, whereas in ido it is preserved, so that continuing to type characters that match the currently-selected completion isn't going to switch you to another matching completion.

the_af 7y ago

You have a point and automated tests are definitely a big deal. However, as Wikipedia summarizes about "No Silver Bullet": > "While Brooks insists that there is no one silver bullet, he believes that a series of innovations attacking essential complexity could lead to significant improvements." So I'd say your experience doesn't contradict his point. Automated testing is not an orders of magnitude improvement, and software projects continue to fail or be flawed at an alarming rate, but it definitely helps! (like Brooks also said of high-level languages).

OrangeMango 7y ago
Automated testing existed at the time Brooks wrote his essay. In "The Soul of a New Machine", published 5 years prior, engineers arrived in the morning and examined the results of the automated tests that ran overnight, looking for regressions and improvements in the microcode for the new processor. The author treats this sort of behavior as standard engineering work, something all serious engineering professionals do and have been doing for as long as such a thing was possible. Not new, not novel. What we have now is the result of refinements and improvements, perhaps it is a series of innovations. You are right - automated testing doesn't refute Brooks.

omaranto 7y ago

This is off-topic in a discussion of silver bullets, but what advantages do you see in ido-style completion over icomplete? They feel very similar to me and icomplete is built-in, so I went with that.

rcthompson 7y ago
I feel like ido is just a more fully-explored version of the same concept. For example, if you use C-. and C-, to rotate the list in icomplete, that rotation is not preserved if you then continue typing, whereas in ido it is preserved, so that continuing to type characters that match the currently-selected completion isn't going to switch you to another matching completion.