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

271–280 of 322 posts

Re: Pain Points of Haskell

#271

Post by nimih »

danielscrubs wrote: post #73
barking wrote: post #2

Warning possible flamebait: could Clojure be the solution?

Correct me if I'm wrong but Clojure nudges avoiding mutable state while Haskell uses type theory to enforce it at your leisure at compilation time. Clojure seems like a great language, but it has a completely different focus. I'd say Idris is a contender instead, which is not lazy and has theory proving. Will it become popular in the wild? Of course not, Python & JavaScript or something even easier is going to eat th…

I think Clojure puts a similar amount of effort to Haskell in order to discourage mutable state: the core library makes the easy solutions the ones that use immutable data structures and pure functions, and you have relatively ergonomic escape hatches (State/ST monad, atoms/volatiles/transients) available if you need them. Haskell's compile-time checking of purity and explicit effects is obviously absent from Clojure, but at a high level I think the two languages are mostly aligned in how easy they think it should be to use mutable state[0].

That being said, this is just picking nits and I agree with your larger point that Clojure and Haskell provide very different sets of trade-offs, so one really isn't a good substitute for the other[1].

[0] edit: Clojure just uses the more Clojure-y approach of eschewing compile-time checks in favor of assuming the user is able to responsibly use mutable state and indicate via some side-channel the contract a given function adheres to. Rich Hickey--if he cared about type systems in the first place--would likely argue that there's nothing inherent in Haskell which prevents programmers from writing truly labyrinthine stateful code by performing their computation within the appropriate monad; I have certainly done so myself, on occasion.

[1] Unless your only metric is "ability to get functional programming weenies to argue/chatter in HN comments," in which case they pretty interchangeable IME.

Re: Pain Points of Haskell

#272

Post by junker123 »

I've been doing professional FP work for 20+ years at this point. Haskell has community was the biggest killer for me. It was great when I made the jump from Standard ML to Haskell about 15 years ago. About 5 years ago I just couldn't stand what it had morphed into any longer - from the tension created by certain companies to well known community members who were just trouble for one reason or another. Instead of returning to Standard ML, I've been doing Ocaml for the last 5 years or so and couldn't be happier.

Re: Pain Points of Haskell

#273

Post by marcosdumay »

klipt wrote: post #178
MaxGabriel wrote: post #154

Earlier quoted context omitted.

I'm the CTO at Mercury ( https://mercury.com/ ) and we have 100% of our backend written in Haskell. It's gone really well so far. Answering another commenter's question, I would say the "secret weapons" are: 1. Hiring: Haskell is a very in-demand language by very good engineers. For a startup, it's absolutely amazing for recruiting and I can't overstate how important recruiting good people is for a startup. 2. Correc…

> 1. Hiring: Haskell is a very in-demand language by very good engineers. For a startup, it's absolutely amazing for recruiting and I can't overstate how important recruiting good people is for a startup. Although for engineers, supply-and-demand favoring employers typically means it disfavors employees: you may effectively be taking a pay cut to use Haskell compared to more popular languages.

The labor market is not zero-sum.

If Haskell is just a signal that selects for more competent people, companies will be happy to hire people whose competence they would have to invest a lot to match otherwise, and developers will be happy to get a larger salary than they would be able to get otherwise. (But yes, this would disfavor people with other kinds of signal.)

If it selects for high productivity people, or if it helps people be more productive, companies will be happy from getting more output than they would otherwise, and developers will still get more money.

The stereotype is that Haskell jobs pay less, and developers are happy to work with a better language. That still doesn't disfavor any party, but I don't think anybody has any evidence that this is the case. Notice that the GP is talking about people competence, not salary.

Re: Pain Points of Haskell

#274

Post by millimeterman »

wk_end wrote: post #33
pdimitar wrote: post #10

Earlier quoted context omitted.

Then maybe an argument can be made that this should be front-and-center in the docs? (Note that I am not claiming anything though, haven't checked Haskell's docs in a while.) It's also a surprise to me that you seem to say that OCaml is Haskell without the lazy eval being the default, mind expanding on that? Quite interesting.

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

Haskell certainly has a _better_ parallelism story than OCaml but I wouldn't call it great. It's really nothing special.

Re: Pain Points of Haskell

#275

Post by millimeterman »

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

IMO stuff like and >>= are fine. They're part of the standard library and are very widely used so you just learn them once. The real problem is when random libraries invent so many symbolic operators that they become their own little incomprehensible DSLs (looking at you, lens).

Re: Pain Points of Haskell

#276

Post by millimeterman »

ivanbakel wrote: post #194
Supermancho wrote: post #175

Earlier quoted context omitted.

> I personally don't understand the hangup on the existence of an IDE. I don't understand the lack of a hangup. It's obvious from using an IDE to going back to a text editor. It hurts adoption, it hurts beginners, it hurts the ecosystem...ie disparate tools grouped with known interactions are not necessary to fully understand when creating a program, leave those details in the IDE as a simplified interaction (eg chec…

My point is there's no "lack" of tooling. Nowadays, the Haskell IDE engine is good enough for general use. It's pretty trivial to plug into every general-purpose editor. More and more beginners nowadays do not want to install a whole new IDE. They don't want to have to configure it, learn it, and understand all of its nuances and foibles. They prefer using their existing setup (VSCode, Atom, vim, emacs, etc.) with a…

> Nowadays, the Haskell IDE engine is good enough for general use. It's pretty trivial to plug into every general-purpose editor.

Strong disagree. Even in small hobby projects it's slow, has limited functionality, and needs frequent restarts to function properly.

Re: Pain Points of Haskell

#277

Post by millimeterman »

lmm wrote: post #22
gridlockd wrote: post #7

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

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.

While true, this isn't a free get out of jail card whenever someone brings up slow compilation. OCaml's compiler is blazing fast.

Re: Pain Points of Haskell

#278

Post by smichael »

johnday wrote: post #201
ivanbakel wrote: post #194

Earlier quoted context omitted.

My point is there's no "lack" of tooling. Nowadays, the Haskell IDE engine is good enough for general use. It's pretty trivial to plug into every general-purpose editor. More and more beginners nowadays do not want to install a whole new IDE. They don't want to have to configure it, learn it, and understand all of its nuances and foibles. They prefer using their existing setup (VSCode, Atom, vim, emacs, etc.) with a…

> Nowadays, the Haskell IDE engine is good enough for general use. Sadly I am unconvinced of this. If it were true, there would not be an immediate and significant push to make `haskell-language-server`. Having tried many times to get `hie` working, I can say that it's a pain in the bum. Suppose I have 12 projects, one made every month for the last year. Each of these 12 will be using a different stack resolver, poss…

I don't think it's quite that bad. Most likely you could easily use 1-2 ghc versions for those, and you need one build of IDE tools per ghc version, not per resolver, no ?

Re: Pain Points of Haskell

#279

Post by ghostwriter »

mlthoughts2018 wrote: post #229
ghostwriter wrote: post #120

Earlier quoted context omitted.

> not realizing the memory footprint of this can be far, far worse than just materializing the whole list in memory, depending on the situation. you need to reference a particular Python implementation at this point

Nah, you really don’t. The only notable difference would be in stackless Python, and since for all practical purposes only CPython and PyPy matter for widely discussing Python usage on applied problems, it can be safely omitted.

You really do. "Generators" are APIs, their implementations may vary, even across different CPython versions, and Stackless is not the only implementation (yet a significant one) that you should consider when talking about the differences in memory footprint. Numba, Cython, Nuitka, and a few other more exotic compilers all have their own implementations of compiled generators, and some of them allocate the required tracking structure quite compactly on the stack [1].

But let's say I agree with you. To make the case demonstrably true, I'd like to see the context where a total volume of generator instantiations becomes less efficient than all possible list/tuple allocations with their contained data. Do you mind sharing your stats? What kind of codebase is it? I'd like to understand the layout of it and to draw my own conclusion on whether the mentioned veteran code is sane.

[1] http://numba.pydata.org/numba-doc/0.20.0/developer/generator...

Re: Pain Points of Haskell

#280

Post by mcguire »

tome wrote: post #251
mcguire wrote: post #245

Earlier quoted context omitted.

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: " I…

> The next ML will be pure, with effects only via monads Which has already been proven wrong, by the way, by F#, which appeared in 2005 ("Wearing the hair shirt" was from 2003), so I think the comment is not to be taken too literally. https://www.microsoft.com/en-us/research/publication/wearing...

Did Simon Peyton-Jones work on F#?
Post reply on HN