Hacker News Reader

Comment by weeksie | Hacker News Reader

Ah, a Haskell circle-jerk waiting to happen and a confession that's really a way to act superior about Haskell's type system. Listen, it's a great language and I've spent a few years deep in it, but I find this post arrogant and not even accurate.

The libraries he is talking about are for data types, something that the type system (almost by definition) is perfectly adequate for testing. So yes, he's tested it by compiling it. But for any real world Haskell program the type system alone is not enough.

View on HN

Wow, you are quick to accuse the community of being a "circle-jerk" even before most people commented. Looking through the other comments on this thread, most are either against the practice or qualify it. And the qualification is completely reasonable--given sufficiently general types, the space of possible implementations becomes very small which means you are increasingly likely to be correct just if your code typechecks.

The article never claims you can always use the type system in place of tests. It doesn't even claim that it is a reasonable practice. The only thing it says is that the author did rely on the type system and that he thinks it is reasonable given sufficiently polymorphic types.

In short, you're knocking down a straw man and using it to accuse the entire community of being an arroganet circle-jerk.

I think your reply is inappropriately negative ("circle-jerk", "real world"), and that the negatively of your post detracts from what value might be derived from the article.

The author of the post provided an amusing example of a case where he posits the type system is sufficient and valuable. He didn't claim that the type system would be sufficient for a complete real-world application.

Well, I guess I'm just old enough and ugly enough to call things like I see them. Haskell is a neat language, but it is frustrating to listen to these sorts of brag-posts about the language because they're filled with dangerous hubris. The type system is amazing for certain kinds of problems. Hey, if you're writing a compiler then Haskell is probably the best language out there. Or in memory data structures. Hm. Or parsers. . . . It's a great language for CS research.

The term "real world" is not meant to slur, it's meant to be accurate. I've shipped code written in Haskell and I deeply understand the huge pain in the arse it is to use in production for applications that are not toys.

Can you share some examples where you've found it to be a huge pain in the arse to use in production?

"Dangerous hubris" is an extremely condescending phrase. Do you think the author does not realize that the type system is only sufficient in certain, very specific cases? That's exactly what he mentions at the very end--the reason he trusted the type system so much is only because he believes there is only one non-trivial, non-recursive implementation with the requisite types. He qualifies exactly what he means and, moreover, does not even defend his behavior. And that is "dangerous hubris"?

Also, there is certainly plenty of real-world code I would not like to write with Haskell--drivers, for example. However, it seems great for web-apps, which are very "real world" and, naturally, very important on HN.

In my personal experience, it's also surprisingly good for quick command-line scripts in place of Bash or Perl. Writing small scripts for automation and command-line clients for my existing tools was as easy or easier in Haskell than in any other language I've used.

Sorry to burst your bubble, but I wonder if your experience is clouded by the (past) inadequacy of your skill set and learning level. We use Haskell in production across a number of domains and it has produced solid results. So do a number of other very serious companies out there (as an example, most banks have varying degrees of Haskell in production for critical systems).

Also, how are parsers or in-memory data structures NOT real-world tasks? You never had to parse some bit-stream or stage a sophisticated-enough computation pipeline that required lots of different, intermediate data types?

I'm not sure why you're seemingly dying to make negative blanket statements based on how "it was a pain in the arse" for YOU.

I don't think you realize just how condescending and full of arrogance your posts are.

You are implying that computer science is both useless and only consists of implementing toys. What makes your problems "real world" and the problems that haskell is good for not "real world"? What makes something "not a toy"? Parsers and compilers are toys?

If you want to start a discussion about things that make haskell difficult to work with on a daily basis, please do so. Otherwise, kindly stop throwing around insults.

>I've shipped code written in Haskell and I deeply understand the huge pain in the arse it is to use in production for applications that are not toys.

And yet plenty of people (myself included) are using haskell for real world, production, non-toy applications all the time. So either all of us people using it are mentally ill and just imagining up non-existent production haskell code, or your experience reflects your ability, not the language's capabilities.

If you're using the term “real world”, it is extremely unlikely---like sha1 hash collision unlikely---that you are being accurate. In all cases where I can remember its being used, it's being used as a way to avoid a concrete and accurate description of fact, and to add a touch of disdain for something else.

> not even accurate.

What is not accurate in that post?

I explained that in the second paragraph.

The author didn't claim that the system is alone sufficient "for any real world Haskell program", so your refutation appears rather spurious.

I explained that he _did_ test the program because he was writing a type. The type system by definition checks types.

I see what you mean, but it's rather bizzare to classify type checking as a form of testing, even if type system is very strong. Types and tests are different ways of specifying behaviour: tests are existential guarantees (output of the code sometimes has some properties), types are universal guarantees (output of the code always has some properties).

In an ideal world, tests would be subsumed by types, but in reality tests can cover things that types do not.

> In an ideal world, tests would be subsumed by types

It would be literally impossible for this to happen in a Turing-complete language, though, because a hypothetical 'perfect' type system would be able to solve the halting problem.

The Haskell 'Bottom' type alludes to this in its documentation, actually: http://www.haskell.org/haskellwiki/Bottom

(Essentially, Bottom is a member of every type, or else the compiler would need to distinguish between a halting program and a non-halting program before accepting the input program).

Some people argue that in an ideal world we wouldn't be using Turing-complete languages. Nothing like a total functional programming language to make life better :).

Some people argue that totality isn't enough, you really want a feasible (polytime) language.

http://www.di.unito.it/˜gaboardi/papers/BaillotGaboardiMogbi...

;-)

I thought about total functional programming, like Agda. But even if you have Turing completeness, you can add time constraints to tests and everything will be decidable.

Reply on news.ycombinator.com