5 ms·

Shells need to be good at composing programs together, languages compose libraries. Pipes and output redirection, running things in parallel and waiting till t

by t43562 4y ago

Shells need to be good at composing programs together, languages compose libraries. Pipes and output redirection, running things in parallel and waiting till they end - for some reasons these things suck in some languages compared to what the most basic shell can provide. Shells let you do unexpected, unintended integrations. I think languages could do better without breaking

dolmen 4y ago
Programs called from the shell for integration are not all consistent and that's another reason why shell programmins is not easy. Exit status are inconsistent. Stderr output: is it a warning (ignorable) or an error?
- t43562 4y ago
  Stderr output does not indicate that a program has failed. It's just a communication channel to the user that's not affected when you pipe or redirect stdout. So useful for programs where to want to make sure that data doesn't get mixed up with messages to the user. exit codes are the only true way to tell if some process failed and programs should set them properly.
eru 4y ago
Though to be honest, eg Bash isn't all that great at composing programs, too. Especially when you want to handle failure. Mostly shells are good at scaling downward, ie having relatively little syntactic (and brain) overhead for very simple things. Especially when you are ok to handle any failures manually.
throwawaaarrgh 4y ago
Yes! Shells excel at integrating loosely-coupled interfaces. Languages seem to suck at it.
- chasil 4y ago
  Specific shells. "Bash is like the neighbor who seems nice and sweet, but maybe they don’t have a life you’d want to have personally. They have some pretty serious character flaws and obviously make mistakes, but in the end they are a nice person who tries hard to make sure the people that depend on them are doing ok. "Batch [cmd.exe] is the guy who looks like that neighbor, but then turns out to be a serial killer." https://blog.nullspace.io/batch.html https://blog.nullspace.io/batch.html
H4ZB7 4y ago
...aaand if you actually think this through you will just come to the conclusion - piping isn't anything special, its just an operator - piping has like 10 different things you need to account for, just a bunch of stuff is chosen FOR you (heuristically) in the shell. for example IFS. whether its correct for a given pipeline is an entirely different question - any form of error handling in a pipeline is a syntactic disaster mostly because shell syntax completely sucks - every second program in the pipeline will literally just execute code from the input until you figure out the secret option to make it not do that anymore - data has a structure, whether you think it does or not. whenever you fail to account for all possible cases (doesn't help that these tools mostly don't have any specified format) of that (such as in most shell scripts), you are opening holes for bugs. both sides of the pipe must use the same data structure (and since its shell that means encoding it to text which changes depending on your locale and encoding). - for most cases you don't even need pipes: a = f() g(a) or just g(f()) piping is just premature optimization like lazy evaluation. composing functions is actually simpler, just shells have no (good) way to do it.
- t43562 4y ago
  What's important to me is that I can feed a huge amount of data generated by one process into another process without ever having to write it to disc. This is important in a practical rather than theoretical way. As for structured data......lines of ascii is more that useful enough a great deal of the time.

by t43562 4y ago

dolmen 4y ago

Programs called from the shell for integration are not all consistent and that's another reason why shell programmins is not easy. Exit status are inconsistent. Stderr output: is it a warning (ignorable) or an error?

t43562 4y ago
Stderr output does not indicate that a program has failed. It's just a communication channel to the user that's not affected when you pipe or redirect stdout. So useful for programs where to want to make sure that data doesn't get mixed up with messages to the user. exit codes are the only true way to tell if some process failed and programs should set them properly.

eru 4y ago

Though to be honest, eg Bash isn't all that great at composing programs, too. Especially when you want to handle failure. Mostly shells are good at scaling downward, ie having relatively little syntactic (and brain) overhead for very simple things. Especially when you are ok to handle any failures manually.

throwawaaarrgh 4y ago

Yes! Shells excel at integrating loosely-coupled interfaces. Languages seem to suck at it.

chasil 4y ago
Specific shells. "Bash is like the neighbor who seems nice and sweet, but maybe they don’t have a life you’d want to have personally. They have some pretty serious character flaws and obviously make mistakes, but in the end they are a nice person who tries hard to make sure the people that depend on them are doing ok. "Batch [cmd.exe] is the guy who looks like that neighbor, but then turns out to be a serial killer." https://blog.nullspace.io/batch.html https://blog.nullspace.io/batch.html

H4ZB7 4y ago

...aaand if you actually think this through you will just come to the conclusion - piping isn't anything special, its just an operator - piping has like 10 different things you need to account for, just a bunch of stuff is chosen FOR you (heuristically) in the shell. for example IFS. whether its correct for a given pipeline is an entirely different question - any form of error handling in a pipeline is a syntactic disaster mostly because shell syntax completely sucks - every second program in the pipeline will literally just execute code from the input until you figure out the secret option to make it not do that anymore - data has a structure, whether you think it does or not. whenever you fail to account for all possible cases (doesn't help that these tools mostly don't have any specified format) of that (such as in most shell scripts), you are opening holes for bugs. both sides of the pipe must use the same data structure (and since its shell that means encoding it to text which changes depending on your locale and encoding). - for most cases you don't even need pipes: a = f() g(a) or just g(f()) piping is just premature optimization like lazy evaluation. composing functions is actually simpler, just shells have no (good) way to do it.

t43562 4y ago
What's important to me is that I can feed a huge amount of data generated by one process into another process without ever having to write it to disc. This is important in a practical rather than theoretical way. As for structured data......lines of ascii is more that useful enough a great deal of the time.