Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pain Points of Haskell

dixonary.co.uk

Post reply on HN
Print view View original

141–150 of 322 posts

Re: Pain Points of Haskell

#141

Post by mr_custard »

tome wrote: post #135
nextos wrote: 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…

To answer your questions literally without much nuance: Yes, Haskell is viable for production. There are caveats, as with any other language. Haskell has more caveats that most other languages you would be familiar, but it's nonetheless perfectly suitable in the right environment. No, don't use Agda or Idris in production, they're totally unfit. Agda is not intended to be. Idris may be but it will take 5 or 10 years.…

> The only members of the ML family that I'm aware of are Ocaml and the flavours of Standard ML. Only Ocaml is fit for production.

F# is also a member of the ML family and is totally fit for production.

Re: Pain Points of Haskell

#142

Post by jackcviers3 »

SeanDav wrote: post #43
rednum wrote: 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…

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…

A monad is an abstract interface for sequencing side effecting operations in a way that guarantees referential transparency. They do this by hiding the extraction of the value contained in the monad and passing that value to a user supplied lambda that takes a value of the type of the value contained in the monad and returning a new monad containing a different type. Thus, you cannot do step one after step two, because step one must extract the value from its containing monad.

In a modern OOP language, like Java, this is analogous to using for each in to build a new list from a given input list. Due to the abstraction, a monad can do this without exposing the internal loop state to the outside world, a single bind expression safe to refactor, whereas moving the for loop requires moving two statements in order to be safe to move.

Re: Pain Points of Haskell

#143

Post by implicit »

nextos wrote: post #125
the_af wrote: 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…

> Haskell really is a "secret weapon" and people who use it for production tend to love it That's exactly my question. I'd be really interested in hearing about domains where Haskell is a secret weapon and how it compares to ML family languages and dependently-typed ones.

I did a bunch of professional Haskell work in a prior life[1]. Most of its 'secret weapon' status springs from the way Haskell lets you control side effects.

We had a fantastic unit testing harness[2]. With effect tracking, you can arrange for your harness to put precise fences around nondeterministic code. You don't need to rely on experience and discipline to ensure that tests are reliable or fast. The type system does it for you.

Effect tracking also makes concurrent code easier to write. You have a great deal of control over how and when threads can be created, and what kinds of logic is permitted on those threads.

GHC's IO manager offers green threads and async IO, so rather than a select loop, you just fork threads and perform "blocking" IO calls. You get about the same efficiency as a select loop this way.

Lastly, something we learned to appreciate over the years is that Haskell is easier to refactor. When you combine the rigid type system, effect tracking system, and ease of writing unit tests, it becomes very easy to refactor old Haskell. It doesn't really matter how bad the old code was or whether the original author is around to help you at all.

If you intend for your product to evolve continuously forever, this is truly a secret weapon.

    [1] https://andyfriesen.com/2014/03/25/what-its-like-to-use-haskell.html
    [2] https://andyfriesen.com/2015/06/17/testable-io-in-haskell.html

Re: Pain Points of Haskell

#144

Post by tombert »

tome wrote: post #135
nextos wrote: 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…

To answer your questions literally without much nuance: Yes, Haskell is viable for production. There are caveats, as with any other language. Haskell has more caveats that most other languages you would be familiar, but it's nonetheless perfectly suitable in the right environment. No, don't use Agda or Idris in production, they're totally unfit. Agda is not intended to be. Idris may be but it will take 5 or 10 years.…

I think that F# is ok for production. I used it at a previous job without too many pain-points, especially in comparison to Haskell. I'm not a huge fan of MSBuild, but it works relatively well, and of course you have access to the massive .NET library and the entire ecosystem of C# libraries out there, and there's even some tooling to make the C# stuff play nicely with the F# constructs.

Re: Pain Points of Haskell

#145

Post by boygobbo »

chriswarbo wrote: post #124
ghostwriter wrote: post #49

Earlier quoted context omitted.

It is in your interest to have multiple string-like datatypes in a lazy language, especially when some of them are not real strings, but rather streams of binary data. https://mmhaskell.com/blog/2017/5/15/untangling-haskells-str...

I agree, although the arguments in that article aren't the strongest. In particular: The main reason given for 'String' being slow is that it's immutable and hence leads to many duplicate Strings being created. In fact, the main reason Strings are slow is that their linked-list structure has a lot of overhead, and may be scattered around in memory. For example, the String "abc" will be represented something like this…

Does this approach avoid the issue of substrings preventing the strings they refer to from being garbage collected (e.g. as in Java's substring() before JDK 7)?

Re: Pain Points of Haskell

#146

Post by _bxg1 »

tome wrote: post #135
nextos wrote: 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…

To answer your questions literally without much nuance: Yes, Haskell is viable for production. There are caveats, as with any other language. Haskell has more caveats that most other languages you would be familiar, but it's nonetheless perfectly suitable in the right environment. No, don't use Agda or Idris in production, they're totally unfit. Agda is not intended to be. Idris may be but it will take 5 or 10 years.…

There's ReasonML, which compiles to JS and seems intended for production

Re: Pain Points of Haskell

#147

Post by johnday »

jgwil2 wrote: post #138
KSteffensen wrote: post #132

Earlier quoted context omitted.

I think the unreadability is a consequence of libraries defining their own infix operators left and right. E.g. according to hoogle >* 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.

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.

is pronounced either "ap" or "and" depending on context.

For example

div (Just 5) (Just 7)

Would be pronounced "map div over Just 5 and Just 7".

Re: Pain Points of Haskell

#148

Post by chriswarbo »

boygobbo wrote: post #145
chriswarbo wrote: post #124

Earlier quoted context omitted.

I agree, although the arguments in that article aren't the strongest. In particular: The main reason given for 'String' being slow is that it's immutable and hence leads to many duplicate Strings being created. In fact, the main reason Strings are slow is that their linked-list structure has a lot of overhead, and may be scattered around in memory. For example, the String "abc" will be represented something like this…

Does this approach avoid the issue of substrings preventing the strings they refer to from being garbage collected (e.g. as in Java's substring() before JDK 7)?

AFAIK ByteString suffers this problem: substrings will prevent their whole array from being GCed.

By default, data read from files, stdin, etc. is split into 64k chunks (e.g. see functions like 'hGetN' in http://hackage.haskell.org/package/bytestring-0.9.2.1/docs/s... ), so only the 64k chunks containing the parts we want will be kept.

There is a function 'copy' which will explicitly return a copy of only the character range that's used, so the original can be GCed ( https://hackage.haskell.org/package/bytestring-0.10.10.0/doc... )

Re: Pain Points of Haskell

#149

Post by johnday »

brazzy wrote: post #127
johnday wrote: post #61

Earlier quoted context omitted.

> If your language is slow to compile, it cannot be that good. I know compilation times are a problem, but this seems untrue. Compile times are a problem of the compiler and not the language. GHC is slow because of how much it is doing behind the scenes. Other, more streamlined compilers may be faster.

> Compile times are a problem of the compiler and not the language. This is definitely untrue. Language design has a huge effect on how easy (or even possible) it is to write a compiler that scales well. You can quite easily design a language where compilation is NP-complete...

In my comment (which you responded to) I am using the definite article. "The" language in this case is Haskell, and "the" compiler is GHC.

The inference rules and complexities of Haskell as defined in the 2010 report are minimal and as a result, a fast compiler could theoretically exist for Haskell. Speed is not a primary concern for GHC devs, though.

Re: Pain Points of Haskell

#150

Post by Vosporos »

foldr wrote: post #110
tome wrote: post #90

Earlier quoted context omitted.

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.

That's interesting! At work we use stack and our own LTSs to manage our dependencies. Nix is only used for reproducible CI.
Post reply on HN