Live data from Hacker News

Pain Points of Haskell

dixonary.co.uk

101–110 of 322 posts

Re: Pain Points of Haskell

#101
post #47

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

What does this comment or linked article even mean? :D

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.

Re: Pain Points of Haskell

#102
post #42

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 messag…

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

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 productive with Scala which, while being a member of the ML family, is much more intricate due to OO + FP on top of great Java interop and many Haskell-like features (laziness, monads, lenses...).

Haskell doesn't feel the same. I have learned some Haskell over the years. Since I come from a pure FP education (started with SML) and I have lots of type theory background, everything feels familiar, yet I've found it really hard to be productive or to justify the mental overhead of laziness. I have developed some small projects in Haskell, but I haven't found it a productive alternative to the languages above.

Re: Pain Points of Haskell

#103
post #6

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-techni…

My experience is that the most basic tasks have a very mature library base in my context (web domain). Such as typed web endpoints, web servers and clients, JSON parsing and working with databases. I expect some domains are even far more mature with Haskell.

However, when you explore more specific things like shipping emails via a 3rd party service, various authentication protocols, monitoring via external services, spinning up persistent job queues etc. you start running into odd problems that you need to debug and even possibly fix at library level. That may considerably slow down development.

Re: Pain Points of Haskell

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

Re: Pain Points of Haskell

#105

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

Surprisingly, this hasn't hurt me as much as I expected it would. Yes, the compilation times are slow but for the most part you have the type checker guide you while developing.

Slow compilations are very annoying for tests though.

Re: Pain Points of Haskell

#106

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

Compilation time generally isn't a problem if you work from the REPL (it's super-quick to reload the REPL after changing a file). The only time you pay for a full compile is for release.

Yep, it's the dependencies that take long to compile. Once you've done that already compiling your own source code is a lot faster, probably somewhat comparable to other compiled languages.

Re: Pain Points of Haskell

#107
post #102
post #42

Earlier quoted context omitted.

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

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 has argued of Lisp, Haskell really is a "secret weapon" and people who use it for production tend to love it.

EDIT: a prior version of this post claimed Facebook employed Philip Wadler, which is incorrect. Sorry! I got my wires crossed and confused Philip Wadler with Simon Marlow!

[1] https://www.linkedin.com/in/simonmarlow/

Re: Pain Points of Haskell

#108
post #24

Earlier quoted context omitted.

Can't it be both?

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

Re: Pain Points of Haskell

#109
post #81

Earlier quoted context omitted.

Of course you need to know the semantics of the programming language you're using. The point is that lazy evaluation introduces additional complexity on top of that.

the point is that it's not semantics of a language alone, it's the semantics of the language + the libraries + the data constructors + the flow order. Lazy evaluation doesn't introduce additional complexity on top of that for no good reason, it actually trades a few of these complexities for one additional abstraction that lets you think about your programs in terms of data flows and transformations (instead of alloc…

The additional complexity may or may not be justified; the point is that it exists.

Re: Pain Points of Haskell

#110
post #90
post #80

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 re…

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…

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.

Post reply on HN