In Defense of Verbosity

Today, Pubsub brought me Jeff’s post, “In Defense of Verbosity.”  In it, he talks about (and praises) the fine expressive balance that Monad allows you to walk between terseness, and verbosity.
In an interactive session (where you care only about the output,) terseness is your friend.  Take, for example, the following command that finds the 10 most referenced DLLs in running processes:

gps | select  id -exp modules | group filename | sort count -des | select -f 10

That’s easy to type, but a bear to understand.  If this command will die along with your history buffer, then you’ve done no harm – and saved yourself typing to boot.  If you plan to enshrine this in a script, though, you need to be considerate of the poor sap that will have to eventually maintain that script.  More often than not, that poor sap is you.

So, yes, Monad supports verbosity:

## Get all of the processes
$processes = get-process

## For all of the processes, expand out their Modules.
## This works like a SQL join.  If you have a process object with
## ID=1234, Modules={Filename=ntdll.dll, Filename=gdi32.dll}
## then we get pseudo objects like this:
## ID=1234,Filename=ntdll.dll
## ID=1234,Filename=gdi32.dll
$allModules = $processes | select-object Id -expand Modules

## Group the results by Filename (module file name, that is)
$filenames = $allModules | group-object Filename

## Then pick the top ten.
$topTen = $filenames | sort Count -descending:$true | select -first 10
write-object $topTen

A similar philosophy holds for all programming languages, and even more importantly so.  In programming, your code doesn’t vanish along with your history buffer.  It becomes a maintenance task as soon as you finish writing it.  How difficult a maintenance task?  Well, that’s up to you.

By the way, Jeff:

[terse shorthand is often more difficult to read than terse code.  This is an intentional trade-off, though, as the time spent to capture information is far more precious than the time spent to post-process it.]

[Edit: Monad has now been renamed to Windows PowerShell. This script or discussion may require slight adjustments before it applies directly to newer builds.]

4 Responses to “In Defense of Verbosity”

  1. ac writes:

    You can write



    I don’t see either making much sense..

    How about: -oa -od or -ascending / -descending

    where -o obviously "order"
    What’s with the $true? ascending:$false == descending:$true?

  2. Lee Holmes writes:

    The logic behind the -descending:$true flag is this:

    – When you specify no sort order, we sort the objects in ascending order.
    – We only want to support one flag for ascending / descending, so that makes the possible defaults -ascending:$true, or -descending:$false.
    – By default, missing boolean parameters have a value of ‘$false,’ since users like to enable options, rather than disable them.
    – This makes -descending:$false the default (and the way to sort in Ascending order,) and -descending:$true the way to sort in Descending order.

    Now, I think I might have confused you by "-des". Monad has very good disambiguation logic on parameters, so all of the following are equivalent:



    It can’t be any shorter, as it would then conflict with the three-letter stem for ‘-debug’

    Regarding your suggestion of "-od", the "order" portion of your abbreviation is implied by the "sort-obejct" cmdlet.

  3. ac writes:

    I wonder what is going to happen if I have that script used in a critical process and it has

    "topTen = $filenames | sort Count -des | select -first 10"

    Imagine the "sort" is a 3rd party command.

    Now some time in future the 3rd party deemed necessary to add a new feature along with security updates to the sort program. The new feature is "sort Count -destroycompatibility". What is my -des now going to be calling, -destroy… or -descending ?

    I can see it’s probably not all that likely but it could be disastrous if such new command was introduced.

    I would like to see a way to avoid writing those -sht for -shortcut in Monad, and have a shell integrated Intellisense instead for writing slightly more verbose scripts. Better readability and less memorizing of commands. People expect it now, atleast those who’ve ever used Visual Studio.

  4. Lee writes:

    Since removing parameters is considered a breaking change, it would be only proffesional of the authors of the third party cmdlet to do it with care.

    If they left the old one in, you’d get an error message that ‘desc’ is not unique enough. If they removed the old one and added the new one, then that would be the reason this is considered a breaking change 🙂 The same holds even more true for the one-letter abbreviations that characterize most commandline tools.

Leave a Reply