Verb-Noun vs. Noun-Verb
simblob.blogspot.com
simblob.blogspot.com
Auto-complete also really helps with discoverability. Consider checking for the presence of a key in a map/dictionary. In Java, auto-complete will quickly lead you to `map.containskey(key)`. In Python, though, you'd have to know that the syntax is `if value in dict`.
Now, let's check for the presence of a value. Auto-complete again quickly leads you to `map.containsValue(value)`. In Python, Google tells me that it's `if value in dict.values()`, which seems more difficult to stumble upon.
And that's for a built-in data structure. A lot of my job involves trudging through other people's code, trying to figure out how they architect their ball of cats. Auto-complete is a great tool for that; it lets you quickly and easily poke around, and see what the various nouns in the system can do.
Yes, way in the heart of a functional program there's some code sorting lists of ints or something. But by that time, it's all labeled to the point where the functions just tell you what happens. As someone browsing the source, the nouns disappear.
list.stream().filter().mapToInt().sum() just reads better to me than sum( mapToInt( filter(list) ) )
def do(x, fs):
for f in fs:
x = f(x)
return x
do(list, filter, partial(map, int), sum)
They differentiate thread first/last for Fns with arity > 1, just like Clojure.
CompletableFuture<Member> asyncProjectMembers =
Async.pipeline(Accounts.where("id >= ?", 1000);,
(accounts) -> accounts.loadProjects("updated_at >= ?", Instant.now().minusDays(30)),
(projects) -> projects.loadMembers());
const people = list.stream();
const peopleOlderThan50 = people.filter(??);
const average = peopleOlderThan50.mapToInt().sum() / peopleOlderThan50.length;
Also, for non-toy examples, there are real benefits to composing transformations, so that you don't pay the memory and performance costs of assigning intermediate sequences.
list |> map (1+) |> filter odd |> sumI haven't seen an autocomplete that works on pipes. But with a good type system, it is technically possible to list all compatible functions that take "noun" as first parameter.
Sometimes you supply partially applied functions (also with pipes in noun->verb order) and that's not so easy to match:
noun |> verb1 |> (otherNoun >> verb2) |> etc
But perhaps even functions that take "noun" as nth parameter could be suggested.
list map filter odd sumEnglish reads left to right overall, but writing instructions in English does not flow smoothly either way. e.g. "shuffle a deck of playing cards then deal four" reads more naturally than either "a deck of playing cards shuffle then four cards deal" or "deal four cards after shuffling a deck of playing cards".
shuffle(cards).deal(4) is a mix of both approaches.
Usually the languages either encourage cards.shuffle().deal(4) or deal(shuffle(cards),4).
In the 'noun-verb'/OOP version the sequence of modifications follows the english reading order where basically I only have to keep information about the last result in my head. The functional verb-noun version I have to pop in and out of layers: 'ok we're dealing what?, something shuffled, what are we shuffling?, the cards object/variable, ok we're dealing shuffled cards how many are we dealing? 4.'
In general the noun-verb follows the sequence of operations applied by the computer so it's easier to read.
But simply turning it around to cards.shuffle().deal(4) isn't a good answer, it's still the case that you can only put a small number of things together in a chain because it stops making sense. If the next move was to start the game, "cards.shuffle().deal(4).startgame('some-card-game')" does not make sense because starting the game is not something the cards do, but "start(deal(shuffle(cards), 4), 'some-card-game')" can make sense because start is a function which takes a board state and a game to start. It describes the world state, not the cards and their abilities.
That is, neither style is right, but a mixed style where both approaches are available and you can mix and match to be more expressive, works much better, IMO. Chunking a small number of things with prefix into one operation, or with postfix into one operation, but combining those chunks flexibly at a larger scale.
“Say that” “He said”
This isn't an argument for noun-verb over verb-noun, though it's an argument for more homogeneous syntax. `if value in dict` isn't noun-verb OR verb-noun.
There's not really a reason that f(<tab> couldn't complete with arguments (and it does in many systems). I think if you wanted to use autocomplete to make a point, you'd have to argue that it's more effective somehow to complete on verbs than on nouns.
``` (-> list parseInt isOdd sum) ```
Is the same as
``` (sum(isOdd(parseInt(list))) ```
Particularly useful if you're pulling a deeply nested key out.
On the other hand, tools like Hoogle [0] let you search for functions based on type, so you can search for e.g. `ByteString -> _` to find functions that take a bytestring. There's no reason the same paradigm can't be applied in an IDE.
(Note that this cant be a hash check because it’s not testing the presence of a key.)
(Also note that the story is different if you look at sufficiently archaic versions of Python.)
Ruby do have equivalents to Python magic methods... disguised as normal methods. For example Python `__hash__` is Ruby `hash` and both are used by built-in dict/hash values and you should be aware of that fact in both. There are some philosophical differences as well, Python likes to have standalone functions that are customized via magic methods (e.g. `str` vs. `__str__`, you don't normally call the latter) and in Ruby everything is method (e.g. `to_s`). It really seems like a matter of taste.
Speaking of which, I wonder whether we'll program in Tamarian one day. Whether we'll be able to build functioning software from a really high-level abstractions, and perhaps not try to micromanage it too much.
(And then when something goes wrong, the program will simply say, "Shaka, when the walls fell.")
I would say vim is also noun-verb as you can select text and then tell it to perform an action on it, but supports convenience methods for verb-noun, or just verb. It's just that most the verbs also have a default selection they apply to as well, whether it be a character, a line, or some larger block of content. Thus, 'x' deletes one character, but 10x deletes 10 characters, using 'v' to select text and then x deletes the selected characters. 'dd' deletes the default (current) line, '10dd' (or 'd10d' to mix it up) deletes the next 10 lines, using 'v' to select a range of lines and then 'd' deletes those lines. Additionally, you can just define a range of lines to apply a command do in command mode: 10,20d deletes lines 10-20.
I know what you're going to say, "dw is a verb noun!" but really, it's not. w is verb--it's a function that, in this case, takes the d function and applies it to a word. The fact that it is a verb is proven by the fact that the expression executes when you type the verb. It's unfortunate that the vim verb "w" corresponds to the English noun "word", but that's probably the best that could be done given there are only so many keys on the keyboard.
That's not to say it doesn't have a place in roguelikes, just that each game needs to carefully consider what it brings to the table, and also what it cuts out.
It might be useful to think about this in term of how many players it affects.
My opinion is that for each seasoned roguelike player who enjoys this "wonderful" aspect, there will be multiple roguelike newbies who will be discouraged by the unfriendly UX and just leave.
This is a strange viewpoint. This "wonderful" aspect of NetHack applies solely to newbies; seasoned players already know what they can do.
For example crafting systems or other forms of modifiers. I combine water with my sticks and get wet sticks then use those to make a camp fire which makes it extra smokey. Which leads to more introducing more systemic interactions and the beauty of those is that systems that interact have great potential for emergent behavior.
Simplifying Nethack's interface may well make it a worse game but it's not the case that a simpler interface in another game implies losing out on the fun of discovery.
Sure. That's what I was trying to say in the second paragraph. It's not a matter one being better than the other in general, or even for roguelikes. It's that there are things to consider about how you interact with the system in every case, so it deserves some attention.
For Nethack, I think the game is better for the interface not giving you clues what you can and cannot do. For other games, that likely isn't the case (very few support both the breadth of unique actions and make discovering those part of the draw of the game).
That would retain the "discovery" aspect of the game while also providing the convenience. You could even spin it into a game mechanic with "confusion" (randomizing your noun->verb options) and "amnesia" (erasing your noun->verb options).
The big drawback of noun-first is that it makes the player feel less creative because there’s no discovery: every object lists what it can do on the label. That’s no fun!
I like engraving with my wands and dipping weapons in holy water! I like polymorphing into a metallivore and eating metal rings to gain their properties! I like dipping one potion into another to create weird effects via alchemy!
When I started I was an avid Angband player. I had just gotten my first laptop computer and was frustrated by how difficult it was to play using the limited keyboard without a full numeric keypad. The main problem is that the default Angband keyset uses up almost all of the letters for all of the different verbs: quaff, read, cast, pray, wave, aim, throw, etc. (There is an alternate keyset based on Vi, but I could never internalize the "arrow keys".)
It was especially frustrating because, like Amit notes here, most verbs only apply to a few items. You can't read a potion or quaff a scroll, so allocating two separate keys to those actions is redundant. So in a fit of pique, I decided I would make my own roguelike with a single "use" command that could use all kinds of items.
I did learn something interesting about usability in the process. One nice feature of Angband's keyset is that it's harder to accidentally use the wrong item. If you intend to quaff a potion but accidentally pick an inventory slot containing a scroll, nothing happens. The specific verb commands act like a sort of redundancy check for the operation. But, overall, I think having a single use command is better.
This is orthogonal to whether the verb or noun comes first. I've just reduces the number of verbs by collapsing many of them into a single multi-purpose "use". I've gone through several iterations of the UI for the game and I'm still on the fence as to whether it makes more sense to select the item or the operation first. It's a little tricky in a roguelike because you usually need to select the item from something: either your inventory, equipment, or on the ground.
So if you want to drink a potion from your backpack, it could be any of:
- Use -> inventory -> potion
- Inventory -> use -> potion
- Inventory -> potion -> use
The first option is good most of the time because the player does know what action they want to perform. But the other two are good because they give the UI a chance to show the player the inventory before they make a selection. The first option feels like a stab in the dark where if you don't know what's in your inventory, you don't know if you have anything to use in the first place.
Of course, if the UI always passively shows the inventory, that problem goes away. So the visual design affects the order that operations might make the most sense. It's a hard problem.
I'm a longtime NetHack player who switched to Crawl, and I've been thinking a lot about the differences between the two games.
One neat NetHack feature is that objects often do have unexpected uses (as well as uses in combination with one another), and at least in a few cases you can make these uses by applying an unusual action to an object. The first example that comes to mind is that when polymorphed into a different monster, you may be able to eat things that your human form couldn't, sometimes with especially desirable (or undesirable) effects. NetHack players probably appreciate on the whole that the game doesn't actively suggest this possibility to them and that they have to think of it or try it to see what will happen.
Another example is that there are a couple of things that can be used as weapons to good effect that are not obviously weapons, so the ability to wield arbitrary objects is important there.
On the other hand, NetHack uses these possibilities as a source of humor and challenge to the player (partly to create a slightly more open-world feeling, typified by the saying that "the dev team thinks of everything", and partly to increase the amount of knowledge that a player can master and bring to bear on the game). Crawl has a very different philosophy and the actions available to the player are, compared to NetHack, more straightforward and obvious in their implications.
I did try in explore mode to see whether the game prompts you with unusually-edible items when you're polymorphed, and it actually does, so it's a slightly less hidden feature than I was thinking.
"This whistle is delicious!"
The problem with Angband is that the verbs are mostly disjoint. The only thing you can quaff is a potion, the only thing you can read is a scroll.
Part of my motivation for collapsing all of those "use" verbs to a single use command is because it frees up opportunities to add new operations that can be applied to a range of item types. It frees up keyboard space.
Right! When reading the article I had a bit of a feeling of hesitancy: the ubiquity and general-purpose-ness of functions in FP is the whole point!
Creating a single "use" is like using polymorphism to write a generic function, in a sense. You might imagine `use :: a -> Action` or something. As opposed to the article's take, which calls for `readScroll :: Scroll -> Action` and `openDoor :: Door -> Action`, etc.
I don't understand how most of the keys being occupied can be the "main problem", if you're not able to use those keys directionally anyway.
In Angband, most of the letters and punctuation on the main keyboard area are already allocated. You can rebind them, but since the different items need different commands, I don't think that there was any way to collapse multiple verbs onto the same key.
Terminal games were played with a keyboard, so feature creep resulted in every damn key on keyboard being used.
Most games slowly evolved away from that when joysticks and mouses became the dominant input devices (although I remember flight simulators still using most of the keyboard) but there were lots of games were people were still using the keyboard because it was faster (like FPS games).
Nowadays, with touch screens, using a keyboard is no sensible option and you naturally land a "first select the object then what you want to do with it".
But with roguelikes, you still often have a Verb-Object interface with keyboard shortcuts unless you play roguelikes that were designed from the start with a mobile interface in mind.
I started with verb-noun on the Star then migrated over to the noun-verb on the mac. Noun-verb seemed immediately better.
I wonder if XEROX PARC virtual desktop research came before or after the Star?
As I recall the standard top-level menus were “File, Edit, Options, Help”
With a system based on 'U'se, you're trading using fewer keyboard keys for more keypresses. You need to prefix most of actions with 'U'. Even Crawl lets you carry a-z items. When the list of items grows big, you either lose time scrolling through it to find a potion, or need to press and extra key to filter potions. In Crawl, when you press 'e', it only shows you edible items.
And for people so keen to compare with natural languages, we don't say use a sandwich, use flour or use paperclip. Natural languages could get away with just having few verbs, but you would have to make communication longer to clarify. Incidentally this is how English looks for a non-native english speaker. While words may be shorter on average, you need to string more of them together to get the same meaning. An extreme case of this is Toki Pona, which by design has 120 words for you to combine. An intentionally simple language based on belief simplicity leads to happiness.
The bottom line: over-reliance on few keys means the interface is optimized for low learning curve, not for long term use. Think Nano vs Vim.
The bottom line 2: the article sounds like it's written by a new convert. Noun first has merits and areas where it's better, but it's not something that cures cancer.
Computer games have evolved towards minimal learning curve, because it sells more games. Back when computers were mostly used by nerds, those people weren't bothered by having to read long manuals. The average computer user today IS bothered.
This is in stark contrast with board games. Board gamers must fully know rules to know how to play. When you play a board game, you have a higher initial learning curve, but once you do know, you immediately perform actions you want to make. In a typical modern computer game, you'd have to go through a sequence of menus.
BTW this is the definition of a game I subscribe to. A game is a set of rules. By this definition, most Call of Duty games are the same game.
canvas.draw(pen, brush, circle)
circle.draw(canvas, pen, brush)
... and so on
canvas.draw(pen, circle)
draw(canvas, pen, smiley)
There aren't many languages which support multimethods, but overloading functions is sufficient for statically typed cases, and it's appealing (for me) to have the same syntax for "builtin" methods and ones you add yourself:
draw(canvas, pen, brush, circle)
draw(canvas, pen, brush, smiley)
For what it's worth, I really dislike it when languages implement operator overloading for binary operators as methods on the first object without a way to dispatch to the second object. This makes it very difficult to have your new types play well with the builtin or library provided types. Binary operators really are functions with two arguments.
OOP is not about nouns. It's about establishing protocols between subsystems. What you're describing are the typical fake "dilemmas" of someone coming from a static, class-oriented programming languages like Java.
Look up Class Responsibility Collaborator exercise.
Is that what it's about? I try to establish protocols between subsystems without OOP quite often. Are you referring to message passing specifically?
I'm pretty sure most people who strongly like OOP are sure their particular definition is the correct one. I haven't seen many people agree about what that definition is though. I generally dislike OOP, but perhaps that's because my definition is "encourages implementation inheritance". As you're keen to note, the standard list of other things (encapsulation, message passing, dynamic dispatch, interface inheritance, and even "establishing protocols") are available in a lot of other languages which people don't generally consider OO.
Perhaps I'm ignorant, but I like my way of doing things, and a.f() is less attractive to me than f(a) for all the reasons I listed.
Or maybe it tells you that the benefits of OOP are different from what they're theoretically supposed to be. What I read from the thread is that there seems to be significant psychological appeal to some in the noun-verb way, and OOP (perhaps unintentionally) satisifies that need. (And that helps me understand the frequent "Julia needs a thing.do() syntax" complaint on the Julia forums, and why telling them "semantically do(thing) does the same thing" doesn't seem to work.)
canvas pen brush circle drawBy going "noun-verb", you are fixing the first 3 dimensions and leaving one remaining (hence the ~1000x reduction in search space for autocomplete). By going "verb-noun" you are only fixing 1-dimension, leaving the other 3 unknown, and autocomplete would have a larger search space.
Putting it another way. If I started a story "the year was 2015", I've only narrow the one time axis, but the "noun/place" hasn't been narrowed at all, so you still have a sphere of possibilities. However, if I started a story "we were on the Golden Gate bridge", I've pinpointed the 3-dimensions of place/noun, and now the reader only has to pinpoint where on the "time-line" we are. And even that timeline has been shortened to a segment of ~100 years.
If you have a sparse matrix of nouns and verbs where cells show whether a given verb(noun) pairing is valid, indexing by noun is clearly more efficient, because most of the time you know exactly what you're operating on, but not necessarily what the operation you want is named. The variables are likely right there before your eyes, a couple lines above the cursor, but the functions are spread out all over the code base.
"Here, we study naturalistic speech from linguistically and culturally diverse populations from around the world. We show a robust tendency for slower speech before nouns as compared with verbs. Even though verbs may be more complex than nouns, nouns thus appear to require more planning, probably due to the new information they usually represent."
How does the reader trying to guess the date narrow the choice of verbs?
You might be on TGGBridge jogging, and the date is irrelevant. It seems like fixing the location to TGGBridge narrows the possible verbs, but it’s still a huge list - “we were on” means you could be doing anything people can do - photographing, touring, jogging, sketching, working as a bridge repair crew or structural engineer or a vehicle breakdown van or an Uber driver or protesting or meeting up in a well known location.
In English, “I was driving..” implies a vehicle, but “a car..” doesn’t imply you were driving it, or necessarily doing anything to/with it at all.
My thinking is when someone visualizes something they need to visualize the place/noun first and the verb (what happened over time). The first requires 3 dimensions and the latter just one more.
Still, there is something else... I just don't like it.
PowerShell provides incredibly flexible syntax, enough that it can satisfy most styles of script writing.
The practice you describe (short names in CLI and long names in scripts) can be achieved. A couple of things to note about how PS binds arguments to function calls: 1. If you omit names, the parameters are bound positionally. 1. If you use names, you do not have to type the full name. It is sufficient to type an unambiguous prefix of the parameter name and the most appropriate parameter will be selected.
So for example in the CLI you can just to `ls -r -fi .csproj` whereas in a script you can use the fully self-documenting `ls -Recurse -Filter .csproj`.
Hope this helps!
In my opinion this is a non-issue (at least when comparing powershell to other shells) because the number of cases where you have to worry about bash command 'X' actually being different from your system (even across varieties of Unix-y OSes) is much greater than this handful of convenience aliases in powershell.
You can shorten flags in powershell, fyi.
I made the switch to powershell from bash recently (after 20+ years with bash and its antecedents). I didn't love the aesthetic of powershell to begin with, but the advantages are pretty convincing.
Short aliases are "unsafe" across platforms but this is a non-issue since this situation is so much worse for bash, and at least you have long canonical names for things when it counts (i.e. writing scripts). How much bash code has been written over the years to figure out which code path to follow based on which flavor of awk you have or safeguard your function from user aliases for rm?
Thinking there is a "higher bar" to learn powershell vs bash is purely bias due to what you already know. I'm not saying everyone needs powershell and I don't think it's great for everyone but it definitely isn't harder to learn than bash. It's much more discoverable (even if only thanks to actual types and 'gm'). I haven't used ISE at all.
But if it does clash, you get an error, so really when using this you press tab to demonstrate either that you have a uniquely short string and it autocompletes to the full name, or you press tab and find you don't have a uniquely short string and then tab through until it's the one you want and see the full name.
There are short parameter aliases, e.g. -EA for -ErrorAction which are not unique substrings, and you can define those on your own cmdlets and advanced functions, but they seem less common.
And it would be possible to enforce some of this with a style checker in your own scripts, because you can introspect cmdlets and advanced functions to see what parameters they support, and make sure your invocations always use the full parameter name. I don't know if any checkers do, but VS Code with the PowerShell extension will style check your scripts.
I think the bigger issue is that MS stuffs all the modules you don't need into every session, so when you want to do something simple against your DHCP server, you also have to tab past all your AD, SAN, NFS, etc, etc cmdlets in the process, which is just dumb.
Or do Ctrl-Enter to get the list of all matches and navigate with arrow keys, should be faster.
Thinking of it, I don't really need discoverability often but if I did I'd probably resort to
Get-Command | %{$_.Name} | fzf
bound to a key or so: this gives you fuzzy matching search of all possible commands. I just tried, 1683 commands in total and this got me all Smb commands in about the amount of time it took me to type 'SMb. It doesn't get better than that. Well, except that you could have fzf split the screen and show the help for each command there.
This is also the typical PS (or other shells for that matter) story: people complaining about not being able to do discoverability whle in fact the there are actually some seriously good options but it's those options which are hard to discover :)
get-command *smb*
get-command |% Name
- it's fuzzy and more i.e. https://github.com/junegunn/fzf#search-syntax
- gives you a list which you can shrink further, again with fuzzy matching
- list can be navigated using keyboard, and then selected from
To avoid having to write that {$_.}
Heh, I actually didn't know that. Or forgot.
That’s modern UX for you. Hide features to the degree that only a lucky few will ever find them :). A lot of websites and mobile apps have adopted that philosophy.
(In reality it’s slightly less clear because tab would then have to show you other file names, executables, batch files, etc. names, at least Set- narrows it down to cmdlets to do with setting).
CLIs require matching the flags to the direct objects they apply to and carrying that mapping around in your head (and the command will just fail if you try and apply the wrong flag to the wrong object).
It's not really weird, (verb)-(direct object)-[(indirect object)] with the subject implied in yh direction of the command is a very common structure for imperative commands in natural language. Given that PS largely targets operators that are not (and even moreso were not when PS was developed) general coders, following natural language imperative patterns makes a lot of sense.
There probably is somewhere a natural language that uses object-verb in the imperative, but o haven't heard of one.
Its still a nice little scripting language, and its awesome when you want to just avoid some Windows GUI nonsense. Plus Powershell's interactive nature makes learning it significantly easier than some of the more complicated languages I've picked up since then, although its getting harder and harder to excuse Microsoft's poor design choices around it.
https://nim-lang.org/docs/tut2.html#object-oriented-programm...
Since english can verb nouns like nominalization, i can't tell what the benefit is. one boards the board of a ship, levers a lever, and locks a lock.
We "lockpick" more often than we "save face" perhaps English is a head-first language.
In formal writing, a difference exists between nominal and verbal-style.
Take one of your examples, you're much more likely to know you can "board" once you know there's a "ship." Without the ship as context first, only people who are already familiar with ships know that boarding is even an option.
This provides a poor experience in terms of discoverability.
The head of a sentence is its verb, so no.
I don't buy the auto-completion argument. Can my IDE really tell me all the ways I can use an Integer? I don't think so.
When it hit home for me was when Java 8 lacked Stream.takeWhile(predicate) and I decided to implement it for myself. I could implement takeWhile(predicate, stream), I could not implement stream.takeWhile(predicate).
Sure it can. E.g. (not an IDE, and some double underscore methods translate to operators, but the mapping is trivial):
>>> dir(int)The IDE (or, here the "dir" method) shows everything _available_ to use as a method on an integer.
If you meant "but can it show functions that are not on the integer type but that accept integers?" -- then many IDEs cannot, but it's not a difficult feature to add in an IDE for known libs/modules.
Can't think of any other way a question like "Can my IDE really tell me all the ways I can use an Integer?" makes sense. Of course the IDE wont know about yet unwritten methods which still count as "ways to use an integer". But nobody claimed it can above, and the absence of that doesn't discard autocompletion as an argument (to using the noun first).
I think protocols are neat, but I'm uncertain whether their usefulness outweighs the added mental burden of keeping track of them all (since they can be defined anywhere and take effect everywhere).
[0] https://homepages.inf.ed.ac.uk/wadler/papers/expression/expr...
Annoying context switches and slowdowns to lookup function naming and possible options (without autocomplete) can still interfere with the flow of a programmer as he writes a program...
import pandas as pd
from pyspark.sql import functions as f北に行く (north, go) ポーションを飲む (potion, drink) スライムを戦う (slime, fight).
This would make the call e.g. v1->cross(v2) syntactic sugar for the call cross(v1, v2).
The main reason it's not just an obvious win for autocomplete and readability is that it provides for multiple ways to do one thing, and is one more thing you need to know when learning this new language. Rather than having some code call plane->yAxis() and other code call yAxis(plane), it might be nicer to have only one way.
The other counterargument: the OOP-like syntax could support the expectation that polymorphism works like e.g. Java, where e.g. v1.cross(v2) would only considers the type of v1 when deciding which overload to call. FeatureScript has multiple dispatch and will consider the types of all arguments when choosing an overload.
All that said, the change it seems like a win overall, but we're waiting for the language to mature more to see if clearer arguments emerge.
[0] https://cad.onshape.com/FsDoc/
[1] https://forum.onshape.com/discussion/comment/33495/#Comment_...
One option is a linter/formatter that can warn and configurably push you in one way or the other.
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
The benefit to verb/noun (or noun.verb) is getting BOTH. If you effectively drop the verb, you lose out on half the communication.
To use another comment, you may not want to quaff a ladder, but it is a bad idea to assume you just "ladder", and if assume too narrow a field it leads to frustrations. (In programming or in games. Back when I looked into text adventure games (interactive fiction) there was a truism that "use" was a _bad_ verb)
If you ARE wide enough....then you have little difference between noun verb and verb noun except for the effort required.
Honestly, I was more interested in the first part of the article, that talked about checking the state if the world rather than a sequence if steps.
As Alan Perlis said back in 1982:
> "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."
When I'm writing in a FP language, it's true I don't get much autocomplete help, but the upside is that I've got 100 core functions that operate on almost anything. Even if you flipped around the order of the syntax on screen, autocomplete wouldn't help much, because you can apply any verb to any noun. I rarely have to convert between types, and when I do it's a couple words at most.
When I'm writing in an OO language, with typical class libraries and frameworks, I get a lot of help from autocomplete, because once you know the "type", there's only a few things you can do with it. The corollary is that I usually spend half my program converting from the type I have to the type that I need.
(Think about English. We could simplify the language by eliminating words like "eat", and just say "I'm going to go use lunch", but then we wouldn't have the word "eat" available for any other nouns, even where it'd be helpful and clear.)
> It is better for programmers if they can choose from two medium length lists than to have to choose from a very long list (where a lot has to be typed before it's useful) and then a very short list (where not much is gained).
This doesn't tell the whole story. As they say, you write code once, but read it many times. I'm perfectly OK with giving up autocomplete (for writing) if it means I don't have to spend twice as many lines of code (for writing and reading) to convert an X to a Y just so I can call f() on it.
The more generic the functions, the less code I have to write, and having less code has huge benefits across the board -- for writing, reading, debugging, testing, performance, and so on. Autocomplete can be nice, but it's not nice enough to want to sacrifice everything else.
I personally chose verb-noun, but it would be very simple to flip it around.