Live data from Hacker News

The Haskell user experience

rickdzekman.com

11–20 of 50 posts

Re: The Haskell user experience

#11

My experience with learning Haskell was: When it works, it's magical. Finally realising that monads allow little bubbles of cause-and-effect. STM, which is utterly magical. Realising that not having side effects is freeing, not restricting. Collapsing huge chunks of code into little bits of pattern matching. Finding myself casually using a higher-order type because it was the easiest way to solve a problem. When it's…

Personally, I've been spending a lot of my recent time trying to debug a Parsec parser (it seems to be going into loops of backtracking, but I can't figure out where and why ), and it's been a clusterfuck. * `trace` and `traceM` don't actually get evaluated, so I can't use printing to find my bugs. * Even putting `trace "..." True` as a guard to my parser combinators doesn't seem to actually print anything. * `seq` a…

Note that trace is implemented in terms of unsafePerformIO (which is fine for debugging).

To get a trace message, you need to attach the trace to something that does get evaluated. I mostly define a somewhat simpler helper like this:

    tt :: Show a => a -> a
    tt x = trace (show x) x
So you surround your expressions with it and see there values, when those values get evaluated of course. Eg:

    myParser = (\_ code -> tt code)  parseComment  parseCode

Re: The Haskell user experience

#12
post #5

Personally I switched from learning Haskell to learning Racket and couldn't be happier. On the other side of banging my head I think Cabal is the biggest disappointment of my experience and it was the worst package management headaches for my own private builds. Now that I am done with a book of Haskell and being a total hack at Haskell with very little skills (I did learn quite a bit of Lambda Calculus along the way…

Your comparison isn't sound. LISPs and MLs are as close together as Apples and Oranges on the functional family tree.

Cabal has its problems and it primarily stems from a lack of any good "this is how you should use it" guides. Cabal is not a package manager!

I cannot force you to like something but I will say this in the hope that you re-evaluate your judgement: if you still think Racket is a much better experience than Haskell and its ecosystem, you likely haven't experienced Haskell in-full. I know both languages and I've used both in production software (including many other functional languages) and I can say without any doubt in my mind that I will never select Racket over Haskell for writing software, if presented the choice.

Are there glaring warts in the language? The ecosystem? The tooling? Sure, nothing is perfect and one can easily point out many more warts in other technologies that are far more popular.

Re: The Haskell user experience

#13
There is... certainly a learning curve. The Haskell community is still tiny. Per capita, it's one of the best language communities out there. It just hasn't had the thousands or millions of person-hours necessary to make everything pretty and intuitive.

I generally say that, all else equal, and if I were to use a GC'd language-- obviously, there are projects that mandate C or other low-level languages-- then I would use: Python for a short-term (days) project, Clojure for a medium-term ( 3 months, or multi-developer) one. You don't find yourself needing static typing if you're doing a small, self-contained, line-of-business task like a script. You start to really want it for multi-developer programs and for infrastructural jobs that'll take months to complete (and, at age 32-- that's ancient in programming years-- the only programming challenges that really interest me are the hard ones where Haskell's type discipline pays off in a major way).

Haskell will probably never beat Python in terms of ease-of-use, and (while I would prefer Haskell over other offerings for hard-core machine learning infrastructure) it has a ways to go before it can take over the exploratory data science world (we need data frames, and it's not at all clear what the "right" way to impose type discipline on such beasts is).

All of that said, Haskell is way better than it used to be in terms of user experience. It's gone from god-awful (circa mid-2000s) to hard-but-acceptable, and in the context of a longer-term project (i.e. at least 2 months) the uptake is a rounding error and the pain is paid off.

Furthermore, I don't think that Haskell's opt-out approach to laziness is more than a cosmetic issue. You can have as much strictness as you want; you just have to ask for it. However, high-performance programming in other languages (e.g. Clojure, Python) is also deeply technical and warty. When you start adding type hints and using Java arrays in your machine learning code, it doesn't look like Clojure anymore. My point in all this is that HPC is technical and rough in all of the major languages, and Haskell's laziness is just a small part of that.

Re: The Haskell user experience

#14
post #12
post #5

Personally I switched from learning Haskell to learning Racket and couldn't be happier. On the other side of banging my head I think Cabal is the biggest disappointment of my experience and it was the worst package management headaches for my own private builds. Now that I am done with a book of Haskell and being a total hack at Haskell with very little skills (I did learn quite a bit of Lambda Calculus along the way…

Your comparison isn't sound. LISPs and MLs are as close together as Apples and Oranges on the functional family tree. Cabal has its problems and it primarily stems from a lack of any good "this is how you should use it" guides. Cabal is not a package manager! I cannot force you to like something but I will say this in the hope that you re-evaluate your judgement: if you still think Racket is a much better experience…

RPL has been the one killer feature for my choice of Racket. I wanted to learn Functional programming and do a few scripts. Just after reading a book and a half and trying to get a few things done I really liked Racket when I went through a MOG on Programming Languages on Coursera. It went from ML to Racket and it just clicked for me.

Re: The Haskell user experience

#15

My experience with learning Haskell was: When it works, it's magical. Finally realising that monads allow little bubbles of cause-and-effect. STM, which is utterly magical. Realising that not having side effects is freeing, not restricting. Collapsing huge chunks of code into little bits of pattern matching. Finding myself casually using a higher-order type because it was the easiest way to solve a problem. When it's…

> A billion little unmemorable functions with symbolic names

Pretty much. If you though Common Lisp was bad, this is much worse. And that makes for a major (re-)learning curve every time you stop programming in Haskell for a couple of months.

Re: The Haskell user experience

#16
post #5

Personally I switched from learning Haskell to learning Racket and couldn't be happier. On the other side of banging my head I think Cabal is the biggest disappointment of my experience and it was the worst package management headaches for my own private builds. Now that I am done with a book of Haskell and being a total hack at Haskell with very little skills (I did learn quite a bit of Lambda Calculus along the way…

> I think there is a BIG reason why Haskell has not grown in popularity in language usage and is beat by Scheme and almost beat out by ML.

Is it? I would think there is easily WAY more Haskell currently in use in both industry and academia than Scheme. Certainly the mindshare is much, much larger. I have no idea where ML is, but it seems like it should be roughly on the same order as Haskell, and surely beating Scheme.

Re: The Haskell user experience

#17

My experience with learning Haskell was: When it works, it's magical. Finally realising that monads allow little bubbles of cause-and-effect. STM, which is utterly magical. Realising that not having side effects is freeing, not restricting. Collapsing huge chunks of code into little bits of pattern matching. Finding myself casually using a higher-order type because it was the easiest way to solve a problem. When it's…

> Even BASIC would at least give me a line number!

You can get line numbers and even stack traces if you compile your program (assuming you use GHC) with `-prof` and execute it with `+RTS -xc`. But most libraries try their best to avoid using exceptions altogether and it's generally discouraged to use the non-total functions from Prelude like `head` or `!!` and use safer alternatives instead.

Re: The Haskell user experience

#18

My experience with learning Haskell was: When it works, it's magical. Finally realising that monads allow little bubbles of cause-and-effect. STM, which is utterly magical. Realising that not having side effects is freeing, not restricting. Collapsing huge chunks of code into little bits of pattern matching. Finding myself casually using a higher-order type because it was the easiest way to solve a problem. When it's…

And you haven't even mentioned Cabal, which is arguably the single worst thing about the Haskell ecosystem.

Re: The Haskell user experience

#19
post #9

My experience with learning Haskell was: When it works, it's magical. Finally realising that monads allow little bubbles of cause-and-effect. STM, which is utterly magical. Realising that not having side effects is freeing, not restricting. Collapsing huge chunks of code into little bits of pattern matching. Finding myself casually using a higher-order type because it was the easiest way to solve a problem. When it's…

> Trying to debug a memory leak caused by insufficient strictness --- why do I need to care about this? The runtime should just take care of it for me; the whole point of a lazy language is that I shouldn't have to care when evaluation happens. This is a completely wrong assumption. The point of laziness is not so you won't have to care about evaluation order. Everyone would like to have a language in which you don't…

intuition about lazy evaluation order can be very misleading

Re: The Haskell user experience

#20
Haskell has all the features of languages that become mainstream and mandated top-down on workplaces. I wouldn't be much surprised if in a decade people start complaining about Haskell-shops they way we complain about Java-shops now. (But then, no language could get there without a marketing budget...)

Haskell lets big teams collaborate very well, makes it hard to bad coders to destroy an entire project, consist in a good enough filter so that HR won't hire obscenely bad developers, gives enough space for software architects do their thing, and gives plenty of objectively measurable points to make managers happy.

That said, it's completely immature. Haskell lacks packaging, environment tools, and even a complete standard library (hell, I had to put a package[1] at Hackage because no available TLS library would work!). It has all kinds of interesting advanced features, but the basics are simply missing.

[1] http://hackage.haskell.org/package/uniform-io

Post reply on HN