13 ms·

What was your "ah ha" moment with Haskell?

116 points by dons 14y ago

opminion 14y ago
The first example of parametric polymorphism, as introduced by a good teacher. I wasn't even attending the class proper, but taking notes for a deaf student as a paid job.
supersillyus 14y ago
My "ah ha" moment with Haskell was after a few years of using it quite regularly, I realized that it wasn't actually making me more productive in the kind of code I actually write from day-to-day. It's a lovely language and I wouldn't discourage anyone from using it, but for my purposes I realized it was more exciting than useful at some point, and after that I haven't been back to it as much.
- slewis 14y ago
  What's your go to language now?
- CoffeeDregs 14y ago
  Agreed. It's so beautiful, but so constraining. I'm a much better developer for having used it, but returned to Python/Ruby/Java[for-speed] after spending lots of time with Haskell. That said, I desperately miss static-typing and Hindley-Milner type inference... I keep searching for the perfect language.
  - srean 14y ago
    Then I would be interested about your opinion on OcaML/MLTon, F# and Scala. To me they seem like a good balance. If you are more adventurous then try Felix. EDIT: apparently someone did not like your comment. Some downvotes confound me.
    - CoffeeDregs 14y ago
      Would that downvotes interested me... To your questions: OcaML: seems like a hack-ish [S]ML. There's a nice comparison between SML and OcaML here : http://adam.chlipala.net/mlcomp/ http://adam.chlipala.net/mlcomp/ . I like SML's syntax, but OcaML made it too easy to be imperative and seemed too hackish. Most of the OcaML I've seen looks like weird C, but written in OcaML because it's F4ST3R. F# : I run Linux... next! Scala* : I can't stand it. I use Python for everyday coding and I really don't like the philosophy behind str(), len(), and friends, but it's otherwise straightforward. There's pretty much only 1 [reasonable] way to do things in Python. Scala seems like the evile lovechild of Perl and SML. Classes and "case Classes"? WTF? Type inferencing, but not powerful type inference? If you're going to move to Java++ without going too far toward Haskell, then Gosu or Mirah seem like better compromises. That said, I'm only investigated Scala [not coded in it], so my griefing is likely due to a lack of familiarity. SML/MLTon: the syntax is 95% good but they should have embraced significant-whitespace wholeheartedly. Do they really need an "end"? But, generally, I really like SML's thinking. In particular, I'm rooting for SML by following Yeti (https://github.com/mth/yeti https://github.com/mth/yeti; but "case" is closed with "esac", really?!) and Roy (http://roy.brianmckenna.org/ http://roy.brianmckenna.org/). Oh and I hate header files. Sooooo 1995... Clojure: static typing. I want to believe, but the lack of static typing (including Hindley-Mindler type systems) seems like a short-cut. I think the static/dynamic typing argument is a relic of pre-good-static-typing system and I don't think that big, server-side languages should be dynamically and/or weakly typed. That said, Stuart, and his hair, are great. Felix: interesting, but I see no mention of type inference, so have concerns about the type system. Also, the wiki is broken and that makes me think "dead project". But, unfortunately, I want mature toolchains, libraries, etc, so, though I wrote a mid-sized web framework in Haskell, I'm one of those who is waiting for a functional language to emerge as the winner. Until then, I'll work in Python and will support Yeti and Roy. * I've forgotten where I saw it, but Scala also had some bizarre rules around interpreting variables in case statements [or something] involving the case of the argument. I closed the book at that point. Haskell has special notations for special features, not special assumptions for normal features.
      - srean 14y ago
  - pka 14y ago
    Could you give a concrete example that shows why Haskell is constraining?
- wardenclyffe 14y ago
  I trust that you've read the excellent essay "And then there's Haskell..." http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/044101.html http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/0441... (Edit: After further research if you were on Hacker news mid january last year this would in fact be old news, sorry for the unwitting repost)
- masklinn 14y ago
  > I realized that it wasn't actually making me more productive in the kind of code I actually write from day-to-day I've got a quip for that in my quotefile: > "Haskell mainly helps with my C++ template coding when I'm doing money oriented programming" -- fnord123
  - jerf 14y ago
    I've noticed that slowly, but surely, Haskell really is winning. C++ is now basically running as fast as it can to become Haskell. It's such an old language with so much baggage that "as fast as it can" isn't very fast at all, and it has no chance of ever reaching it, but the trendline is clear. The question the programming community faces over the next, oh, ten years or so, is "Can we get the benefits of Haskell without the strict attention to the type system and without having to rigidly separate IO?" Or a bit more sarcastically/cynically, can we get the benefits without having to fundamentally change how we do business? My gut says no, but I'm open to being proved wrong. (Oh, and yeah that's not the only question, there's others like "What about OO? Can we keep it?", but I think that's really the core question; do we really have to rigidly control our side effects or can we keep our sloppy side-effect usage? Everything else is either incidental next to that, or flows from it.)
    - sseveran 14y ago
      The answer is no. Marking side effects is the one thing, probably more than any other that makes haskell awesome for building applications. For instance STM is awesome in Haskell because it is easy for the compiler to see any and all side effects. The real thing that would be cool would be a strict haskell with optional laziness.
      - jerf 14y ago
        As I said, my gut agrees with you, but I think that given the relative newness of this idea, that the programming community at large should be given some time to make the case that the benefits can be obtained without so much of the cost. There's only a bare handful of languages that have even taken a serious swing at it, like Clojure and lately D. I want more evidence before I call it. Probably the most promising approach that might salvage conventional programming approaches is a process-based model like Erlang or Go, where each process is internally mutable (mostly unlike Erlang, though it does have the process dictionary), but strictly segmented such that one process can not mutate another's state. This hybrid approach might be viable, and while it's not exactly business-as-usual, it's not as far a trip as full-on IO isolation. (Still, that affords just slamming everything in one process, at which point you don't win much. Will be interesting to watch Go's ecosystem develop and see if goroutines manage to become something deeply and pervasively used in all libraries or a thing occasionally used when the situation is desparate.)
flink127 14y ago
My "ah ha" moment with Haskell was when I ragequit for the 23rd time and decided that Haskell is probably not for me.
- ufo 14y ago
  That also what I did when I realized that the "return" function isn't actually for returning values. But then I came back for the 24th time and got hooked. Now Im doomed forever.
  - jonsterling 14y ago
    :) What an unfortunate function name. But "pure" isn't much better...
    - pja 14y ago
      I always thought it ought to be "inject" or something. Return is just outright confusing to novices & just encourages them to believe that do ... return notation has something to do with imperative programming. Which is does of course, but only by the most circuitous of routes. My embarrassing Haskell moment was how long it took me to realise that I could never get Arrow notation to work because the first argument to an arrow was the "arrow type" bit, so I was always trying to pass the wrong number of arguments to (*) and friends. Took me ages to get over that hump.
jiggy2011 14y ago
I studied haskell at university, but there was very little explanation of why it would be useful or the fundamental difference between it and a standard iterative language (or maybe there was and I skipped that day). At that point I assumed it was simply a language invented by academics in order to torture undergrads. It wasn't until a bit later and playing around with things like python and Javascript and using closures/lambdas that I realized I could use some of the functional ideas I had drilled when doing haskell to write simpler code. Now when I go back to Java I often get frustrated and the amount of code I have to write simply to work around the fact that functions are not first class objects.
- spacemanaki 14y ago
  > Now when I go back to Java I often get frustrated and the amount of code I have to write simply to work around the fact that functions are not first class objects. Frankly, I've mostly gotten over Java's lack of first-class functions and just make do with the boilerplate involved with regular for-loops or with anonymous implementations of interfaces that are just stand-ins for functions, etc. What I really struggle with nowadays is Java's (relative to Haskell's) weak type system. I'm only a novice Haskell programmer, but even so I miss things like Maybe, Either, tuples, etc, which can be really painful to work around the lack of in Java. I've realized I would rather work in a dynamically typed language or a strong statically typed language than the wretched mess that is Java.
  - jonsterling 14y ago
    Remember, Maybe and Either are not language features in Haskell, but rather library features! Java is totally capable of hosting them. (Though, there isn't any special syntax for tuples in Java).
    - pka 14y ago
      Yes, but without pattern matching and a do-like syntax sugaring they are close to useless, unfortunately.
    - 14y ago
shriphani 14y ago
I really like this: twoK=1:(map (2*) twoK) I still have a long way to go though - I can't write a lot of it without getting stuck and giving up. It would be really nice if I was comfortable with haskell.
meowzero 14y ago
It wasn't Haskell but another functional programming language (scala). I got my major "ah ha" moment when I did a code review with another experienced functional programmer. It showed to me that functional programming is a different paradigm.
lkrubner 14y ago
Off topic, but my "ah ha" moment with both Clojure and Lisp was this blog post by John Lawrence Aspden: http://www.learningclojure.com/2010/09/clojure-faster-than-machine-code.html http://www.learningclojure.com/2010/09/clojure-faster-than-m... He managed to get a statement to go as fast the JVM could possibly go, and he did this by getting the code to write code (the code added type castings to every variable, which apparently gave the JVM the info it needed to optimize like crazy). And there is no way to do that without hard-coding, and if you don't know what kind of data you are going to get, then obviously there is no way to hard-code anything. In other words, this kind of stunt can only be done in a language that allows this kind of code-that-writes-code.
- deleted 14y ago
  [deleted]
- batista 14y ago
  >* In other words, this kind of stunt can only be done in a language that allows this kind of code-that-writes-code.* On the other hand, this kind of stunt will still be a stunt, not a common use case of the language.
sordina 14y ago
I didn't have a single "ah ha" moment, but things became much clearer when I realised that although it was possible to have heterogeneous collections through the use of type-classes, what I nearly always wanted was to create a new data type with a constructor for each behaviour I was interested in encompassing. The fact that data-types are so cheap, both syntactically and computationally, really frees you up from having to worry about not creating them. I did go too far the other way for a while and created new types for everything. There exists a happy middle ground, but it's hard to define where exactly it lies.
neutronicus 14y ago
I have yet to have my big ah-ha moment for how to do what I do (scientific computing) in Haskell. I recently found myself needing a proof-of-concept implementation for solving a bunch of big tridiagonal matrices in parallel using MPI. I thought to myself "here's an opportunity to use Haskell!", but I must confess I'm rather stumped for how one goes about allocating some memory, banging on it, communicating a subset of it to another processor(s), reading a buffer from the other processor, and then banging on the memory I allocated before some more based on what I got back from the other processors(s). Does one actually attempt to control the machine with this level of granularity with Haskell? Can one actually get any mileage out of the type system doing this sort of thing? Or am I just trying to fit a square peg in a round hole?
- bos 14y ago
  In my experience, Haskell is not yet a great language for numerically intensive computing. I'll explain in a bit, but before I do, let me first address your question about "can I bang on bits?". Yes, you can allocate memory and do all the low-level hacking you please in Haskell. It's not really any harder than in C, although the notation is different and that throws people. But because this is a very imperative way of programming, it's also not going to be any faster than C (typically it'll be a bit slower). There are even MPI bindings for Haskell, and they look pretty much the same as for other languages (i.e. very low level). If you're just foontling around imperatively in big homogeneous arrays and sending messages, then the type system really won't do you any good, and you'll rightly find yourself wishing for the notational convenience and speed of Fortran 95. You could use immutable arrays (the Vector type is your friend) and higher order functions instead, and thereby benefit from Haskell's rather nice parallel evaluation support with only a little effort. This is quite practical, and can lead to pretty code that runs quickly. Where all the fancy type-related machinery comes into play for numeric code is still largely a matter of research. There are interesting projects underway for parallel programming (both on CPUs and GPUs) that rely heavily on the type system. They're not obviously useful for real work yet, and since they rely on advanced type system features, neither are they something you just pick up and use as a newbie. Nevertheless, I think they're pretty cool projects, and I have been watching them for a few years. So while there's a lot of interesting stuff going on, the current state of affairs is somewhat mixed. You might enjoy learning your way through it, though; there are many rewards to the path.
jamesbritt 14y ago
I was converting a somewhat complex Haskell example into Ruby for a presentation and kept running into neat concise Haskell expressions that I could not easily express in Ruby. It got me thinking that Haskell might be a better Ruby.
tonetheman 14y ago
Ha already been said, but my ah ha came when after reading quite a bit about it. I realized I was incapable of understanding it and moved on. :)
- djhworld 14y ago
  Reading won't get you anywhere unfortunately. The ingenuity of Haskell is doing, writing code. You'll have many 'ah-ha!' moments after that. Also I think the major problem with Haskell is A LOT of the online content out there is primarily aimed at academia and quite honestly baffles me too. If you stick with LYAH and RWH and...just doing code then it becomes a lot more usable and fun to program in
- gtani 14y ago
  dont' give up! Remmeber your friends. Hoogle is your friend the REPL is your friend (typeclassopedia, too, but that's for later). The point is to get into the REPl and start defining the contours of the type system, monomorphism restriction, inference, etc, in your mind
danieldk 14y ago
There were far to many 'ah ha' moments. So, I'll take one that I don't hear too often ;). Suppose that you are working on FFI code: do x <- malloc poke x myCDouble return x My C reflex was: 'I have to specify how much memory I want to allocate, but malloc doesn't take an argument, what the heck?'. Obviously, since Haskell has proper type inference, it can deduce that x is a pointer to a CDouble, and has no trouble allocating the proper amount of memory. But for a moment I was thinking it can read my mind :).
clux 14y ago
Reading the blow your mind wiki was ah ha overload. http://www.haskell.org/haskellwiki/Blow_your_mind http://www.haskell.org/haskellwiki/Blow_your_mind
verroq 14y ago
Learn Haskell to see how things could be done. Don't use Haskell for things that should be done.
vitomd 14y ago
My ah ha moment was when I found this tutorial http://learnyouahaskell.com/ http://learnyouahaskell.com/ , because was really fun and I learned a lot. Before, I was trying to learn from this: http://www.haskell.org/tutorial/ http://www.haskell.org/tutorial/ and was so boring that I almost quit

116 points by dons 14y ago

The first example of parametric polymorphism, as introduced by a good teacher. I wasn't even attending the class proper, but taking notes for a deaf student as a paid job.

supersillyus 14y ago

My "ah ha" moment with Haskell was after a few years of using it quite regularly, I realized that it wasn't actually making me more productive in the kind of code I actually write from day-to-day. It's a lovely language and I wouldn't discourage anyone from using it, but for my purposes I realized it was more exciting than useful at some point, and after that I haven't been back to it as much.

slewis 14y ago
What's your go to language now?
CoffeeDregs 14y ago
Agreed. It's so beautiful, but so constraining. I'm a much better developer for having used it, but returned to Python/Ruby/Java[for-speed] after spending lots of time with Haskell. That said, I desperately miss static-typing and Hindley-Milner type inference... I keep searching for the perfect language.
- srean 14y ago
  Then I would be interested about your opinion on OcaML/MLTon, F# and Scala. To me they seem like a good balance. If you are more adventurous then try Felix. EDIT: apparently someone did not like your comment. Some downvotes confound me.
  - CoffeeDregs 14y ago
    Would that downvotes interested me... To your questions: OcaML: seems like a hack-ish [S]ML. There's a nice comparison between SML and OcaML here : http://adam.chlipala.net/mlcomp/ http://adam.chlipala.net/mlcomp/ . I like SML's syntax, but OcaML made it too easy to be imperative and seemed too hackish. Most of the OcaML I've seen looks like weird C, but written in OcaML because it's F4ST3R. F# : I run Linux... next! Scala* : I can't stand it. I use Python for everyday coding and I really don't like the philosophy behind str(), len(), and friends, but it's otherwise straightforward. There's pretty much only 1 [reasonable] way to do things in Python. Scala seems like the evile lovechild of Perl and SML. Classes and "case Classes"? WTF? Type inferencing, but not powerful type inference? If you're going to move to Java++ without going too far toward Haskell, then Gosu or Mirah seem like better compromises. That said, I'm only investigated Scala [not coded in it], so my griefing is likely due to a lack of familiarity. SML/MLTon: the syntax is 95% good but they should have embraced significant-whitespace wholeheartedly. Do they really need an "end"? But, generally, I really like SML's thinking. In particular, I'm rooting for SML by following Yeti (https://github.com/mth/yeti https://github.com/mth/yeti; but "case" is closed with "esac", really?!) and Roy (http://roy.brianmckenna.org/ http://roy.brianmckenna.org/). Oh and I hate header files. Sooooo 1995... Clojure: static typing. I want to believe, but the lack of static typing (including Hindley-Mindler type systems) seems like a short-cut. I think the static/dynamic typing argument is a relic of pre-good-static-typing system and I don't think that big, server-side languages should be dynamically and/or weakly typed. That said, Stuart, and his hair, are great. Felix: interesting, but I see no mention of type inference, so have concerns about the type system. Also, the wiki is broken and that makes me think "dead project". But, unfortunately, I want mature toolchains, libraries, etc, so, though I wrote a mid-sized web framework in Haskell, I'm one of those who is waiting for a functional language to emerge as the winner. Until then, I'll work in Python and will support Yeti and Roy. * I've forgotten where I saw it, but Scala also had some bizarre rules around interpreting variables in case statements [or something] involving the case of the argument. I closed the book at that point. Haskell has special notations for special features, not special assumptions for normal features.
    - srean 14y ago
- pka 14y ago
  Could you give a concrete example that shows why Haskell is constraining?
wardenclyffe 14y ago
I trust that you've read the excellent essay "And then there's Haskell..." http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/044101.html http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/0441... (Edit: After further research if you were on Hacker news mid january last year this would in fact be old news, sorry for the unwitting repost)
masklinn 14y ago
> I realized that it wasn't actually making me more productive in the kind of code I actually write from day-to-day I've got a quip for that in my quotefile: > "Haskell mainly helps with my C++ template coding when I'm doing money oriented programming" -- fnord123
- jerf 14y ago
  I've noticed that slowly, but surely, Haskell really is winning. C++ is now basically running as fast as it can to become Haskell. It's such an old language with so much baggage that "as fast as it can" isn't very fast at all, and it has no chance of ever reaching it, but the trendline is clear. The question the programming community faces over the next, oh, ten years or so, is "Can we get the benefits of Haskell without the strict attention to the type system and without having to rigidly separate IO?" Or a bit more sarcastically/cynically, can we get the benefits without having to fundamentally change how we do business? My gut says no, but I'm open to being proved wrong. (Oh, and yeah that's not the only question, there's others like "What about OO? Can we keep it?", but I think that's really the core question; do we really have to rigidly control our side effects or can we keep our sloppy side-effect usage? Everything else is either incidental next to that, or flows from it.)
  - sseveran 14y ago
    The answer is no. Marking side effects is the one thing, probably more than any other that makes haskell awesome for building applications. For instance STM is awesome in Haskell because it is easy for the compiler to see any and all side effects. The real thing that would be cool would be a strict haskell with optional laziness.
    - jerf 14y ago
      As I said, my gut agrees with you, but I think that given the relative newness of this idea, that the programming community at large should be given some time to make the case that the benefits can be obtained without so much of the cost. There's only a bare handful of languages that have even taken a serious swing at it, like Clojure and lately D. I want more evidence before I call it. Probably the most promising approach that might salvage conventional programming approaches is a process-based model like Erlang or Go, where each process is internally mutable (mostly unlike Erlang, though it does have the process dictionary), but strictly segmented such that one process can not mutate another's state. This hybrid approach might be viable, and while it's not exactly business-as-usual, it's not as far a trip as full-on IO isolation. (Still, that affords just slamming everything in one process, at which point you don't win much. Will be interesting to watch Go's ecosystem develop and see if goroutines manage to become something deeply and pervasively used in all libraries or a thing occasionally used when the situation is desparate.)

flink127 14y ago

My "ah ha" moment with Haskell was when I ragequit for the 23rd time and decided that Haskell is probably not for me.

ufo 14y ago
That also what I did when I realized that the "return" function isn't actually for returning values. But then I came back for the 24th time and got hooked. Now Im doomed forever.
- jonsterling 14y ago
  :) What an unfortunate function name. But "pure" isn't much better...
  - pja 14y ago
    I always thought it ought to be "inject" or something. Return is just outright confusing to novices & just encourages them to believe that do ... return notation has something to do with imperative programming. Which is does of course, but only by the most circuitous of routes. My embarrassing Haskell moment was how long it took me to realise that I could never get Arrow notation to work because the first argument to an arrow was the "arrow type" bit, so I was always trying to pass the wrong number of arguments to (*) and friends. Took me ages to get over that hump.

jiggy2011 14y ago

I studied haskell at university, but there was very little explanation of why it would be useful or the fundamental difference between it and a standard iterative language (or maybe there was and I skipped that day). At that point I assumed it was simply a language invented by academics in order to torture undergrads. It wasn't until a bit later and playing around with things like python and Javascript and using closures/lambdas that I realized I could use some of the functional ideas I had drilled when doing haskell to write simpler code. Now when I go back to Java I often get frustrated and the amount of code I have to write simply to work around the fact that functions are not first class objects.

spacemanaki 14y ago
> Now when I go back to Java I often get frustrated and the amount of code I have to write simply to work around the fact that functions are not first class objects. Frankly, I've mostly gotten over Java's lack of first-class functions and just make do with the boilerplate involved with regular for-loops or with anonymous implementations of interfaces that are just stand-ins for functions, etc. What I really struggle with nowadays is Java's (relative to Haskell's) weak type system. I'm only a novice Haskell programmer, but even so I miss things like Maybe, Either, tuples, etc, which can be really painful to work around the lack of in Java. I've realized I would rather work in a dynamically typed language or a strong statically typed language than the wretched mess that is Java.
- jonsterling 14y ago
  Remember, Maybe and Either are not language features in Haskell, but rather library features! Java is totally capable of hosting them. (Though, there isn't any special syntax for tuples in Java).
  - pka 14y ago
    Yes, but without pattern matching and a do-like syntax sugaring they are close to useless, unfortunately.
  - 14y ago

shriphani 14y ago

I really like this: twoK=1:(map (2*) twoK) I still have a long way to go though - I can't write a lot of it without getting stuck and giving up. It would be really nice if I was comfortable with haskell.

meowzero 14y ago

It wasn't Haskell but another functional programming language (scala). I got my major "ah ha" moment when I did a code review with another experienced functional programmer. It showed to me that functional programming is a different paradigm.

lkrubner 14y ago

Off topic, but my "ah ha" moment with both Clojure and Lisp was this blog post by John Lawrence Aspden: http://www.learningclojure.com/2010/09/clojure-faster-than-machine-code.html http://www.learningclojure.com/2010/09/clojure-faster-than-m... He managed to get a statement to go as fast the JVM could possibly go, and he did this by getting the code to write code (the code added type castings to every variable, which apparently gave the JVM the info it needed to optimize like crazy). And there is no way to do that without hard-coding, and if you don't know what kind of data you are going to get, then obviously there is no way to hard-code anything. In other words, this kind of stunt can only be done in a language that allows this kind of code-that-writes-code.

deleted 14y ago
[deleted]
batista 14y ago
>* In other words, this kind of stunt can only be done in a language that allows this kind of code-that-writes-code.* On the other hand, this kind of stunt will still be a stunt, not a common use case of the language.

sordina 14y ago

I didn't have a single "ah ha" moment, but things became much clearer when I realised that although it was possible to have heterogeneous collections through the use of type-classes, what I nearly always wanted was to create a new data type with a constructor for each behaviour I was interested in encompassing. The fact that data-types are so cheap, both syntactically and computationally, really frees you up from having to worry about not creating them. I did go too far the other way for a while and created new types for everything. There exists a happy middle ground, but it's hard to define where exactly it lies.

neutronicus 14y ago

I have yet to have my big ah-ha moment for how to do what I do (scientific computing) in Haskell. I recently found myself needing a proof-of-concept implementation for solving a bunch of big tridiagonal matrices in parallel using MPI. I thought to myself "here's an opportunity to use Haskell!", but I must confess I'm rather stumped for how one goes about allocating some memory, banging on it, communicating a subset of it to another processor(s), reading a buffer from the other processor, and then banging on the memory I allocated before some more based on what I got back from the other processors(s). Does one actually attempt to control the machine with this level of granularity with Haskell? Can one actually get any mileage out of the type system doing this sort of thing? Or am I just trying to fit a square peg in a round hole?

bos 14y ago
In my experience, Haskell is not yet a great language for numerically intensive computing. I'll explain in a bit, but before I do, let me first address your question about "can I bang on bits?". Yes, you can allocate memory and do all the low-level hacking you please in Haskell. It's not really any harder than in C, although the notation is different and that throws people. But because this is a very imperative way of programming, it's also not going to be any faster than C (typically it'll be a bit slower). There are even MPI bindings for Haskell, and they look pretty much the same as for other languages (i.e. very low level). If you're just foontling around imperatively in big homogeneous arrays and sending messages, then the type system really won't do you any good, and you'll rightly find yourself wishing for the notational convenience and speed of Fortran 95. You could use immutable arrays (the Vector type is your friend) and higher order functions instead, and thereby benefit from Haskell's rather nice parallel evaluation support with only a little effort. This is quite practical, and can lead to pretty code that runs quickly. Where all the fancy type-related machinery comes into play for numeric code is still largely a matter of research. There are interesting projects underway for parallel programming (both on CPUs and GPUs) that rely heavily on the type system. They're not obviously useful for real work yet, and since they rely on advanced type system features, neither are they something you just pick up and use as a newbie. Nevertheless, I think they're pretty cool projects, and I have been watching them for a few years. So while there's a lot of interesting stuff going on, the current state of affairs is somewhat mixed. You might enjoy learning your way through it, though; there are many rewards to the path.

jamesbritt 14y ago

I was converting a somewhat complex Haskell example into Ruby for a presentation and kept running into neat concise Haskell expressions that I could not easily express in Ruby. It got me thinking that Haskell might be a better Ruby.

tonetheman 14y ago

Ha already been said, but my ah ha came when after reading quite a bit about it. I realized I was incapable of understanding it and moved on. :)

djhworld 14y ago
Reading won't get you anywhere unfortunately. The ingenuity of Haskell is doing, writing code. You'll have many 'ah-ha!' moments after that. Also I think the major problem with Haskell is A LOT of the online content out there is primarily aimed at academia and quite honestly baffles me too. If you stick with LYAH and RWH and...just doing code then it becomes a lot more usable and fun to program in
gtani 14y ago
dont' give up! Remmeber your friends. Hoogle is your friend the REPL is your friend (typeclassopedia, too, but that's for later). The point is to get into the REPl and start defining the contours of the type system, monomorphism restriction, inference, etc, in your mind

danieldk 14y ago

There were far to many 'ah ha' moments. So, I'll take one that I don't hear too often ;). Suppose that you are working on FFI code: do x <- malloc poke x myCDouble return x My C reflex was: 'I have to specify how much memory I want to allocate, but malloc doesn't take an argument, what the heck?'. Obviously, since Haskell has proper type inference, it can deduce that x is a pointer to a CDouble, and has no trouble allocating the proper amount of memory. But for a moment I was thinking it can read my mind :).

clux 14y ago

Reading the blow your mind wiki was ah ha overload. http://www.haskell.org/haskellwiki/Blow_your_mind http://www.haskell.org/haskellwiki/Blow_your_mind

verroq 14y ago

Learn Haskell to see how things could be done. Don't use Haskell for things that should be done.

vitomd 14y ago

My ah ha moment was when I found this tutorial http://learnyouahaskell.com/ http://learnyouahaskell.com/ , because was really fun and I learned a lot. Before, I was trying to learn from this: http://www.haskell.org/tutorial/ http://www.haskell.org/tutorial/ and was so boring that I almost quit