Name of "Amb" Operator

Question

Like many others, I was first puzzled by the presence of the "Amb" operator, wondering (a) what "Amb", an apparent abbreviation, stood for; and (b) what the method does.  While a quick search turned the answers I sought, I recommend expanding the name to "Ambiguous".  The expanded form of "Amb" is not immediately obvious (my first guess was 'Ambient'), and it violates Microsoft's own naming guidelines:

In general, you should not use abbreviations or acronyms. These make your names less readable. Similarly, it is difficult to know when it is safe to assume that an [abbreviation or] acronym is widely recognized.

(see MSDN documentation for the origin of the above quote)

Regards,

Mike

Answer 1

For me it is more important not rename things that have been around for decades http://community.schemewiki.org/?amb. 

Answer 2

For me it is more important not rename things that have been around for decades http://community.schemewiki.org/?amb. 

The operator's history is beside the point.  The issue is one of usability.  Unless a developer is already familiar with the 'amb' operator, its function cannot be easily inferred from the abbreviation.  Expanding the name to "Ambiguous" gives the developer more information to go on, potentially saving him a trip to the documentation.  Moreover, it's not really 'renaming' an existing operator since the existing name is simply an abbreviation.

Another issue is consistency--Microsoft has made a concerted effort to standardize naming conventions throughout the .NET ecosystem.  Their guidelines are sensible and tend to make things easier on everyone.  Note this excerpt from Framework Design Guidelines, 2nd Edition:

It is equally important not to use abbreviations and acronyms that are not generally understood--that is, do not use anything that the large majority of people who are not experts in a given field would not know the meaning of immediately.

Are most .NET developers already familiar with the 'amb' operator?  Probably not.  However, most WinForms and WPF developers are probably familiar with the concept of ambient properties, hence my brain immediately made the connection between 'amb' and 'ambient' rather than 'amb' and 'ambiguous'.

Mike

Answer 3

I'd say that non-experts are familiar with Amb, if they have studied an intro to functional programming.  It's used everywhere by that name, and has since 1961.  Is URL intended for experts or non-experts? 

Answer 4

Amb is an abbreviation.
URL is an acronym.

Amb has not been around for decades in .net, and there are a lot of .net developers for whom .net is their first framework. The standard for the BCL has always been to avoid abbreviations. The meaning of Amb was absolutely not clear to me when I first saw it. I think the argument to maintain something simply for historic legacy is a bad one. I don't think finding "Ambiguous" would confuse anyone looking for the "Amb" operation. However, "Amb" requires either guessing or research to deduce its meaning.

Answer 5

IMHO if we rename known concepts (no matter is the original names were wrong) we can never build a common constitutional memory. 

And, in this particular case, consider the use of Amb a small tribute to John McCarthy without whom we would not have had LINQ expression trees and lambda expressions. Say thanks to John for his great contributions to our field every time you use Amb ...

Answer 6

We have plenty of other abbreviations in the BCL.  RegEx, Enum, EventArgs, Concat, IntPtr, AppDomain, MarshalByRefObject and ParamArrayAttribute come to mind.  I don't really think Amb is that different.   I think the big thing against uncommon abbreviations and acronyms in the framework is to avoid cryptic names like _wcstombs_s_l and strpbrk.  

Amb is not that bad... I didn't know what it was initially, moused over it, got the tooltip "Returns the observable sequence that reacts first.", learned something new, and continued on. :)

Answer 7

I disagree and don't see this as a valid point. What should we do with Cons using this argument? Cons adds an item to a functional list, but we already have an Add method that mutates a list, and Cons doesn't mutate. So now you have a meaningful name but the developer won't realize it works very differently. I'm acutally surprised that LINQ used Where, Select, Aggregate, etc. for familiar functional names. They could still have used extensions Filter, Map, Reduct, etc. and allowed the query syntax to model SQL. While those unfamiliar with functional programming will not know what the operators are, they certainly still won't know even if they are renamed. To really use Rx, LINQ, etc. correctly, you need to learn functional programming, and in so doing you'll learn the intent of these. That's part of the fun! :)

Answer 8

I disagree and don't see this as a valid point. What should we do with Cons using this argument? Cons adds an item to a functional list, but we already have an Add method that mutates a list, and Cons doesn't mutate. So now you have a meaningful name but the developer won't realize it works very differently. I'm acutally surprised that LINQ used Where, Select, Aggregate, etc. for familiar functional names. They could still have used extensions Filter, Map, Reduct, etc. and allowed the query syntax to model SQL. While those unfamiliar with functional programming will not know what the operators are, they certainly still won't know even if they are renamed. To really use Rx, LINQ, etc. correctly, you need to learn functional programming, and in so doing you'll learn the intent of these. That's part of the fun! :)

Going only by the name, I would have no idea what the "Cons" operator does.  Based on your description, I think it could use a more descriptive name.  It appears someone on the framework team agrees, as the "Cons" operator has been renamed to "StartWith" in the latest drop.

Mark's reasoning is dead-on.  It's reasonable to assume that if "Amb" is expanded to "Ambiguous", then it will remain discoverable to anyone looking for "Amb".  At the same time, the expanded name better conveys the operator's purpose.  Honestly, I'd be in favor of a new name altogether (something like "WaitAny"), but "Ambiguous" would still be an improvement, while continuing to pay homage to McCarthy.

A vcomrhencke pointed out, there are several types in the BCL which use abbreviations.  However, in fairness, most of these have been around since .NET 1.0, long before thoughtful naming standards were established.  There are several cases where you can see common abbreviations being dropped in favor of their expanded form, e.g. "ApplicationSettings" replacing "AppSettings".  New frameworks should continue this trend.

Answer 9

Amb is an abbreviation.
URL is an acronym.

Amb has not been around for decades in .net, and there are a lot of .net developers for whom .net is their first framework. The standard for the BCL has always been to avoid abbreviations. The meaning of Amb was absolutely not clear to me when I first saw it. I think the argument to maintain something simply for historic legacy is a bad one. I don't think finding "Ambiguous" would confuse anyone looking for the "Amb" operation. However, "Amb" requires either guessing or research to deduce its meaning.

Since the original author of the thread used this line from the .NET Framework Design Guidelines "It is equally important not to use abbreviations and acronyms", it should be pretty obvious what my point is.  URL certainly hasn't been around in .NET for decades either.

Amb is a well known operator, URL is pointer to an address essentially, and fully expanding the name to UniformResourceLocator is not going to help anyone understand what a URL is, and no one is going to understand what Ambiguous does either vs. Amb, unless they read about it.

Answer 10

Amb is a well known operator, URL is pointer to an address essentially, and fully expanding the name to UniformResourceLocator is not going to help anyone understand what a URL is, and no one is going to understand what Ambiguous does either vs. Amb, unless they read about it.

I don't think it's a fair comparison.  Most casual web surfers know what a URL is, even back in the early .NET days.  Developers who don't know what a URL is are unlikely to be using any web/networking APIs.  Developers who have no significant experience with functional programming are unlikely to be familiar with "Amb".  I think this covers a large subset of .NET developers, considering many of them came from either a C/C++ or Java background.

In order for this to be a valid comparison, we would have to assume that developers who are unfamiliar with functional programming, continuations, and such are also unlikely to use the Rx Framework.  That's not a reasonable assumption, though.  The need for web/networking APIs is largely driven by project requirements--if you're strictly a client UI developer, you probably don't need to dive into those APIs.  Rx, on the other hand, provides a useful set of APIs that could be applied to almost any project.  Just the same, almost any project could be completed without touching Rx.  There are plenty of general cases where Rx could save developers time, like unit tests for asynchronous operations.  Since one of the primary objectives of the BCL team is to make all developers' lives easier, esoteric naming schemes should be avoided.

On a side note, developers who do have functional programming experience are more likely to (incorrectly) assume that the average developer is as well-educated on the subject as they are.  Your average "not necessarily a hardcore programming geek" developer who has been working in object-oriented languages throughout his career is unlikely to have dabbled in functional programming, as it's not often required to get the job done.  I'm a language geek, and I still hadn't heard of "Amb".

I do agree that "Ambiguous" isn't that much better than "Amb".  However, it would bring the operator into conformance with naming standards, and as a bonus, it's slightly less cryptic.  It doesn't detract from the current name in any way that I can see.  It's just as discoverable, and anyone familiar with "Amb" should know that it's short for "Ambiguous".

Answer 11

The first thing I did when I got the first drop of Rx was try to use Cons to build a list, but I couldn't find it, and I expected it to be there, because that is what it is known as in all functional languages as far as I know, and that's what SICP taught me long ago.  I agree with Ryan, and Erik's point on having a shared memory is right on the money.  If I search for "StartWith" there will be very little information about it, but if I search for Cons, I will find exactly what I am looking for.  I think renaming StartWith was a mistake.  If you do a search you will find a few Rx code samples using Cons, which of course are out of date and confusing.  I'd rather see both names if it's that important, but I am sure that's against some other set of guidelines.  ;)

Answer 12

I really didn't mean to start a big debate here--I just saw a case where an operator name seemed inconsistent with Microsoft standards, and suggested a relatively simple fix to (a) improve consistency and (b) maybe improve usability a little.  I'm not going to be heartbroken if the name goes unchanged.  It doesn't actually bother me.  As has been pointed out, one trip to your favorite search engine is all you need to familiarize yourself with the "Amb" operator.  On the other hand, you could just as easily write your own extension methods to map some of the operators to more familiar names.

I do agree that some of the "friendly" operator names are just as cryptic as the "classic" names.  I would think "Prepend" would be better choice than "StartWith".

Answer 13

Amb is a well known operator, URL is pointer to an address essentially, and fully expanding the name to UniformResourceLocator is not going to help anyone understand what a URL is, and no one is going to understand what Ambiguous does either vs. Amb, unless they read about it.

I don't think it's a fair comparison.  Most casual web surfers know what a URL is, even back in the early .NET days.  Developers who don't know what a URL is are unlikely to be using any web/networking APIs.  Developers who have no significant experience with functional programming are unlikely to be familiar with "Amb".  I think this covers a large subset of .NET developers, considering many of them came from either a C/C++ or Java background.

In order for this to be a valid comparison, we would have to assume that developers who are unfamiliar with functional programming, continuations, and such are also unlikely to use the Rx Framework.  That's not a reasonable assumption, though.  The need for web/networking APIs is largely driven by project requirements--if you're strictly a client UI developer, you probably don't need to dive into those APIs.  Rx, on the other hand, provides a useful set of APIs that could be applied to almost any project.  Just the same, almost any project could be completed without touching Rx.  There are plenty of general cases where Rx could save developers time, like unit tests for asynchronous operations.  Since one of the primary objectives of the BCL team is to make all developers' lives easier, esoteric naming schemes should be avoided.

On a side note, developers who do have functional programming experience are more likely to (incorrectly) assume that the average developer is as well-educated on the subject as they are.  Your average "not necessarily a hardcore programming geek" developer who has been working in object-oriented languages throughout his career is unlikely to have dabbled in functional programming, as it's not often required to get the job done.  I'm a language geek, and I still hadn't heard of "Amb".

I do agree that "Ambiguous" isn't that much better than "Amb".  However, it would bring the operator into conformance with naming standards, and as a bonus, it's slightly less cryptic.  It doesn't detract from the current name in any way that I can see.  It's just as discoverable, and anyone familiar with "Amb" should know that it's short for "Ambiguous".

Look at your own posts and count the abbreviations and acronyms.  Why do I know what you are saying?  Context, experience, shared memory, you can't wade far into the pool without running into these abbr./acros., and if you were talking to another developer you'd avoid the full word and use the abbreviation to make it even more clear what you are saying.  Like saying "Cons a list" instead of "Construct a list" because "Cons" gives context to the use of the word (related to a list), where you may think I meant new List<T>().  The abbreviations become so common that you don't even think twice about whether it's ok to use "BCL".  I would give an example with Amb but it's not as easy.  ;-)

Answer 14

>  It appears someone on the framework team agrees, as the "Cons" operator has been renamed to "StartWith" in the latest drop.

For a different reason; I don't want Intellisense to show Cons whenever I type a . That said, I toyed with calling it Snoc, which is the name functional programmers use ;-)

Answer 15

Look at your own posts and count the abbreviations and acronyms.  Why do I know what you are saying?  Context, experience, shared memory, you can't wade far into the pool without running into these abbr./acros., and if you were talking to another developer you'd avoid the full word and use the abbreviation to make it even more clear what you are saying.  Like saying "Cons a list" instead of "Construct a list" because "Cons" gives context to the use of the word (related to a list), where you may think I meant new List<T>().  The abbreviations become so common that you don't even think twice about whether it's ok to use "BCL".  I would give an example with Amb but it's not as easy.  ;-)

Ah, but your colleagues are more likely to be familiar with the same programming constructs as you, given that you likely work on many of the same projects.  The .NET ecosystem is very broad, which is why naming standards exist.  The guys writing the frameworks are generally a lot more knowledgeable and experienced than the guys consuming those frameworks (many of which are junior-level developers).  The idea behind the guidelines is to avoid inadvertently creating a set of APIs that is not easily understood by other developers, many of whom aren't as smart or well-educated as you are.  The other driving factor is, again, consistency.  As we've seen here, different developers have vastly different ideas about whether certain names, acronyms, or abbreviations are "well-known" enough to be used in APIs.  It's arguably better to just say "don't use acronyms or abbreviations" than to let each development team use its own standards, which would result in a lot more inconsistency.

Answer 16

>  It appears someone on the framework team agrees, as the "Cons" operator has been renamed to "StartWith" in the latest drop.

For a different reason; I don't want Intellisense to show Cons whenever I type a . That said, I toyed with calling it Snoc, which is the name functional programmers use ;-)

Intellisense pollution is just another problem with extension methods in general.  As for the names, you have a bit more freedom than the BCL authors, as the Rx operators aren't going to be included in the BCL for .NET 4.0.

You could always go to Krzysztof Cwalina and say, "Here are some APIs I'd like to see included in the BCL.  Are there any naming or design changes you think should be made first?".  I'd be interested to hear his thoughts.

Answer 17

Hi Mike,

as one of the original developers of FxCop, I can assure you that we spend a lot of time thinking about the names of the Rx operators. As for Amb, I like the fact it stirred up this much discussion as I think it is important to read the history about this operator to really understand its behavior. I don't think naming it Ambiguous would have done justice as there is more to this operator than the literal definition of ambiguous in the english dictionary...

Jeffrey
don't forget: 'the code is more what you'd call "guidelines" than actual rules' :)

Answer 18

Talking about naming; we went through many long discussions with the BCL guys (including Krysztof) about the names for the IObserver<T> methods.

Originally we started out with Yield, Break, and Throw, and we ended up with OnNext (was Notify for a while), OnCompleted (was OnDone for a while), and OnError.

Answer 19

On a side note, developers who do have functional programming experience are more likely to (incorrectly) assume that the average developer is as well-educated on the subject as they are.  Your average "not necessarily a hardcore programming geek" developer who has been working in object-oriented languages throughout his career is unlikely to have dabbled in functional programming, as it's not often required to get the job done.  I'm a language geek, and I still hadn't heard of "Amb".

I definitely don't agree with that statement. I know most of my colleagues rarely have any idea of what I am talking about. However, I still use "monads" and the correct terms. Yes they are jargon, but would you change π to "the multiplier to the radius when determining the area of a circle"? I would hope not. A lot of people are afraid of big or unknown terms for no reason at all. I had no idea what Amb was, but I have enjoyed learning about it. I think I might have been more frustrated if it was actually called "Ambiguous". I would have said to myself, "Really? Thanks a lot," and likely left that one to a lot later evaluation. Instead, I looked into it a lot sooner.

I do agree that "Ambiguous" isn't that much better than "Amb".  However, it would bring the operator into conformance with naming standards, and as a bonus, it's slightly less cryptic.  It doesn't detract from the current name in any way that I can see.  It's just as discoverable, and anyone familiar with "Amb" should know that it's short for "Ambiguous".

I don't really understand your fixation on naming standards here. Amb is a commonly used operator in other functional languages. As such, I should think that carries more weight than just an abbreviation guideline. A new developer would struggle with either naming convention, but a functional developer would only struggle if it was renamed to something completely different. As a perfect example, have a look at the "Homework: Find Call/CC" thread. I would never have guessed "Create" since it seems very clear that it creates an observable, not that it allows you to transform the rest of the block into a continuation. (For that matter, I'm still not sure that it does. Erik, Wes, or Jeffrey care to comment on the last post there?) In my opinion, changing the name from a common functional term makes it more difficult to carry over from one to the next. But then again, not all functional languages quite agree, either. :)

Answer 20

Well, if you don't like Amb, then you should also get rid of:

Math.Cos

Math.Sin

Math.Sqrt

Math.Exp

Math.Pow

etc...

What about Math.PI? That should really be: Math.LengthOfHalfCircumferenceOfUnitCircle or something.

What about strange symbols like +, -, *, /, %? 

Somehow we accept things that we learned at young age, but once adults, we don't want to learn new symbols or well established names anymore?

Amb and Cons are no different from any of these really, these are well know concepts in mathematics / computer science. You might argue that most developers had basic math and therefore know what cos means, but where do you draw the line then?

PS: A similar discussion was held in the Haskell Cafe about Monoid versus Appendable btw, so even in the computer science community, discussions like these pop up :)