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

241–250 of 322 posts

Re: Pain Points of Haskell

#241

Post by tome »

tathougies wrote: post #226
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…

> (several types of them). I find this criticism very bizarre. C++ and C have several different string types, as does python. This comes down to the fact that what programmers think are strings are often not really and vice versa. To be clear, a 'string' is a sequence of characters or glyphs meant for human consumption or that are produced by a human as input. A string is not a sequence of bytes. C++ and C get this r…

Another great comment on this thread which could be a blog post of its own :)

Re: Pain Points of Haskell

#242

Post by pdimitar »

tathougies wrote: post #226
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…

> (several types of them). I find this criticism very bizarre. C++ and C have several different string types, as does python. This comes down to the fact that what programmers think are strings are often not really and vice versa. To be clear, a 'string' is a sequence of characters or glyphs meant for human consumption or that are produced by a human as input. A string is not a sequence of bytes. C++ and C get this r…

You might find this a bizarre criticism but In Java, Ruby, Elixir, Rust strings are all Unicode with escape hatches for manually handling byte arrays (that could be C strings).

In that regard I still find it extremely puzzling that some languages / runtimes still struggle with only giving you two choices: byte arrays and UTF-8 strings. I really don't know what's so hard about it. As mentioned in another comment in this [now pretty big] sub-thread, this is one of the things I found off-putting in OCaml which is otherwise an excellent language.

As for Haskell, it has been about 2 years since I last looked at it. I might be spoiled by the languages I enumerated but I just found the docs [at the time] lacked proper nuance to give you a way to immediately make a choice. Dunno. It's not only the strings though; Haskell's community focuses so much on certain aspects that basic ergonomics get neglected.

I am willing to retry getting into it one day. Just shared my general impressions which are very likely outdated.

Re: Pain Points of Haskell

#243

Post by lkuty »

mumblemumble wrote: post #113
rednum wrote: post #56

Earlier quoted context omitted.

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

I would turn that on its head: Provide several motivating examples, together with concrete solutions. Once you've provided a couple of those, then you can call attention to the commonalities that unite all those solutions. At which point, the abstract explanation is almost trivial. For example: My understanding of monads ultimately came together rather quickly and painlessly. After I had initially just given up on th…

It was quite similar for me. Scott Wlaschin's Railway Oriented Programming and its other articles on its site (and in particular https://fsharpforfunandprofit.com/series/map-and-bind-and-ap...) helped me greatly too. I liked its idea of an "elevated world". Another helpful source was/is https://wiki.haskell.org/All_About_Monads. But I thought a lot about them for the past few years. I tried also to make a detour through category theory but it did not help except for getting a lot of books in my library.

Another helpful article was Philip Wadler's "Monads for Functional Programming" (http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...).

Re: Pain Points of Haskell

#244

Post by tome »

misja111 wrote: post #240
2mol wrote: post #157

Earlier quoted context omitted.

The tooling situation has rapidly improved in my opinion, nowadays ghcide [0] (a language server implementation) is really great and easy to set up. I really do hope that not too many people feel like the message is "keep out". In recent years the community has generally strived to be welcoming to beginners and share the excitment of learning Haskell, without the arrogance. The aforementioned tooling improvements wer…

>> ghcide .. is really great and easy to set up Honestly, I tried to set up ghcide because I would love to have a good ide for Haskell but stopped because the setup procedure is not easy at all. Or maybe I'm getting something completely wrong? On the link you are giving, there are the following steps: - clone a git repo - run cabal install - test that ghcide is able to load your code (!) Quote: "If it doesn't work, s…

> finally integrate it in the ide that you are currently using. I am using IntelliJ IDE with the Haskell plugin and apparently I am out of luck because it is not listed.

Well, is it an IDE that supports LSP? If so, it should just work. If not, then ghcide won't work with it. Providing a language server is the whole point of what it does!

Re: Pain Points of Haskell

#245

Post by mcguire »

spekcular wrote: post #28
dunefox wrote: post #19

Earlier quoted context omitted.

I'm gonna need a source for that.

The exact quote and source (powerpoint slides) are in this HN comment: https://news.ycombinator.com/item?id=1924061 . See also the insightful comment of plinkplonk on that thread.

That's the "Wearing the Hair Shirt" talk, for those that are familiar.

"Purity is more important than, and quite independent of, laziness

"The next ML will be pure, with effects only via monads. The next Haskell will be strict, but still pure.

"Still unclear exactly how to add laziness to a strict language. For example, do we want a type distinction between (say) a lazy Int and a strict Int?"

From plinkplonk:

"It is through insisting on laziness as default and solving some of the problems encountered (via monads for e.g) that he arrived at the position that "the next Haskell will be strict". He also notes some open problems with adding laziness into a statically typed strict language (slide 40 "Still unclear exactly how to add laziness to a strict language. For example, do we want a type distinction between (say) a lazy Int and a strict Int?")."

Re: Pain Points of Haskell

#246

Post by misja111 »

johnday wrote: post #198
ashtonkem wrote: post #186

Earlier quoted context omitted.

I fully grok monads. I’ve done enough reading and usage of them to understand them. They are not a useful abstraction for programming. They’re mathematically correct, but that’s not the same as what an industrial engineer needs. The big warning sign is monad transformers. Alone, monads are totally fine, but the issue is that you rarely want one . So you end up with this unwieldy tower of transformers that would make…

I firmly believe that monads (and monad transformers) are exactly what an industrial engineer needs, for the following important reason. A monad describes its scope in such a way that writing code outside of its scope is a compile time error. If your code needs certain capabilities, it must invoke the computational context of those capabilities (which is usually a monad in Haskell). If it doesn't, then the context ca…

Even if you have separated concerns by having method 1 return Monad transformer A and method 2 return transformer B, you will still have to combine the results of both your methods at some point.

Re: Pain Points of Haskell

#247

Post by gavinray »

jackcviers3 wrote: post #212
gavinray wrote: post #156

Earlier quoted context omitted.

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…

The reply by louthy is great, but it doesn't answer your first question: > What is referential transparency? A function reference that can be replaced at all call sites in a program with its body with all of the references to its arguments replaced with references to the call site arguments without the observable behavior of the program changing is referentially transparent. In practice, it means that you can safely…

Monad is really just "flatMap"?

Is this basically it then:

    interface Monad  {
      flatMap: (arg: Some) => Maybe
    }


    let userAges: Monad.flatMap = flatMap(users, user => user.age)

Re: Pain Points of Haskell

#248

Post by yakshaving_jgt »

mcguire wrote: post #239
yakshaving_jgt wrote: post #216

Earlier quoted context omitted.

Those two operators are very common, and they're typically called "fmap" and "bind", respectively.

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.

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.

Re: Pain Points of Haskell

#249

Post by misja111 »

tome wrote: post #244
misja111 wrote: post #240

Earlier quoted context omitted.

>> ghcide .. is really great and easy to set up Honestly, I tried to set up ghcide because I would love to have a good ide for Haskell but stopped because the setup procedure is not easy at all. Or maybe I'm getting something completely wrong? On the link you are giving, there are the following steps: - clone a git repo - run cabal install - test that ghcide is able to load your code (!) Quote: "If it doesn't work, s…

> finally integrate it in the ide that you are currently using. I am using IntelliJ IDE with the Haskell plugin and apparently I am out of luck because it is not listed. Well, is it an IDE that supports LSP? If so, it should just work. If not, then ghcide won't work with it. Providing a language server is the whole point of what it does!

There is a LSP plugin for IntelliJ but it is not very stable. But that was not my point: maybe I'm spoiled because I'm coming from the JVM universe, but I don't agree that ghcide installation is easy. For me, "easy" means running an installer or invoking homebrew, and continue being productive.

Re: Pain Points of Haskell

#250

Post by tathougies »

pdimitar wrote: post #242
tathougies wrote: post #226

Earlier quoted context omitted.

> (several types of them). I find this criticism very bizarre. C++ and C have several different string types, as does python. This comes down to the fact that what programmers think are strings are often not really and vice versa. To be clear, a 'string' is a sequence of characters or glyphs meant for human consumption or that are produced by a human as input. A string is not a sequence of bytes. C++ and C get this r…

You might find this a bizarre criticism but In Java, Ruby, Elixir, Rust strings are all Unicode with escape hatches for manually handling byte arrays (that could be C strings). In that regard I still find it extremely puzzling that some languages / runtimes still struggle with only giving you two choices: byte arrays and UTF-8 strings. I really don't know what's so hard about it. As mentioned in another comment in th…

> You might find this a bizarre criticism but In Java, Ruby, Elixir, Rust strings are all Unicode with escape hatches for manually handling byte arrays (that could be C strings).

In Java, there is a 'String' class that is used for strings most of the time, but there is also char[], which would be confusing to many C programmers. It's only familiarity and ubiquity that make this choice 'obvious' for most devs

> In that regard I still find it extremely puzzling that some languages / runtimes still struggle with only giving you two choices: byte arrays and UTF-8 strings.

To be clear, Haskell's strings and Text are not UTF-8. Thy are containers that can hold any unicode character, but the particular way in which they're stored is not really guaranteed. I believe Text is UTF-16 internally, and String, being based on Char, uses full UTF-32.

Post reply on HN