3 ms·

I fully agree - that can be very tricky indeed. But I think your response on VIM does add another great point to this discussion: nobody would have considered

by hooby 6y ago

I fully agree - that can be very tricky indeed. But I think your response on VIM does add another great point to this discussion: nobody would have considered VIM incomplete for not having JSON support, before JSON even existed. In theory, VIM could have been complete AND finished earlier without JSON-support, back in the day before JSON. But then JSON happened - and suddenly VIM suddenly no longer had a complete set of core features. And not being complete means not being finished - since being complete is pre-requisite for being finished. And doesn't that mean, that a piece of software which does NOT get new features, can't stay "finished" when things change and new requirements emerge? Doesn't a piece of software have to get new features so it can stay (close to) finished - and doesn't revert back to being incomplete? The only way a piece of software could ever stay "finished" without getting new features is, if it was used for something that no longer sees any change happen or any new requirements emerge - it basically has to be a completely non-evolving field of work with static, unchanging requirements. But any active, evolving field of work will always see changes and new stuff and subsequently new requirements will emerge. Software has to react to those changes in requirements.

codesections 6y ago
> And not being complete means not being finished - since being complete is pre-requisite for being finished. And doesn't that mean, that a piece of software which does NOT get new features, can't stay "finished" when things change and new requirements emerge? Doesn't a piece of software have to get new features so it can stay (close to) finished - and doesn't revert back to being incomplete? That's a really interesting question. I guess some of it comes down to whose perspective we're looking at the software from. I'd tend to look at it from the author/mountaineer's point of view: If Bram Moolenaar had declared that Vim was complete with version 7 and would never add major features like async/JSON support, I'd probably say that the program was "finished", even if it lacked certain features that I'd like it to have. (Those missing features might cause me to use a different piece of software, but I don't think they'd give me cause to complain that the hypothetical Vim was "incomplete") (And, indeed, there was a period ~5 years ago where it looked like Moolenaar might go that route, especially with respect to async support. My understanding is that his initial unwillingness to add async support/other new features was a big part of the impetus for Neovim.) > The only way a piece of software could ever stay "finished" without getting new features is, if it was used for something that no longer sees any change happen or any new requirements emerge - it basically has to be a completely non-evolving field of work with static, unchanging requirements. I'm not sure that the entire _field_ needs to be static. For example, Quake strikes me as a finished piece of software – that doesn't mean that video games (or even first person shooters) aren't evolving. It just means that Quake carved out a narrow section of that field and finished delivering on its design goals within that narrow slice.

by hooby 6y ago

codesections 6y ago

> And not being complete means not being finished - since being complete is pre-requisite for being finished. And doesn't that mean, that a piece of software which does NOT get new features, can't stay "finished" when things change and new requirements emerge? Doesn't a piece of software have to get new features so it can stay (close to) finished - and doesn't revert back to being incomplete? That's a really interesting question. I guess some of it comes down to whose perspective we're looking at the software from. I'd tend to look at it from the author/mountaineer's point of view: If Bram Moolenaar had declared that Vim was complete with version 7 and would never add major features like async/JSON support, I'd probably say that the program was "finished", even if it lacked certain features that I'd like it to have. (Those missing features might cause me to use a different piece of software, but I don't think they'd give me cause to complain that the hypothetical Vim was "incomplete") (And, indeed, there was a period ~5 years ago where it looked like Moolenaar might go that route, especially with respect to async support. My understanding is that his initial unwillingness to add async support/other new features was a big part of the impetus for Neovim.) > The only way a piece of software could ever stay "finished" without getting new features is, if it was used for something that no longer sees any change happen or any new requirements emerge - it basically has to be a completely non-evolving field of work with static, unchanging requirements. I'm not sure that the entire _field_ needs to be static. For example, Quake strikes me as a finished piece of software – that doesn't mean that video games (or even first person shooters) aren't evolving. It just means that Quake carved out a narrow section of that field and finished delivering on its design goals within that narrow slice.