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.
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.