Comment by ColinDabritz | Hacker News Reader

Comment by ColinDabritz | Hacker News Reader

Parent Full thread

This is a specific critique about the usability of the Unix shell, and I think most of this is still valid. The inside jokes (less is more) and overloaded meanings of command names is still an issue today, for example. Some of the visibility has improved by various means, but overall there is still a fair amount of 'black box' that takes arcane knowledge to peek in to.

Naming is one area I appreciated Microsoft's approach in Powershell. They have command names with a Verb-Noun structure, and full clear words, sometimes quite long. Then, after establishing clear canonical forms for the commands, they add a few well chosen aliases for short invocation and memorization.

Of all the critiques though, the Cognitive Engineering objection, that the system is not well designed to be used by human capacities, is still true across many platforms, especially in esoteric areas like the command line.

Also interestingly, I am guessing that this is the same Donald A. Norman of 'The Design Of Everyday Things'. It's fascinating to see these ideas in flight in 1981.

How do we address these things? How does one "redesign Unix" today?

> ...Powershell. They have command names...

Except that PowerShell commands, 'cmdlets', are really just .NET classes that run within PowerShell, like Ruby and Python classes, none of which are the same as working with GNU or BSD utilities and other executables in POSIX shells. That PowerShell's interface obfuscates its true nature is a huge violation of honest design, a massive violation of what's described in "Design of Everyday Things," leads to false comparisons, and misleads people into thinking it is providing the same functionality as working with executables in POSIX shells when it's actually providing chaining functionality like that in other scripting languages.

Isn't the purpose of a shell to obfuscate the gritty details of what happens behind the scenes? In Linux, when I execute a binary or a shell script, there is no obvious difference to me. Can you explain why it matters or would be considered bad design?

> obfuscate

I'm certain the user meant "obfuscate" in the sense given in the dictionary.

You are using it here in a different sense, like "provide a layer of abstraction so that un-needed details do not have to be considered."

It's good to tuck away un-needed complexity behind abstractions. But those abstractions should not obfuscate.

Interesting. You can, of course, work with actual executables in that environment too. Can you highlight some of the areas where it causes different behaviors or other design issues?

"That PowerShell's interface obfuscates its true nature"

It's different from Unix shells, but obfuscates? If so, so do bash, etc, with their built-ins. 'echo' doesn't start a process, either.

Also, it would be stupid if PowerShell didn't take advantages of the memory safety guarantees that the .Net Platform gives it.

> Except that PowerShell commands, 'cmdlets', are really just .NET classes that run within PowerShell, like Ruby and Python classes, none of which are the same as working with GNU or BSD utilities and other executables in POSIX shells.

That's categorically incorrect and shows a lack of knowledge of both Powershell and .Net classes. But instead of me showing you that you're wrong, let me teach you how to prove to yourself that you're wrong.

Open up Powershell, type in

     ( get-command get-date ).dll

This will find the dll on your system for the get-date cmdlet, but any will do ( C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.PowerShell.Commands.Utility on my box). Now spin up ILSpy or any .Net decompiler.

Let's look at the GetDateCommand class. That's a 400 line class, which according to you, shouldn't exist (as cmdlets are "really just .Net classes"). In fact this entire DLL shouldn't exist.

But GetDateCommand is one of PS's simplest commands since it wraps DateTime (in CorLib), so "wait! See!" you say. But what you need to understand is that Powershell is built on top of .Net, .Net is effectively Powershell cmdlet's "kernel" so just like UNIX commands communicate with the actual kernel, cmdlets are going to leverage functionality in their "kernel" (.Net whenever possible).

My point is, that no, Powershell cmdlets are NOT just .Net classes. However you CAN use .Net classes directly in Powershell. For example:

     [System.DateTime]::Now

> cmdlets are NOT just .Net classes

Yes they are.

The fact that you (and others I've seen here and elsewhere) continue to believe otherwise further demonstrates how deceptive PowerShell's design is.

What's interesting is that the cmdlet documentation is very clear:

"Cmdlets differ from commands in other command-shell environments in the following ways:

"Cmdlets are instances of .NET Framework classes; they are not stand-alone executables....

"Cmdlets do not generally do their own parsing, error presentation, or output formatting. Parsing, error presentation, and output formatting are handled by the Windows PowerShell runtime."

https://msdn.microsoft.com/en-us/library/ms714395%28v=vs.85%...

> Yes they are.

I literally just spoon fed you exactly how to go look for yourself about how cmdlets work and how they're distinct from the .Net classes they represent. I honestly don't know what more I can do.

> The fact that you (and others I've seen here and elsewhere) continue to believe otherwise further demonstrates how deceptive PowerShell's design is.

You realise I understand how Powershell works top to bottom, right? Where are they "deceiving me?" You can yourself can go learn about Powershell's artitecture (you have the tools, I've given them to you, and you clearly have access to the documentation).

> What's interesting is that the cmdlet documentation is very clear:

Wait is your biggest issue that cmdlets are held within DLLs of classes instead of standalone binaries? Because based on the snippets you posted I can only assume that is what your issue is.

Wait, but hold on, how many internal commands do most UNIX shells have? Dozens? Hundreds? Here's a list of them for bash: http://www.gnu.org/software/bash/manual/html_node/Bash-Built...

So why one rule for UNIX and another for Powershell? Why does it matter that you can store multiple commands (cmdlets) inside of a single DLL?

I'm only passingly familiar with PowerShell but really, it's Microsoft, in the bloody documentation, that literally states precisely that cmdlets are instances of .NET Framework classes:

"Cmdlets differ from commands in other command-shell environments in the following ways:

Cmdlets are instances of .NET Framework classes; they are not stand-alone executables.

https://msdn.microsoft.com/en-us/library/ms714395%28v=vs.85%...

We can have an ontological debate about how an instance of an-object-as-a-concept is different from an instance of an-object-as-memory-content but I think that's best left to amateur philosophers.

You're right with the caveat that they can also be powershell scripts.

Anyone arguing that PS isn't really just 'scriptable .Net' is unfamiliar with the more advanced ideas of PS.

PS is different things to different people, but from a pure tech perspective the above is an apt description of PS.

edit:

I should also mention I find the idea of using PS as an example of an easy, intuitive shell to be laughable at best. Anyone who believes that has definitely tried to do much more than simply Get-Item, New-Item, type things. Once you start getting into more advanced things it becomes a hairy mess.

I had trouble parsing this - Could you explain, in a sentence or two, why cmdlets are more than .NET classes? What's the significance of the GetDateCommand class existing?

> What's the significance of the GetDateCommand class existing?

That it is additional code, above and beyond the core .Net classes.

>it's actually providing chaining functionality like that in other scripting languages

How do you feel bash et al are substantively different from "chaining functionality like that in other scripting languages"?

The only force greater than the frustration of a new comer in front of these cryptic commands is the frustration of an experienced user if you ever change even one character in any of these commands.

The other problem is discoverability. If it requires to check a documentation then it's probably badly designed in the first place. This is the power of GUI, a new user can visually observe the state of the system and see all the options available from there, and make progress quickly. I would expect any newly designed command interface to have an intellisense-like drop down for both commands available and arguments of these commands, with a short description and a link to the documentation if required.

Discoverability can be configured in zsh as part of completion system. I've found that this covers many of my needs:

    % grep -<TAB><TAB>

    --after-context        -A           # specify lines of trailing context
    --basic-regexp         -G           # use basic regular expression
    --before-context       -B           # specify lines of leading context
    --binary-files                      # specify type to assume for binary files
    --byte-offset          -b           # print the byte offset with output line
    --colour               --color      # distinguish matching string
    (...)

OK this looks awesome. Will try out zsh now!

> If it requires to check a documentation then it's probably badly designed in the first place.

This notion is perhaps what is wrong with computing today.

If you come at any interface "tabula rasa" the only way to figure it out short of documentation/instruction is trial and error. "Discoverability" is so a distraction at best, and even then heavily dependent on prior (cultural) experience.

The idea of a GUI and Intellisense is to have an embedded short documentation.

Next to each checkbox, a GUI should have a plain text, short description of what it does (and a couple of words is often enough). Each item in an intellisense drop down has a short description too. The idea is not to eliminate documentation but to display it in the current context so that:

1. users make the correct choice when they type (i.e. the description will prevent them from making a mistake they would have made otherwise)

2. users know what other choice is available

3. users do not need to look for some offline documentation that may or may not refer to the version of the program they use (or the distribution of linux they use!) or may apply in a different context

4. users do not need to memorize occasionally used commands

> embedded short documentation

That would be "--help", which GNU requires[1] in all[2] of their programs. Combined with the tab completion that others have mentioned and the full documentation in man(1)/info(1), it is easy to discover how to use most commands iff you are willing to actually read the documentation that is available.

[1] https://www.gnu.org/prep/standards/html_node/Command_002dLin...

[2] modulo a few that emulate very old behavior for comparability reasons

Sort of. It goes out the window once in an app. GUIs really are good for discoversbility.

"The only 'intuitive' interface is the nipple. After that it's all learned."

    s/intuitive/discoverable/

GOOD GUIs are nice for discoverability, and the same is true for CLIs. There are many GUIs that are absolutely horrid, which rely on non-obvious icons or assume certain usage styles and offer no assistance if you don't have the same background assumptions as the GUI's creator.

Having used many different types of programs over the last ~30 years, I have wasted far more time with bad GUIs than I have with bad CLIs. At least with the CLI I can grep the output or documentation for what I want. I cannot grep a menu or GUI form to find some option I've forgotten the name of.

What this comes down to is that it is fairly easy to make a good GUI for simple things, and good programmers can make a nice GUI for the moderate and complex tasks. This is where discoverability is primarily useful, as it assists the inexperienced user and the dilettante.

For those of us that want to use our computer in a far more serious way, what the UNIX style CLI (shell) provides us is an interface that is still very learnable (IFF you invest in the time it takes to read the documentation!), that enables crafting commands that are simply not practical in any GUI. If you don't believe this, tell me how I can, for example:

    - recursively walk an arbitrary directory tree of images at ($SRCDIR)
    - except for any dirfectgory that ends in '.backup'
    - finding any file that is NOT a PNG, 
    - convert that that file into a PNG
    - but saving the new files in new directory tree ($DSTDIR),
      creating any necessary parent directories

That would be a mess in any GUI. In bash + imagemagick, it would be:

    for i in "${SRCDIR}/**/!(*.backup)/!(*.png) ; do
        dst="${DSTDIR}${i#${SRCDIR}}"
        mkdir -p "$(dirname "${dst}")"
        convert "${i}" "${i%.*}.png"
    done

Yes, that's ugly, but at least it is possible.

It is my opinion that Visual Studio is Microsoft's best designed software and I am convinced that it is because it is the only software they produce where the developers do any serious dog fooding! All other softwares (Office and Windows mainly) seem to be developed for some hypothetical user which ain't me or anyone I have met.

Visual Studio introduced a few years ago a fully searchable GUI, which I think is a great idea. There is search box at the top and it will search through menus and options. Windows 8 started doing this too for some control panel functions but it is very incomplete.

And if you stick it in a .sh you have pretty much created a special purpose program.

I recently find it easier to bite the bullet and write the command on the spot, rather than to try to locate some custom made three liner somewhere. Just writing the logic from scratch becomes effortless with a bit of practice. It helps me focus on the task-at-hand, rather than digging into memory if I solved an issue before, and if I stored it somewhere convenient, with an apropriate name.

After having successfully located the snippet, only too often I have discovered that it does not do exactly what I want right now. Then I am left with the choice of changing the past script to also fit the new purpose, without destroying the previous work.

All this mental effort to save yourself three lines of typing seems a questionable endeavor. I have come to love the throwaway scripts.

They are still referring to documentation then, just now it is in-lined with the knobs they are operating. As such, still failing (in the absolutist sense) the idea of not having to check documentation.

And i see much the same working on CLI, via tab completion etc. Using the Linux ip command in the zsh shell can be interesting in that regard.

That is less direct though as I assume it is getting the information from the man page, which on Linux may not be maintained with the command (the BSDs are better here), rather than extracted from the source/api of the command itself.

While you're right it depends on prior cultural experience/knowledge of the domain, discoverability is very important.

That's the "big wall" that got people joking about how to quit vi. Even to get to help, typing :help needs some help to get you there.

The critique is not towards vi/emacs, they were like that because of technical limitations. But even then it can be improved

Do you need a manual to use an ATM? The GPS system that comes with your car? A new stereo?

Today, not being discoverable is a sure way your product won't be used, unless it's very useful in a very strict domain (like Apache, and even then)

First time i used an ATM, one of my parents were there with me. As such i got instructions in how to do it.

I don't have a car with a built in GPS.

Operating a stereo comes back to the whole experience thing, as most of the buttons are "old". Most of the button icons to operate a CD player are the same that was used for a casette player back in the day. And likely ones first encounter with either was back when one was a kid trying to get their parent to put on some music or other.

The closest i recall to reading about coming at computing "tabula rasa" was about a computer in a wall in India. And there the kids did what kids do, they poked and prodded and broke stuff to see how it worked.

This to the point that they developed their own cultural contexts for various icons (one was referred to via some deity name because it looked like a set of drums the deity was depicted using).

Having fuzzy search/completion is also a mandatory thing. The "no news is good news" is a very important negative factor for newcomers. Of course programmers and scientists have mileage to learn 'semantics' of operators by heart and learn to compose effects in their head so it's not as important to them.

Nowadays one could setup a zfs-on-linux so you can have free FS level undo.

pps: two things CLI have that may be worth the pain

  - sequences: globbing, for ... in
  - composition: pipes

Even using MSDOS I felt weirdly empowered when I saw this.

I believe the next major revision to command-line interfaces will be natural language input, preview, correct/verify. Maybe just input, action, then possibly undo/redo with modification.

No need for the user to remember if it was called make_dir or mkdir or whatever.

Given that "natural language" is a minefield of context sensitivity and overloaded meanings, i don't see it being any better.

Why would this be any more true of shells than it is of programming languages? The sort of things people do with the shell requires a certain specificity and simplicity (who wants to implement an NLP just to implement a compatible shell?)

Natural language input has displaced the graphical interface, somewhat. People use it every day on their phones.

Reply on news.ycombinator.com