4 ms·
> IMHO that's because we have software running that's over half a century, with organizations depending on it, and so it needs to continue running. Well; as I
by 9dev 2y ago
> IMHO that's because we have software running that's over half a century, with organizations depending on it, and so it needs to continue running.
Well; as I said, I'm absolutely not arguing for somehow removing that feature—having the existing terminals continue working is definitely unavoidable, for the reasons you stated. However, that shouldn't mean there's zero movement in the space. We have several coexisting approaches to everything from operating systems to processors to web browsers; keeping legacy software functional shouldn't be an argument to hinder innovation in the entire space.
> All the tooling that deals with json, yaml, etc is still parsing strings, and I prefer that to a binary format in most cases
There is a subtle difference here: A tool reading JSON from standard input and parsing that is just parsing strings, too, yes. However, what about a platform that passed messages from one tool to another on some kind of channel designated for passing JSON messages, exclusively? I don't think we should just have a --json parameter for GNU utils, but really a formalised way for unrelated applications to exchange data, without each of them having to fend off parsing errors. And reality right now is even worse, with every one of those utils having their own, bespoke output format.
Re: ANSI escaping: This ties into the same point. Applications should have more to their disposal than just reading and writing strings. If there were a way to attach metadata to input and output, we could pass on stuff like what should be coloured how, without requiring escape code parsing downstream. I'm inclined to agree with you on all of this being intensive effort-wise, but that hasn't deterred us in other cases either.
> if someone can't figure out how to extract a tar archive just from looking at the synopsis on the man page and scrolling through the options, unless the archive was maliciously named to hide the fact that it's gzipped or something, I think that person would be a pre-junior developer and still have a way to go to become junior.
I can see where you're coming from, but that's just gate keeping. The terminal is great interface, but does it really have to as undiscoverable? IDEs offer so much introspection into source code-- why can't we even have that for the terminal (except shell-specific completion hacks, which are just a poor approximation of what we should have). I'm not saying we should dumb it down to enable any fool to extract that archive, but UX-wise, it could be a lot easier to learn how something works. And yes, tar was a bad example. How about, say `ip`? Been using it for years, and still cannot remember how to do basic stuff with it without looking it up.