undefined | Better HN

0 pointsdoktrin11y ago0 comments

Thanks for your response. I'd like to dive a little deeper into the basis for these claims. My current stance is that there isn't sufficient reason to adopt Haskell for use in production.

> Write software faster with fewer bugs

Is there an evidentiary basis for the 'fewer bugs' claim? What type of software are people writing faster with Haskell?

>> easier to maintain down the road because the "mental model" is maintained in the types by the compiler

That seems fair.

>> it's more succinct, it's fast

In isolation, that's a bit hand wavy IMO.

>> some of the world's brightest computer scientists work on it

This is something I hear quite often from the Haskell community in particular. It may or may not be true, but it gets repeated far too often IMHO. It feels like a bit of an appeal to authority.

0 comments

eru11y ago

>> Write software faster with fewer bugs > Is there an evidentiary basis for the 'fewer bugs' claim? What type of software are people writing faster with Haskell?

http://donsbot.wordpress.com/2007/05/01/roll-your-own-window... and especially http://donsbot.wordpress.com/2007/05/17/roll-your-own-window... give a good introduction into the mindset behind programming in Haskell.

The latter focusses on zippers. Zippers solve the problem of having a connection and a `cursor' into that connection to mark one element--in the case of XMonad we mark the window that has focus.

In C you would probably solve this with an array and an int. Unfortunately, the compiler can't help ensure that your int always points into the array, and that deleting and inserting are doing the right thing. Zippers help here.

Ixiaus11y ago

Interesting you should ask for more verification of my claim to fewer bugs because I'm about to embark on using Haskell in the new startup I'm working for and they may require stronger reasoning than I have been providing.

I've been thinking about how to qualify the claim logically or maybe quantify it. Anywho, aside from that I can tell you that the vast majority of bugs I introduce into my Python code (or other languages) are caught by GHC - these are bugs that purely have to do with my inability to remember what something is or is doing, or fear of refactoring something, or some tangled mess of types that are harder to reason about in Python because they're in my head instead of encoded in Haskell.

I've discovered that when I've been able to compile my Haskell programs the bugs I find in them are usually business logic bugs now. Occasionally I'll make use of QuickCheck / HUnit for automated property testing and unit testing, and that will help catch those business logic bugs.

Very subjective and anecdotal but I can promise you that the experience is very real.

> In isolation, that's a bit hand wavy IMO.

Sure, but if you take into account Haskell's denotational semantics vs. other language's operational semantics it should be pretty clear that Haskell inherits Mathematic's idiom for succinct expression. That idiom also informed the language designers when building Haskell's grammar and syntax, it's very flexible and abstract - both in the essence of the language (it's semantics) and its modality.

When reading idiomatic Haskell, there's a lot of information packed into a line, conceptually and syntactically.

> This is something I hear quite often from the Haskell community...

Sure, it probably borders on it, but in many ways other language communities commit the bandwagon fallacy (Go is one) - so I think you can poke holes all over the place. The fact though that proof proving systems and dependently typed languages like Agda and Idris (which are the future and I think will supplant Haskell unless Haskell can evolve) are being written in Haskell which speaks to the level of intellect and forward thinking in the community.

j / k navigate · click thread line to collapse