Verb-Noun vs Noun-Verb

Kurt asked the question “why not Noun-Verb vs Verb-Noun” in his post:

There are lots of answers to this some better than others.  Let me rattle off a couple of them:

  1. VMS DCL/AS400.  Issac Newton once said that if he could see farther, it was because he was standing on the shoulders of giants.  So it is with Monad.  People like to point out the similarities between Monad and various UNIX shells/utilities and scripting languages.  Absolutely true – many of us have deep UNIX backgrounds and  have a lot of respect for that body of work.  That said, Monad is influenced as much by VMS/DCL and AS400/CL as it is UNIX.  These are wonderful environments built with the clear vision that they would be used by people running production shops where operations and management really mattered.  These environments are strict about naming guidelines, common syntax, environmental setup, operational characteristics, etc etc. 

    Both of these environments are hard core about naming and leverage a Verb-Noun pattern.  Apollo’s Domain/OS and AIX also used Verb-Noun models as well.  BTW – you can see the influences of the VMS & AS400 focus on production qualities in:  having a single common command line parser,  -VERBOSE, -CONFIRM, -ERRORACTION (actually our entire near-manical focus on error handling comes from a focus on production readiness), and others.

  2. Programmer vs Admin focus.  Kurt points out that a Noun-Verb schema would mirror the OO programming world.  That is another reason we are Verb-Noun.  There are 2 aspects to this:

    1. Admins are admins with needs similar but distinctly different from those of programmers.  We already have world-class languages and tools for programmers, what we need improvement on is Admin languages and tools.  I did not want teams thinking that they could just expose their .NET objects and think that they were meeting the needs of admins.  These teams need to think about the needs of admins and provide consistent, high level, task-oriented, set-oriented operations with a strong focus on error handling and operational control.  You can easily do that with a thin layer on top of .NET objects but you can’t get that by just exposing .NET objects.  So being Verb-Noun helps drive home this point.

    2. Take a look at the inconsistency of Method names on .net objects.  It is Kill() for a process object but Stop() on a serviceController object.  Putting the noun first puts people in the mindset that their domain is the high order bit and they pick methodnames optimized for their domain.  Putting the Verb first makes it clear that the User Experience is the high order bit and the domain specifics are the low order bit.  We want an very high level of verb reuse to provide a consistent, predictable user-experience. 

Jeffrey P. Snover
Monad Architect

Comments (6)

  1. says:

    Perhaps I have a different perspective on this.  I started my career as a unix (SCO) administrator nearly a decade ago managing nearly 100 systems remotely connected systems, installing patches and new releases and replicating inventory data with trading partners as a nightly cron job.  We had a large library of shell scripts managing nearly the entire lifecycle from installation, configuration, data conversions, replication, OS and software patches and even scripts to troubleshoot issues on remote systems for use by the call center.  

    What I loved most about the unix environment was that I could write programs as they run.  Allowing me to inspect the state of variables and files before determining what I need to write next.  Transforming data is often many small steps – sed this, grep that, awk this choosing the least complex tool for the next logical step in the transformation.  Often during development I would output data to tty or a file for inspection and later as I became more sure of the resulting data I’d pipe it directly into the next command rather then reading and writing files.

    In unix nearly everything about the system configuration and/or system state was stored in or at least available in plain text format allowing complex applications to be written simply by manipulating plain text.  In windows however most information about system configuration is stored in binary files that are only accessible through custom tools and system state stored in memory requiring specific and often complex APIs to query or manipulate running processes, APIs that are often only accessible to compiled applications.  Thus the thing I loved most; the ability inspect and write programs as they run is the debugger where every time I need to make a change I have to terminate the program, thus discarding any non-persistent state information, recompile and start the process from scratch.

    At heart I’ve always been a developer and the few years I spent as a unix administrator I always felt like it was a developers role nearly everything I did involved some sort of programming even if it was only called scripting.  After a few years I moved on to a role as a "real" developer on the windows platform and I still miss many of the tools I had on the unix platform but as mentioned previously text processing tools on a windows platform are not that useful and over time I’ve forgotten many of them.  

    I recently found myself helping convert data from a legacy erp system.  I get alot of that data in Excel spreadsheets exported from there legacy system and find myself needing to join and merge various spreadsheets, perform lookups and validations against a database and variety of other tasks excel vba just doesn’t cut it.  I’ve found myself writing many small C# programs that pull the data out of excel via OLE DB Jet provider, splicing and joining data from various columns mapping it to a database table running sql scripts to validate and join datasets and finally extract the data out into the desired format that will be loaded into CRP and eventually PROD.  Like in the unix environment I find myself using a pipes and filter like approach performing many small transformations, but unlike unix where I can inspect and change the program as it runs I need to write the program data and state variables to temp files so that I can terminate, modify, recompile and restart the program where I left off without repeating the same transformations and validations over and over again on several thousand records.  Even as a compiled program it can take some time and once the data has been converted to the desired format its unlikely I’ll ever use the program again. An interactive shell for this type of adhoc programming would be very valuable to me.  

    I’m aware that many unix shells and commands are available for windows platform but its been so long since used perl or awk that it would take me longer to relearn them then to just write it in C#.  From my perspective what sets Monad apart from the perl, awk or whatever is the .NET integration allowing me to write many of these adhoc programs without the need to learn or relearn separate class libraries.  I’m also following Ruby which I’ve spent some time learning but last time I played with I had some issues with the .NET integration.  The thing I like about Ruby which I would really like to see in Monad eventually is the ability to create and even modify the class definition to add or change a method all at runtime.  I know classes can be created at runtime in .NET 2 but I don’t think it is possible to modify a runtime class after it has been created.

    So back to the topic, how does this relate to noun-verb, first of all Monad is not just a tool for administrators.  The window platform desperately needs an interactive programming shell that can, unlike unix ports, directly support the .NET framework to access the necessary APIs to manipulate system configuration and state.  I can’t say anything about AS400 environment but IMHO unix admins are probably better programmers then most vb programmers.  

    You will find inconsistency in verb names when crossing different domains and even simalar domains such as “email” “post” and “blog” sometimes new verbs form in domains when the process has changed a bit such as “google” instead of “search” not because they are trying to be inconsistent but because it conveys something is different or special about this verb (okay “google” is probably just marketing gimmick, but I when I say I “googled” it you can assume I wasn’t [msn/yahoo] “searching” for it).  And although there are some objects that perform similar tasks such as Process.Kill() and Service.Stop() these are the correct verbs for the given domain.  Kill has been the generally accepted verb to terminate a process since as long as I can remember, but if you look at services mmc snap in the verb to end a service is stop not because its being inconsistent but rather because killing a process is often associated with immediate termination without time to clean-up temporary resources or flush pending writes to disk, services are not killed they are stopped and the difference is important.  Even with the differences, you will also find a great amount of similarity in the .NET framework, in fact developers are often forced to use the same name due to subclassing and interface implantation, but even when inheritance or interface implementation is not a concern most developers try to be as consistent as possible with the naming where possible.  IMHO there is more consistency in class names and method names not only within the .NET framework but across OO languages and libraries then there is inconsistency.  For example nearly ever GUI library I know of regardless of the language or class library uses the term Button and the method Click, depending on the language conventions it might have a prefix like TButton or CButton or whatever but you can generally be assured if you look for button you can probably find it.

    I actually am starting to think that built cmdlets might not even be necessary, why can’t MshObject implement WriteHost, and whatever collection class is used when piping data support sort, filter, foreach?  Many dynamic languages place the sort method on the collection as it provides much broader and consistant usage, consider:

    MSH> get-item C:Windows* -include a* -exclude *z  | remove-item -whatif

    # but the following doesn’t work becuase include doesn’t exist on get-process:

    MSH> get-process –include *a –exclude *z | stop-process  -whatif

    Whereas if implemented on the collection you could use include exclude on any collection:

    MSH> Path(“C:Windows*”).FilterInclude(“*a”).FilterExclude(“*z”).foreach { $_.Remove(whatif = true) }

    MSH> Process.GetList().FilterInclude(“*a”).FilterExclude(“*z”).foreach { $_.Stop(whatif = true) }

    Perhaps its possible to add these as MshScriptProperties?  

    Anyways, I’m don’t even expect I will be using that many cmdletts with access to the .NET framework I can still do things the .Net way.  Even if I never invoke a single cmdlett I still find the interactive programming environment quite a compelling feature and think it will still have a place in my toolbox for some of my adhoc programming tasks that seem too simple to need to write and compile an application for but a tad too specific to expect to find some other simple tool that does exactly what I want without needing to learn some new domain specific language or class library when I already know how to do it in .NET.

    Anyways, I think I must have written a book by now… thanks for listening 🙂

    – Kurt

  2. Richard Siddaway says:

    From an admins point of view the verb-noun is much easier to read

  3. Since alot of the time Programmers are sys admins Verb-Noun only seems natural and why change a good thing?

  4. verbs and nouns says:

    Could I have some eamples of sentences using a verb and a noun

  5. Johannes Janssens says:

    For years now this discussion goes on and on, and yes I know that for the time being the verb-noun prophets wun the battle. Nevertheless, I am convinced that noun-verb is the right way to go ( definitely in OO), but I'm also convinced that most programmers are to lazy and to stressfull busy to even have the courage to chance their bad habits, to try at least to feel the benefit of noun-verb. I did both, and definitely, noun-verb it has to be. Programmers must learn that once they call something an 'Entity', they may not call it a 'Table' a bit later on. Noun consistency is the key to high-level thinking. Anyway, I'm retiring now, bye !