3 ms·
I’m saying nothing for or against the rest of the article, but this one sentence does not describe software as I know it: “But above all this is the sheer waste
by braythwayt 7y ago
I’m saying nothing for or against the rest of the article, but this one sentence does not describe software as I know it: “But above all this is the sheer waste of human effort in terms of the production of rotting software in repositories.”
The act of writing code changes the programmer. I have written many things that didn’t turn into successful open source, nor did they act as resume-ware. But the act of writing them taught me something.
There is no waste of human effort involved when you practice your craft. This is like telling me that if I climb a cliff and then lower myself back to the ground, I haven’t gone anywhere.
Right now I’m working on implementing a subset of regular expressions that compile to finite-state recognizers. There is a zero-percent chance that my working code will be used in production.
So what? I am learning something about pattern-matching, and perhaps it will grow into a little language like SNOBOL.
http://raganwald.com/2019/09/21/regular-expressions.html http://raganwald.com/2019/09/21/regular-expressions.html
If that is a waste, then most of my most enjoyable moments programming were also a waste.
- zozbot234 7y ago> But above all this is the sheer waste of human effort in terms of the production of rotting software in repositories. Yup, what about the amount of human effort that has been wasted in the course of producing off-the-shelf proprietary software? How much of that proprietary stuff is now entirely useless, for some reason or another? It's just so weird to make an engineering-focused argument for proprietary stuff, when the only case that's even remotely plausible is about production incentives, and everything else hugely favors FLOSS. As an aside, I'm pretty sure that, in the medium-to-long run, we'll manage to fund FLOSS development to an entirely satisfactory extent via crowdfunding, and that while saving a lot of dough compared to what it would take to fund proprietary development in the same way. But in fact, even his point about support revenues is misguided. Well-designed and easy-to-use software does not really draw fewer paid-support arrangements than software that's hackish, unintuitive and the like. The nees for paid support is almost entirely an organizational one, so it matters zilch how easy the software is to support in reality; it's far more important that the organization can point to that support contract if any such need should arise.