6 ms·

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 co

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
      > F# : I run Linux... next! I feel your pain. The other thing that bothers me is that Mono developer(s?) have been extremely bone headed about tail recursion. Hey guys if you are reading this, sorry about the tone, but that needed saying. John Harrop can be quite a troll but he is right in calling Mono out on this. Their incorporations of futures and promises is indeed an attraction though. But then we only have a non-binding promise from Microsoft that they wont go after other implementations. Thats not a threat I would like to be under. I really would love a multicore enable runtime for OCaML. I dont even ask for threads, just the ability to run some of the concurrency exposed by the functional semantics be (optionally) run in parallel without forking processes. Yeti...I dont know, unless JVM includes proper tail calls I will always have this nagging sensation in my brain. Felix, BTW is far from dead, in fact it is quite the opposite, its too intensively developed. The wiki is very new, so there would be some breakage there. The original website is stable. Oh it uses Hindley-Milner type inferencing. From your comment it seems you would like the white space thing http://people.csail.mit.edu/mikelin/ocaml+twt/ http://people.csail.mit.edu/mikelin/ocaml+twt/ I have never used it though. Wonder if there is anything akin to P4Caml for SML to give you significant white space. But I think you will get over the syntax :) I have to work with arrays a lot, there SML is a bit more verbose.
      - halter73 14y ago
        Where do you get the impression that Microsoft's promise is non-binding? Microsoft's official FAQ on their Community Promise explicitly states that it irrevocable and legally binding [1]. I have previously read complaints that the promise doesn't cover enough of the .NET libraries among other issues [2], but I was not aware until now of anyone claiming that it is non-binding. [1] http://www.microsoft.com/openspecifications/en/us/programs/community-promise/faq/default.aspx http://www.microsoft.com/openspecifications/en/us/programs/c... [2] http://www.fsf.org/news/2009-07-mscp-mono http://www.fsf.org/news/2009-07-mscp-mono
    - mahmud 14y ago
      I don't think you understand either ML or Lisp. SML would never make whitespace significant because: 1) that's a brain-dead choice, and 2) ML, much like Lisp, is used as a language, as a notation, and as a "kernel" language. Clojure without dynamic-typing is bath-water without baby. What is the point of interactivity, homoiconicity and macros if the language is statically typed?
  - morsch 14y ago
    I'm sure any downvotes he got (I didn't moderate) was due to his making a fairly strong, and fairly objective claim -- Haskell is constraining -- without saying why it was constraining or even elaborating in what manner it was constraining.
- 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.)

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
    > F# : I run Linux... next! I feel your pain. The other thing that bothers me is that Mono developer(s?) have been extremely bone headed about tail recursion. Hey guys if you are reading this, sorry about the tone, but that needed saying. John Harrop can be quite a troll but he is right in calling Mono out on this. Their incorporations of futures and promises is indeed an attraction though. But then we only have a non-binding promise from Microsoft that they wont go after other implementations. Thats not a threat I would like to be under. I really would love a multicore enable runtime for OCaML. I dont even ask for threads, just the ability to run some of the concurrency exposed by the functional semantics be (optionally) run in parallel without forking processes. Yeti...I dont know, unless JVM includes proper tail calls I will always have this nagging sensation in my brain. Felix, BTW is far from dead, in fact it is quite the opposite, its too intensively developed. The wiki is very new, so there would be some breakage there. The original website is stable. Oh it uses Hindley-Milner type inferencing. From your comment it seems you would like the white space thing http://people.csail.mit.edu/mikelin/ocaml+twt/ http://people.csail.mit.edu/mikelin/ocaml+twt/ I have never used it though. Wonder if there is anything akin to P4Caml for SML to give you significant white space. But I think you will get over the syntax :) I have to work with arrays a lot, there SML is a bit more verbose.
    - halter73 14y ago
      Where do you get the impression that Microsoft's promise is non-binding? Microsoft's official FAQ on their Community Promise explicitly states that it irrevocable and legally binding [1]. I have previously read complaints that the promise doesn't cover enough of the .NET libraries among other issues [2], but I was not aware until now of anyone claiming that it is non-binding. [1] http://www.microsoft.com/openspecifications/en/us/programs/community-promise/faq/default.aspx http://www.microsoft.com/openspecifications/en/us/programs/c... [2] http://www.fsf.org/news/2009-07-mscp-mono http://www.fsf.org/news/2009-07-mscp-mono
  - mahmud 14y ago
    I don't think you understand either ML or Lisp. SML would never make whitespace significant because: 1) that's a brain-dead choice, and 2) ML, much like Lisp, is used as a language, as a notation, and as a "kernel" language. Clojure without dynamic-typing is bath-water without baby. What is the point of interactivity, homoiconicity and macros if the language is statically typed?
- morsch 14y ago
  I'm sure any downvotes he got (I didn't moderate) was due to his making a fairly strong, and fairly objective claim -- Haskell is constraining -- without saying why it was constraining or even elaborating in what manner it was constraining.
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.)