Naming Conventions

Oct 2, 2009 at 11:01 PM
Edited Oct 3, 2009 at 3:31 AM


I am having a hard time figuring out what some of your methods are doing just by their names. This is probably because I do not have a F# background.

Names like Curry mean nothing to me. I realize that Haskell Curry is an important name in functional logic, but it doesn't help me to understand the method's purpose. I had to really look at what it was doing in order to fully grasp its purpose. Memoize is also a very "technical" term. Boost does Curry like functions in the Bind code set. Bind is a decent name. Memoize is really just a input to output cacher.

I implemented a Bind-like library for C# before. It caused extremely poor performance. This is because the C# compiler created a class for each of the "bound values", which led to multiple levels of indirection. After two or more bindings, performance start to degrade.

I think some of your methods, especially those ending with "2" should probably also have more meaningful names. C++ has a tranform method for combining the values from two sequences and generating a third. You seem to be finding Extension Method-friendly methods. I mean, the Through methods seem a little odd to me. It reads well, but operating on an int as though it were a class isn't typical; most people treat it like a primitive.

Oct 5, 2009 at 12:22 AM


FYI, it is probably better to use our Google group ( to handle future discussion on this, but I'll answer here for now.

RE: Naming

We chose names because they're (as far as we know) the standard computer science/industry names for those concepts. One of my personal gripes is when library writers take concepts that are well defined with one name and rename it to be something "more understandable". In my opinion this causes more confusion than it's worth. The .NET IList interface is one example that comes to mind since it conflicts with the computer science notion of a linked list vs an array. Another big benefit is that you can easily do a search for "currying" or "memoization", and have plenty of resources to explain what it does if you don't understand it.

That being said, we do have some names that we want to clean up. At this point, unless we see a lot of other requests for it, Curry and Memoize are not on the list to be changed.

One other thing that we have tried to do to make things more approachable regardless of names is the explanatory tests in the Elevate.Guide project. Did you find these tests helpful when trying to understand how things worked? If not, what can we do to make them easier to understand?


RE: Performance

Performance is often relative. If you're micro-optimizing away the cost of a couple of method calls, you might be overdoing it for the general developer. However, we want to Elevate to perform as well as possible, so if you have any examples of where performance is poor, please let us know.


RE: Extension Methods

I think that you're right about how the average C# developer views extension methods and primitive types. I don't know that it's a good perception, though. Languages like Ruby use a syntax like 1.Through(5) to great effect. Either way, if you don't like that style, you can always call it like a static method.


Oct 14, 2009 at 2:57 AM

I just got your message. I will post to the google newsgroup from now on.

After looking at the wikipedia pages, I agree that perhaps your names for Memoization and Curry are okay. Again, that comes from my lack of functional programming experience.

One of the things I have tried to stear clear of when developing code in C# is to program "outside the paradigm". C# is slowly encompassing more and more functional programming-like features, but I still think it is a far way off. The BCL developers are actually talking about creating a Tuple class, but their implementation is somewhat short-sighted in my opinion. People want a tuple class similar to what Python provides, with the pretty paranthesis syntax and whatnot. Personally, I wonder about the productivity that such a class will bring. C#'s anonymous classes seem to provide this functionality (mostly) with a slightly more object-oriented approach.

Performance is becoming less important. Many libraries today rely entirely on reflection and other slow technologies (like parsing XML). "Slow" is really relative. It is always a little tempting to break out the profiler and see how you are doing, but it rarely is beneficial. What we need is a library that focuses on changing the "way we think" about programming in C#. After writing an algorithms library, I didn't really see any benefit. The classes that really stuck out were the ones that weren't provided by the STL but were useful and those that took on a different angle something I already worked with.

My Formatter class allows someone to format a string similar to String.Format, but it uses named placeholders instead. This is a simple class, but it has had a lot of applications.

I recently added an "In" method to my library. It allows a SQL like syntax for determining whether a value is in a collection. So, you can say 5.In(1, 2, 3, 4, 5, 6, 7) and it will return true. I like the syntactic sugar, but I'm not sure I like it yet. It doesn't look so weird if the integer or whatever is a variable. Personally, I think I prefer an Any method. I also prefer a GetRange method. It think its aesthetics.

Well, I don't disagree with you. Its your library and you can do with it what you want. I hope some new ideas do come from it and that I find something that makes my job easier. Maybe someday it will be like when I discovered the STL... that was a bumpy, revolutionary ride.

Best of luck!