Live data from Hacker News

Pain Points of Haskell

dixonary.co.uk

111–120 of 322 posts

Re: Pain Points of Haskell

#111
post #34

I would say all this is improving, and while these are all pain points, they are much less a pain point than they were just couple years ago. My personal ergonomics improved when I ditched standard prelude for classy-prelude. Regarding Strings, I just use Text type.

What is classy-prelude? Last time I coded something in Haskell (ages ago :() I didn't hear of this.

Re: Pain Points of Haskell

#112
post #62
post #2

Warning possible flamebait: could Clojure be the solution?

I've tried to get into Clojure multiple times and it feels quite unergonomic to program. I think my brain is not correctly shaped for its constructs, whereas Haskell fits my mental models perfectly.

Very interesting. I feel like I have written this exact sentence somewhere online only with the languages reversed. Tried to get into FP multiple times with Haskell, never clicked, then tried Clojure and felt productive after 2 days.

Re: Pain Points of Haskell

#113
post #56
post #43

Earlier quoted context omitted.

You seem to be disagreeing with the OP about how to explain Monads, yet the link provided by the OP is referred to as a "non-explanation". It is true that Monads are a pain point in Haskell. They are extremely powerful but not easy to grok, even by some very smart programmers. Quote from main article about Monads: > "Monads.....Despite many attempts though, I don’t think we have yet found the best way of explaining w…

To rephrase what I mean: I disagree with the idea that we can explain all technical concepts in non-technical way, which OP seems to support. I don't think we can get much better with teaching monads than providing actual formal definition plus motivating examples. I simply believe monad is too abstract and we can't have a nice analogy similar to the one OP provides ("Functors can be broadly explained in terms of con…

I would turn that on its head: Provide several motivating examples, together with concrete solutions. Once you've provided a couple of those, then you can call attention to the commonalities that unite all those solutions. At which point, the abstract explanation is almost trivial.

For example: My understanding of monads ultimately came together rather quickly and painlessly. After I had initially just given up on the whole thing. And then I watched Scott Wlaschin's Railway Oriented Programming talk (https://fsharpforfunandprofit.com/rop/). And then I learned what's really going on with LINQ's query DSL and SelectMany. And had someone show me how to easily compose Optional types without having to forever be explicitly interrogating whether they have a value or not. With all that under my belt, the pattern suddenly became rather obvious.

What did not help me in any way was any article that explicitly sets out to try and explain monads. They are all, as far as I'm aware, guilty of tring to sow the seeds before tilling the earth.

Re: Pain Points of Haskell

#114
post #60

Earlier quoted context omitted.

> Really hoping OCaml and Haskell can improve their package management story - they are getting there, but it still holds me back from really using them on a daily basis. Cabal 3.x with Nix-style buildscovers all packaging needs that I ever had with Haskell ecosystem[1]. And there's a new wave of tooling based on incremental Nix builds, that you can begin using today [2] [1] https://cabal.readthedocs.io/en/latest/nix…

Yeah, it's really great to see the progress there. However, afaik, it still doesn't freeze packages by default, or let you have multiple packages of the same version in a dependency tree[1]. The former can be worked around, but it's annoying that it's not the default. The latter is more frustrating however! [1] https://news.ycombinator.com/item?id=23454711

Stack does this, if I understand what you're saying. Stack+nix has worked quite well for me for a few projects.

Re: Pain Points of Haskell

#115
post #99

While there are lots of benefits for choosing Haskell it is certainly not without its flaws as a development platform. IDE has been my largest point of pain so far. I'm just used to a more interactive development experience, and sadly the tooling is just not there yet with Haskell. That said, there's great effort right now in that area so hopefully it'll improve. On top of the broken record system, another annoying p…

Atom editor with its Haskell IDE plugin works like a charm. It has REPL and all other inspection stuff you need out of box. What other feature you would need is an unknown unknown to me.

Thanks for the tip!

I've been using ghcide on Vscode, and it keeps crashing and sometimes just simply freezing. What's more, I can't get multi-component support to work, meaning I have no IDE support for any test files, need to write them blind. No REPL that I know of either.

I tried hie before, it crashed even far more often and the type inference sometimes took a very long time to come up with hints.

Re: Pain Points of Haskell

#116
post #107
post #102

Earlier quoted context omitted.

A bit off topic, but is Haskell viable for production? Or is it just really intended as an experiment? Is it worthwhile to jump into Haskell now, or perhaps one should look into Idris or Agda? Any companies using Haskell where it has proven a distinct advantage? Ocaml and SML (the former being sadly quite unpopular these days) are an order of magnitude simpler than Haskell. They are easy to master. I have been quite…

> A bit off topic, but is Haskell viable for production? Or is it just really intended as an experiment? It's viable for production and there are businesses which use it, notably fintechs. Also Facebook for some things (Facebook employs Simon Marlow [1]). And I know this is an irrelevant anecdote, but I have a friend who has been working in several startups which use Haskell for the last few years. Like Paul Graham h…

Facebook employs Wadler? Since when?

Re: Pain Points of Haskell

#117
post #99

While there are lots of benefits for choosing Haskell it is certainly not without its flaws as a development platform. IDE has been my largest point of pain so far. I'm just used to a more interactive development experience, and sadly the tooling is just not there yet with Haskell. That said, there's great effort right now in that area so hopefully it'll improve. On top of the broken record system, another annoying p…

Atom editor with its Haskell IDE plugin works like a charm. It has REPL and all other inspection stuff you need out of box. What other feature you would need is an unknown unknown to me.

An Atom plugin that actually worked after at most 3 days of effort trying to get it to work would have been nice.

Re: Pain Points of Haskell

#118
post #24

Earlier quoted context omitted.

Sure, but I believe that Haskell is great just because it tries stuff that isn't in other languages, like laziness by default. If it's really a pain point you can always switch to Ocaml or others.

>If it's really a pain point you can always switch -XStrict on FTFY

Is that flag really ever smart to switch on? I've heard StrictData makes a lot more sense but turning Strict on prevents the compiler from making some quite crucial optimizations, resulting in degraded performance.

Re: Pain Points of Haskell

#119
post #107

Earlier quoted context omitted.

> A bit off topic, but is Haskell viable for production? Or is it just really intended as an experiment? It's viable for production and there are businesses which use it, notably fintechs. Also Facebook for some things (Facebook employs Simon Marlow [1]). And I know this is an irrelevant anecdote, but I have a friend who has been working in several startups which use Haskell for the last few years. Like Paul Graham h…

Facebook employs Wadler? Since when?

Gah! I meant to say Simon Marlow [1], co-developer of the Glasgow Haskell Compiler (GHC) [2]. Sorry for the confusion, I'll edit my other post now.

  [1] https://www.linkedin.com/in/simonmarlow
  [2] https://en.wikipedia.org/wiki/Simon_Marlow

Re: Pain Points of Haskell

#120

Earlier quoted context omitted.

that's why I mentioned "other languages/libraries where data is immutable". Replace a constructor for list() with a constructor for graph() from a random library. You won't be able to estimate the complexity of it just by reading the client code, you need to know implementation details. In Python world, list() may be called to explicitly guarantee an expected shape of a value in runtime. I see it regularly, when vari…

I think you are missing a lot of details about when it is wise vs. unwise to rely on generators and coroutines in Python for lazy evaluation. Some of the most common mistakes I see Python beginners make are using list or tuple when they could use a generator instead. Rarely it leads to serious memory consumption issues, more often it just leads to messy list-append-copy style code, which is very forgivable. Some of t…

> not realizing the memory footprint of this can be far, far worse than just materializing the whole list in memory, depending on the situation.

you need to reference a particular Python implementation at this point

Post reply on HN