Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving the UX of (command-line) tools

blog.opalang.org

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Improving the UX of (command-line) tools

#11

Post by chimeracoder »

fcurella wrote: post #9
chimeracoder wrote: post #8

At the risk of sounding like a broken-record aging neckbeard (reality: I'm a college student with light stubble), I think the title of this thread is very misleading, even if the blog post itself contains valuable material. First, I'm just barely old enough to remember using DOS on a machine without Windows -- which I believe is the last time that a GUI/DE wasn't viewed as 'essentially essential' for an end-user comp…

I think there is much more that can be done to make tools more user-friendly. An example that pops to my mind is when you misspell a git command, and git suggest what you could've intended: $ git pill git: 'pill' is not a git command. See 'git --help'. Did you mean this? pull That's already one step towards a better UI, but it could go even one step further if I could answer the question, ie: I press 'y' and git will…

I'm not saying that the UI couldn't be improved - I'm just saying that what they're doing isn't really an improvement on the the command-line as a UI, as it's just a domain-specific application. (And, I implied this but didn't state it explicitly: domain-specific applications should aim to be as 'compatible' as possible from a UI standpoint with the generic tool - ie, Unix - deviating only when there's a specific need to, and defaulting to the generic toolset. I'd need to see more to judge if Opa fits this; it's just a general principle).

More importantly, though: what you're looking for can already be done! Just use zsh (or, even simpler: a bash correction tool).

Because Unix is so modular, you can make these kinds of UI changes without breaking or even changing the underlying toolset. That means that you and I can tailor the UI to our specific needs, and we don't even really have to touch the general purpose toolset. Other examples include using Vim keybindings for the shell instead of Emacs (try modifying keyboard shortcuts with most pre-compiled GUI applications!) or scripting and aliasing.

Thanks for mentioning that, actually, because it illustrates my point very well! The command-line UI's strength is that it's literally as modular and as minimal as possible (at least, as far as I can conceive of). That's what I personally love the most about it. It defines only the bare minimum of tools necessary to satisfy two conditions:

1. By default, [almost] everything works as expected, with no customization (but assuming knowledge of the system). 2. Those who want to customize will find that it provides all of the tools necessary to create the exact interface they want, without modifying the underlying toolset as well. (This customization can be done to an essentially arbitrary level -- the technical limitations are well beyond what a reasonable person would consider 'sane').

You may make the argument, then, that the command-line isn't even an interface at all! It's more like an abstract interface that lets you stitch the tools together to define the interface you want, all the while providing a 'default interface' - a sensible set of defaults for those who can't be bothered to customize.

(Edit: I understand that tools aren't perfect - the git-pull/git-push asymmetry is an example - but the inconsistencies are vastly outnumbered by the overarching uniformity. And again, with such a modular model, you can create the UI you want without waiting for Linus to change the behavior of git).

Re: Improving the UX of (command-line) tools

#12

Post by stcredzero »

jules wrote: post #5
stcredzero wrote: post #2

Opa has some brilliant design decisions. Also, with the advent of Source Maps in Chrome and Firefox, the time is right for an end-to-end integrated web development language. Though I do find it strange as a long time OO person that "tightly coupled" is used as a positive trait in the "Hello Opa" post. As I predicted years ago, Static and Dynamic typing are starting to lose their distinctions. I wonder if someone has…

Already exists, e.g. F# in Visual Studio. Note however that type inference and dynamic typing, although similar on the surface in that you don't have to write type annotations, are completely different things. The OO tenet says "Don't couple unrelated things". The converse of this is "Don't decouple related things", which is equally valid yet often ignored. Decoupling X and Y means that in the cases where you want to…

The OO tenet says "Don't couple unrelated things". The converse of this is "Don't decouple related things", which is equally valid yet often ignored.

Orthogonal areas of concern that are used together are just that: used together. They can be used together and packaged in a way that's super convenient. That still doesn't mean I want them tightly coupled.

NB: Works well together != tightly coupled.

An example of this is the Java file API. In an effort to decouple a reference to a file...we end up with FIVE classes

Yeah, I freakin hate that too. This Java JMI Api I used once, I had to instantiate seven entities from as many different classes just to get to send a message. But not all Java libraries are paragons of good object design. (You can leave off the Java, actually)

A better design is to "couple" these things together in a gimmeTheContentsAlready(filename).

Sorry, but you're mistaken here. Things are just as decoupled in the VisualWorks Smalltalk class library. There are equivalents to: (File, FileInputStream, DataInputStream, InputStreamReader, BufferedReader) and much more, but you can also still do:

    'file.dat' asFilename readStream
If you wanted to, you could just add a method to String named gimmeTheContentsAlready that would just return you the whole contents of the file with that pathname as a String. (I'd name it fileContents, though.) Either would take 3 short, easy to read lines of code, or one messy one, and about 2 minutes to write and save in your image.

Convenient methods and well designed APIs aren't the same as "tight coupling." If you think they are, then you need to read some better OO code.

EDIT: Another example -- at the same place there was a Sun message bus we used in the same product line, same functionality as JMI, just with better performance. Needed to instantiate 2 object to send a message with that.

Re: Improving the UX of (command-line) tools

#13

Post by jules »

stcredzero wrote: post #12
jules wrote: post #5

Earlier quoted context omitted.

Already exists, e.g. F# in Visual Studio. Note however that type inference and dynamic typing, although similar on the surface in that you don't have to write type annotations, are completely different things. The OO tenet says "Don't couple unrelated things". The converse of this is "Don't decouple related things", which is equally valid yet often ignored. Decoupling X and Y means that in the cases where you want to…

The OO tenet says "Don't couple unrelated things". The converse of this is "Don't decouple related things", which is equally valid yet often ignored. Orthogonal areas of concern that are used together are just that: used together . They can be used together and packaged in a way that's super convenient. That still doesn't mean I want them tightly coupled . NB: Works well together != tightly coupled. An example of thi…

It just depends on your definition of tightly coupled. By your definition Opa's implementation isn't tightly coupled either (the http server doesn't depend on the database, etc.). A better term is probably tightly integrated, and as far as I can see they also use this term on the rest of the website.

Re: Improving the UX of (command-line) tools

#14

Post by stcredzero »

jules wrote: post #13
stcredzero wrote: post #12

Earlier quoted context omitted.

The OO tenet says "Don't couple unrelated things". The converse of this is "Don't decouple related things", which is equally valid yet often ignored. Orthogonal areas of concern that are used together are just that: used together . They can be used together and packaged in a way that's super convenient. That still doesn't mean I want them tightly coupled . NB: Works well together != tightly coupled. An example of thi…

It just depends on your definition of tightly coupled. By your definition Opa's implementation isn't tightly coupled either (the http server doesn't depend on the database, etc.). A better term is probably tightly integrated, and as far as I can see they also use this term on the rest of the website.

It just depends on your definition of tightly coupled.

Back in my day, "tightly coupled" was somewhat like the opposite of "modular."

Re: Improving the UX of (command-line) tools

#15

Post by mabdt »

chimeracoder wrote: post #11
fcurella wrote: post #9

Earlier quoted context omitted.

I think there is much more that can be done to make tools more user-friendly. An example that pops to my mind is when you misspell a git command, and git suggest what you could've intended: $ git pill git: 'pill' is not a git command. See 'git --help'. Did you mean this? pull That's already one step towards a better UI, but it could go even one step further if I could answer the question, ie: I press 'y' and git will…

I'm not saying that the UI couldn't be improved - I'm just saying that what they're doing isn't really an improvement on the the command-line as a UI, as it's just a domain-specific application. (And, I implied this but didn't state it explicitly: domain-specific applications should aim to be as 'compatible' as possible from a UI standpoint with the generic tool - ie, Unix - deviating only when there's a specific nee…

Another example of catastrophic UX is certainly the unix command 'find', as in: find . -name "*.opa" -exec cat \{\} \; | wc -l

I wonder if any Unix beginner has ever managed to find the syntax for -exec without copy-pasting the examples :)

Re: Improving the UX of (command-line) tools

#16

Post by thwarted »

mabdt wrote: post #15
chimeracoder wrote: post #11

Earlier quoted context omitted.

I'm not saying that the UI couldn't be improved - I'm just saying that what they're doing isn't really an improvement on the the command-line as a UI, as it's just a domain-specific application. (And, I implied this but didn't state it explicitly: domain-specific applications should aim to be as 'compatible' as possible from a UI standpoint with the generic tool - ie, Unix - deviating only when there's a specific nee…

Another example of catastrophic UX is certainly the unix command 'find', as in: find . -name "*.opa" -exec cat \{\} \; | wc -l I wonder if any Unix beginner has ever managed to find the syntax for -exec without copy-pasting the examples :)

One aspect of having composable components is knowing how they get composed. The fact that {} and ; may need to be escaped is something having to do with the shell, not with find and it's -exec syntax.

In fact, this is one of those things that is obvious once you learn about shell and how commands lines get expanded and executed. The problem there is that most people don't learn about the shell until forced to by being bitten by something goofy and unintuitive like -exec arguments. The order in which people learn about these things, and it being difficult to discover (in that I can suggest a way to "verify" the command line before running it, but that doesn't help if you don't know how to interpret the results, which also requires experience dealing with the system as a whole) is what causes the catastrophic failure.

That these may need to be escaped is even documented in the find(1) documentation.

    -exec command ;
    Execute command; true if 0 status is returned.
    All following arguments to find are taken to be arguments to
    the command until an argument consisting of `;' is encountered.
    The string `{}' is replaced by the current file name being
    processed everywhere it occurs in the  arguments to the command,
    not just in arguments where it is alone, as in some versions of
    find.  Both of these constructions might need to be escaped
    (with a `\') or quoted to protect them from expansion by the
    shell.
Post reply on HN