6 ms·

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 meani

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?

agumonkey 11y ago
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.
- agumonkey 11y ago
  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.
integraton 11y ago
> ...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.
- ColinDabritz 11y ago
  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?
- redwards510 11y ago
  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?
  - javert 11y ago
    > 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.
- UnoriginalGuy 11y ago
  > 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
wodenokoto 11y ago
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.
- wcummings 11y ago
  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.
- digi_owl 11y ago
  Given that "natural language" is a minefield of context sensitivity and overloaded meanings, i don't see it being any better.
dbpokorny 11y ago
> The inside jokes (less is more) and overloaded meanings of command names is still an issue today, for example What issue? Who is this an issue for? Against which project will this issue be opened? This either is or is not an issue. If it's an issue, then do something about it. If it isn't an issue, then don't say it is.
cm2187 11y ago
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.
- digi_owl 11y ago
  > 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.
  - cm2187 11y ago
    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
    - digi_owl 11y ago
      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.

agumonkey 11y ago

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.

agumonkey 11y ago
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.

integraton 11y ago

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

ColinDabritz 11y ago
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?
redwards510 11y ago
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?
- javert 11y ago
  > 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.
UnoriginalGuy 11y ago
> 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

wodenokoto 11y ago

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.

wcummings 11y ago
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.
digi_owl 11y ago
Given that "natural language" is a minefield of context sensitivity and overloaded meanings, i don't see it being any better.

dbpokorny 11y ago

> The inside jokes (less is more) and overloaded meanings of command names is still an issue today, for example What issue? Who is this an issue for? Against which project will this issue be opened? This either is or is not an issue. If it's an issue, then do something about it. If it isn't an issue, then don't say it is.

cm2187 11y ago

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.

digi_owl 11y ago
> 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.
- cm2187 11y ago
  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
  - digi_owl 11y ago
    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.