Why Not Haskell? • Hacker News Board

Re: Why Not Haskell?

#41

Post by michaelochurch » Tue, Oct 18, 2011, 2:15 AM UTC

lurker17 wrote: post #11

michaelochurch wrote: post #3

Haskell is a hard language because (a) laziness is not intuitive, especially when space-performance matters (sadly, it does) and (b) pure functional programming is just not practical for most people. Like the OP said, it's awesome for brain-stretching, but not the easiest language to use. I started writing a game in Haskell and found that the scaffolding necessary to do randomness in the "right" way was just too pain…

Hmm, as long as you do randomness in the IO monad, it's not any harder to do random numbers than it is to print to the screen. http://hackage.haskell.org/packages/archive/random/1.0.0.2/d... getStdRandom :: (StdGen -> (a, StdGen)) -> IO aSource Uses the supplied function to get a value from the current global random generator, and updates the global generator with the new generator returned by the function. For examp…

This is a fair point, but I'd generally prefer not to use the IO monad to generate random numbers because it feels "wrong", just like using IORef for mutable data when there are more "right" types feels wrong. Strictly speaking, pseudo-randomness isn't doing IO unless the source of randomness is considered something to which one is I/Oing.

Re: Why Not Haskell?

#42

Post by gawi » Tue, Oct 18, 2011, 2:20 AM UTC

Agreed that Haskell might not be to perfect fit for most of the enterprise projects out there, BUT nevertheless it is worth learning and mastering. The perceived difficulty comes from decades of teaching of imperative programming. I'm myself the product of C/C++/Java and it's amazing how I've manage to deal with so many peculiarities of theses languages. After having learned Haskell, I realize that it's much more coherent than the vast majority of other programming languages (including the functional languages). I'm learning Scala today and frankly, Haskell is much simpler. It is just amazing what you can achieve with good abstractions (parallelism, performance, modularity).

You might be tempted to use it yet but I'd suggest you keep on eye on this language. The potential is great and Haskell is evolving quite fast.

Re: Why Not Haskell?

#43

Post by devs1010 » Tue, Oct 18, 2011, 2:28 AM UTC

bhurt wrote: post #16

I wished I lived in the authors world. A world where you don't have to maintain the code you wrote- or worse yet, someone else wrote. Where you could declare a program "done" and walk away and never have to revisit it. A world where "mostly works" is good enough- secure in the knowledge that you're not going to be rousted out bed at 2 in the morning on a weekend because some server in outer Mongolia hit that corner c…

agreed, maybe I haven't expanded my mind enough but once I started using a widely used language to program in (not saying which) where I can write relatively easily, scalable maintainable code, find plenty of work and pay the bills, my desire to experiment with other, more obscure languages has kind of fallen off, there has to be a reason why some languages are widely used and others aren't. No language is ever going to please everyone but thats how life is, you can't always change the world to suit your preferences

Re: Why Not Haskell?

#44

Post by uriel » Tue, Oct 18, 2011, 2:28 AM UTC

socratic wrote: post #9

If the question is, should we use Haskell to solve this problem, or should we use JavaScript, I can't imagine that the answer is often Haskell. (Maybe if the question is, should we use OCaml or should we use Haskell...) That said, what really came out of left field was the OP saying that he and his friends are more and more using Go. Is Go adoption happening? I'd love to have a systems programming language that isn't…

> Is Go adoption happening?

Slowly (not surprisingly giving the youth of the language), but it is happening, see: http://go-lang.cat-v.org/organizations-using-go

Re: Why Not Haskell?

#45

Post by aaronblohowiak » Tue, Oct 18, 2011, 2:33 AM UTC

radarsat1 wrote: post #25

I've been doing a whole lot of scientific Python lately, and every time I let my program run for like an hour only to crash on an array of the wrong dimensions, or pass in a scalar where an array is expected or vice versa, I swear and wish I was using a strongly typed language like Haskell. If only it had the same tools as SciPy I'd be all over doing my scientific work in Haskell. (Not to mention it would have faster…

save more intermediate values to disk so resuming upon failure is easier.

Re: Why Not Haskell?

#46

Post by uriel » Tue, Oct 18, 2011, 2:34 AM UTC

melling wrote: post #21

In the end the author seems to be using Go for a lot more development. Are people here finding it to be a good solution? It seems like it might be the language that could bridge the iOS and Android systems for app development.

For me Go has made programming enjoyable again.

Re: Why Not Haskell?

#47

Post by abi » Tue, Oct 18, 2011, 2:39 AM UTC

michaelochurch wrote: post #3

Haskell is a hard language because (a) laziness is not intuitive, especially when space-performance matters (sadly, it does) and (b) pure functional programming is just not practical for most people. Like the OP said, it's awesome for brain-stretching, but not the easiest language to use. I started writing a game in Haskell and found that the scaffolding necessary to do randomness in the "right" way was just too pain…

With regards to generating random numbers, the Foreign Function Interface is also really useful. Here's a one-line wrapper around random(3).

  foreign import ccall "stdlib.h random" c_rand :: CDouble -> CLong

Re: Why Not Haskell?

#48

Post by TheEzEzz » Tue, Oct 18, 2011, 3:19 AM UTC

aaronblohowiak wrote: post #45

radarsat1 wrote: post #25

I've been doing a whole lot of scientific Python lately, and every time I let my program run for like an hour only to crash on an array of the wrong dimensions, or pass in a scalar where an array is expected or vice versa, I swear and wish I was using a strongly typed language like Haskell. If only it had the same tools as SciPy I'd be all over doing my scientific work in Haskell. (Not to mention it would have faster…

save more intermediate values to disk so resuming upon failure is easier.

It's painful even when it only takes a single time step to reach the error (sometimes upwards of a minute or more). It's as if I've gone from an interpreted language with no compile time to a compiled language with horrendous compile times.

Re: Why Not Haskell?

#49

Post by pjscott » Tue, Oct 18, 2011, 3:26 AM UTC

kamechan wrote: post #10

"If you've written a Haskell program that runs, it's highly likely to be a correct solution." having done a bit of work with haskell myself, i'd say it's even better for this for haskell programmers. if you're using type signatures and you've written a haskell program that passes type-checking, it's highly likely to be a correct solution

But just in case it isn't, remember that QuickCheck is a remarkably easy and powerful way to test weird edge cases:

http://book.realworldhaskell.org/read/testing-and-quality-as...

Re: Why Not Haskell?

#50

Post by PPGualtieri » Tue, Oct 18, 2011, 3:27 AM UTC

Once you manged to grok the basic stuff about Typeclasses, Functors, Applicative, Monads, Monad Transformers, different notions of recursion, a minimal understanding of how lazyness can be quite tricky, the multitude of different ways of how errors and exceptions are handled in various libraries, and perhaps basic STM, Haskell has a tendency to become even more complex. If you want to do efficient IO and prevent space leaks, you have to learn about Iteratees, Enumerators and Enumeratees. If you wish to create GUIs in a bearable manner, its imperative that you learn about FRP and Arrows eventually. Then there's the innumerable amount of language extensions to Haskell of the GHC flavor, each of which comes with only scarce documentation and examples, but with a lot of theory (Fundeps, Type families, Existential types, GADTs ...). But there's more: Comonads, Kleisli Arrows and probably things I haven't even heard about. The whole point being: If you want to be able to handle 'real world stuff' in Haskell, its not enough to stay 'mostly pure' and use StateT, unfortunately. I like Haskell - I shudder when I think of C, C++ and Java - but at this point in time I find it overwhelming.