3 ms·

Maybe it is time to rethink what a terminal is, and get rid of the restriction to be text-only? There is really no reason for that, other than Typewriter herita

by 9dev 3y ago

Maybe it is time to rethink what a terminal is, and get rid of the restriction to be text-only? There is really no reason for that, other than Typewriter heritage.

jampekka 3y ago
It's been that time for decades. And it has been retought many times but never seems to catch on. I think even unices have abandoned the UNIX philosophy and turned largely into "there's an app for that", so maybe there's not much interest for a better composable UI.
mbreese 3y ago
There are some terminals that can display inline images, but those features aren’t commonly used. Why? Text works. Text is the lowest common denominator for working with data. This is why terminals are still primarily text based. This is also why stdin/out/err are also commonly text based (when the user is expected to view it). Text is simple and easy to parse. Binary data exchange formats (or objects) come in and out of vogue, but text just keeps on working.
- 9dev 3y ago
  Is that so? Because the way I see it, there are a bazillion different tools, plus decades of accrued knowledge only related to massaging data into text and back to structures. How many human brain cycles are wasted to data conversion on the Terminal? Text is a lousy abstraction. It may have worked well 50 years ago when computing was limited to researchers on American universities, but the digital world back then has little in common with ours. Acting like extending the shell to anything beyond plain text would require switching to fancy new serialisation formats every other year is a red herring. The only thing it takes is admitting a shell isn’t used on typewriters but modern computers, where humans use high-resolution screens and programs can exchange structured data. Everything else follows, and is well suited for standardisation. But that will never happen as long as grumpy sysadmins insist that cobbling together grep and sed in some arcane incantation is the only thing we ever need.
  - jampekka 3y ago
    When the alternative is to fire up some mess of an IDE with some nightmearish COM/.NET/ProtoBuf/whathaveyou overengineering marvels, I take grep and sed every time. Simple text-based structured data format (something like YAML) with possibility to embed binary would be the way to go IMHO. And of course one should be able to show graphics in the terminal. But we're not gonna get it. Open source tol is being rapidly enshittified by corporate EEE with their badly overengineered enterprise crap. :(
    - 9dev 3y ago
      I don't know why you seem to think we can only have "super-lightweight 2kb C binary" or "giant over engineered Java-IDE" - there's lots of space in between. I don't think anybody would want to give up snappy terminals, but at the same time, why does this have to imply loosing out on half a century of user experience research??
      - jampekka 3y ago
        The original proposal in the thread was PowerShell+IDE. That's overengineering on top of overengineering on top of overengineering.
    - feldrim 3y ago
      Well, that looks like a straw man fallacy. Assuming the only alternative is a full-blown enterprise IDE for a Unix shell is at least a strawman.
      - jampekka 3y ago
        IDE on top of PowerShell was the proposal in this thread.
- jampekka 3y ago
  Text does work, but text data exchange formats come in and out of vogue just like binary. And when any structure is needed, we typically get some ad-hoc text format that doesn't interoperate. JSON has made things better here, but it's a bit of a verbose eyesore for humans. I think the lack a structured (text based) format is a definite shortcoming in UNIX. Whitespace delimited lists of strings do get you surprisingly far (although some things are a total mess, e.g. filenames with spaces). But a simple more structured format (e.g. stripped down YAML with maybe non-prefixed lines being a list/iterator of strings for backward compatibility) would make the shell a lot more powerful. You should be able to include binary in these, but make it render nicely in the terminal (e.g. like browser devtools do). This doesn't also exclude having binary. And binary data is piped though programs all the time, but it makes including other data painful. Also don't see any harm in being able to show images in the terminal when wanted.
  - mbreese 3y ago
    While I think that ASCII including a specific record delimiter character (0x1E) that isn’t used is a missed opportunity, I actually think the lack of a set interchange format is a benefit. No format will work for everyone and if there was one set format, we’d still have people complaining about how it doesn’t work for their usecase. We'd also have had to (finally) answer the question of how to send the schema with the data. JSON (and XML and YAML and…) are all methods to try and adapt a text based data interchange format. And they all work roughly the same. You ultimately need some kind of processing library to full read them. But working with the data in any sort of structured context requires specialized tools (ex: jq). Or you can still grep it, just like I do to manage my tab delimited data, and get part of the way. I think the chaos of having no standard is kinda the point. Text is the lowest format that is easy for people to work with. We can visually parse it pretty easily, so the tools that support text can be pretty universal. Grep, sed, and awk can do a lot. But to do anything more, you’re always going to need some kind of specialized parsing, even for tab delimited or CSV data. So, let the terminal work with generic text and be “good enough”. As an example: you mentioned JSON and YAML and suggested a slimmed down YAML might be more powerful. I deal with columnar data with tens to hundreds of columns and thousands of lines. This wouldn’t work with either JSON or YAML… it’s too verbose. Instead I use (compressed) tab delimited text files for their ease of parsing in many languages. But those won’t work for many other use cases. With data exchange, there is never going to be one right sized option for all needs. If you can accept that, then the “right” option is to choose none of them.
- pjmlp 3y ago
  Outside UNIX world they were relatively common in alternative realities.

by 9dev 3y ago

Maybe it is time to rethink what a terminal is, and get rid of the restriction to be text-only? There is really no reason for that, other than Typewriter heritage.

jampekka 3y ago

It's been that time for decades. And it has been retought many times but never seems to catch on. I think even unices have abandoned the UNIX philosophy and turned largely into "there's an app for that", so maybe there's not much interest for a better composable UI.

mbreese 3y ago

There are some terminals that can display inline images, but those features aren’t commonly used. Why? Text works. Text is the lowest common denominator for working with data. This is why terminals are still primarily text based. This is also why stdin/out/err are also commonly text based (when the user is expected to view it). Text is simple and easy to parse. Binary data exchange formats (or objects) come in and out of vogue, but text just keeps on working.

9dev 3y ago
Is that so? Because the way I see it, there are a bazillion different tools, plus decades of accrued knowledge only related to massaging data into text and back to structures. How many human brain cycles are wasted to data conversion on the Terminal? Text is a lousy abstraction. It may have worked well 50 years ago when computing was limited to researchers on American universities, but the digital world back then has little in common with ours. Acting like extending the shell to anything beyond plain text would require switching to fancy new serialisation formats every other year is a red herring. The only thing it takes is admitting a shell isn’t used on typewriters but modern computers, where humans use high-resolution screens and programs can exchange structured data. Everything else follows, and is well suited for standardisation. But that will never happen as long as grumpy sysadmins insist that cobbling together grep and sed in some arcane incantation is the only thing we ever need.
- jampekka 3y ago
  When the alternative is to fire up some mess of an IDE with some nightmearish COM/.NET/ProtoBuf/whathaveyou overengineering marvels, I take grep and sed every time. Simple text-based structured data format (something like YAML) with possibility to embed binary would be the way to go IMHO. And of course one should be able to show graphics in the terminal. But we're not gonna get it. Open source tol is being rapidly enshittified by corporate EEE with their badly overengineered enterprise crap. :(
  - 9dev 3y ago
    I don't know why you seem to think we can only have "super-lightweight 2kb C binary" or "giant over engineered Java-IDE" - there's lots of space in between. I don't think anybody would want to give up snappy terminals, but at the same time, why does this have to imply loosing out on half a century of user experience research??
    - jampekka 3y ago
      The original proposal in the thread was PowerShell+IDE. That's overengineering on top of overengineering on top of overengineering.
  - feldrim 3y ago
    Well, that looks like a straw man fallacy. Assuming the only alternative is a full-blown enterprise IDE for a Unix shell is at least a strawman.
    - jampekka 3y ago
      IDE on top of PowerShell was the proposal in this thread.
jampekka 3y ago
Text does work, but text data exchange formats come in and out of vogue just like binary. And when any structure is needed, we typically get some ad-hoc text format that doesn't interoperate. JSON has made things better here, but it's a bit of a verbose eyesore for humans. I think the lack a structured (text based) format is a definite shortcoming in UNIX. Whitespace delimited lists of strings do get you surprisingly far (although some things are a total mess, e.g. filenames with spaces). But a simple more structured format (e.g. stripped down YAML with maybe non-prefixed lines being a list/iterator of strings for backward compatibility) would make the shell a lot more powerful. You should be able to include binary in these, but make it render nicely in the terminal (e.g. like browser devtools do). This doesn't also exclude having binary. And binary data is piped though programs all the time, but it makes including other data painful. Also don't see any harm in being able to show images in the terminal when wanted.
- mbreese 3y ago
  While I think that ASCII including a specific record delimiter character (0x1E) that isn’t used is a missed opportunity, I actually think the lack of a set interchange format is a benefit. No format will work for everyone and if there was one set format, we’d still have people complaining about how it doesn’t work for their usecase. We'd also have had to (finally) answer the question of how to send the schema with the data. JSON (and XML and YAML and…) are all methods to try and adapt a text based data interchange format. And they all work roughly the same. You ultimately need some kind of processing library to full read them. But working with the data in any sort of structured context requires specialized tools (ex: jq). Or you can still grep it, just like I do to manage my tab delimited data, and get part of the way. I think the chaos of having no standard is kinda the point. Text is the lowest format that is easy for people to work with. We can visually parse it pretty easily, so the tools that support text can be pretty universal. Grep, sed, and awk can do a lot. But to do anything more, you’re always going to need some kind of specialized parsing, even for tab delimited or CSV data. So, let the terminal work with generic text and be “good enough”. As an example: you mentioned JSON and YAML and suggested a slimmed down YAML might be more powerful. I deal with columnar data with tens to hundreds of columns and thousands of lines. This wouldn’t work with either JSON or YAML… it’s too verbose. Instead I use (compressed) tab delimited text files for their ease of parsing in many languages. But those won’t work for many other use cases. With data exchange, there is never going to be one right sized option for all needs. If you can accept that, then the “right” option is to choose none of them.
pjmlp 3y ago
Outside UNIX world they were relatively common in alternative realities.