4 ms·

One downvote and counting. This is just my opinion. Let's crank this up a notch. Those advocating for more advanced interfaces are missing the point. Text is al

One downvote and counting. This is just my opinion. Let's crank this up a notch. Those advocating for more advanced interfaces are missing the point. Text is all you need, no graphics or objects or widgets, just text. I have no problem with this, I enjoy it like this, we don't need an improvement. There I said it, any downvotes will be worth it, because I get to voice my opinion. In the end I will still be happily using my POSIX shell scripts, awk, sed and enjoy my life.

Siyo 7y ago
"Goto is all you need, no ifs or loops or dynamic dispatch, just jumps. I have no problem with this, I enjoy it like this, we don't need an improvement. There I said it, any downvotes will be worth it, because I get to voice my opinion. In the end I will still be happily using my assembler and enjoy my life." I'm sorry, I couldn't help myself. Your comment reminds me of an anecdote I heard from the early times of structured programming. When structured programming was just gaining its feet, there was a certain class of programmers who just could not understand why people would want to write structured code. You can do everything in assembly they said, you have much more control over performance, etc. They looked down on structured programming as not "real programming". There's a lot of benefits to adding some structure to text. I don't think that Nushell's approach is the best one, but to say that there are no problems and we shouldn't look to improve things is just backwards. We should always look to improve our tools and our craft, otherwise we would still be stuck writing assembly.
- roryrjb 7y ago
  I get it, but to clarify, and maybe it's to do with the work I do, I have no problem with current shells, I think they are great. As I learn more about them and use different features I like them more. This is my experience.
  - erezsh 7y ago
    Maybe you're just not very imaginative. I can see my workflow improve considerably by using a structured-io shell, and I'm already quite proficient in bash. So, I'm very happy some people are trying to make it happen. Also, I'm not sure what your argument is, except "I don't get it"? It's fine, lots of people don't get stuff. Just move on, and maybe in a few years when it's mature, you'll see it again and go "Ah!"
- roryrjb 7y ago
  Also goto being considered bad is already a very old idea. Yet it is still used, sparingly in the right places. Shell underpins a lot of stuff, it is tried and tested. Text is already structured, or can be, IFS, new lines, etc.
- chongli 7y ago
  There's a lot of benefits to adding some structure to text. There are benefits, true, but there are also potentially serious drawbacks. Chief among them, I would hazard, is the risk that we get locked into a format that didn't anticipate a (completely unknown) future need and we have to go back and rewrite everything again. The beauty of text's lack of structure is that people are free to interpret it any way they please.
  - ziftface 7y ago
    I keep seeing comments like this one, but just as you can parse textual data into something more structured, like the examples in the post, you can also print the structured data as text. So the tools that use and generate structured data are no less compatible because it's easy to go back and forth between the formats at will. You're not losing anything with this approach.
    - sverige 7y ago
      > You're not losing anything with this approach. True, but you are adding something. And if you add things you don't really need, it becomes plain old cruft. Like the others above, I understand the urge to make some things simpler by adding complexity, but for the long haul I'm convinced it's better to keep tools simple and add any needed complexity to the code you're writing (whether it's shell scripts or anything else). And then document the complexity so future you or some poor stranger can understand why the hell you did that in the first place. But I don't look forward to reading comments like "X was deprecated so we're converting these tables back to text streams so they can be converted back to Y properly."
  - amaccuish 7y ago
    But isn't that precisely the problem? A lot of people are unsatisfied with the current solution which doesn't lend itself to a particular goal? Aren't we now locked into a format (plain text) which is now becoming more and more of a pain (what type is this? is this text related to this other text?) and we're now having to go back to old utilities and add --json?
CJefferson 7y ago
I find it basically impossible to compose programs where I have things like a list of filenames with spaces. It turns out some programs support some kind of option to separate with nulls, but they are inconsistent and not everything supports it. So I end up having to put everything in one giant call to 'find', which defeats the compositionality of shells.
- cben 7y ago
  Null-terminated mode: turns out tons of tools have these: https://github.com/fish-shell/fish-shell/issues/3164#issuecomment-354600352 https://github.com/fish-shell/fish-shell/issues/3164#issueco... But yeah, 2nd "standard" hurts compositionality. Default posix/bash splitting of output by spaces is very big-prone and having to type "$array[@]" all over the place is annoying. But splitting by lines is much saner. Now newlines in file names, that's just evil and should be outlawed at OS level. I think OSX did this (?) In bash life can be easier by setting IFS (Google "bash strict mode" though I have reservations about the IFS part). But really, its easy to fix in a non-posix shell. Fish splits by lines and interpolates variables as arrays by default.
stinos 7y ago
Text is all you need In essence, yes. Yes you can get pretty far with sed and the likes. But it's not because it's all we really need, that other things (objects in this case) don't offer an improvement and make things better/easier/more convenient. Just like we theoretically could get along fine with just the CLI, doesn't mean that it is the single best thing in the world for all possible occasions.
- roryrjb 7y ago
  True, but also when using shell for scripting, when you want to use an associative array or some other "advanced" feature, from a shell point of view, well then you should move on to a different language. So in the same sense in such cases you should move on to a different language rather than trying to get the shell to do all things for all people. I am a very strong proponent of shells and shell scripting but realistically it's only designed to do certain things, those things it's perfect for, for some things it's bad for, use something else.
kryptiskt 7y ago
"Text" is a useless specification when building a program that produces data that other programs consume, or consumes data that other programs produce. There is nothing actionable in knowing that you have text to work on other that you can presumably discount the appearance of nulls in it.
sixothree 7y ago
Text is awful and annoying to deal with.

Siyo 7y ago

"Goto is all you need, no ifs or loops or dynamic dispatch, just jumps. I have no problem with this, I enjoy it like this, we don't need an improvement. There I said it, any downvotes will be worth it, because I get to voice my opinion. In the end I will still be happily using my assembler and enjoy my life." I'm sorry, I couldn't help myself. Your comment reminds me of an anecdote I heard from the early times of structured programming. When structured programming was just gaining its feet, there was a certain class of programmers who just could not understand why people would want to write structured code. You can do everything in assembly they said, you have much more control over performance, etc. They looked down on structured programming as not "real programming". There's a lot of benefits to adding some structure to text. I don't think that Nushell's approach is the best one, but to say that there are no problems and we shouldn't look to improve things is just backwards. We should always look to improve our tools and our craft, otherwise we would still be stuck writing assembly.

roryrjb 7y ago
I get it, but to clarify, and maybe it's to do with the work I do, I have no problem with current shells, I think they are great. As I learn more about them and use different features I like them more. This is my experience.
- erezsh 7y ago
  Maybe you're just not very imaginative. I can see my workflow improve considerably by using a structured-io shell, and I'm already quite proficient in bash. So, I'm very happy some people are trying to make it happen. Also, I'm not sure what your argument is, except "I don't get it"? It's fine, lots of people don't get stuff. Just move on, and maybe in a few years when it's mature, you'll see it again and go "Ah!"
roryrjb 7y ago
Also goto being considered bad is already a very old idea. Yet it is still used, sparingly in the right places. Shell underpins a lot of stuff, it is tried and tested. Text is already structured, or can be, IFS, new lines, etc.
chongli 7y ago
There's a lot of benefits to adding some structure to text. There are benefits, true, but there are also potentially serious drawbacks. Chief among them, I would hazard, is the risk that we get locked into a format that didn't anticipate a (completely unknown) future need and we have to go back and rewrite everything again. The beauty of text's lack of structure is that people are free to interpret it any way they please.
- ziftface 7y ago
  I keep seeing comments like this one, but just as you can parse textual data into something more structured, like the examples in the post, you can also print the structured data as text. So the tools that use and generate structured data are no less compatible because it's easy to go back and forth between the formats at will. You're not losing anything with this approach.
  - sverige 7y ago
    > You're not losing anything with this approach. True, but you are adding something. And if you add things you don't really need, it becomes plain old cruft. Like the others above, I understand the urge to make some things simpler by adding complexity, but for the long haul I'm convinced it's better to keep tools simple and add any needed complexity to the code you're writing (whether it's shell scripts or anything else). And then document the complexity so future you or some poor stranger can understand why the hell you did that in the first place. But I don't look forward to reading comments like "X was deprecated so we're converting these tables back to text streams so they can be converted back to Y properly."
- amaccuish 7y ago
  But isn't that precisely the problem? A lot of people are unsatisfied with the current solution which doesn't lend itself to a particular goal? Aren't we now locked into a format (plain text) which is now becoming more and more of a pain (what type is this? is this text related to this other text?) and we're now having to go back to old utilities and add --json?

CJefferson 7y ago

I find it basically impossible to compose programs where I have things like a list of filenames with spaces. It turns out some programs support some kind of option to separate with nulls, but they are inconsistent and not everything supports it. So I end up having to put everything in one giant call to 'find', which defeats the compositionality of shells.

cben 7y ago
Null-terminated mode: turns out tons of tools have these: https://github.com/fish-shell/fish-shell/issues/3164#issuecomment-354600352 https://github.com/fish-shell/fish-shell/issues/3164#issueco... But yeah, 2nd "standard" hurts compositionality. Default posix/bash splitting of output by spaces is very big-prone and having to type "$array[@]" all over the place is annoying. But splitting by lines is much saner. Now newlines in file names, that's just evil and should be outlawed at OS level. I think OSX did this (?) In bash life can be easier by setting IFS (Google "bash strict mode" though I have reservations about the IFS part). But really, its easy to fix in a non-posix shell. Fish splits by lines and interpolates variables as arrays by default.

stinos 7y ago

Text is all you need In essence, yes. Yes you can get pretty far with sed and the likes. But it's not because it's all we really need, that other things (objects in this case) don't offer an improvement and make things better/easier/more convenient. Just like we theoretically could get along fine with just the CLI, doesn't mean that it is the single best thing in the world for all possible occasions.

roryrjb 7y ago
True, but also when using shell for scripting, when you want to use an associative array or some other "advanced" feature, from a shell point of view, well then you should move on to a different language. So in the same sense in such cases you should move on to a different language rather than trying to get the shell to do all things for all people. I am a very strong proponent of shells and shell scripting but realistically it's only designed to do certain things, those things it's perfect for, for some things it's bad for, use something else.

kryptiskt 7y ago

"Text" is a useless specification when building a program that produces data that other programs consume, or consumes data that other programs produce. There is nothing actionable in knowing that you have text to work on other that you can presumably discount the appearance of nulls in it.

sixothree 7y ago

Text is awful and annoying to deal with.