28 ms·

Pain Points of Haskell

250 points by runeks 6y ago

barking 6y ago
Warning possible flamebait: could Clojure be the solution?
- ssijak 6y ago
  Solution to what exactly? Clojure is Lisp like jvm language with different characteristics.
- The_rationalist 6y ago
  Scala
- m12k 6y ago
  A solution to which of the listed pain points?
- dkersten 6y ago
  I’m a huge Clojure fan, but I don’t think so. They are very different languages with fundamentally opposed opinions on the use of static vs dynamic types, for example.
- johnday 6y ago
  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.
  - Random_ernest 6y ago
    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.
  - dgb23 6y ago
    Would you say you are a top-down thinker/programmer?
    - johnday 6y ago
      I think so, yes. I think Haskell helps with this. You can write the top level code first, and be fairly confident that, if the types are sensible, there will be a sensible implementation by the time you reach the bottom. It also helps that there's so much code reuse that the "depth" reached is quite shallow compared to what you might see in other languages.
- danielscrubs 6y ago
  Correct me if I'm wrong but Clojure nudges avoiding mutable state while Haskell uses type theory to enforce it at your leisure at compilation time. Clojure seems like a great language, but it has a completely different focus. I'd say Idris is a contender instead, which is not lazy and has theory proving. Will it become popular in the wild? Of course not, Python & JavaScript or something even easier is going to eat the world.
  - nimih 6y ago
    I think Clojure puts a similar amount of effort to Haskell in order to discourage mutable state: the core library makes the easy solutions the ones that use immutable data structures and pure functions, and you have relatively ergonomic escape hatches (State/ST monad, atoms/volatiles/transients) available if you need them. Haskell's compile-time checking of purity and explicit effects is obviously absent from Clojure, but at a high level I think the two languages are mostly aligned in how easy they think it should be to use mutable state[0]. That being said, this is just picking nits and I agree with your larger point that Clojure and Haskell provide very different sets of trade-offs, so one really isn't a good substitute for the other[1]. [0] edit: Clojure just uses the more Clojure-y approach of eschewing compile-time checks in favor of assuming the user is able to responsibly use mutable state and indicate via some side-channel the contract a given function adheres to. Rich Hickey--if he cared about type systems in the first place--would likely argue that there's nothing inherent in Haskell which prevents programmers from writing truly labyrinthine stateful code by performing their computation within the appropriate monad; I have certainly done so myself, on occasion. [1] Unless your only metric is "ability to get functional programming weenies to argue/chatter in HN comments," in which case they pretty interchangeable IME.
    - danielscrubs 6y ago
      I have nothing against Clojure. I like dynamic typing when doing data science, and I like heavily enforced types when someone else dumps code in my lap.
- tome 6y ago
  I would think that the solution to Haskell having pain points would be fixing the Haskell pain points.
spekcular 6y ago
This is a great post. However, there are so many more things that should be on here! If I could suggest just one, it would be lazy evaluation by default, which makes it exceedingly hard to reason about time and space complexity. Also relevant is the author's article on problems using Haskell on Arch Linux: https://dixonary.co.uk/cabal-2020 https://dixonary.co.uk/cabal-2020
- dunefox 6y ago
  That's not a pain point, that's a core part of the language. If you don't want that use Ocaml.
  - pdimitar 6y ago
    Then maybe an argument can be made that this should be front-and-center in the docs? (Note that I am not claiming anything though, haven't checked Haskell's docs in a while.) It's also a surprise to me that you seem to say that OCaml is Haskell without the lazy eval being the default, mind expanding on that? Quite interesting.
    - dunefox 6y ago
      From what I've seen of Ocaml it's similar but with strict evaluation. Then again, it has no support for unicode strings so I never really looked at it again. But algebraic data types, exhaustive pattern matching, and modules make it the next best thing, I think.
      - pdimitar 6y ago
        Yeah, one of the things I dislike in it as well. UTF-8 should be built-in, not relied upon by libraries, even if they are commonly used by everyone.
        HelloNurse 6y ago
        Lack of well-made strings puts the language as a whole in a bad light: if you don't bother supporting fundamental practical needs, asking me to use your experimental, half-engineered proof of concept is arrogant.
rednum 6y ago
As someone who stopped following Haskell world few years ago, this was quite interesting read. I wonder what is the state of ecosystem (libraries) now: a few years ago one of my friends complained that for most basic tasks there is some library but usually half-working and abandoned. However: I think the point about monads is fundamentally misguided. Monad is an abstract concept and trying to explain it in non-technical way (as linked from the post) will always fail. It makes as much sense as explaining time signatures in non-musical terms, or a Banach space in non-mathematical terms. I've seen this sentiment recurring every now and then; it feels like some people really want to avoid formal definitions for the sake of it, even when formal definitions make things easier. When it comes to monads, I think you can't get any better than the semi-formal definition (typeclass with return and join) plus some motivating examples. For me looking at Reader/Writer/State helped get this; I agree with OP that List is kinda weird.
- SeanDav 6y ago
  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 what they actually are. " and > " The Wikipedia article has quite a good example of non-explanation."
  - rednum 6y ago
    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 containers..."). In my opinion the "platonic ideal of a monad tutorial" is more or less the (semi) formal definition of monad + some motivating examples. This is also something that cannot be understood if you don't have proper background (which is understanding simpler typeclasses like monoid and functor). I also would not call monads a pain point to be fair.
gridlockd 6y ago
The compilation time is the dealbreaker for me right there. If your language is slow to compile, it cannot be that good.
- danielscrubs 6y ago
  I'd say it is at least twice as fast as Scala, and faster than Swift in compilation time. Any besides OP that experienced slow Haskell compilations?
  - thepratt 6y ago
    When Template Haskell or multiple packages join the fray, compilation times can get quite high, quite quickly. This is more an experience with stack, as there are means for incremental caching to avoid full rebuilds when a top-level change is made - nix-build and bazel being a few. It doesn't help that sometimes stack can't tell if it should rebuild TH or not - a long standing bug.
- lmm 6y ago
  If the compiler finds problems that you'd otherwise need a test suite to catch, then as long as the compiler is faster than that test suite you still come out ahead.
  - gridlockd 6y ago
    If the compiler is slow, I feel unproductive. I need to try out things quickly, I need to iterate. The bugs don't matter at this stage.
    - lmm 6y ago
      You may not need a full compile for that though. Some combination of incremental compilation, non-optimising compiles, or a presentation compiler / typechecker only can be enough to iterate with.
    - kccqzy 6y ago
pdimitar 6y ago
As a guy who casually (definitely not in-depth) reviewed working with Haskell about 2 years ago I'd say the most relatable part of the article to me is: complexity in tooling and unnecessary tension when working with libraries. Also the String situation (several types of them). A lot of the other points could be addressed but the community's seeming unwillingness to tackle everyday productivity sends to me the message: "Keep out!". :( As a comparison, Elixir's Mix and Rust's Cargo are amazingly ergonomic build systems and provide all the tooling you need to work with the languages and your projects. And hey, don't kill me. As I said, I reviewed it casually for several days while comparing it with Rust and OCaml. They aren't the easiest to start with either but Rust's tooling is excellent, OCaml's is also excellent but not immediately obvious (their docs have improved a lot), and Haskell's is... kind of there, as the article points out.
- bjz_ 6y ago
  > OCaml's is also excellent but not immediately obvious (their docs have improved a lot) Interesting! The last time I tried OPAM, it actually seemed more frustrating than Cabal! Maybe it's improved? Last time I tried OPAM it would install packages globally by default, and avoiding that was a confusing process, when that should be the default behavior. Cargo (while not perfect) has really nice defaults out of the box - ie. it generates a lockfile by default, scopes packages locally to individual projects, and lets you use more than one package of the same version in the same project. 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.
  - pdimitar 6y ago
    I got told some months ago to look for these docs: https://news.ycombinator.com/item?id=22395595 https://news.ycombinator.com/item?id=22395595 It seems all we want can be made to work but it does require some tinkering and being aware of the tools' options.
  - ghostwriter 6y ago
    > 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-local-build-overview.html https://cabal.readthedocs.io/en/latest/nix-local-build-overv... [2] https://github.com/nmattia/snack https://github.com/nmattia/snack
bjz_ 6y ago
The new improvements to Cabal have been super nice of late, but one thing I _really_ wish Cabal would do is allow for multiple versions of a library to be used in the same project. Having to satisfy a single library version is incredibly frustrating, and the solver errors are incredibly confusing. This is especially confusing when it complains about a library deep in your dependency graph being in conflict. Ultimately the failure mode means that you can't build your package and are blocked until a fix is made upstream, where as with a package manager like Cargo you can still build your project. The downside is that you have a duplicate in your dependency graph - but this can be fixed upstream in an asynchronous fashion.
- ulrikrasmussen 6y ago
  I agree that this is a pain point. I not familiar with Cargo and would like to know how this actually works. Don't you risk binary incompatibility issues because the same symbols are occupied by different versions of the same package? For example, what if my package depends on A(v1.0) and B, B depends on A(v2.0), and furthermore B exposes a type from A(v2.0) in its API? Does the package manager distinguish internal dependencies from dependencies that are exposed in the API of the package?
  - bjz_ 6y ago
    I think Rust gives the symbols unique hashes for each crate version to avoid this. See this answer on Stack Overflow for more information: https://stackoverflow.com/a/51722134 https://stackoverflow.com/a/51722134 - not sure if there is a better reference document though. You sometimes get weird errors like expected `A` but found `A` in the unusual event that you actually run into this, but this is probably something that could be fixed.
    - ulrikrasmussen 6y ago
      Thank you for the link, that clarified it for me. It seems that it requires compiler support to do it in the same way as Rust does it, but I like that approach better than complicating the package definitions with two types of dependencies. Reading that post also reminded me of the Unison language [1] which would even allow the same type from different versions of a library to be identified as the same if it wasn't altered. It does this by identifying every type and function by the hash of their respective definitions. [1] https://www.unisonweb.org/ https://www.unisonweb.org/
johndoe42377 6y ago
So, you wanna to shit on Haskell as part of your virtue signalling? Here, bro, try to argue like a man. https://karma-engineering.com/lab/wiki/FirstPrinciples/HaskellPhilosophy https://karma-engineering.com/lab/wiki/FirstPrinciples/Haske...
- exdsq 6y ago
  What does this comment or linked article even mean? :D
  - johndoe42377 6y ago
    Well, as you might know, there is a classic talk on YouTube in which SPJ half-jokes about religious zeal of purity in Haskell, to avoid "sins" of side effects as only religions purists might do. It is actually very clever and even beautiful analogy, because if there is anything good about any organized religion it is self-discipline and principle-guided minimalism. Haskell - the language defined in the Haskell report - desugars into pure Lambda Calculus (augmented with a few extra expressions and types), strongly typed with type-classes. This is based on logical formalism which is called System F omega. On the implementation side this core language is nothing but pure substitution, beta reduction and a few additional evaluation rules. As long as it is being keept this way Haskell's core language is a pure logic. Technically and conceptually. It just is. The result of the main function is a pure math-like expression to be executed by the runtime which is linked into each executable. The expression is still pure, as math or logic, while runtime is impure and is doing all mundane sinful mutations. Sounds spooky, but this is how Haskell works, and these actual characteristics make it unique, of its own kind, a miracle if you wish. The problem with HN, by the way, that normies with swarm here do not even understand what other people are talking about. They downvote because they feel silly.
    - deleted 6y ago
      [deleted]
    - AnimalMuppet 6y ago
      No, we downvote because you act like a jerk. If you want to talk to people here, lose the attitude. For example: "normies". Yeah, you don't actually need to use putdowns to communicate. If you're going to be on HN, don't do that.
n3k5 6y ago
Linked page just says “something went wrong” at the moment; cache: https://web.archive.org/web/20200608072453/https://dixonary.co.uk/blog/haskell/pain https://web.archive.org/web/20200608072453/https://dixonary....
- sradman 6y ago
  Seems to be back with the following added to the top of the article: > This is a temporary rehosted version while my website is hugged to death.
js8 6y ago
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.
- logicchains 6y ago
  Another happy user of classy-prelude here. It massively reduced the amount of imports I need at the top of every file.
- the_af 6y ago
  What is classy-prelude? Last time I coded something in Haskell (ages ago :() I didn't hear of this.
  - tome 6y ago
    The first hit on Google will tell you :)
    - the_af 6y ago
      Hehe, such a classy way of telling me lmgtfy :P You're right of course, and I've found out what it is.
ghostwriter 6y ago
> There is no featureful Haskell plugin for any major text editor which can be installed without command-line intervention This is not true for at least a year already, as there's IntelliJ Haskell: * https://github.com/rikvdkleij/intellij-haskell https://github.com/rikvdkleij/intellij-haskell * https://plugins.jetbrains.com/plugin/8258-intellij-haskell https://plugins.jetbrains.com/plugin/8258-intellij-haskell
- lol768 6y ago
  This one's a good start, but it's still painfully behind other IntelliJ language plugins. E.g. I expected HSpec tests to work in the same way that I can run JUnit tests within the IDE, but no such luck.
- Nebasuke 6y ago
  It can be installed, but I still spent 3 or more hours debugging before I got everything to work on Windows. I had to spend some time reading obscure GitHub issues to find some of the underlying problems and fix them (this included manually installing some package which didn't work under the command line default code page). To compare, it took me less time to get Agda working.
johnday 6y ago
Thanks for hugging my site to death! Note to admins: I've swapped it to Github Pages for the time being and the DNS change should propagate soon. Edit: Github Pages doesn't support adding HTTPS to a newly added domain for some reason.
- xrisk 6y ago
  You can put it behind Cloudflare and it should provision a certificate instantly.
foldr 6y ago
One thing that irks me about the current Haskell ecosystem is that it seems to be going all-in on Nix. Nix is interesting, but I can't think of another programming language where the only way to get a reasonable development environment is to run a particular Linux distribution. (I know that you can install nix as a package manager on OS X and other Linux flavours, but at least on OS X, packages don't work all that reliably. The enormous disk space requirements are also an issue when using a laptop.)
- rowanG077 6y ago
  You can run Nix fine on any Linux distribution. But it's still a bad idea because I want Haskell to work sanely on Windows and going all in on a tech that doesn't support windows doesn't seem smart to me.
  - exdsq 6y ago
    It works quite well on WSL2 which comes out the box with Windows, so it's _almost_ there :)
- tome 6y ago
  Could you share what you mean by that, or how you got that impression? I've used Nix once, four years ago, and I didn't really like it[1]. I've never used it since. The only thing in the Haskell ecosystem that requires Nix is GHCJS, I think, which is bleeding edge technology that few use. Cabal's new package management style is called "Nix-style" but otherwise has no connection to Nix whatsoever (I wish they'd use a different name actually -- "persistent style", "immutable style"?). [1] For various reasons to do with user experience. I'm sure it's improved a lot by now.
  - foldr 6y ago
    I guess my experience is colored by my last gig as a Haskell developer, where our entire development and deployment process was nix-based. I understand that it is possible to use Haskell without using Nix. However, I do get the impression that a significant section of the community see nix as the best way to manage Haskell dependencies. The (insanely confusing) naming of the new cabal features seems to support that.
dustingetz 6y ago
The community has different priorities than industry
- brazzy 6y ago
  Which priorities are those, in your opinion?
hopia 6y ago
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 part is that the runtime monitoring and introspection story isn't so great compared to the likes of Erlang.
- diegoperini 6y ago
  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.
  - hopia 6y ago
    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.
  - Eliezer 6y ago
    An Atom plugin that actually worked after at most 3 days of effort trying to get it to work would have been nice.
    - diegoperini 6y ago
      If you have ghc and stack installed, this plugin will automatically recognize a project bootstrapped with stack and decorate Atom with IDE like widgets, without requiring a configuration. It can take a few minutes to make it work if your bash_profile doesn't do unexpected stuff on the PATH variable.
nickbauman 6y ago
It strikes me that I need to be a mathematician to use Haskell. Especially when someone like Rob Pike makes claims that "I cannot read the syntax of Haskell and understand it."
- KSteffensen 6y ago
  I think the unreadability is a consequence of libraries defining their own infix operators left and right. E.g. according to hoogle >*< is an operator for three different libraries. Maybe this makes sense once you are very familiar with a library (like for example if you are a library dev), but if you are trying to learn a new library it makes for pretty much unreadable code.
  - jgwil2 6y ago
    One thing that irks me as someone who has dabbled in Haskell is not knowing how I should pronounce infix operators like <*> or <?> as I'm reading a line to myself.
    - johnday 6y ago
      <star> is pronounced either "ap" or "and" depending on context. For example div <$> (Just 5) <star> (Just 7) Would be pronounced "map div over Just 5 and Just 7".
    - whateveracct 6y ago
      I never read operators in my head, so the answer is "no pronunciation at all" I'd say learning Haskell caused me to read code without using words.
- whateveracct 6y ago
  That's because Rob Pike never learned Haskell. Expecting to just look at it and know it because you know other languages is quite frankly silly! You don't need to be a mathematician though. Many Haskellers I've worked with either didn't go to university or went for something else. I only ever learned C before Haskell, for instance.
ivanbakel 6y ago
I personally don't understand the hangup on the existence of an IDE. Don't get me wrong - IDEs are great, especially for beginners. But "one-editor-per-language" is an increasingly outdated mode of thinking. The culture shock of having to download a whole new IDE for a new language is a distinct negative. Beginners benefit from new languages slotting neatly into existing tools, which is exactly what the language server efforts in Haskell have yielded. A (perhaps) valid criticism would be "the Haskell community has not done enough to make sure the language server is easy usable" - and I wouldn't even say that that was the case.
- Supermancho 6y ago
  > I personally don't understand the hangup on the existence of an IDE. I don't understand the lack of a hangup. It's obvious from using an IDE to going back to a text editor. It hurts adoption, it hurts beginners, it hurts the ecosystem...ie disparate tools grouped with known interactions are not necessary to fully understand when creating a program, leave those details in the IDE as a simplified interaction (eg checkbox to run a lint every save). Lack of tooling (erlang and lua's lack of a comprehensive package manager comes to mind) stunts language maturity. It's a pain point.
  - ivanbakel 6y ago
    My point is there's no "lack" of tooling. Nowadays, the Haskell IDE engine is good enough for general use. It's pretty trivial to plug into every general-purpose editor. More and more beginners nowadays do not want to install a whole new IDE. They don't want to have to configure it, learn it, and understand all of its nuances and foibles. They prefer using their existing setup (VSCode, Atom, vim, emacs, etc.) with a nice slot-in for the new language - which is exactly what the Haskell tooling supports. By comparison, a custom IDE is a massive undertaking, and a relatively fruitless one. It takes a tremendous effort to do well, and up until that point it actually negatively impacts the learning experience: if you encourage beginners to use a mediocre IDE, they will experience the language in a mediocre way.
    - johnday 6y ago
PhineasRex 6y ago
The complaint about records is interesting because there aren't that many major languages that actually do records well. For a language of its age, it actually does records rather well. People sometimes forget that Haskell is older than Java and like Java it has a ton of baggage from its early days. The tooling is definitely an issue for bringing in beginners, but as far as the build process goes if you're using docker and hosting your own package mirror (as you should be for a professional deployment) it's perfectly serviceable.
- iso-8859-1 6y ago
  And records will be a lot friendlier with RecordDotSyntax! :D https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0282-record-dot-syntax.rst#1-motivation https://github.com/ghc-proposals/ghc-proposals/blob/master/p...
- tbenst 6y ago
  I think Purescript has a joyous handling of records. Anyone know what the closest equivalent is for Haskell?
wilde 6y ago
One additional pain point for me is the number of symbolic operators. It’s hard to search for what some of them do, and even harder to have a conversation with a coworker when half your code is things like <$> or >>=.
- yakshaving_jgt 6y ago
  Those two operators are very common, and they're typically called "fmap" and "bind", respectively.
  - mcguire 6y ago
    Right, and when you have three or for libraries defining different symbolic languages, your code begins to resemble J. This is one of the reasons I gave up on Scala.
    - yakshaving_jgt 6y ago
      This hasn’t been my experience writing Haskell every day. The language is a good tool, but it isn’t magic. You still need to apply good taste.
- kccqzy 6y ago
  Search with Hoogle.
- millimeterman 6y ago
  IMO stuff like <$> and >>= are fine. They're part of the standard library and are very widely used so you just learn them once. The real problem is when random libraries invent so many symbolic operators that they become their own little incomprehensible DSLs (looking at you, lens).
lambdasquirrel 6y ago
This is nice, and yet, not much different from what the Haskell community was dealing with 5 years ago. They are also mostly programming concerns, as opposed to engineering concerns. How do you deal with simple things like exceptions and string interpolation? There are guides trying to explain monads, but no straightforward answer for dealing with these sorts of things, with building separate libraries / packages, setting up your own CI with your own stackage repo. And we haven’t gotten into production yet. The ecosystem doesn’t have these things built out, or, it’s just not documented/agreed upon so you’d effectively be starting from scratch. While it might be nice to use Haskell for math-y things, in the end, you’d have to be able to instrument it, monitor/log it, etc. That doesn’t appear to be in place either. When I worked with Haskell last, these were all blockers.
- johnday 6y ago
  As a PhD student, I don't have enough experience working with Haskell in an industrial context to comment on the engineering concerns. I believe you when you say that these things are all problems. However, I'm aware that at least some solutions are underway. For example, the shake library [1] is a nice way to set up competent, reproducible build systems. [1] https://hackage.haskell.org/package/shake https://hackage.haskell.org/package/shake
- kccqzy 6y ago
  > How do you deal with simple things like exceptions and string interpolation? While I agree string interpolation isn't convenient, exceptions in Haskell are great. You can throw exceptions in pure code (throw upon evaluation), in IO (throw when sequenced), catch them, inspect them by doing type down casting, etc, all without pulling a dependency. It's even better than Rust. (In Rust I had to use the anyhow crate to get back some basic features I thought should be present by default.)
- st1ck 6y ago
  Exceptions work rather similar to other languages, except that you can only catch them in IO code. So generally (IMO) it's better to reserve them for actually exceptional cases, and not throw them around like in Python. String interpolation can be done with external libs using quasiquotations. It's not very pretty this way, so typically string concatenation or printf is used. Of all the things, math-y is probably not the be best usecase for Haskell, when you can use Python, R, SageMath maybe, or Julia. Haskell is best for writing parsers, compilers, interpreters. Or if you need a rich static type system. If you throw in LiquidHaskell, you have pretty good tooling for writing mostly correct programs.
mcguire 6y ago
Does Cabal still have issues with multiple, conflicting versions of packages installed globally? Stack's main advantage was that packages (essentially everything, including the compiler if I remember correctly) are installed in project-space, so that two different projects don't conflict, anyway.
- tathougies 6y ago
  the new cabal v2 system does not encourage global package installation. It adopts a stack-style approach and IMO is actually better than stack.
amelius 6y ago
I think Haskell would be the perfect language to write reference implementations in. I.e., stuff that gets spec'd out by committees like RFCs or Web technologies.
gautamcgoel 6y ago
Surprised that no one mentioned what a headache arrays are in Haskell. First, there are several different libraries: Data.Array, Data.Vector, Repa, etc. Second, the syntax is very clunky, especially if you are using multidimensional arrays. It's a real shame, since most machine learning/scientific computing programs are very heavy on arrays.
junker123 6y ago
I've been doing professional FP work for 20+ years at this point. Haskell has community was the biggest killer for me. It was great when I made the jump from Standard ML to Haskell about 15 years ago. About 5 years ago I just couldn't stand what it had morphed into any longer - from the tension created by certain companies to well known community members who were just trouble for one reason or another. Instead of returning to Standard ML, I've been doing Ocaml for the last 5 years or so and couldn't be happier.
piinbinary 6y ago
I would add a debugger to this list. The one built into GHCi is the only working one I know of, and it has major failings (such as telling me that variables aren't in scope when they clearly are).

250 points by runeks 6y ago

barking 6y ago

Warning possible flamebait: could Clojure be the solution?

ssijak 6y ago
Solution to what exactly? Clojure is Lisp like jvm language with different characteristics.
The_rationalist 6y ago
Scala
m12k 6y ago
A solution to which of the listed pain points?
dkersten 6y ago
I’m a huge Clojure fan, but I don’t think so. They are very different languages with fundamentally opposed opinions on the use of static vs dynamic types, for example.
johnday 6y ago
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.
- Random_ernest 6y ago
  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.
- dgb23 6y ago
  Would you say you are a top-down thinker/programmer?
  - johnday 6y ago
    I think so, yes. I think Haskell helps with this. You can write the top level code first, and be fairly confident that, if the types are sensible, there will be a sensible implementation by the time you reach the bottom. It also helps that there's so much code reuse that the "depth" reached is quite shallow compared to what you might see in other languages.
danielscrubs 6y ago
Correct me if I'm wrong but Clojure nudges avoiding mutable state while Haskell uses type theory to enforce it at your leisure at compilation time. Clojure seems like a great language, but it has a completely different focus. I'd say Idris is a contender instead, which is not lazy and has theory proving. Will it become popular in the wild? Of course not, Python & JavaScript or something even easier is going to eat the world.
- nimih 6y ago
  I think Clojure puts a similar amount of effort to Haskell in order to discourage mutable state: the core library makes the easy solutions the ones that use immutable data structures and pure functions, and you have relatively ergonomic escape hatches (State/ST monad, atoms/volatiles/transients) available if you need them. Haskell's compile-time checking of purity and explicit effects is obviously absent from Clojure, but at a high level I think the two languages are mostly aligned in how easy they think it should be to use mutable state[0]. That being said, this is just picking nits and I agree with your larger point that Clojure and Haskell provide very different sets of trade-offs, so one really isn't a good substitute for the other[1]. [0] edit: Clojure just uses the more Clojure-y approach of eschewing compile-time checks in favor of assuming the user is able to responsibly use mutable state and indicate via some side-channel the contract a given function adheres to. Rich Hickey--if he cared about type systems in the first place--would likely argue that there's nothing inherent in Haskell which prevents programmers from writing truly labyrinthine stateful code by performing their computation within the appropriate monad; I have certainly done so myself, on occasion. [1] Unless your only metric is "ability to get functional programming weenies to argue/chatter in HN comments," in which case they pretty interchangeable IME.
  - danielscrubs 6y ago
    I have nothing against Clojure. I like dynamic typing when doing data science, and I like heavily enforced types when someone else dumps code in my lap.
tome 6y ago
I would think that the solution to Haskell having pain points would be fixing the Haskell pain points.

spekcular 6y ago

This is a great post. However, there are so many more things that should be on here! If I could suggest just one, it would be lazy evaluation by default, which makes it exceedingly hard to reason about time and space complexity. Also relevant is the author's article on problems using Haskell on Arch Linux: https://dixonary.co.uk/cabal-2020 https://dixonary.co.uk/cabal-2020

dunefox 6y ago
That's not a pain point, that's a core part of the language. If you don't want that use Ocaml.
- pdimitar 6y ago
  Then maybe an argument can be made that this should be front-and-center in the docs? (Note that I am not claiming anything though, haven't checked Haskell's docs in a while.) It's also a surprise to me that you seem to say that OCaml is Haskell without the lazy eval being the default, mind expanding on that? Quite interesting.
  - dunefox 6y ago
    From what I've seen of Ocaml it's similar but with strict evaluation. Then again, it has no support for unicode strings so I never really looked at it again. But algebraic data types, exhaustive pattern matching, and modules make it the next best thing, I think.
    - pdimitar 6y ago
      Yeah, one of the things I dislike in it as well. UTF-8 should be built-in, not relied upon by libraries, even if they are commonly used by everyone.
      - HelloNurse 6y ago
        Lack of well-made strings puts the language as a whole in a bad light: if you don't bother supporting fundamental practical needs, asking me to use your experimental, half-engineered proof of concept is arrogant.

rednum 6y ago

As someone who stopped following Haskell world few years ago, this was quite interesting read. I wonder what is the state of ecosystem (libraries) now: a few years ago one of my friends complained that for most basic tasks there is some library but usually half-working and abandoned. However: I think the point about monads is fundamentally misguided. Monad is an abstract concept and trying to explain it in non-technical way (as linked from the post) will always fail. It makes as much sense as explaining time signatures in non-musical terms, or a Banach space in non-mathematical terms. I've seen this sentiment recurring every now and then; it feels like some people really want to avoid formal definitions for the sake of it, even when formal definitions make things easier. When it comes to monads, I think you can't get any better than the semi-formal definition (typeclass with return and join) plus some motivating examples. For me looking at Reader/Writer/State helped get this; I agree with OP that List is kinda weird.

SeanDav 6y ago
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 what they actually are. " and > " The Wikipedia article has quite a good example of non-explanation."
- rednum 6y ago
  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 containers..."). In my opinion the "platonic ideal of a monad tutorial" is more or less the (semi) formal definition of monad + some motivating examples. This is also something that cannot be understood if you don't have proper background (which is understanding simpler typeclasses like monoid and functor). I also would not call monads a pain point to be fair.

gridlockd 6y ago

The compilation time is the dealbreaker for me right there. If your language is slow to compile, it cannot be that good.

danielscrubs 6y ago
I'd say it is at least twice as fast as Scala, and faster than Swift in compilation time. Any besides OP that experienced slow Haskell compilations?
- thepratt 6y ago
  When Template Haskell or multiple packages join the fray, compilation times can get quite high, quite quickly. This is more an experience with stack, as there are means for incremental caching to avoid full rebuilds when a top-level change is made - nix-build and bazel being a few. It doesn't help that sometimes stack can't tell if it should rebuild TH or not - a long standing bug.
lmm 6y ago
If the compiler finds problems that you'd otherwise need a test suite to catch, then as long as the compiler is faster than that test suite you still come out ahead.
- gridlockd 6y ago
  If the compiler is slow, I feel unproductive. I need to try out things quickly, I need to iterate. The bugs don't matter at this stage.
  - lmm 6y ago
    You may not need a full compile for that though. Some combination of incremental compilation, non-optimising compiles, or a presentation compiler / typechecker only can be enough to iterate with.
  - kccqzy 6y ago

pdimitar 6y ago

As a guy who casually (definitely not in-depth) reviewed working with Haskell about 2 years ago I'd say the most relatable part of the article to me is: complexity in tooling and unnecessary tension when working with libraries. Also the String situation (several types of them). A lot of the other points could be addressed but the community's seeming unwillingness to tackle everyday productivity sends to me the message: "Keep out!". :( As a comparison, Elixir's Mix and Rust's Cargo are amazingly ergonomic build systems and provide all the tooling you need to work with the languages and your projects. And hey, don't kill me. As I said, I reviewed it casually for several days while comparing it with Rust and OCaml. They aren't the easiest to start with either but Rust's tooling is excellent, OCaml's is also excellent but not immediately obvious (their docs have improved a lot), and Haskell's is... kind of there, as the article points out.

bjz_ 6y ago
> OCaml's is also excellent but not immediately obvious (their docs have improved a lot) Interesting! The last time I tried OPAM, it actually seemed more frustrating than Cabal! Maybe it's improved? Last time I tried OPAM it would install packages globally by default, and avoiding that was a confusing process, when that should be the default behavior. Cargo (while not perfect) has really nice defaults out of the box - ie. it generates a lockfile by default, scopes packages locally to individual projects, and lets you use more than one package of the same version in the same project. 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.
- pdimitar 6y ago
  I got told some months ago to look for these docs: https://news.ycombinator.com/item?id=22395595 https://news.ycombinator.com/item?id=22395595 It seems all we want can be made to work but it does require some tinkering and being aware of the tools' options.
- ghostwriter 6y ago
  > 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-local-build-overview.html https://cabal.readthedocs.io/en/latest/nix-local-build-overv... [2] https://github.com/nmattia/snack https://github.com/nmattia/snack

bjz_ 6y ago

The new improvements to Cabal have been super nice of late, but one thing I _really_ wish Cabal would do is allow for multiple versions of a library to be used in the same project. Having to satisfy a single library version is incredibly frustrating, and the solver errors are incredibly confusing. This is especially confusing when it complains about a library deep in your dependency graph being in conflict. Ultimately the failure mode means that you can't build your package and are blocked until a fix is made upstream, where as with a package manager like Cargo you can still build your project. The downside is that you have a duplicate in your dependency graph - but this can be fixed upstream in an asynchronous fashion.

ulrikrasmussen 6y ago
I agree that this is a pain point. I not familiar with Cargo and would like to know how this actually works. Don't you risk binary incompatibility issues because the same symbols are occupied by different versions of the same package? For example, what if my package depends on A(v1.0) and B, B depends on A(v2.0), and furthermore B exposes a type from A(v2.0) in its API? Does the package manager distinguish internal dependencies from dependencies that are exposed in the API of the package?
- bjz_ 6y ago
  I think Rust gives the symbols unique hashes for each crate version to avoid this. See this answer on Stack Overflow for more information: https://stackoverflow.com/a/51722134 https://stackoverflow.com/a/51722134 - not sure if there is a better reference document though. You sometimes get weird errors like expected `A` but found `A` in the unusual event that you actually run into this, but this is probably something that could be fixed.
  - ulrikrasmussen 6y ago
    Thank you for the link, that clarified it for me. It seems that it requires compiler support to do it in the same way as Rust does it, but I like that approach better than complicating the package definitions with two types of dependencies. Reading that post also reminded me of the Unison language [1] which would even allow the same type from different versions of a library to be identified as the same if it wasn't altered. It does this by identifying every type and function by the hash of their respective definitions. [1] https://www.unisonweb.org/ https://www.unisonweb.org/

johndoe42377 6y ago

So, you wanna to shit on Haskell as part of your virtue signalling? Here, bro, try to argue like a man. https://karma-engineering.com/lab/wiki/FirstPrinciples/HaskellPhilosophy https://karma-engineering.com/lab/wiki/FirstPrinciples/Haske...

exdsq 6y ago
What does this comment or linked article even mean? :D
- johndoe42377 6y ago
  Well, as you might know, there is a classic talk on YouTube in which SPJ half-jokes about religious zeal of purity in Haskell, to avoid "sins" of side effects as only religions purists might do. It is actually very clever and even beautiful analogy, because if there is anything good about any organized religion it is self-discipline and principle-guided minimalism. Haskell - the language defined in the Haskell report - desugars into pure Lambda Calculus (augmented with a few extra expressions and types), strongly typed with type-classes. This is based on logical formalism which is called System F omega. On the implementation side this core language is nothing but pure substitution, beta reduction and a few additional evaluation rules. As long as it is being keept this way Haskell's core language is a pure logic. Technically and conceptually. It just is. The result of the main function is a pure math-like expression to be executed by the runtime which is linked into each executable. The expression is still pure, as math or logic, while runtime is impure and is doing all mundane sinful mutations. Sounds spooky, but this is how Haskell works, and these actual characteristics make it unique, of its own kind, a miracle if you wish. The problem with HN, by the way, that normies with swarm here do not even understand what other people are talking about. They downvote because they feel silly.
  - deleted 6y ago
    [deleted]
  - AnimalMuppet 6y ago
    No, we downvote because you act like a jerk. If you want to talk to people here, lose the attitude. For example: "normies". Yeah, you don't actually need to use putdowns to communicate. If you're going to be on HN, don't do that.

n3k5 6y ago

Linked page just says “something went wrong” at the moment; cache: https://web.archive.org/web/20200608072453/https://dixonary.co.uk/blog/haskell/pain https://web.archive.org/web/20200608072453/https://dixonary....

sradman 6y ago
Seems to be back with the following added to the top of the article: > This is a temporary rehosted version while my website is hugged to death.

js8 6y ago

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.

logicchains 6y ago
Another happy user of classy-prelude here. It massively reduced the amount of imports I need at the top of every file.
the_af 6y ago
What is classy-prelude? Last time I coded something in Haskell (ages ago :() I didn't hear of this.
- tome 6y ago
  The first hit on Google will tell you :)
  - the_af 6y ago
    Hehe, such a classy way of telling me lmgtfy :P You're right of course, and I've found out what it is.

ghostwriter 6y ago

> There is no featureful Haskell plugin for any major text editor which can be installed without command-line intervention This is not true for at least a year already, as there's IntelliJ Haskell: * https://github.com/rikvdkleij/intellij-haskell https://github.com/rikvdkleij/intellij-haskell * https://plugins.jetbrains.com/plugin/8258-intellij-haskell https://plugins.jetbrains.com/plugin/8258-intellij-haskell

lol768 6y ago
This one's a good start, but it's still painfully behind other IntelliJ language plugins. E.g. I expected HSpec tests to work in the same way that I can run JUnit tests within the IDE, but no such luck.
Nebasuke 6y ago
It can be installed, but I still spent 3 or more hours debugging before I got everything to work on Windows. I had to spend some time reading obscure GitHub issues to find some of the underlying problems and fix them (this included manually installing some package which didn't work under the command line default code page). To compare, it took me less time to get Agda working.

johnday 6y ago

Thanks for hugging my site to death! Note to admins: I've swapped it to Github Pages for the time being and the DNS change should propagate soon. Edit: Github Pages doesn't support adding HTTPS to a newly added domain for some reason.

xrisk 6y ago
You can put it behind Cloudflare and it should provision a certificate instantly.

foldr 6y ago

One thing that irks me about the current Haskell ecosystem is that it seems to be going all-in on Nix. Nix is interesting, but I can't think of another programming language where the only way to get a reasonable development environment is to run a particular Linux distribution. (I know that you can install nix as a package manager on OS X and other Linux flavours, but at least on OS X, packages don't work all that reliably. The enormous disk space requirements are also an issue when using a laptop.)

rowanG077 6y ago
You can run Nix fine on any Linux distribution. But it's still a bad idea because I want Haskell to work sanely on Windows and going all in on a tech that doesn't support windows doesn't seem smart to me.
- exdsq 6y ago
  It works quite well on WSL2 which comes out the box with Windows, so it's _almost_ there :)
tome 6y ago
Could you share what you mean by that, or how you got that impression? I've used Nix once, four years ago, and I didn't really like it[1]. I've never used it since. The only thing in the Haskell ecosystem that requires Nix is GHCJS, I think, which is bleeding edge technology that few use. Cabal's new package management style is called "Nix-style" but otherwise has no connection to Nix whatsoever (I wish they'd use a different name actually -- "persistent style", "immutable style"?). [1] For various reasons to do with user experience. I'm sure it's improved a lot by now.
- foldr 6y ago
  I guess my experience is colored by my last gig as a Haskell developer, where our entire development and deployment process was nix-based. I understand that it is possible to use Haskell without using Nix. However, I do get the impression that a significant section of the community see nix as the best way to manage Haskell dependencies. The (insanely confusing) naming of the new cabal features seems to support that.

dustingetz 6y ago

The community has different priorities than industry

brazzy 6y ago
Which priorities are those, in your opinion?

hopia 6y ago

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 part is that the runtime monitoring and introspection story isn't so great compared to the likes of Erlang.

diegoperini 6y ago
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.
- hopia 6y ago
  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.
- Eliezer 6y ago
  An Atom plugin that actually worked after at most 3 days of effort trying to get it to work would have been nice.
  - diegoperini 6y ago
    If you have ghc and stack installed, this plugin will automatically recognize a project bootstrapped with stack and decorate Atom with IDE like widgets, without requiring a configuration. It can take a few minutes to make it work if your bash_profile doesn't do unexpected stuff on the PATH variable.

nickbauman 6y ago

It strikes me that I need to be a mathematician to use Haskell. Especially when someone like Rob Pike makes claims that "I cannot read the syntax of Haskell and understand it."

KSteffensen 6y ago
I think the unreadability is a consequence of libraries defining their own infix operators left and right. E.g. according to hoogle >*< is an operator for three different libraries. Maybe this makes sense once you are very familiar with a library (like for example if you are a library dev), but if you are trying to learn a new library it makes for pretty much unreadable code.
- jgwil2 6y ago
  One thing that irks me as someone who has dabbled in Haskell is not knowing how I should pronounce infix operators like <*> or <?> as I'm reading a line to myself.
  - johnday 6y ago
    <star> is pronounced either "ap" or "and" depending on context. For example div <$> (Just 5) <star> (Just 7) Would be pronounced "map div over Just 5 and Just 7".
  - whateveracct 6y ago
    I never read operators in my head, so the answer is "no pronunciation at all" I'd say learning Haskell caused me to read code without using words.
whateveracct 6y ago
That's because Rob Pike never learned Haskell. Expecting to just look at it and know it because you know other languages is quite frankly silly! You don't need to be a mathematician though. Many Haskellers I've worked with either didn't go to university or went for something else. I only ever learned C before Haskell, for instance.

ivanbakel 6y ago

I personally don't understand the hangup on the existence of an IDE. Don't get me wrong - IDEs are great, especially for beginners. But "one-editor-per-language" is an increasingly outdated mode of thinking. The culture shock of having to download a whole new IDE for a new language is a distinct negative. Beginners benefit from new languages slotting neatly into existing tools, which is exactly what the language server efforts in Haskell have yielded. A (perhaps) valid criticism would be "the Haskell community has not done enough to make sure the language server is easy usable" - and I wouldn't even say that that was the case.

Supermancho 6y ago
> I personally don't understand the hangup on the existence of an IDE. I don't understand the lack of a hangup. It's obvious from using an IDE to going back to a text editor. It hurts adoption, it hurts beginners, it hurts the ecosystem...ie disparate tools grouped with known interactions are not necessary to fully understand when creating a program, leave those details in the IDE as a simplified interaction (eg checkbox to run a lint every save). Lack of tooling (erlang and lua's lack of a comprehensive package manager comes to mind) stunts language maturity. It's a pain point.
- ivanbakel 6y ago
  My point is there's no "lack" of tooling. Nowadays, the Haskell IDE engine is good enough for general use. It's pretty trivial to plug into every general-purpose editor. More and more beginners nowadays do not want to install a whole new IDE. They don't want to have to configure it, learn it, and understand all of its nuances and foibles. They prefer using their existing setup (VSCode, Atom, vim, emacs, etc.) with a nice slot-in for the new language - which is exactly what the Haskell tooling supports. By comparison, a custom IDE is a massive undertaking, and a relatively fruitless one. It takes a tremendous effort to do well, and up until that point it actually negatively impacts the learning experience: if you encourage beginners to use a mediocre IDE, they will experience the language in a mediocre way.
  - johnday 6y ago

PhineasRex 6y ago

The complaint about records is interesting because there aren't that many major languages that actually do records well. For a language of its age, it actually does records rather well. People sometimes forget that Haskell is older than Java and like Java it has a ton of baggage from its early days. The tooling is definitely an issue for bringing in beginners, but as far as the build process goes if you're using docker and hosting your own package mirror (as you should be for a professional deployment) it's perfectly serviceable.

iso-8859-1 6y ago
And records will be a lot friendlier with RecordDotSyntax! :D https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0282-record-dot-syntax.rst#1-motivation https://github.com/ghc-proposals/ghc-proposals/blob/master/p...
tbenst 6y ago
I think Purescript has a joyous handling of records. Anyone know what the closest equivalent is for Haskell?

wilde 6y ago

One additional pain point for me is the number of symbolic operators. It’s hard to search for what some of them do, and even harder to have a conversation with a coworker when half your code is things like <$> or >>=.

yakshaving_jgt 6y ago
Those two operators are very common, and they're typically called "fmap" and "bind", respectively.
- mcguire 6y ago
  Right, and when you have three or for libraries defining different symbolic languages, your code begins to resemble J. This is one of the reasons I gave up on Scala.
  - yakshaving_jgt 6y ago
    This hasn’t been my experience writing Haskell every day. The language is a good tool, but it isn’t magic. You still need to apply good taste.
kccqzy 6y ago
Search with Hoogle.
millimeterman 6y ago
IMO stuff like <$> and >>= are fine. They're part of the standard library and are very widely used so you just learn them once. The real problem is when random libraries invent so many symbolic operators that they become their own little incomprehensible DSLs (looking at you, lens).

lambdasquirrel 6y ago

This is nice, and yet, not much different from what the Haskell community was dealing with 5 years ago. They are also mostly programming concerns, as opposed to engineering concerns. How do you deal with simple things like exceptions and string interpolation? There are guides trying to explain monads, but no straightforward answer for dealing with these sorts of things, with building separate libraries / packages, setting up your own CI with your own stackage repo. And we haven’t gotten into production yet. The ecosystem doesn’t have these things built out, or, it’s just not documented/agreed upon so you’d effectively be starting from scratch. While it might be nice to use Haskell for math-y things, in the end, you’d have to be able to instrument it, monitor/log it, etc. That doesn’t appear to be in place either. When I worked with Haskell last, these were all blockers.

johnday 6y ago
As a PhD student, I don't have enough experience working with Haskell in an industrial context to comment on the engineering concerns. I believe you when you say that these things are all problems. However, I'm aware that at least some solutions are underway. For example, the shake library [1] is a nice way to set up competent, reproducible build systems. [1] https://hackage.haskell.org/package/shake https://hackage.haskell.org/package/shake
kccqzy 6y ago
> How do you deal with simple things like exceptions and string interpolation? While I agree string interpolation isn't convenient, exceptions in Haskell are great. You can throw exceptions in pure code (throw upon evaluation), in IO (throw when sequenced), catch them, inspect them by doing type down casting, etc, all without pulling a dependency. It's even better than Rust. (In Rust I had to use the anyhow crate to get back some basic features I thought should be present by default.)
st1ck 6y ago
Exceptions work rather similar to other languages, except that you can only catch them in IO code. So generally (IMO) it's better to reserve them for actually exceptional cases, and not throw them around like in Python. String interpolation can be done with external libs using quasiquotations. It's not very pretty this way, so typically string concatenation or printf is used. Of all the things, math-y is probably not the be best usecase for Haskell, when you can use Python, R, SageMath maybe, or Julia. Haskell is best for writing parsers, compilers, interpreters. Or if you need a rich static type system. If you throw in LiquidHaskell, you have pretty good tooling for writing mostly correct programs.

mcguire 6y ago

Does Cabal still have issues with multiple, conflicting versions of packages installed globally? Stack's main advantage was that packages (essentially everything, including the compiler if I remember correctly) are installed in project-space, so that two different projects don't conflict, anyway.

tathougies 6y ago
the new cabal v2 system does not encourage global package installation. It adopts a stack-style approach and IMO is actually better than stack.

amelius 6y ago

I think Haskell would be the perfect language to write reference implementations in. I.e., stuff that gets spec'd out by committees like RFCs or Web technologies.

gautamcgoel 6y ago

Surprised that no one mentioned what a headache arrays are in Haskell. First, there are several different libraries: Data.Array, Data.Vector, Repa, etc. Second, the syntax is very clunky, especially if you are using multidimensional arrays. It's a real shame, since most machine learning/scientific computing programs are very heavy on arrays.

junker123 6y ago

I've been doing professional FP work for 20+ years at this point. Haskell has community was the biggest killer for me. It was great when I made the jump from Standard ML to Haskell about 15 years ago. About 5 years ago I just couldn't stand what it had morphed into any longer - from the tension created by certain companies to well known community members who were just trouble for one reason or another. Instead of returning to Standard ML, I've been doing Ocaml for the last 5 years or so and couldn't be happier.

piinbinary 6y ago

I would add a debugger to this list. The one built into GHCi is the only working one I know of, and it has major failings (such as telling me that variables aren't in scope when they clearly are).