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

Why Not Haskell?

neugierig.org

Post reply on HN
Print view View original

71–80 of 134 posts

Re: Why Not Haskell?

#71

Post by ch0wn »

joeyh wrote: post #39
Adaptive wrote: post #32

Earlier quoted context omitted.

I was very excited when I first discovered git-annex. When I saw it was written in haskell that sealed the deal for me. The haskell code I run is all very robust and I was very happy you'd selected it for g-a. Have you posted anything else about how specifically Haskell has made it better? I'd enjoy reading more about that.

I've been meaning to blog about that sometime soon. (Edit: I did write this post earlier http://kitenet.net/~joey/blog/entry/happy_haskell_hacker/ ) Also been meaning to do a screencast showing what I think of as type driven refactoring, since while I've heard haskell programmers discuss it I've not seen it actually demonstrated

I would love to watch that. Sounds really exciting.

Re: Why Not Haskell?

#73

Post by darklajid »

Adaptive wrote: post #36

For those interested in learning Haskell, I can recommend the lesser known "Haskell Road to Logic, Maths, and Programming": http://www.amazon.com/Haskell-Logic-Maths-Programming-Comput... It's great to go over old and new math concepts and do so while exploring Haskell.

I don't know. For me this sounds like a very bad idea.

What is putting me off (tried building small things in Haskell a couple of times) is the already heavily buzzword compliant community, throwing not only a new language with new concept at me, but adding words that at first seem to be made up on the spot.

Additionally, as others have said here, I'm having most troubles interacting with the world (IO!). Pure functions (Math!) are ~easy~ to represent.

You suggest starting with that language and learning 'new math concepts' on the go?

(I'm sure this works for some people and hats off to you guys, but for me this increases the mental complexity immensely)

Re: Why Not Haskell?

#74

Post by gaius »

boothead wrote: post #66
swah wrote: post #7

With the trend of SOA and webservers like Mongrel2, perhaps its a good time to start putting the more esoteric languages in production in the form of small services (w/ ZeroMQ for example).

Agreed, zmq and some form of cross language serialization library (we're using protocol buffers) is a seriously powerful tool to have in your box. There are some patterns that seem perfectly suited to a small piece of haskell at the end of a zmq socket.

I am using AQ to help get OCaml into "real" use: http://gaiustech.wordpress.com/2011/05/26/ociml-new-feature-...

Re: Why Not Haskell?

#75

Post by monopede »

abi wrote: post #47
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

That will most likely bite you since you're giving a pure type to a non-referentially transparent function. There is a reason why random functions are in a state monad or IO.

Re: Why Not Haskell?

#76

Post by exDM69 »

PPGualtieri wrote: post #50

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 spac…

So what? I'm a computer scientist. I dig this stuff!

Take a look at this stuff in your favorite flavor of the Blub programming language. Most of the same stuff that the Haskell community calls with strange names exists in the imperative/OO world. However, in the imperative/OO world these things tend to be ad-hoc constructions ("design patterns"?) that don't have any theoretical background and are difficult to reason about.

Re: Why Not Haskell?

#77

Post by Uchikoma »

joevandyk wrote: post #59
PPGualtieri wrote: post #50

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 spac…

Are most of those names for simple concepts / design patterns / types? I'm finding more and more that the hardest part of haskell is understanding the syntax and the terminology.

A lot of stuff is quite easy, after reading http://learnyouahaskell.com/ - but there is a tendency in the Haskell community, perhaps not in the core but at the fringes to look more elite, and with a lot of hand waving to make simple things (Monads come to mind) something complex sounding.

Take the IO Monad. Everyone who wrote some web/servlet code, that needs to output stuff to the web over several classes (might not be the best design in the beginning) uses a Writer (or other class) to aggregate output. He therefore, as global vars are bad (and thread local are worse ;-) adds a Writer to every method.

public T doSomeStuff(T input, Writer io)

This is nasty and ugly, and the IO monad is in essence just another way to write this in a neat form, make it composable and control the IO environment.

public IO doSomeStuff(IO input)

But you would not get this insight from any of the monad tutorials written by Haskell people (except the link above). Simple monad insight comes form other people outside the Haskell community, e.g. James Iry

http://james-iry.blogspot.com/2007/09/monads-are-elephants-p...

Re: Why Not Haskell?

#78

Post by gnuvince »

pnathan wrote: post #17

I've been spending time learning Haskell lately, as part of an investigation into tools which are amenable to static analysis at work. To learn about the situation, I've put together similar programs in Lisp, OCaml, and Haskell, as well as installed compilers for Haskell & Ocaml on the PPC. Well - I've coded for over a decade, and I've never encountered such a difficult to use language and jargony community & documen…

I found that one of the largest difference between Haskell and OCaml is the amount of time I spent figuring out how to make code go fast. Because OCaml is eagerly evaluated and that its compiler is extremely simple, I find that the "tools" that I learned in school and in my time coding in other languages apply to making OCaml code fast (and predictibly fast). With Haskell, you need to be more keenly aware of how evaluation is handled, and I guess I have still a lot of things to learn there, because I still have problems making really simple Haskell functions that don't crash.

Re: Why Not Haskell?

#79

Post by seabee »

michaelochurch wrote: post #41
lurker17 wrote: post #11

Earlier quoted context omitted.

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.

Right, but pseudo-randomness is still monadic because you are mutating the state of the random number generator. That it is in IO is an implementation detail of where that generator's state lives.

It's been a little while since I worked with Haskell but I'll surprised if nobody ported e.g. Mersenne Twister to it, complete with its own Random monad. If not, maybe that could be a new project...

Post reply on HN