Programming With Types, Not Tutorials

That's definitely how I felt while learning Haskell: Like putting together a jigsaw, which reveals itself when it's done, rather than the usual plumbing and hoping there are no leaks in the end!

Sadly, that nice glimpse doesn't really view that nicely. :(

It feels like someone showed me an image of a processor and said "see, you just have to line up the pins with where it goes." What could be simpler? If it doesn't fit the pins, it is the wrong processor.

> ... like putting together a puzzle

It's funny how lots of good formalisms, notations, and DSLs all achieve this quality in different ways.

In particular, this reminds me of the mathematics of tensors, or Bra-Ket notation in QM. Both of these systems use notation to give each piece of the puzzle a particular shape, so that if you know all of the pieces you can often see immediately how they should fit together.

This seems (to me) to be the most important part of designing an API, and the brilliant strength of a good type system is that you get this quality for free.

> This article gives a nice glimpse into the essence of why modern strong static type systems like Haskell's are such a huge win for development. The type system gives you a way to bound the number of things that you must understand about an API in order to use it. The confidence that we get from having these guarantees makes code reuse orders of magnitude easier in Haskell than it is in pretty much any other language in mainstream use today.

Nicely put. I think that's the clearest statement I've ever seen about why a powerful, expressive type system is a Good Thing.

Now, tell me how to get this point across to a programming-languages class for junior/senior C.S. majors, in at most a couple of days, starting 18 hours from now. ;-)

Learning functional programming is not trivial, especially if you come from the imperative paradigm. Haskell was my first language and I still struggled not to think procedurally in the beginning , and the type-checker refused almost all of my programs. But after a while you start to get less and less type errors, and soon types will be your friend and guide you when writing programs.

I have to say though; static types itself doesn't prevent bugs, they only prevent common errors. But if you got an expressive type system like Haskell (or OCaml etc.) you can write well-typed programs. A great example is Yesod[0], which is a web framework completely designed around being well-typed.

0. http://www.yesodweb.com/

EDIT: Okey, "well-typed" may not be the right term. TAPL calls every program that pass the type-checker well-typed so what I meant is programming written type-safe.

If you don't know functional programming, of course you won't be able to understand functional code at a glance. You wouldn't expect someone who doesn't know imperative programming to intuitively understand imperative code at a glance either. It's not opaque, it just requires learning.

Not being able to convert the code in your head into type-safe functioning code just means that you don't understand the code well enough yet. That's not a bad thing about you or about the language, it's just the state of things. Once you gain that understanding, you'll be able to write code that compiles, and you'll also discover that now the compiler is your best friend. Writing Haskell is extremely comforting to me, because I know that the compiler has my back. It's not a straightjacket, it's a guardrail alongside a mountain highway.

Think of how you looked at C++ code before you learned to program and you'll see the same phenomenon. Very little of your knowledge about imperative programming transfers over to Haskell so it's not surprising that you look at it and see gibberish. It's the same way many people can pick up Latin-derivative languages quickly after learning a few, but find that their knowledge doesn't transfer and struggle to learn Mandarin or Russian.

For what it's worth, my own experience has been that becoming fluent with the functional style makes the imperative style seem really bizarre. I've made multiple attempts to learn Go, but for the life of me I can't; it seems so byzantine and archaic, like a creaking, inconsistent Rube Goldberg machine. The feeling in functional languages that everything is an expression and evaluates to a value actually feels really liberating; everything can be thought of a series of transformations.

This is not meant to argue with you, merely to provide the viewpoint that imperative programming is yet another valid way of performing computation, not necessarily the _natural_ way.

The compiler is doing a lot of it for us.

> Thanks to GeneralizedNewtypeDeriving, I got the three instances I wanted for free via F.

A good bit of what you're seeing as "mechanical" is actually the simplicity achieved because Haskell is expressive enough to get very close to the abstractions that we really need. Haskell allows you to decompose problems in ways such that each step along the way is very simple and in many cases obviously correct.

Obligatory Hoare quote:

> There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.

Haskell is absolutely fantastic. In C, when I'm given only the prototype of a function like:

> int foo(int, int);

Even if you tell me it is referentially transparent, I have no idea what that bloody function really does.

But with HASKELL, with just the type signature you can write a program that does what you want even though you don't know what the components you used do! Mind/Blown.

My understanding is that Agda will do it for you. I think GHC is getting something similar with type holes, too.

It's a very good thing that when there's only one way to get the correct result, the compiler forbids everything else.

Would you prefer the compiler allow incorrect code?

A lot of intermediate Haskell material (and advanced Haskell material) is locked up in a series of papers. They're usually well-written, but the intermediate Haskell canon is not well-defined nor is it in a comfortable format; I often find that when I recommend a paper to someone they have a tendency to be turned away... even if it's a tutorial paper not so different from a blog post.

I started reading "Beginning Haskell". So far the most practical Haskell learning resource I've encountered. http://www.apress.com/9781430262503

There are some good beginner tutorials, but beyond that the documentation is absolutely terrible. The typical documentation for a Haskell library will be a page that lists all of the modules in the library with a link to a page for each module. The page for each module will be a list of functions in the module with a type signature, and if you are lucky a one sentence description of what the function does. There will not be a single explanation or example of how to actually use the library.

Part of the issue is the wide spectrum of code of Haskell that people write. Beginners to Haskell will write code that is very radically different from the code that more experienced programmers write. Not to say that code that one writes in the style of Learn-You-Haskell or Real-World-Haskell level is bad but there is a wide range of choices of how to write Haskell.

Haskell also tends to also have a wide gap between beginner material and advanced material and not a whole lot in between. Some beginners will often come and see advanced discussions about the lens library for instance and will assume that they need to learn the lens library in order to program in Haskell. This just leads to disaster since it's nearly impossible for beginners to decipher the type error messages that come out of it until they grok the type system at a more advanced level.

I enjoy http://book.realworldhaskell.org/

Part of the reason intermediate documentation is a bit lacking is the incredible usefulness of the #haskell freenode IRC channel. If you ever have any questions about haskell, feel free to drop by and ask. There's usually at least one person around who'll be willing to take the time to explain it in as much depth as you need.

Are you implying developers should know the inner details of every library used?

Realistically most devs read documentation or Google to get something done. They only dive into the library if the documentation is unclear or something is broken. Reading well written libraries is a good learning experience, but not a requisite to use one.

In Haskell a function's type signature is expressive enough to exist as rudimentary API documentation.

The library described in the article gives you a way to take an arbitrary data type, and treat its values as the primitive actions of an embedded domain-specific language (that's what singleton does), and then write interpreters for that language by saying how those primitives should be interpreted (which is what interpret does). All (or at least most of) the control structures for the language come for free, because there's an instance of Monad.

This tends to be quite helpful especially in the case where there are multiple interpretations you might be interested in. For example, a graphics library might provide an interpreter that executes drawing primitives using OpenGL to put stuff on the screen directly, as well as one which interprets the same data by manipulating arrays of pixels. Perhaps another could construct an SVG.

To do that, you'd provide a data type whose constructors would encode whatever drawing primitives your library supported, things like circles and lines and Bézier splines, and then use the interpret function to define each interpreter by supplying a function which takes a given primitive and says how to carry out whatever actions are needed to be taken to display or render it.

(Note: this example is likely a little simplistic, because most of the operations in a drawing library won't have return values, but this set-up allows for such things. You could also make a version where the things drawn also continuously produce values by reacting to user input, allowing for some sort of optional interactivity.)

You'd also likely define a bunch of user-facing versions of the primitives which would amount to singleton applied to each of the constructors of your data type, just for the sake of convenience and implementation-hiding.

Then you have a library where people can define complex drawings in terms of the primitives you provided, and supply any one of those to any one of the interpreters you defined in order to put it on the screen, or write it out to an SVG file, or whatever.

For no additional work, you get operations like

sequence :: [Drawing a] -> Drawing [a]

from the monad library, for taking a list of drawings and producing a drawing which carries them out in sequence (whatever you've decided that ought to mean via your interpretations, probably stacking them on top of each other), as well as many others.

A more interesting example (in that it would involve input as well as output) might be a library for coordinated communication of some sort over different types of underlying network protocols (necessitating different interpreters for the primitive communication operations). Again, you'd get lots of control structures for free, things like for-each loops, and ways to define new bits of a protocol by applying a function to the results of a bunch of smaller pieces of communication.

A simpler example would be a basic list operator, given a method you can guess what it does.

    [a] -> a

That takes a list (brackets denote a linked list) and returns a single item. There is a small list of things that this could be. It can't filter or order in any way, since there are no restrictions or functions provided, it can't aggregate for the same reason, that leaves either the first item or the last item.

[Yep head and last](http://www.haskell.org/hoogle/?hoogle=%5Ba%5D+-%3E+a)

Looking at that list we can see some other alternatives that I mentioned

    foldl1 :: (a -> a -> a) -> [a] -> a --Aggregation
    maximumBy :: (a -> a -> Ordering) -> [a] -> a --Ordering
    maximum :: Ord a => [a] -> a
    (!!) :: [a] -> Int -> a --Indexing
    sum :: Num a => [a] -> a --Aggregating
    product :: Num a => [a] -> a

And if followed along, you will notice all of his implementation points were straightforward.

Note that all of this assumes you have very well written APIs that follow this chain of logic, otherwise you can write things like this.

    second :: [a] -> a
    second _:i:_ = i

It compiles (or would with the default case added) but is rather odd and would throw off this line of reasoning. Similarly by abusing unsafe methods you can do crazy things.

I suppose it is a bit ironic that I chose to build a library that really does benefit from higher-level explanation.

That's what happens when you build software engineering tools - you have to convince programmers of their value, even if they see how to use them.

"I have no idea what the program presented is supposed to do, or what problem is being solved, despite knowing all the types being used."

This is an absolutely fair observation. The code being shown is basically chowells79's recreation of a library that I wrote about a year ago:

http://hackage.haskell.org/package/free-operational

Basically, it really only makes sense once you've studied and grasped the key ideas behind a handful of other things: (a) functors, applicatives and monads; (b) the `operational` monad (another library, which mine recreates and expands on); (c) free monads (yet another library).

If you look at the link above, you'll note that I've chosen to follow the opposite approach—I provide links to other sources that provide the background context for what the library is doing. Elsewhere in the documentation I provide extended (but toy) examples of how to use it, of which I'd highlight the one in here:

http://hackage.haskell.org/package/free-operational-0.5.0.0/...

That page's example demonstrates a toy implementation of parser combinators and three different ways of using it: (a) parsing strings, (b) enumerating the strings that a parser accepts, and (c) optimizing parsers by merging paths with common prefixes.

So basically, the library is a kind of interpreter construction toolkit. A very abstract one...

It takes time man. Understanding is a process. You have to start somewhere. Good for him, it was all greek to me.

That's why I was very precise in my statement.

    The great thing about Haskell is that for many purposes, you don't need to understand the math or have a tutorial to use a new library.

and

    But a complaint that you can't use most libraries because they involve math you don't understand and don't have any tutorials? That's one of the silliest things I've ever heard.

Note the word "library" in both of those. I was very precise. Library documentation isn't lacking the way some people complain loudly that it is.

I couldn't maintain or understand the low-level code Java depends on without great effort (I know I could if I devoted enough time, which I usually don't have). Same for low-level libraries for C or any other language.

I think the argument here is that -- given that there are no problems with the library; otherwise you're screwed in any language -- type information for Haskell libraries gives you more useful information than docs & tutorials for libraries in other languages.

The author repeatedly asserts that he is not scared of math, and would probably be able to understand the libraries he uses if he spent the time. It's just that he doesn't need to.

Where are you seeing any discrepancies from camelCase? The only thing I see is that types and constructors (i.e. Functor/Applicative/F) start with capital letters.

Also, to be frank, many languages give a false sense of knowledge portability. "As a long time programmer" may not carry you so far into Haskell (or Prolog, or Forth) unless you've seen something else in their paradigms.

Functor, Applicative, F and liftF are not reserved terms. What makes you think so?

They are user defined (or in this case, library defined).

> I skimmed it, tried to read it, and still have no idea what the person was even trying to do.

The fact that you haven't learned enough Haskell to understand the article after skimming it doesn't make Haskell problematic.

Exactly! Syntax matters!

Haskell's syntax is radically different because it matters that it is. It's not different to obfuscate or be obstructionist.

It's different because it's better, for the features of the language. Function application via whitespace is a key feature to make automatic currying pleasant. Automatic currying is a key feature to make partial application pleasant. The patterns continue.

Haskell's syntax wasn't chosen by throwing darts at a dartboard. It wasn't chosen to upset C programmers. It was chosen to optimize simplicity and clarity of code that uses the language.

It missed the mark occasionally, but overall it did a good job. Syntax does matter, and Haskell is proof that using higher levels of abstraction benefits greatly from syntax that encourages it.