Hacker News Reader

This sound about as useful as a man page. For me it often goes like this:

"What's the command that shows me file system usage again?"

> man -k file system usage

result = 5 pages of matching commands, often poorly formatted, word wrapping oddly, sometimes without even carriage returns between the commands, so it's all one long list. And this is in Unix which has had something like 45 years to clean up this mess.

I don't hold out hope that this sort of interface will ever be presented usefully, and we already have a better system in a GUI.

As opposed to the discoverability within the Mac interface for showing disk usage? I can't tell you how long it took me to find it.

And heaven help you if you want to find out where all of that data is on the hard drive.

Oh, by the way, it's at:

Apple menu -> About This Mac -> Storage

And don't alt-tab away from it; you can't get back to it using the keyboard. You have to use Mission Control or back through the Apple menu again.

A simpler alternative that has existed for decades in Mac OS is right-click disk -> Get Info, which is analogue to right-click disk -> Properties on Windows. That’ll give you usage/free space remaining and is probably as discoverable as it gets short of creating an entirely separate app explicitly named “Disk Usage” or some such.

Simply getting to a finder window where I can do a "Get Info" on a hard drive requires finding your way to the "Computer" finder window, which requires digging in menus or right click context pulldowns on window titles (?).

While it works on folders, it just gives you a question mark for the size while it is working out the size of the sub-items on disk with no indication that it's actually going to change that.

So yes, there are alternative methods, but they are no more friendly to discoverability as the Apple Menu method.

'As opposed to the discoverability within the Mac interface for showing disk usage?'

The answer lies in your question. A lot of power user (yes, relative but Apple have focused on consumer) functionality is buried in the gui, and every release pushes stuff deeper in to the interface.

A nice example for discoverability in conjunction with text commands is JIRA's search capability with JQL.

It allows you to type queries, and each point offers dropdowns that list valid attributes, operators, values (in case of limited choice of values). I like it.

This is brilliant. Do you have suggestions for where I can go to read more about this idea?

This question seems to point in this direction of changing our shell syntax from `vo` to `ov`, based on Jef Raskin's Humane Interface http://ux.stackexchange.com/questions/48051/how-to-extend-th... .. I imagine pluggable shell grammars would allow open ended exploration this way.

I see this strongly related to many combinators in FP too.

(system command arguments)

flip -> (system arguments command) curry -> (system arguments) command

# and for the humane touch:

thread (system (completing-read)) (completing-read)

etc etc

Oh, and BTW, GUIs didn't buy ergonomy, sometimes you need to open an application then the data (aka /tweet "bla"), early systems had a simple 1:1 map 'type' 'program' with an 'open-with' intermediate. Then they added 1:N ... One day it will be a tiny Hindley-Milner unifier ;)

The gui equivalent would be right-clicking on a thing. There's probably a lot on what you should put in that menu, and you could probably take some general principles from that.

It sounds to me (apart from the auto-suggest) that this is exactly like piping on the command line.

    echo "My random thoughts" | tweet

Naked Objects is an example of a UI driven by the underlying objects rather than by the use cases thought up by a programmer.

https://en.wikipedia.org/wiki/Naked_objects

Interesting. I'd not realised this before but in terms of human language classic CLI is of the form: Verb Subject

Whereas English (and other European languages that I know some grammar for) are of the form: Subject Verb

I.e. you're advocating that CLI interfaces should be more like English...

Except the text to tweet is not the subject, but rather the object. And English is VO, just like the command line. The suggestion is that we use Japanese's OV order.

Yep I'm wrong sorry.

And then you have German, where VSO/VOS is a question, and SVO/SOV/OSV/OVS are normal sentences.

I don't understand what makes this more useful as a text-based thing, rather than, say, something like the OS X right-click Actions/Share menus, especially when when the latter can work on fragmentary parts of other documents without needing to juggle interfaces.

One of the problems with this that probably occurs to everyone is that there are many more actions you can do with a file than there are files in a typical directory. So you might say > how file, and it might return 1000 things you can do with it.

To answer my own objection, > how (or whatever the tool is called), or just the object itself as in the author's example, could display categorized actions, or offer a way to navigate submenus, or it could limit initial output to things that a non-superuser would want to do and offer additional options for superusers to browse more advanced options (or assume they know what other tools exist and use them directly).

Glad to see this suggested. This is very similar to why OO programming was such a more humane system.

A problem with most OO programming languages is that methods are declared as part of the class itself. This makes it difficult to extend an existing class you don't control, or reuse a method elsewhere.

C# supports extension methods, which are basically static helper methods whose first parameter is the type to which you want to attach the method. For example, I could create a 'ToTitleCase' extension method on type 'string'. Then, given a string instance, I can simply do 'myString.ToTitleCase()'.

One step further would be to add support for multiple parameters. For example, instead of listing all functions that accept an 'int' as an argument, you could ask for all functions that accept both an 'int' and a 'string' as an argument. Given 3 and "test", the 'repeat' function could be suggested, resulting in "testtesttest".

To make things even better, one could provide (explicitly or not) the return type of the function they're looking for. For example, if you're assigning to a variable of type 'int', and all you have is a 'string', then you probably want to see a list of all functions that take a 'string' as an argument, and return an 'int'. In that case, you would see functions like "parseInt" or "getLength". It's kind of like playing domino, where you already know the type of the input and output, and only need to connect them together. Keep in mind that you can't always transform one type to the other in a single function call, which means the system would also need to recommend combinations of functions, such as "parseDateTime + getDayOfWeek" when you need to transform a 'string' to an 'int'. Perhaps the name of the arguments could even be used as some kind of sorting heuristics (a 'string' variable named "date" surely should be parsed to some kind of DateTime at some point).

Over in Haskell-land, hoogle will perform fuzzy searches on type signatures. Having something like that at hand in the shell could certainly be neat.

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.

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.

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.)

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.

> 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?

"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.

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?

"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.

> 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.

Not sure what you're comparing OO to , but it certainly makes l little sense if you're comparing with FP. Grouping by function is so much more natural than artificially attaching the same function into different objects. When I copy, do I care whether I'm copying a document or a program? All I care about is the functionality, which is copying. This applies to many cases. OO design forcefully fractures every function into different objects, which makes extension a nightmare.

It would be an interesting exercise to take a corpus of user CLI commands, and try to use the types and formats of the arguments to predict the command.

Assuming a CLI is on parity w/r/t usability as a GUI, which takes a shorter amount of time and less effort to construct? GUI certainly.

I don't think I would entirely agree with that. Surely it depends on the developer. I can build a traditional CLI program faster than I can arrange a GUI for an equivalent program in something like interface builder although I've met developers who are faster the other way around.

Yeah a basic CLI is super easy. I mean at the sophistication required to be as usable as the parent post implies may be more difficult.

Do people build those GUIs without toolkits or GUI builders though? An advanced shell concept would presumably come with tooling too...