5 ms·

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

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. All this reminds me of a comment made by a friend of mine awhile back when he was learning Haskell. He said that programming in Haskell feels less like programming and more like putting together a puzzle. I think this article very nicely captures what he was getting at.

Xophmeister 13y ago
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!
taeric 13y ago
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.
- chowells 13y ago
  To be fair, I was starting from approximately "here is where the pins go" in the types I wanted, and "here is how the pins are arranged" in the form of the libraries that could solve it. The complaint I was addressing was that math-heavy libraries that lack tutorials are nearly impossible to use. I provided a constructive proof that it's not hard at all, if you understand the type system.
  - taeric 13y ago
    I didn't mean this so much as a critique of your post. I do believe it serves its target well. I just get annoyed with attempts to elevate it to "a huge win for development." Indeed looking back, I think I picked the wrong analogy. Your post seems to be saying that "without directions on how to put it together, if you know what all the parts of a bike do, you can figure out how to assemble it yourself." There is certainly a fair bit of truth to this. However, this seems to belie a high level of understanding for all for the parts. At least if you hope for a speedy and correct assembly.
    - nbouscal 13y ago
      I think the better analogy is: all the parts are brightly colored, and if you try to put a red part in a blue hole the compiler won't let you. Okay I guess that's not really an analogy anymore, but, you get the point.
      - taeric 13y ago
        Same basic analogy, though. If the parts come such that they only fit together one way, then finding how to get them together can be deduced by looking at them. Falls flat when either a) you don't fully understand the parts or b) you are wanting to try a combination not strictly accounted for in the designing of the existing parts. Problem A is straight forward. Having an in depth knowledge of the "types" in a system has clear benefits. However, not really understanding the types is doable, provided you are strictly in the "assembly" phase of development. I believe that is what this post was about. Problem B is the killer to me. Often "combinations not accounted for" include partial combinations. It is not unreasonable to want to make sure the wheels of a bike spin with the chain before the pedals are placed.
        nbouscal 13y ago
        Have you played with Haskell at all? Partial combinations aren't a problem. Partial application is extremely well-supported. The goal of a type system is that the only combinations that don't work are broken combinations. Haskell isn't all the way there yet (imho dependent types will be necessary), but it's very close, and more than close enough for 99.9% of real work. Completely agree on your assessment of problem A, and that that's what this post is about. Learning the actual math behind the constructions is definitely beneficial, but for people who don't have the time or inclination to do that, this post demonstrates that they can still get enough of the benefits to be productive.
siddboots 13y ago
> ... 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.
- eru 13y ago
  > [...] get this quality for free. Let's say, for much cheaper. Designing a good API in Haskell still requires work---but it's arguably easier to get right than in most other languages.
ggchappell 13y ago
> 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. ;-)

Xophmeister 13y ago

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!

taeric 13y ago

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.

chowells 13y ago
To be fair, I was starting from approximately "here is where the pins go" in the types I wanted, and "here is how the pins are arranged" in the form of the libraries that could solve it. The complaint I was addressing was that math-heavy libraries that lack tutorials are nearly impossible to use. I provided a constructive proof that it's not hard at all, if you understand the type system.
- taeric 13y ago
  I didn't mean this so much as a critique of your post. I do believe it serves its target well. I just get annoyed with attempts to elevate it to "a huge win for development." Indeed looking back, I think I picked the wrong analogy. Your post seems to be saying that "without directions on how to put it together, if you know what all the parts of a bike do, you can figure out how to assemble it yourself." There is certainly a fair bit of truth to this. However, this seems to belie a high level of understanding for all for the parts. At least if you hope for a speedy and correct assembly.
  - nbouscal 13y ago
    I think the better analogy is: all the parts are brightly colored, and if you try to put a red part in a blue hole the compiler won't let you. Okay I guess that's not really an analogy anymore, but, you get the point.
    - taeric 13y ago
      Same basic analogy, though. If the parts come such that they only fit together one way, then finding how to get them together can be deduced by looking at them. Falls flat when either a) you don't fully understand the parts or b) you are wanting to try a combination not strictly accounted for in the designing of the existing parts. Problem A is straight forward. Having an in depth knowledge of the "types" in a system has clear benefits. However, not really understanding the types is doable, provided you are strictly in the "assembly" phase of development. I believe that is what this post was about. Problem B is the killer to me. Often "combinations not accounted for" include partial combinations. It is not unreasonable to want to make sure the wheels of a bike spin with the chain before the pedals are placed.
      - nbouscal 13y ago
        Have you played with Haskell at all? Partial combinations aren't a problem. Partial application is extremely well-supported. The goal of a type system is that the only combinations that don't work are broken combinations. Haskell isn't all the way there yet (imho dependent types will be necessary), but it's very close, and more than close enough for 99.9% of real work. Completely agree on your assessment of problem A, and that that's what this post is about. Learning the actual math behind the constructions is definitely beneficial, but for people who don't have the time or inclination to do that, this post demonstrates that they can still get enough of the benefits to be productive.

siddboots 13y ago

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

eru 13y ago
> [...] get this quality for free. Let's say, for much cheaper. Designing a good API in Haskell still requires work---but it's arguably easier to get right than in most other languages.

ggchappell 13y ago

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