Hacker News Reader

Comment by theli0nheart | Hacker News Reader

Every language has a catalyst that pushes it from obscurity into mainstream use. Whether it be a project (Ruby on Rails), a programmer (Linus Torvalds -> C), a company (Google -> Python), or a library (Boost -> C++), there is always a force behind adoption.

Most languages undergo a "fad period", where it's hip and cool to write in it and people just do it because other people do it. Clojure is going through this right now, as are Scala and (arguably) Haskell.

We'll just have to see. I honestly hope Haskell becomes popular. Judging by http://shootout.alioth.debian.org/u32/haskell.php, performance really isn't an issue. It's more of just an issue of programmer adoption and a willingness to throw yourself out there to spend some time to learn how to think outside of the imperative programming box.

View on HN

This reddit post tells me why Haskell isn't that popular.

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.

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

Except that it's not necessary, because at least 3 solutions that don't use unsafePerformIO were posted to that Reddit thread.

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.

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).

mind sharing your experience with the language?

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.

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!

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...

Well, sure. Haskell uses mathematical terminology sometimes.

Other languages use weird terminology, too: "public static void main"? How about "pure virtual destructor"? "Visitor"?

There isn't really a reason why someone picking up haskell should have to understand language like this when they encounter it.

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.

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.

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

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.

I must be parsing this incorrectly because it looks like you're arguing that C was obscure before Linus used it.

You're not.

I want to add that he was just the first guy that popped into my head when I thought C. I questioned it at first too, but the more I thought about it, Linux itself could have just as well have been written in Pascal or Lisp. If it had been, perhaps a lot of the tools, drivers, etc that interact with Linux would've been written in that language as well?

Perhaps a better example is needed.

C was never obscure in the way that Haskell is now and C++ once was. It was popularized by the project for which it was invented: UNIX, of which Linux is a two-decades-late clone. C's prevalence has always been closely tied to that of UNIX.

Not sure about that - I seem to remember reading some stuff from the mid/late seventies that was pretty skeptical about the whole idea of using a comparatively high level language for OS development.

Similarly, I don't think C++ was ever obscure in that it was widely publicized as the "next" C and people were pretty keen to use it - it was more that the early tools for C++ failed to live up to the initial promise.

Let's not fixate on the examples, folks. Perhaps they're arguable, but the original point is still valid: languages gain traction through prominent projects.

Right, and C was an obscure reddit in-joke until Linux came along and gave it an air of legitimacy.

Yeah, let's take a position in a discussion, defend it by examples (a questionable tactic, but let's roll with it for now), and then when someone picks apart the examples say 'let's not fixate on the examples, folks'?

(not attacking the OP, I'm not convinced yet one way or the other on the topic, just saying that when someone is called on his arguments and methodology the refutation in an intellectually honest discussion shouldn't be vigorous hand waiving).

I am similarly puzzled at the implication that C++ was obscure prior to Boost, given that C++ was pretty well entrenched in both industry and academia by the time work on Boost began in 1998.

I think giving Linus Torvalds the credit for pushing C into the mainstream is a bit much.

Long before Linus came along C was the programming language of choice for anything from games to operating systems and so on.

Was C really obscure before Linus Torvalds released\popularised linux? I'm fairly young so I have no knowledge of this, but it feels wrong.

edit: just noticed a discussion about this exists already. That'll teach me to read all the comments in future :)

To expand on this, and on the OP, one thing that you need after the force is momentum.

I strongly feel that if Ruby was just Rails, it would have petered out by now (maybe people might have even gone back to Perl and CPAN). I think that GitHub may well be the driving force behind Ruby at this point. GitHub gems are pretty decent, but like the OP points out, Haskell packages aren't.

GitHub no longer builds or serves gems.

Well, what I mean is they're developed on GitHub, then released to RubyGems.

Reply on news.ycombinator.com