3 ms·
This comment reminds me of something of a thought-experiment-come-hacky-side-project that I can’t seem to find. The premise was, what if you could never edit a
by jackweirdy 7y ago
This comment reminds me of something of a thought-experiment-come-hacky-side-project that I can’t seem to find.
The premise was, what if you could never edit a function? Instead, you had to delete it and recreate it entirely whenever changes were needed.
The incentives are twofold - keep functions small, so you don’t lose too much investment if you have to delete code, and think before you start writing, else you waste time.
As I remember, this project came with an AST manipulator that would helpfully delete your function if it’s unit tests failed.
- fasquoika 7y agohttps://github.com/munificent/vigil https://github.com/munificent/vigil
- jackweirdy 7y agoYes! This is it
- geofft 7y agoYou know, thanks to Hyrum's Law https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ , there's a variant of this in many engineering contexts: you can never remove functionality directly, you can only add new functionality, deprecate (but maintain) the old ones, and kill it once everyone has moved. Put that way, it's surprising that people haven't felt incentivized to ship the smallest and most replaceable things.
- squiggleblaz 7y agoThey have and they called in npm.
- danhite 7y agoThe project you remembered but couldn't locate is likely Prune within Limbo in the TCR (test && commit || revert) experimental development style by Kent Beck et al which you can review here: https://increment.com/testing/testing-the-boundaries-of-collaboration/ https://increment.com/testing/testing-the-boundaries-of-coll...