5 ms·

This reddit post tells me why Haskell isn't that popular. http://www.reddit.com/r/haskell/comments/cs54i/how_would_you_write_du_in_haskell/ http://www.reddit.c

This reddit post tells me why Haskell isn't that popular. http://www.reddit.com/r/haskell/comments/cs54i/how_would_you_write_du_in_haskell/ http://www.reddit.com/r/haskell/comments/cs54i/how_would_you... Writing a quick directory traversal function should be a no-brainer in any reasonably general-purpose language. The fact that the above reddit thread is jam-packed with the ins-and-outs of doing this simple task in Haskell tells me that Haskell may be great for some things, but it's probably not general-purpose, or a great fit for anything close to the heavy I/O, streaming, processing sorts of code I write. I actually own Real World Haskell, and have tried off and on to get into it, but I found that Clojure 'took' in my brain 1000x more easily than Haskell. It's a real bitch, because I'd love to be able to say I can write Haskell, but gosh-darn it, I just can't. Grrr. Sigh. quick edit: in answer to your point about a 'killer app' for Haskell, the parsec parser-combinator library looks bloody brilliant. Maybe if I run across a parsing need, maybe it'll help me get something useful out of Haskell, but I suspect my brain just doesn't get on with the Haskelly/MLy languages.

derefr 16y ago
What most other languages do, though, is exactly equivalent to Haskell's unsafePerformIO. If you want to interact with your environment in possibly-destructive ways (and sending a message out of the runtime, whether to the network or the OS, always has the possibility of being destructive, because you can never guarantee what a system not under your control will do in response to your message), just accept the reminder that it's not functional/idempotent/memoizable/whatever else, and do it. This is going to sound like an odd analogy, but saying "I won't use Haskell because I want to do IO, but don't want to unsafely do IO", makes you sound like a person playing a fighting game who blames their loss on the game not being "fair." If you're playing to win[1], and there's an "unfair" tactic, you use it yourself. If "cheating" at Haskell lets you do a higher-quality job, faster, than either using a different language or "playing Haskell as it was meant to be played" (i.e. being a scrub) then why not? [1] http://www.sirlin.net/ptw http://www.sirlin.net/ptw
- Confusion 16y ago
  Except that it's not necessary, because at least 3 solutions that don't use unsafePerformIO were posted to that Reddit thread.
  - derefr 16y ago
    But "not necessary" has never been the problem here. People are complaining because the idiomatic way to explore a directory structure in Haskell isn't familiar to them—it's functional and mathy and strange (because exploring a directory structure in a pure-functional way is mathy and strange.) They want the language to be "as easy to use" as, say, Python, for directory-diving—but that basically means that they want to do it the same way they'd do it in Python. The only part that's hard is figuring out how to do it "the Haskell way"—a.k.a., the unfamiliar, math-filled way. What people need to learn is that you don't have to do that for everything. You can have all the advantages Haskell brings while not trying to make everything in sight into arrows and co-monoids; if it's easier to do it the non-idiomatic way (i.e. the way that doesn't involve turning your easily-expressible business domain into difficult-to-express Mathematics), then do that part that way, and get back to work.
    - lelele 16y ago
      I think you've just nailed it down: Haskell is for mathematicians, or those mathematically oriented. Most programmers are not mathematicians (especially self-taught ones) since at the end of the day common programming tasks don't require you to know advanced math (I'm not implying knowledge wouldn't be very beneficial).
      - jberryman 16y ago
        mind sharing your experience with the language?
        lelele 16y ago
        Learning Haskell has been a side project of mine the summer of two years ago, when there were a bit less tools to help newbies. Not an issue for me, since I've grown used to run code in my mind while reading it, because I firstly learned C without a computer for testing code on. I need fewer "reality checks" than more "hands on" developers (but I still throw snippets at the compiler to understand the gory details). I think Haskell is for those mathematically oriented both because only mathematicians would have cared to wrestle with monads to achieve purity (Clean is as pure as Haskell, with no monads in sight) and because its notation, whose succintness matches that of maths. I confess I've been scared of Haskell's heavy leaning on operators and many levels of precedence among them. I prefer more verbose languages. I'm not mathematically oriented, I think. Have a nice day.
blasdel 16y ago
I started using Haskell five years ago (before the age of dons), and wrote a very intensive (parser generator)^^3 project in it in 2007 that was inspired by some half-finished postdoc papers I found from researchers at Utrecht University — but I haven't really used it in the last several years. When people in that reddit thread started debating zygohistomorphic prepromorphisms, even I assumed it it was reddittard parody. Apparently not!
Confusion 16y ago
To illustrate this point, a choice snippet from that Reddit thread, explaining part of what seems to be considered 'the proper solution'. Please note that my intention is not to make fun of this, but to illustrate that the terminology in which people in the Haskell community communicate makes it impenetrable for someone just trying to pick up the language and do stuff with it. it's a straightforward lifting of the non-monadic version. You can almost get it from g_hylo by using the identity comonad, it's distributivity law, the identity natural transformation, and using T.sequence as the monad's distributivity law[1]. But this doesn't quite get us there because it requires that we can refactor the monadic parts of the coalgebra into the algebra. http://www.reddit.com/r/haskell/comments/cs54i/how_would_you_write_du_in_haskell/c0uxleq http://www.reddit.com/r/haskell/comments/cs54i/how_would_you...
- silentbicycle 16y ago
  Well, sure. Haskell uses mathematical terminology sometimes. Other languages use weird terminology, too: "public static void main"? How about "pure virtual destructor"? "Visitor"?
- jberryman 16y ago
  There isn't really a reason why someone picking up haskell should have to understand language like this when they encounter it.
- applicative 16y ago
  I think you are being misled by the seemingly simple headline "how would you write du...". The question was not straightforwardly practical but deep in the territory of so-called 'recursion schemes: The natural way to do this is to use an unfold to generate a list or tree of all the files in the directory tree, map over them to get the sizes, and do a fold to get the total. -- And similarly elsewhere, more explicitly, as he makes clear why he isn't interested in the 'obvious' solutions, e.g.: Yep, this is a good practical approach if I just want to "du". I'm looking specifically for the fold . map . unfold approach ... The interventions of doliorules and then winterkoninkje (whom you quote) were in fact the ones that spoke to his condition.
jrockway 16y ago
The problem with that Reddit post is that it would take a long time to write du, and Reddit users don't have that long of an attention span. Some people are being nice and trying to answer, but nobody took enough time (say, a week of work) to generate a really good answer. If you asked any question in the form of, "how do I write <non-trivial program> in <any langauge>", and you aren't paying for a week of someone's time to get you a really good answer, you aren't going to get a really good answer. It has nothing to do with Haskell. The reality is that programming involves trial, error, and iteration. People on Reddit can give you good first-drafts, but the final product is up to you. (If you asked, "how can I write du in C", then someone could just paste the source code. But du isn't necessarily the best implementation of du.) I've written some directory traversal code in Haskell for a work project, and I didn't find it to be particularly mind-bending or difficult. I did it the same way I would have in Perl or any other language; visit directory, run my computation, collect the answer, recurse.
- jberryman 16y ago
  I guess the original poster had some performance requirements that the standard lazy IO approaches weren't satisfying. I think he may well have gotten a few good answers there, but I really wish he would have tested them out and reported back about which (if any) worked for him! maybe I'll test them out and do a little blog post on the subject
applicative 16y ago
The desiderata were not 'writing a quick directory traversal function'; these were and are a dime a dozen. The writer explicitly demanded something you could only contemplate in the context of a few programming languages, namely an unfold - fold over the directory system. This is why he rejects all of the no-brainer solutions; he repeats this again and again.

derefr 16y ago

What most other languages do, though, is exactly equivalent to Haskell's unsafePerformIO. If you want to interact with your environment in possibly-destructive ways (and sending a message out of the runtime, whether to the network or the OS, always has the possibility of being destructive, because you can never guarantee what a system not under your control will do in response to your message), just accept the reminder that it's not functional/idempotent/memoizable/whatever else, and do it. This is going to sound like an odd analogy, but saying "I won't use Haskell because I want to do IO, but don't want to unsafely do IO", makes you sound like a person playing a fighting game who blames their loss on the game not being "fair." If you're playing to win[1], and there's an "unfair" tactic, you use it yourself. If "cheating" at Haskell lets you do a higher-quality job, faster, than either using a different language or "playing Haskell as it was meant to be played" (i.e. being a scrub) then why not? [1] http://www.sirlin.net/ptw http://www.sirlin.net/ptw

Confusion 16y ago
Except that it's not necessary, because at least 3 solutions that don't use unsafePerformIO were posted to that Reddit thread.
- derefr 16y ago
  But "not necessary" has never been the problem here. People are complaining because the idiomatic way to explore a directory structure in Haskell isn't familiar to them—it's functional and mathy and strange (because exploring a directory structure in a pure-functional way is mathy and strange.) They want the language to be "as easy to use" as, say, Python, for directory-diving—but that basically means that they want to do it the same way they'd do it in Python. The only part that's hard is figuring out how to do it "the Haskell way"—a.k.a., the unfamiliar, math-filled way. What people need to learn is that you don't have to do that for everything. You can have all the advantages Haskell brings while not trying to make everything in sight into arrows and co-monoids; if it's easier to do it the non-idiomatic way (i.e. the way that doesn't involve turning your easily-expressible business domain into difficult-to-express Mathematics), then do that part that way, and get back to work.
  - lelele 16y ago
    I think you've just nailed it down: Haskell is for mathematicians, or those mathematically oriented. Most programmers are not mathematicians (especially self-taught ones) since at the end of the day common programming tasks don't require you to know advanced math (I'm not implying knowledge wouldn't be very beneficial).
    - jberryman 16y ago
      mind sharing your experience with the language?
      - lelele 16y ago
        Learning Haskell has been a side project of mine the summer of two years ago, when there were a bit less tools to help newbies. Not an issue for me, since I've grown used to run code in my mind while reading it, because I firstly learned C without a computer for testing code on. I need fewer "reality checks" than more "hands on" developers (but I still throw snippets at the compiler to understand the gory details). I think Haskell is for those mathematically oriented both because only mathematicians would have cared to wrestle with monads to achieve purity (Clean is as pure as Haskell, with no monads in sight) and because its notation, whose succintness matches that of maths. I confess I've been scared of Haskell's heavy leaning on operators and many levels of precedence among them. I prefer more verbose languages. I'm not mathematically oriented, I think. Have a nice day.

blasdel 16y ago

I started using Haskell five years ago (before the age of dons), and wrote a very intensive (parser generator)^^3 project in it in 2007 that was inspired by some half-finished postdoc papers I found from researchers at Utrecht University — but I haven't really used it in the last several years. When people in that reddit thread started debating zygohistomorphic prepromorphisms, even I assumed it it was reddittard parody. Apparently not!

Confusion 16y ago

To illustrate this point, a choice snippet from that Reddit thread, explaining part of what seems to be considered 'the proper solution'. Please note that my intention is not to make fun of this, but to illustrate that the terminology in which people in the Haskell community communicate makes it impenetrable for someone just trying to pick up the language and do stuff with it. it's a straightforward lifting of the non-monadic version. You can almost get it from g_hylo by using the identity comonad, it's distributivity law, the identity natural transformation, and using T.sequence as the monad's distributivity law[1]. But this doesn't quite get us there because it requires that we can refactor the monadic parts of the coalgebra into the algebra. http://www.reddit.com/r/haskell/comments/cs54i/how_would_you_write_du_in_haskell/c0uxleq http://www.reddit.com/r/haskell/comments/cs54i/how_would_you...

silentbicycle 16y ago
Well, sure. Haskell uses mathematical terminology sometimes. Other languages use weird terminology, too: "public static void main"? How about "pure virtual destructor"? "Visitor"?
jberryman 16y ago
There isn't really a reason why someone picking up haskell should have to understand language like this when they encounter it.
applicative 16y ago
I think you are being misled by the seemingly simple headline "how would you write du...". The question was not straightforwardly practical but deep in the territory of so-called 'recursion schemes: The natural way to do this is to use an unfold to generate a list or tree of all the files in the directory tree, map over them to get the sizes, and do a fold to get the total. -- And similarly elsewhere, more explicitly, as he makes clear why he isn't interested in the 'obvious' solutions, e.g.: Yep, this is a good practical approach if I just want to "du". I'm looking specifically for the fold . map . unfold approach ... The interventions of doliorules and then winterkoninkje (whom you quote) were in fact the ones that spoke to his condition.

jrockway 16y ago

The problem with that Reddit post is that it would take a long time to write du, and Reddit users don't have that long of an attention span. Some people are being nice and trying to answer, but nobody took enough time (say, a week of work) to generate a really good answer. If you asked any question in the form of, "how do I write <non-trivial program> in <any langauge>", and you aren't paying for a week of someone's time to get you a really good answer, you aren't going to get a really good answer. It has nothing to do with Haskell. The reality is that programming involves trial, error, and iteration. People on Reddit can give you good first-drafts, but the final product is up to you. (If you asked, "how can I write du in C", then someone could just paste the source code. But du isn't necessarily the best implementation of du.) I've written some directory traversal code in Haskell for a work project, and I didn't find it to be particularly mind-bending or difficult. I did it the same way I would have in Perl or any other language; visit directory, run my computation, collect the answer, recurse.

jberryman 16y ago
I guess the original poster had some performance requirements that the standard lazy IO approaches weren't satisfying. I think he may well have gotten a few good answers there, but I really wish he would have tested them out and reported back about which (if any) worked for him! maybe I'll test them out and do a little blog post on the subject

applicative 16y ago

The desiderata were not 'writing a quick directory traversal function'; these were and are a dime a dozen. The writer explicitly demanded something you could only contemplate in the context of a few programming languages, namely an unfold - fold over the directory system. This is why he rejects all of the no-brainer solutions; he repeats this again and again.