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

261–270 of 322 posts

Re: Pain Points of Haskell

#261

Post by kccqzy »

lambdasquirrel wrote: post #210

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

> 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.)

Re: Pain Points of Haskell

#262

Post by kccqzy »

wilde wrote: post #202

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 >>=.

Search with Hoogle.

Re: Pain Points of Haskell

#263

Post by tbenst »

PhineasRex wrote: post #173

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

I think Purescript has a joyous handling of records. Anyone know what the closest equivalent is for Haskell?

Re: Pain Points of Haskell

#264

Post by kccqzy »

gridlockd wrote: post #45
lmm wrote: post #22

Earlier quoted context omitted.

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.

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.

I use emacs flycheck and the compiler is invoked in the way that doesn't generate object code. It just stops after type checking.

Re: Pain Points of Haskell

#265

Post by sweeneyrod »

chewxy wrote: post #39
wk_end wrote: post #33

Earlier quoted context omitted.

They're similar but not really the same. The big differences are: * Haskell is pure whereas Ocaml is not * Haskell has a great story for parallelism whereas Ocaml does not * Haskell has ad-hoc polymorphism (via typeclasses) whereas Ocaml does not * Ocaml has an exceptionally powerful module system whereas Haskell does not

I've heard it best as: both Ocaml and Haskell are pure functional languages. Haskell is Extra Virgin. That said, the notion of purity is a bit BS. At some point in your program you are definitely going to invoke the world-at-large. Whether you do it through IO(), tap your nose and call it "pure" or you do it other way is all down to semantics (not in the PLT sense of the word - the PLT term to use would be "pragmatic…

OCaml is a lot less pure in spirit as well. Not only can you read and write to the outside world without having to jump through hoops, you can also write all your code with pointers, for loops and (mutable) arrays if you so desire.

Re: Pain Points of Haskell

#266

Post by bjz_ »

Erlangen wrote: post #166
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…

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

Oh that's nice to hear! Some questions:

Do you have to run this command manually, and does it mutate the shell state? That's one thing that frustrated me with opam in the past as well. I couldn't just jump into a directory and build a thing, then switch to another project directory - there was a lot of manual switching and unswitching of packages if I recall correct?

Is it possible to install multiple tools globally using opam that use disjoint library versions? Like, I might want to install Abella and Coq side-by-side, but they might have conflicting version requirements. I think I was super excited about opam 2, then tried installing one thing, only to have it break again when I installed something else.

Is it possible to have multiple versions of the same libray in the same project, or does the constraint solver need to find a single solution for each library? [1]

[1] https://news.ycombinator.com/item?id=23454917

Re: Pain Points of Haskell

#267

Post by bjz_ »

talex5 wrote: post #187
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…

By default, opam installs everything into the current "switch". Typically you have switch one per compiler, but you can create one per project. You can also create a "local" switch directly inside your project directory: https://opam.ocaml.org/blog/opam-local-switches/ Another option is to use the duniverse tool ( https://github.com/ocamllabs/duniverse ). That downloads all dependencies to the project directory, and…

Ahh cool - had some similar questions here: https://news.ycombinator.com/item?id=23460980 - mainly, how much manual switching do you have to do? Or is it seamless, depending on what project directory your in? I think I tried the local switches in the past and got really confused when switching projects and everything broke, thinking 'wasn't all this meant to prevent this?'.

Re: Pain Points of Haskell

#268

Post by saityi »

dan-robertson wrote: post #67
dunefox wrote: post #55

Earlier quoted context omitted.

I meant for Haskell, did you mean for Ocaml originally?

If you look at the comment chain, you see: - I don’t like lazy - ocaml is like Haskell but strict - I want higher kinded types (note this is a feature you can turn on in Haskell but ocaml does not have it[1]. The commenter is implying that ocaml is therefore not a sufficient strict Haskell) - you say that higher kinded types are an option, which is true for Haskell but not for ocaml which is being proposed. [1] there…

In case anyone is curious about [1], there is a paper called Lightweight higher-kinded polymorphism -- http://ocamllabs.io/higher/lightweight-higher-kinded-polymor... -- that goes into some of the possible encodings.

Re: Pain Points of Haskell

#269

Post by gautamcgoel »

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.

Re: Pain Points of Haskell

#270

Post by EdwardDiego »

tathougies wrote: post #250
pdimitar wrote: post #242

Earlier quoted context omitted.

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

> In Java, there is a 'String' class that is used for strings most of the time

Nearly all the time. Only time you're likely to see a char[] is in high performance code needs to mutate strings in a space efficient manner.

I would also mention CharSequence, an interface implemented by several string like classes.

Post reply on HN