Pain Points of Haskell • Hacker News Board

Re: Pain Points of Haskell

#161

Post by chriswarbo » Mon, Jun 08, 2020, 3:37 PM UTC

tome wrote: post #128

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…

Great write up! It deserves to be put in a blog post of its own!

Heh, I tend to use HN comments as inspiration for writing blog posts. This one's now at http://chriswarbo.net/blog/2020-06-08-haskell_strings.html

Re: Pain Points of Haskell

#162

Post by chriswarbo » Mon, Jun 08, 2020, 3:38 PM UTC

boygobbo wrote: post #155

chriswarbo wrote: post #148

Earlier quoted context omitted.

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

Thanks for the clarification. BTW I agree with tome - your comment above would make a great blog post.

It's now at http://chriswarbo.net/blog/2020-06-08-haskell_strings.html

Re: Pain Points of Haskell

#163

Post by bojo » Mon, Jun 08, 2020, 3:42 PM UTC

nextos wrote: post #102

bjz_ wrote: 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…

My company writes and supports a lot of custom Haskell software for our parent, an ISP up in Alaska.

What we gain is a high level of confidence in our business logic rules due to strict typing, fewer overall tests, and by avoiding a few small gotchas uncrashable runtimes.

Not to say it doesn’t come without problems. Poor IDE integration (I personally don’t care), questionable documentation at times, and a steep rewrite your brain learning curve.

Some posts I have written.

https://www.alasconnect.com/2018/10/02/introducing-haskell-c...

https://www.alasconnect.com/2018/10/04/productive-haskell-en...

http://blog.bojo.wtf/2020/04/15/is-haskell-a-bad-choice/

Re: Pain Points of Haskell

#164

Post by gmfawcett » Mon, Jun 08, 2020, 3:46 PM UTC

gavinray wrote: post #156

jackcviers3 wrote: post #142

Earlier quoted context omitted.

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

What is "referential transparency"? > "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" I'm not sure I follow. Is this like saying I have a function: let myFunc = (arg1: SomeType): NewType => {} And it takes SomeType, and returns NewType…

I wrote a Reddit post a while back that might help. (The parent comment has since been deleted -- the poster was asking whether using monads in Haskell was kind of like "dependency injection", i.e., passing in all the information that a function might need, as arguments to the function.)

https://www.reddit.com/r/programming/comments/593ud7/a_taste...

Re: Pain Points of Haskell

#165

Post by ansible » Mon, Jun 08, 2020, 3:48 PM UTC

danielscrubs wrote: post #68

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…

A sidenote: how great would it be if someday an abounded, well written, non buggy piece of code could just stand the test of time like math does? Instead we throw projects and programming languages faster than I change my wardrobe. :)

That's what initially drew me to Haskell, and how it seemed closer to math than most other programming languages.

Lazy evaluation brings this to the fore, especially with needing the programmer to make decisions about the sequencing of operations.

Consider these two statements:

  x = a + 5;
  y = b + 3;

So these statements describe the relationship between 'a' and 'x', and 'b' and 'y'. Great. With most programming languages, the programmer also must choose the sequencing of these operations. When they should occur, and in what order. With Haskell, this goes away.

The compiler / runtime system decides when (or if) the values of 'x' and 'y' will be evaluated. With a really, really smart compiler / runtime system, this can lead to great optimizations a C programmer would need to implement by hand when porting code to a new platform with vastly different performance characteristics.

Now... in practice... I found Haskell hard to get comfortable with. I'm quite happy with Rust these days though.

Re: Pain Points of Haskell

#166

Post by Erlangen » Mon, Jun 08, 2020, 3:50 PM UTC

bjz_ wrote: post #42

pdimitar wrote: post #16

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…

Packages are not installed globally in opam by default nowadays. `opam switch` "enables the user to have several installations on disk, each with their own prefix, set of installed packages, compiler version, etc". https://opam.ocaml.org/doc/Usage.html#opam-switch

Re: Pain Points of Haskell

#167

Post by kqr » Mon, Jun 08, 2020, 3:58 PM UTC

_bxg1 wrote: post #146

tome wrote: post #135

Earlier quoted context omitted.

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

In the same space we also find Fable, which hooks into Babel to compile F# to JS. We're using it in production and it's been surprisingly good. It's very nice to be able to share the definitions of data structures between the C# backend and JS (via F#) front-end.

Re: Pain Points of Haskell

#168

Post by ivanbakel » Mon, Jun 08, 2020, 3:59 PM UTC

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.

Re: Pain Points of Haskell

#169

Post by jimbokun » Mon, Jun 08, 2020, 4:00 PM UTC

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…

This is a very nice write up, maybe worthy of becoming a blog post!

Re: Pain Points of Haskell

#170

Post by whateveracct » Mon, Jun 08, 2020, 4:04 PM UTC

logicchains wrote: post #23

spekcular wrote: post #5

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

The -XStrict language extension is a lifesaver here, for when you want a language like Haskell but without lazy evaluation.

Pretty much every time I turn -XStrict on for some module I'm trying to optimize, performance gets worse.

Laziness gets a lot of flak for being hard to reason about. I disagree - it's just different.

But I never hear anyone acknowledge that laziness can bring compositional performance benefits no other language can sniff.