> That suggests it might be relying on things it shouldn't be relying on,
why ? If I have a choice between using a software that works on mac / win / linux, and one that works on those three + a ton of obscure architectures / old systems I'd definitely choose the first one - every additional platform supported invariably means that :
- you have to give up some features or reimplement them yourself (because you want that feature anyways) thus more possibilities of bugs, e.g. the amount of times I've seen people reimplementing badly some POSIX functions or stuff like clock_gettime on windows
- you have to duplicate code, say DLL / so loading if you have some plugin system (plus a mess of #ifdefs because of shit like macOS having a non-functional pthread_cancel, etc...)
- in some cases this may mean that the program author needs to add some run-time indirections, e.g. to call platform functions, which may have a performance cost.
- most likely the build system will be some terrible autotools mess which has not been updated in 15 years and does need 50 changes before working on a modern linux distro (had that merely a week ago) + a batch script for windows
- maybe some performance / technical improvements / simplifications would not be available because they would break compatibility with whatever EBCDIC IBM platform with two users, thus making the software worse, condemning us to the "state of the art" of the oldest supported platform
> If I have a choice between using a software that works on mac / win / linux, and one that works on those three + a ton of obscure architectures / old systems I'd definitely choose the first one
The first option probably means they are assuming the terminal behavior of the common terminal apps desktop users on one of the two/three main platforms are using. But if they're making that assumption, they might as well assume they can use a proper GUI and go with that.
The whole point of terminal programming is that you live within the abstraction which is the terminal. The fact that you're thinking about _systems_ rather than _terminals_ is the problem.
It's perfectly ok to have your app refuse to run on a terminal which lacks certain capabilities (annoying, but ok): You check for whatever you need from the terminal using Terminfo(https://en.wikipedia.org/wiki/Terminfo), and die gracefully if necessary. What's not ok is saying "Oh, I'm running on Windows, so XYZ must be true about the terminal I'm in, I'll just go ahead and assume that's the case".
Also - what you consider "obscure and esoteric systems", for many other people is just "systems".
I didn't bother to comment on this, but these are my thoughts as well. From briefly looking through the source code, it seems like the only way this library cares about the capabilities of the terminal is just checking if '256' or 'truecolor' is in TERM variable, and that's it.
> The whole point of terminal programming is that you live within the abstraction which is the terminal
I really fundamentally disagree that there is a "whole point" to terminals (or any other kind of things we use when we use computers). They are just tools which are able to perform things and one should really not ascribe any kind of semantic layer to them, as this is always a very very brittle abstraction. Just look at things in terms of what they are able to do, not what they are called.
why ? If I have a choice between using a software that works on mac / win / linux, and one that works on those three + a ton of obscure architectures / old systems I'd definitely choose the first one - every additional platform supported invariably means that :
- you have to give up some features or reimplement them yourself (because you want that feature anyways) thus more possibilities of bugs, e.g. the amount of times I've seen people reimplementing badly some POSIX functions or stuff like clock_gettime on windows
- you have to duplicate code, say DLL / so loading if you have some plugin system (plus a mess of #ifdefs because of shit like macOS having a non-functional pthread_cancel, etc...)
- in some cases this may mean that the program author needs to add some run-time indirections, e.g. to call platform functions, which may have a performance cost.
- most likely the build system will be some terrible autotools mess which has not been updated in 15 years and does need 50 changes before working on a modern linux distro (had that merely a week ago) + a batch script for windows
- maybe some performance / technical improvements / simplifications would not be available because they would break compatibility with whatever EBCDIC IBM platform with two users, thus making the software worse, condemning us to the "state of the art" of the oldest supported platform
etc etc...