5 ms·

I guess the real question is whether a new method could be used that would provide a greater benefit.

deleted 4y ago
[deleted]
oblio 4y ago
I'm loathe to say this, because every couple of decades or centuries someone does the impossible, but until that happens: It's impossible. There's too much legacy stuff, it would be like boiling the oceans, and there's both no real glory to be had and no money to be made. Oh, and for the legacy stuff. Since there is no real API, everyone did as they pleased, for the new protocol/standard/tools to take off they would either have to be amazing and almost completely supersede existing stuff (ultra hard) or to offer backwards compatibility, which the lack of the API would make it a humongous software undertaking. I've been watching what the Oil shell is doing to just extend Bash in a smart way, and the amount of work going into just that is mindboggling. You'd need a madman (more likely, several) like Lennart Poettering and look at what did, it got him death threats for writing software and getting it adopted.
- Joker_vD 4y ago
  > it would be like boiling the oceans Well, it's kinda happening, finally, right? The oceans and atmosphere heating up? So not impossible.
EthanHeilman 4y ago
I've spent sometime thinking about this. My too much coffee hot take is that you'd want to separate the presentation layer out and provide much structured ways of interfacing with the processes. It would look something like this: You'd have your high level CLI which would call programs, those programs would provide: 1. input and output in form of JSON services. This would function like a modern pipe functionality, 2. a CLI UI which talked to those services. This CLI can swapped out for another at the callers digression, 3. a built in debugging and code reading system similar to developers console in modern web browsers, 4. and hooks for intercepting calls made outside the program either to the OS or the dynamic libraries like LD_PRELOAD In some sense it would replace the terminal with a web browser like CLI. Unlike a web browser you'd be able to mix and match CLI UIs and pipe processes together. I'm not convinced that is a good idea. The beauty of terminals and the power of being about do stuff like process substitution largely comes from the use of simple abstractions. Would a JSON based pipe be less or more powerful than pipes as they are today? I suppose you could always use a utility to strip the JSON and turn it into the newline text streams that the commandline today is so good at manipulating.

deleted 4y ago

[deleted]

I'm loathe to say this, because every couple of decades or centuries someone does the impossible, but until that happens: It's impossible. There's too much legacy stuff, it would be like boiling the oceans, and there's both no real glory to be had and no money to be made. Oh, and for the legacy stuff. Since there is no real API, everyone did as they pleased, for the new protocol/standard/tools to take off they would either have to be amazing and almost completely supersede existing stuff (ultra hard) or to offer backwards compatibility, which the lack of the API would make it a humongous software undertaking. I've been watching what the Oil shell is doing to just extend Bash in a smart way, and the amount of work going into just that is mindboggling. You'd need a madman (more likely, several) like Lennart Poettering and look at what did, it got him death threats for writing software and getting it adopted.

Joker_vD 4y ago
> it would be like boiling the oceans Well, it's kinda happening, finally, right? The oceans and atmosphere heating up? So not impossible.

EthanHeilman 4y ago

I've spent sometime thinking about this. My too much coffee hot take is that you'd want to separate the presentation layer out and provide much structured ways of interfacing with the processes. It would look something like this: You'd have your high level CLI which would call programs, those programs would provide: 1. input and output in form of JSON services. This would function like a modern pipe functionality, 2. a CLI UI which talked to those services. This CLI can swapped out for another at the callers digression, 3. a built in debugging and code reading system similar to developers console in modern web browsers, 4. and hooks for intercepting calls made outside the program either to the OS or the dynamic libraries like LD_PRELOAD In some sense it would replace the terminal with a web browser like CLI. Unlike a web browser you'd be able to mix and match CLI UIs and pipe processes together. I'm not convinced that is a good idea. The beauty of terminals and the power of being about do stuff like process substitution largely comes from the use of simple abstractions. Would a JSON based pipe be less or more powerful than pipes as they are today? I suppose you could always use a utility to strip the JSON and turn it into the newline text streams that the commandline today is so good at manipulating.