4 ms·

This is an interesting point, but I raise you search and types. One of the points where "the Unix philosophy" (as usually espoused at least) is sorely lacking i

This is an interesting point, but I raise you search and types. One of the points where "the Unix philosophy" (as usually espoused at least) is sorely lacking is that all programs interact with what is popularly called "text" (or a "single type"/"unitype"). For practical reasons it isn't always text, but more importantly (the first bit is a subset of this problem): almost every program has to understand (100%) the output of every other program it has to interact with. If output were typed our applications could ignore (reliably) the bits they don't care about. If output were typed we could search by output-type (e.g. diff produces patch-like-output, so don't bother piping to "xargs", but allow "less" (any type of input) or "git apply" (patch-like-input) or "patch" (patch-like-input). Types could add a huge amount of searchability to CLIs -- and for some reason this isn't appreciated even though we've seen it in a much more limited context such as OOP. (I think my original inspiration for this line of thinking is Paul Chiusano, and he probably deserves most of the credit, honestly.) EDIT: Actually, pondering this a little more: All programs should be forced somehow(!) to carry a "source location" for the source of their output. This is such an annoyance in the daily life of a programmer if you perform a chain of commands like "git diff ... | grep FIXME | grep ^+ | ..." just to get a grip on the FIXMEs you've introduced. The output doesn't show line numbers, because... well, for no really good reason, really. It's just that transformation as text meant that we sort of lost that bit.

nitrogen 11y ago
Two options for showing line numbers: (1) pipe the first command through nl; (2) use a single grep with the line numbering option (it's at least in GNU grep): grep -n '^+.*FIXME' You can also pipe git diff into less or "vim -" to use slash search. Note: on a phone so -n may not be correct.
- lomnakkus 11y ago
  Thanks for the tip (and I think I might actually have it written down in a file somewhere), but this is missing the point. I shouldn't have to do this -- it should be automatic. Why? Because it's required for so many different tasks. For example: Source maps in the web world. EDIT: ... and it's actually possibly(!) even worse in the web world where you often have a ridiculous number of levels to your "transformation". Personally, I have never got "bower (source) -> grunt -> ts/(scala.js+closure) -> babel -> es5" (with source maps) to ever work even semi-reliably. (I know we have too many things in this pipeline, but it's what we have to deal with.)
  - nitrogen 11y ago
    I was actually waiting for your reply saying that I had missed the point :-). I think that automatic line numbering (as an example) misses the point of the UNIX tool philosophy, namely composability. It would seem that the designers of grep and nl thought those were separate tasks. The point of the CLI is that you can make the simple building blocks do whatever you want, for any workflow. You can always make an alias for grep that does numbering by default. Basically, however widespread our personal workflows are, there are vastly more workflows we havent't even thought of that are essential to someone else's livelihood, for whom automatic numbering (or whatever) would ruin everything. As for source maps, yeah, that's got room for improvement.
    - lomnakkus 11y ago
      > I was actually waiting for your reply saying that I had missed the point :-). Hah! EDIT: I had a really complicated thing here, but decided to delete it... because I don't think anyone understands any of this "computers" thing properly, including me. Hope you understand :). EDIT#2: Is there a "flowers for you" emoticon?
dllthomas 11y ago
"almost every program has to understand (100%) the output of every other program it has to interact with." While I mostly agree with your thesis that types could be great in the shell, I think this particular bit is incorrect in a way that undermines your argument (not, I think, fatally). If a program's output doesn't match up with another program's input, a bit of sed (and maybe some awk) will usually do the trick. And if we added types, that would still be the case - output from one command would have to be the right type to be input to another.
- lomnakkus 11y ago
  You're right... in that we can fudge around these things with "fuzziness", but I don't think that's sufficient. Btw, I didn't mean that types should be the arbiter of "a | b", just that it should guide the search process. Obviously, you should always be allowed to really choose "c" even if the system determined "b". But our UI could be so much efficient if the system chose "b" most of the time. EDIT: Classic case, btw: "find ... -print0 | xargs -0 ...". Unless we have pervasive and dependent types, how is any formalism going to know that?
  - dllthomas 11y ago
    "You're right... in that we can fudge around these things with "fuzziness", but I don't think that's sufficient." Well, it's been sufficient. That doesn't mean we can't improve on it. My point was simply that assigning types doesn't actually change things - it is still the case that every program needs to be able to interpret whatever is generated by every program you want to pipe into it, or you need some kind of translation. 'Classic case, btw: "find ... -print0 | xargs -0 ...". Unless we have pervasive and dependent types, how is any formalism going to know that?' Dependent types aren't necessary for that. They might be necessary for `find ... $MIGHTBEPRINT0 | xargs $MIGHTBEDASH0` Edited to add - or wait, you mean the resulting command built by xargs may have a type dependent on the arguments produced by find? That's... messy, yeah.
    - lomnakkus 11y ago
      > Or wait, you mean the resulting command built by xargs may have a type dependent on the arguments produced by find? That's... messy, yeah. Yes! Thinking about interactive CLIs... yes. EDIT: I should add: My main point here is that types would constrict the search space to be reasonable, rather than seeing that "1200 commands are available, do you want to show them all?" prompt. I really think we could be doing much better in this space.

nitrogen 11y ago

Two options for showing line numbers: (1) pipe the first command through nl; (2) use a single grep with the line numbering option (it's at least in GNU grep): grep -n '^+.*FIXME' You can also pipe git diff into less or "vim -" to use slash search. Note: on a phone so -n may not be correct.

lomnakkus 11y ago
Thanks for the tip (and I think I might actually have it written down in a file somewhere), but this is missing the point. I shouldn't have to do this -- it should be automatic. Why? Because it's required for so many different tasks. For example: Source maps in the web world. EDIT: ... and it's actually possibly(!) even worse in the web world where you often have a ridiculous number of levels to your "transformation". Personally, I have never got "bower (source) -> grunt -> ts/(scala.js+closure) -> babel -> es5" (with source maps) to ever work even semi-reliably. (I know we have too many things in this pipeline, but it's what we have to deal with.)
- nitrogen 11y ago
  I was actually waiting for your reply saying that I had missed the point :-). I think that automatic line numbering (as an example) misses the point of the UNIX tool philosophy, namely composability. It would seem that the designers of grep and nl thought those were separate tasks. The point of the CLI is that you can make the simple building blocks do whatever you want, for any workflow. You can always make an alias for grep that does numbering by default. Basically, however widespread our personal workflows are, there are vastly more workflows we havent't even thought of that are essential to someone else's livelihood, for whom automatic numbering (or whatever) would ruin everything. As for source maps, yeah, that's got room for improvement.
  - lomnakkus 11y ago
    > I was actually waiting for your reply saying that I had missed the point :-). Hah! EDIT: I had a really complicated thing here, but decided to delete it... because I don't think anyone understands any of this "computers" thing properly, including me. Hope you understand :). EDIT#2: Is there a "flowers for you" emoticon?

dllthomas 11y ago

"almost every program has to understand (100%) the output of every other program it has to interact with." While I mostly agree with your thesis that types could be great in the shell, I think this particular bit is incorrect in a way that undermines your argument (not, I think, fatally). If a program's output doesn't match up with another program's input, a bit of sed (and maybe some awk) will usually do the trick. And if we added types, that would still be the case - output from one command would have to be the right type to be input to another.

lomnakkus 11y ago
You're right... in that we can fudge around these things with "fuzziness", but I don't think that's sufficient. Btw, I didn't mean that types should be the arbiter of "a | b", just that it should guide the search process. Obviously, you should always be allowed to really choose "c" even if the system determined "b". But our UI could be so much efficient if the system chose "b" most of the time. EDIT: Classic case, btw: "find ... -print0 | xargs -0 ...". Unless we have pervasive and dependent types, how is any formalism going to know that?
- dllthomas 11y ago
  "You're right... in that we can fudge around these things with "fuzziness", but I don't think that's sufficient." Well, it's been sufficient. That doesn't mean we can't improve on it. My point was simply that assigning types doesn't actually change things - it is still the case that every program needs to be able to interpret whatever is generated by every program you want to pipe into it, or you need some kind of translation. 'Classic case, btw: "find ... -print0 | xargs -0 ...". Unless we have pervasive and dependent types, how is any formalism going to know that?' Dependent types aren't necessary for that. They might be necessary for `find ... $MIGHTBEPRINT0 | xargs $MIGHTBEDASH0` Edited to add - or wait, you mean the resulting command built by xargs may have a type dependent on the arguments produced by find? That's... messy, yeah.
  - lomnakkus 11y ago
    > Or wait, you mean the resulting command built by xargs may have a type dependent on the arguments produced by find? That's... messy, yeah. Yes! Thinking about interactive CLIs... yes. EDIT: I should add: My main point here is that types would constrict the search space to be reasonable, rather than seeing that "1200 commands are available, do you want to show them all?" prompt. I really think we could be doing much better in this space.