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

31–40 of 64 posts

Re: In Praise of Haskell

#31

Post by platz »

DanielBMarkham wrote: post #9

One important thing in the article that was a bit obfuscated: modern OOP languages introduce a staggering amount of dependency and complexity. Things like TDD are then layered on top to try to ensure solid code is being built. In a pure functional environment, you don't have those dependency issues. Your problems boil down to types -- do you have the correct fields and definitions in your inputs? -- and transforms --…

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 start working on it."

Will I have to write a FP "white paper" to make a game in FP?

Re: In Praise of Haskell

#32

Post by nightski »

taeric wrote: post #15
DanielBMarkham wrote: post #9

One important thing in the article that was a bit obfuscated: modern OOP languages introduce a staggering amount of dependency and complexity. Things like TDD are then layered on top to try to ensure solid code is being built. In a pure functional environment, you don't have those dependency issues. Your problems boil down to types -- do you have the correct fields and definitions in your inputs? -- and transforms --…

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

Re: In Praise of Haskell

#33

Post by cgh »

nahiluhmot wrote: post #18
iamdev wrote: post #13

Earlier quoted context omitted.

Thanks for pointing that out. The author didn't emphasize that point, and it makes sense now. Is it me, or was it a bad example for where Haskell "really shines"? I don't like the "use Haskell cause it has these really cool functions" approach. Feels so superficial.

It wasn't so much a bad example so much as it was a trivial one. Perhaps a more powerful one (that displays the advantages of lazy evaluation and higher-order functions) would be the function to generate an infinite list of Fibonacci numbers. fibs :: [Integer] fibs = 0 : 1 : zipWith (+) fibs (tail fibs) Even still, it's difficult to get the feel of actually using the language from one function taken from a freshman y…

How about demonstrating the power of laziness by generating the power set of a set? (Taken from Learn You a Haskell).

  powerset :: [a] -> [[a]]  
  powerset xs = filterM (\x -> [True, False]) xs  

  ghci> powerset [1,2,3]  
  [[1,2,3],[1,2],[1,3],[1],[2,3],[2],[3],[]]
Edit: I read LYaH some time ago but this example stuck with me because it's both wonderful and mind-blowing.

Re: In Praise of Haskell

#34

Post by chongli »

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.

Well, the problem with this is that the evidence is locked up in company trade secrets. A lot of the big commercial users of Haskell are in finance and all their code is under lock and key.

Re: In Praise of Haskell

#35

Post by cgh »

platz wrote: post #31
DanielBMarkham wrote: post #9

One important thing in the article that was a bit obfuscated: modern OOP languages introduce a staggering amount of dependency and complexity. Things like TDD are then layered on top to try to ensure solid code is being built. In a pure functional environment, you don't have those dependency issues. Your problems boil down to types -- do you have the correct fields and definitions in your inputs? -- and transforms --…

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

Re: In Praise of Haskell

#36

Post by tieTYT »

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.

The problem is you only waited a week. Haskell is so different from the most popular languages you should approach it like you're learning programming for the first time.

Re: In Praise of Haskell

#37

Post by jroesch »

tmhedberg wrote: post #27
chongli wrote: post #24

Earlier quoted context omitted.

"ruby fever" of 5 years ago The difference is that Haskell is a very principled language. All of the claims and excitement are actually backed up by mathematical proofs. Pure functions really do make your code easier to maintain. And no, it's not the case that Haskell is the only language which allows you to write pure functions. People who try to claim that are being silly and dishonest. Haskell's advantage is that…

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 whether it is empty or not in its type. These types allow one to write functions with signatures like: `safeHead :: SafeList a NonEmpty -> a`. Uses of this function will fail to compile if I can not prove that my list will always be non-empty.

Combine this with the well known Curry-Howard Correspondence [3] which shows that types have a direct correspondence to proofs. The logical extension of this is computer theorem proving languages like Coq, Agda, Epigram, Idris.

For example Coq[4] uses a dependently typed lambda calculus as its proof term language, and sees wide spread use in the formal verification of software. It is not a stretch to say that less powerful types systems like Haskell's allow us to encode some forms of proof. If you view the type checker as an proof checker, one provides propositions to it (in the form of types) and then supplies proof (in the form of terms). These can be trivial propositions like `a :: Int`, which in Haskell there are 2^31 correct answers.

[1] (http://ttic.uchicago.edu/~dreyer/course/papers/wadler.pdf)

[2] (http://en.wikipedia.org/wiki/Dependent_type)

[3] (http://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspond...)

[4] (http://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspond...)

Re: In Praise of Haskell

#38

Post by scarmig »

cia_plant wrote: post #25
skwirl wrote: post #6

This is yet another shallow puff piece on Haskell. Reading it, you would think that the author has only ever used Ruby and Haskell, as he gives the impression Haskell is the only language that supports functional/declarative style programming. In actuality the author is trying to sell Haskell because he sells Haskell IDEs. I'm not knocking Haskell, but let's not pretend that this is a useful piece of journalism.

Yeah, definitely just more propaganda from "Big Haskell IDE".

There's no threat more pernicious to America. Soon we'll have an Haskell IDE individual mandate and from there it's just a slippery slope.

Re: In Praise of Haskell

#39

Post by agentultra »

chongli wrote: post #24
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.

"ruby fever" of 5 years ago The difference is that Haskell is a very principled language. All of the claims and excitement are actually backed up by mathematical proofs. Pure functions really do make your code easier to maintain. And no, it's not the case that Haskell is the only language which allows you to write pure functions. People who try to claim that are being silly and dishonest. Haskell's advantage is that…

If by mathematical proofs you mean a dense, tangled run-time written in C that is statically linked into every executable then I think I understand where you're coming from.

Re: In Praise of Haskell

#40

Post by implicit_cast »

iamdev wrote: post #13
freyrs3 wrote: post #4

Earlier quoted context omitted.

Haskell's version is type safe. PHP, not so much.

Thanks for pointing that out. The author didn't emphasize that point, and it makes sense now. Is it me, or was it a bad example for where Haskell "really shines"? I don't like the "use Haskell cause it has these really cool functions" approach. Feels so superficial.

It's not just you.

Haskell is worth the effort, but I don't think the article's author did a great job of articulating why.

Some things I've noticed:

Haskell does not automatically admit an extra "null" value to every type, so you can ordinarily ignore NullPointerExceptions and the like. When you do need a nullable bit of data, you have to do some extra work: You must rename the type from "Foo" to "Maybe Foo" and change all the callsites. These callsites must test for null and specify what happens. (there exists a non-terminating explode() function if you really want it) The build will fail until every last case is covered. This is great for reliability.

Most data in Haskell is immutable. This encourages good programming practice, sure, but it really pays off when you start writing parallel code. Parallel Haskell is by far the easiest way I know to write fast concurrent stuff. On that note, Haskell's concurrency primitives are very well-designed.

Haskell's solution to callback hell is more general and powerful than anything I know. The "do" block is really just super elegant syntax sugar for a CPS chain.

Our unit test suite does not intermittently fail. We restrict side effects such that our build will fail if a test tries to do non-faked I/O. It took a bit of effort to build, but normal use is effortless.

Post reply on HN