Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Praise of Haskell

drdobbs.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: In Praise of Haskell

#41

Post by MedDev »

cgh wrote: post #35
platz wrote: post #31

Earlier quoted context omitted.

But is there also some selection bias at play here? Typically you don't see a lot of GUI programs or games written in pure FP; so far, I haven't been reading much that exols the virtues of FP in those domains. http://prog21.dadgum.com/138.html "If you want to be on the cutting edge of functional programming research, it's easy. Pick something that looks like a poor match for state-free code, like a video game, and st…

No, you can just watch this talk by John Carmack as he extols the virtues of Haskell for game programming: http://functionaltalks.org/2013/08/26/john-carmack-thoughts-...

The problem I have with this is Carmack is in the top 0.01% of developers so of course writing a game in Haskell is going to be within his grasp. For the rest of us it's a huge exercise in mental gymnastics. I've written a few visualizations for data using Gloss (http://gloss.ouroborus.net/) with Haskell and although it does "just work" when it does compile understanding how to manage state in a pure environment is an uphill learning experience to say the least.

Re: In Praise of Haskell

#42

Post by taeric »

nightski wrote: post #32
taeric wrote: post #15

Earlier quoted context omitted.

Is it irony that the post right below this is complaining about Cabal and "dependency hell?"

No because that dependency hell is up front (Haskell ecosystem likes being explicit). Whereas in dynamic languages you just install it all and hope it doesn't crash (and your unit test coverage is sufficient).

Firstly, I think this is somewhat unfair to dynamic solutions. I could just as easily reword it as "you try and pull in a library and hope it doesn't break your compilation." Simply put, it could be the up front hell that probably puts a lot of people off of a solution.

Not to mention adding a new piece to a highly type based solution could involve modifying a lot of the existing types to make room for the modification. Whereas with many dynamic solutions, this is not the case.

Re: In Praise of Haskell

#43

Post by taeric »

platz wrote: post #29
taeric wrote: post #15

Earlier quoted context omitted.

Is it irony that the post right below this is complaining about Cabal and "dependency hell?"

I think the package system needs work, yes, but I'm not sure this is the fault of "Haskell the Language". Although I've read some blogs that complained that ML gets this right, and Haskell makes it harder with it's typeclasses

I think for a lot of folks, the differences between languages and the surrounding toolset is very diminished. That is, there seems little gain in making this distinction.

Re: In Praise of Haskell

#44

Post by cschneid »

zwieback wrote: post #23
iamdev wrote: post #16

Earlier quoted context omitted.

As someone who has been curious about Haskell, I'm happy to hear someone else say this. The way this article was written feels exactly like the "ruby fever" of 5 years ago.

Or all the other fevers we've suffered through. Haskell seems like an attractive language but I wish boosters wouldn't advocate their languages as the fix to the problems of large-scale software engineering issues when there's little or no evidence for their claims.

There was a cool talk on "The Haskell Chat" episode two [1] that goes over how haskell is used in a large team, some members with expert haskell knowledge, some as just technical end-users of the libraries.

I found it really interesting to see how a large team can deal with a real haskell project.

[1]: http://www.haskellcast.com/episode/002-don-stewart-on-real-w...

Re: In Praise of Haskell

#45

Post by tmhedberg »

jroesch wrote: post #37
tmhedberg wrote: post #27

Earlier quoted context omitted.

While I fully agree that pure code is far easier to maintain than impure code, and the advantages of Haskell are numerous, I think it is a bit strong to state that such claims are backed up by mathematical proofs. Ease of maintenance is a fundamentally subjective claim that cannot be proven, but must be borne out by individual experience (as it has been for you, me, and many others).

It is not a "strong" statement to say that some Haskell code is backed by proofs. There is Wadler's Theorems for free![1] which allows one to reason about pure function's behavior purely from type signatures. As well GHC supports various features that enables one to encode some dependent typing[2] constructs. Allowing the type of value to to depend on the value itself. A common example being a list that can expresses…

I'm aware of dependent types and, more generally, the strong undercurrent of emphasis on provable correctness in the Haskell community at large. I don't disagree at all with what you wrote, but it's not what I was referring to with my comment.

My disagreement was specifically with the implied claim that it can be mathematically proven that Haskell code is easier to maintain than code written in other languages. That has indeed been my experience with Haskell, but I do not think it is directly provable. What seems easy for me may be stupefyingly difficult or confusing for someone else.

"How easy something is" is not really a quantifiable measurement; it is a subjective experience. As chongli points out, however, there are related measurements that can be taken, such as cyclomatic complexity, and those at least seem to be correlated with ease of maintenance. So perhaps I'm just being overly pedantic!

Re: In Praise of Haskell

#46

Post by chongli »

otikik wrote: post #5
clux wrote: post #2

What's not to like? Cabal, which unsurprisingly is not mentioned. Dependency hell makes it stupidly difficult to rely on other people's code on a large scale. I'd rather write uglier code in JavaScript if it means having access to other people's packages immediately and without complications.

Also, after a week I still didn't understand its type system completely. It may be that I am simply too dumb, or that I didn't find the right resources, but 'easy to learn' this language is not.

Rome wasn't built in a day! Learning a new language in a week is not an easy thing to do. The reason other languages seem a lot easier to learn (Python, Ruby, etc.) is that those languages are all fundamentally similar to one another; Haskell is not.

Re: In Praise of Haskell

#47

Post by bunderbunder »

chongli wrote: post #30
tmhedberg wrote: post #27

Earlier quoted context omitted.

While I fully agree that pure code is far easier to maintain than impure code, and the advantages of Haskell are numerous, I think it is a bit strong to state that such claims are backed up by mathematical proofs. Ease of maintenance is a fundamentally subjective claim that cannot be proven, but must be borne out by individual experience (as it has been for you, me, and many others).

Ease of maintenance is a fundamentally subjective claim that cannot be proven, but must be borne out by individual experience (as it has been for you, me, and many others). I disagree. You can make objective measurements of maintainability. You can look at cyclomatic complexity and reusability (both wins for pure functions). You can test how often changes lead to bugs and how often the errors are caught. There are ma…

> You can look at cyclomatic complexity and reusability (both wins for pure functions).

Yes, those are both wins for pure functions. But even there you need an asterisk, because side effects do have their place - the fact of the matter is, the primary task of most real-world software can be summed up as "manipulating mutable state". In light of that I don't think you can necessarily jump from the observation that there are many situations where pure functions are easier to work with than impure ones to the conclusion that pure functions are inherently more maintainable.

But even if that were granted for the sake of argument, it's not much of a win for Haskell. The ability to create pure functions is a feature of every language that has been invented during the lifetime of probably every person reading this post, and therefore not really a differentiating feature of Haskell.

Nor is lack of ability to create impure functions a feature that can be claimed of Haskell, because that simply isn't true. Haskell's real differentiator in that department is just that you've got to jump through hoops to do it. And if your business rules are inherently impure, then it's not clear to me how a language that tries to ghettoize impurity makes them easier to implement.

Re: In Praise of Haskell

#48

Post by thinkpad20 »

otikik wrote: post #5
clux wrote: post #2

What's not to like? Cabal, which unsurprisingly is not mentioned. Dependency hell makes it stupidly difficult to rely on other people's code on a large scale. I'd rather write uglier code in JavaScript if it means having access to other people's packages immediately and without complications.

Also, after a week I still didn't understand its type system completely. It may be that I am simply too dumb, or that I didn't find the right resources, but 'easy to learn' this language is not.

Haskell is really not much more strongly typed than Java, or even C++ (although it's much less liberal with letting you cast than either of those languages). Just like those languages, if a function has been declared to use types a, b and c, then you'd better supply types a, b, and c as arguments. This is the same. The only real extension that I can see is the ability to create functions which accept or return arbitrary types, like `foo :: a -> [a]`, which isn't an option in Java or C++ without some hackery. Of course there are type classes and algebraic data types and other things as well, but I don't think they really make the language "more strongly typed," just more expressive in their types.

What makes Haskell a little challenging in the beginning is its currying, which means you don't need to call a function with all of its stated arguments, and the fact that function application associates to the left; i.e. that `f x y` is the same as `(f x) y`, NOT `f (x y)`, which is closer to how it would be in, say, Ruby or CoffeeScript. There are very good reasons for this, but it does take some getting used to. Currying and associativity rules are responsible for a lot of seemingly incomprehensible type errors. You get better at avoiding them as time goes on. I feel that the weirdness of reading Haskell DSLs, like Parsec, which often make heavy use of customized operators, or do-notation, is an extension of these issues, since most of the difficulty comes from trying to figure out how the types propagate through what amounts to be long, complicated chains of function applications.

Re: In Praise of Haskell

#49

Post by [deleted] »

taeric wrote: post #42
nightski wrote: post #32

Earlier quoted context omitted.

No because that dependency hell is up front (Haskell ecosystem likes being explicit). Whereas in dynamic languages you just install it all and hope it doesn't crash (and your unit test coverage is sufficient).

Firstly, I think this is somewhat unfair to dynamic solutions. I could just as easily reword it as "you try and pull in a library and hope it doesn't break your compilation." Simply put, it could be the up front hell that probably puts a lot of people off of a solution. Not to mention adding a new piece to a highly type based solution could involve modifying a lot of the existing types to make room for the modificati…

[deleted]

Re: In Praise of Haskell

#50

Post by nightski »

taeric wrote: post #42
nightski wrote: post #32

Earlier quoted context omitted.

No because that dependency hell is up front (Haskell ecosystem likes being explicit). Whereas in dynamic languages you just install it all and hope it doesn't crash (and your unit test coverage is sufficient).

Firstly, I think this is somewhat unfair to dynamic solutions. I could just as easily reword it as "you try and pull in a library and hope it doesn't break your compilation." Simply put, it could be the up front hell that probably puts a lot of people off of a solution. Not to mention adding a new piece to a highly type based solution could involve modifying a lot of the existing types to make room for the modificati…

It is more of a contract. The library author is stating this package was developed against these dependencies and versions. It is known to work well in these cases.

This does not mean it will not compile. In fact often the fix is simply for the author or developer to relax the version bounds and everything will be fine.

Lastly, many of these issues arise not because of a direct dependency but an indirect one. The problem is that GHC will not allow you to depend on two packages which themselves depend on different versions of the same package. Once this is fixed, along with sandboxing, will eliminate the vast majority of the cabal hell problem.

Post reply on HN