Hacker News Reader

Comment by mightybyte | Hacker News Reader

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.

View on HN

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

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

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

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.

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.

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.

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.

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.

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.

I confused things by using terminology here. I did not mean partial as in "partial application." I mean partial as in "isn't fully built."

Consider, a bike that doesn't have pedals or even all spokes is a broken combination. You can still spin the parts that are assembled and see what will happen, though.

So, unless I am wrong on this, point B is still troublesome to me.

There is also a concern on whether the "assembly" phase is where time is best saved. How much more effort did it take for some elements so that they would have these "easily assembled" types?

The assembly optimizations come for free, in a sense, because what is really being optimized with the extra work is composability. Assembly time isn't all that important, but composability is absolutely essential.

Regarding things that aren't fully built, I really would need an example to be able to comment. I think the analogy has reached the limit of its usefulness :)

I think my point is best summed up by saying that I can still run a project that has failing unit tests. To my knowledge, I can not run a program that fails type checking.

The argument for this is typically "once it typechecks, it works." However, sometimes I can see enough from the output of a non-test passing piece of code to know whether the idea is even sound.

I think the only reason you think not being able to run a program that doesn't type check is a problem is because you are used to a workflow in which running a program is how you test your ideas. The workflow used to explore ideas while programming in a strongly typed language is of course very different. Personally I think it's a lot better, but that's just opinion.

That is an amusing personal attack. :)

I test my ideas by executing them, yes. Are you truly claiming that you have all of your ideas completely fleshed out before you test any of them?

That sounds incredibly impressive, if so. Can it be done in some cases? Almost certainly. I question whether it can in all, though. Even most.

You don't have to have them completely fleshed out. But you do have to have them fleshed out to the type level. The Haskell compiler can be an invaluable aid in fleshing out the design of problems. Especially when they are complex difficult to wrap your head around.

Certainly wasn't intended to be a personal attack. I'm not claiming that I don't test my ideas, I'm claiming that I do so in a different way. Rather than testing ideas by running the program, I test my ideas by type checking it.

Most of my ideas I first test by a simple sketch of boxes up on a whiteboard. Going from there to some toy code to try out what I suspect are the tough parts of those boxes.

I realize with liberal use of undefined, I can get something similar in Haskel. So, I am not trying to claim in precludes this behavior. Just claiming that it is a rather drastic change to the flow many people are used to.

And really, I don't like claiming many people are used to this. As, I can really only speak for myself.

I don't think they're quite as different as you think, but, it sounds like we agree. Two different ways of doing the same thing. To me, being different from what most people in software engineering are used to really doesn't sound so bad, judging from our industry's track record.

Oh, I definitely agree with that. And don't get me wrong, I actually want to learn and use Haskel somewhere.

I just get wary whenever I see the conversation leaning towards indications that it is a clear win. Seems like it is a qualified win.

Too many of the stories read more like your typical "developer learns new way of thinking, becomes better for it."

Which is ultimately what makes it so frustrating. When someone learns lisp and becomes a better programmer. There isn't much for them to say, other than "learning to think the lisp way has helped me be a better coder."

There are those that get hung up on the metaprograming of lisp. Which is amazing. But, for the most part you can do that elsewhere now. The only thing left is it really is a frame of thinking.

Contrast this with Haskel. Few stories focus on how it helped them see a more comprehensive view of types. Instead, the talk turns to how Haskel is a saving grace that the unwashed masses just isn't used to.

> To my knowledge, I can not run a program that fails type checking.

GHC added support for that. (They jokingly called it Python-mode.) See https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime

Wow, missed this post. Will have to look into that. Very curious how that works. Thanks!

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!

Reply on news.ycombinator.com