Implementing a BTree in Haskell with GADT's | Hacker News Reader

Implementing a BTree in Haskell with GADT's

matthew.brecknell.net

39 pointsbfly200010 comments

One thing I can't really get used to are those short, one-two character-long variables/symbols. For some deity sake, why Br and LF? Line Feed? In Binary Tree? T1, T2, T3? There is Fatboy on T3 in Supreme Commander, that's what I think of when I see this.

Is writing "Tree" that hard? I don't understand why should anyone burden himself with deciphering abbreviations when he can just write the full word.

>Is writing "Tree" that hard?

Not at all. Reading "Tree", on the other hand, is quite hard. Once you get used to Haskell, you can start seeing exactly what alot of things are just by looking at their definitions. This is possibly because the definitions are kept so small. Try listening to the reasoning he is using about the type system, and imagine what that would look like with full sized variable names.

Having said that, when you are making a public interface (or a name that will be used in many places), do please use descriptive names.

I strongly disagree. First, it's possible that reading "Tree" is harder than reading "T", but that doesn't mean that the time needed to understand an expression composed from Ts is shorter than the time to understand Trees. I think - I have no proof, but so you don't for the contrary claim - that the time needed to decipher the meaning of abbreviated variable is greater than short variables save.

As for the type system - I like it strong, static and abstract. It's true that defining GADT happens on a level so high, that some of the type parameters can stand for literally anything, and naming them something other than "a" or "x" or "o" would be silly. That doesn't mean that the type system makes you abbreviate every single name used in definitions. The same goes for overusing infix functions. In Haskell this seems to be a cultural thing: in OCaml, for example, while signatures are really terse, the types, types constructors, etc. are named (almost) always with full words. The same happens in Scheme, or more exactly in Typed Racket, where lack of syntactic support means that you need more letters to be able to easily decipher the meaning. In Erlang, where they use "success typing" as an add-on to the language, this too holds true.

There is that language, J - descendant of APL. I actually went and learned some of it. Now, J is a mathematical notation and while it is quite nice as far as array languages go, it is hardly the best general purpose language. Probably because it's a mathematical notation. Yet even in J, functions other than the core vocabulary are named with full words. Sometimes with a few words.

I have nothing against maths or Haskell. What I want to say is that over-shortening everything is a sign of elitist behavior, which is reinforced by the community, and which serves no useful purpose, and that there are communities gathered around Haskell alternatives which were able to mitigate this problem. As long as no one provides me with a proof that overusing shortened to 2 characters names is beneficial to the readers program understanding, I think I won't change my mind.

Most popular Haskell libraries use single-letter names internally for type and value variables, and then verbose, full names for Types and TypeConstructors. Don't get soured on Haskell just because of one presentation.

I was thinking about tutorials, books and examples, because that's what I had contact with. It may be unfair, but this is a language face to the world and how it's done will for the most part decide if people will adopt the language.

Haskell source, essentially, is mathematical notation. Haskell's definitions are mathematical formulas. If using verbose symbols for writing those had been better then, likely, mathematicians had adopted them already.

Actually, mathematicians have already adopted and abandoned verbose symbols.

Was this abandoning caused by the technology falling short, or for some other reasons? When did it happen? Would the mathematical notation evolve in the same direction if there were tools like Bret Victor suggests available? That's a very interesting question I don't see tackled at all.

You lot crack me up. I'm the author of the video, and it's clear to me that you didn't watch much of it. You'll find your Tree at 6.15. Indeed, the external interface of this whole thing consists of "Tree", "insert" and "delete". Is that clear enough for you?

And also bear in mind that this is a screencast, so you can't ask me to scroll around the code while I'm building it in front of you. You can either have descriptive identifiers, or you can have more than 10% of the implementation visible at a time. Not both. And frankly, it's my video, which I spent over 200 hours writing and producing, so I think I get to make that choice.

I indeed didn't watch the video, and the part I've seen I watched with audio muted. That's because I'm not that interested in Haskell and because I've built many BTrees in many different languages already. Because of this my comment was not aimed at you specifically, which I felt was clear in my first post.

I'm not criticizing your work, rather I point out a larger trend in one community. You should stop being that emotionally attached to your work, because there are people out there who will criticize your work directly. I'm not one of them, however.

I'm also not familiar with making screencasts, but I would suppose that there are some tools for displaying outline of the code. For example, the Speedbar extension for Emacs is able to outline the types, variables and function definitions declared in a module. Take a look here: http://cedet.sourceforge.net/speedbar-multi-2.jpg (the left-most one).

Anyway, I'm not in position to criticize your work, and I never did it. So please stop referring to me as "you lot" and save it for when (not if) it will be really necessary.

Reply on news.ycombinator.com