Eleven days ago I set up a survey to help determine what the community thought the new version of FGL that Thomas Bereknyei and I are working on should be called. This post is about the results from this survey.
About the survey
People that took the survey were asked four things:
- What name did they prefer: “
fgl” or “
- Did they actually do any graph-related programming (not necessarily using FGL);
- Any other comments they might have had;
- Optionally, their name and email address.
Response to comments
Several people had some questions/comments regarding the survey both in the survey itself and on the Haskell Reddit. Here are some responses:
- Why is there only the option of “fgl” and “inductive-graphs”?
Because we couldn’t think of any better names. The former is what the library is already called, the latter describes exactly what the library is about (implementing and using graphs in an inductive fashion). Any other names such as “
boxes-and-arrows” are, we feel, rather silly and don’t make sense. We did ask, but didn’t hear any other names that were relevant.
- Why should you even consider using the name “fgl” if this is a new library?
I don’t want to go through the whole thing all over again, but I’ll summarise. This isn’t a completely new library; it’s just a new implementation (e.g. same as going from QuickCheck-1 to QuickCheck-2; the point of the library is the same, the concepts are the same, the implementation is different and the APIs are incompatible). As for the API incompatibility, that’s what version numbers are for.
- FGL is a silly name anyway/Acronyms are bad in a package name/The word “graph” should appear in the package name/etc.
Agreed. However, the package name “fgl” already exists, and I don’t believe in gratuitous proliferation of package names on Hackage as its hard enough to navigate as it is. Most people in the Haskell community already know that “fgl” is a graph library, etc. Also see the response to the previous question.
- You’re the maintainers; why are you bothering to even ask what the name should be?
Because when we announced our plans, there was a number of vocal people that complained about our “usurpation” (my word, not theirs) of the FGL name for our own library.
- Why are you planning on using the same module namespace as FGL even if you change the package name? Won’t that cause problems ala mtl and monads-fd?
Say what you like about the name of the package (I for one agree that it isn’t an ideal name, especially in the world of “modern” Haskell with Hackage, etc.), I think the module namespace is exactly right. And unless we decide to skip the “
Data” prefix and just have a stand-alone
Graph.*namespace, there isn’t a better namespace available for a package that defines and uses graphs in an inductive fashion. Again, this is a case of “You don’t like it? Fine: pick a better name and if it truly is better we’ll use it.”.
- If you have to change the API, please provide a compatibility API like Parsec-3 has for Parsec-2.
This isn’t going to happen for several reasons (and these are just the ones I could think of whilst writing this blog post):
- Even with the compatibility API, Parsec-3 was slow to be taken up. Admittedly, this was due to a performance regression, but it still doesn’t bode well for how well compatibility APIs fare.
- Parsec-3 could have a compatibility API because they defined a new module namespace for the new API; we don’t plan or want to do that.
- If we have a compatibility API now, we’ll be forced to keep using and maintaining it when we’d much prefer people to use the nice new shinier API instead.
- We plan on providing upgrade paths, such as versions of fgl in the
5.xseries that get closer and closer to the new API and various migration guides/tutorials.
- Most of the function and class names are going to be pretty similar specifically to make porting easier (because of this I’m even planning on using FGL-like terminology for my currently-still-vapourware generic graph library that will eventually provide super-classes for FGL, rather than the more correct graph-theory terminology; e.g.
We might have some compatibility APIs to help with the transition process (e.g. the
noNodesfunction is going to be replaced with
order, which is the proper terminology, but we might define
noNodesas an alias), but these will probably be in a different module and it will still not be possible to have code that will work with both the
5.xseries of FGL and the new library.
Here is the initial overall results from the survey:
- 66 people responded (Google Spreadsheets keeps lying to me and claiming 67, but it seems to be counting the header row as an actual response…).
- 27 (≈ 40.9%) people said they preferred “FGL”; the other 39 (≈59.1%) prefer “inductive-graphs”.
- 40 (≈ 60.6%) of the respondees said they wrote code dealing with graphs.
- There were 26 (≈ 39.4%) extra comments.
- Only 23 (≈ 34.8%) of respondees were brave enough to add their name to the response (and one of these was only a single name without an email address).
If we only consider the 40 people who claimed to write code dealing with graphs, only 16 (≈ 40%) of them preferred FGL; as such, actual usage of fgl or other graph libraries does not seem to change the overall opinion of the community (if my vague recollection of how to do statistics is correct, and this is indeed a representative sample of the community).
Other interesting tidbits
- Martin Erwig (i.e. he-who-wrote-the-original-version-of-FGL) says we should keep using the name “FGL”, laying to rest potential problems that some people have raised.
- Two people didn’t seem to get the point of the survey: one person indicated that they didn’t care, another made an unrelated comment regarding immature equines. However, they partially cancelled each other out: the former claimed to write graph code and voted for fgl, the latter said they didn’t write any graph code and voted for inductive-graphs.
In the raw
For those that want it, a sanitised (in that the email addresses and names have been removed) copy of the results is available (I would have hosted them on wordpress.com with the blog, but it doesn’t allow text files to be uploaded, and I don’t see the point of creating a full blown word processor document – since spreadsheets can’t be uploaded – just for some CSV data).
And so the decision is?
Well…. there isn’t one. A 60% preference is too close to even for me to categorically say that the Haskell community prefers one name over another. As such, unless someone presents a really good reason otherwise we’re going to stick with FGL (due to inertia if nothing else).
My take on all this
After all this debate, I’d like to point out that I’m more and more agreeing that “inductive-graphs” would make a much better library name. However, as I’ve stated previously (including above), I would prefer to use the “fgl” name somehow if nothing else because it’s already there (so a few years from now when – hopefully – the new graph libraries are available and widely used, we don’t have a useless library sitting around confusing people, especially when it used to be present in GHC’s extralibs and the Haskell Platform).
Yet Another Compromise Proposal (or two)
However, I just thought of two possible solutions which may be satisfactory to all involved:
What about if we call the library we’re working on “inductive-graphs”, but then create a meta-library called “FGL” that isn’t just limited to inductive graphs? That is, once I’ve worked out my generic graph API library, then we take a large subset of the modules defined in the libraries contained within this figure and re-export them from the FGL library. Such a library would be analogous to how the Haskell Platform is an initial starting point of the libraries available on Hackage: an all-in-one subset of the available graph libraries in one overall API if you don’t know which libraries to use specifically, and you can then pare down your dependencies to what you actually use.
Another alternative (which I find less attractive) is that we make the FGL library contain the generic graph API; this way the library still exists, but then it is completely different from the
5.x series. I’m mainly suggesting this just to provide another alternative; I don’t think it really makes sense or is viable.