Live data from Hacker News

Haskell for a New Decade [pdf]

dev.stephendiehl.com

51–60 of 190 posts

Re: Haskell for a New Decade [pdf]

#51

When will Haskell get a different spokesperson? Stephen isn’t effective in this role. These posts have jumped the shark to the point when I see a big Haskell post on HN and see stephendiehl.com it’s just time to tune out. For Haskell to succeed, it has to move away from rigid commitment to various pure functional paradigms and move to eager execution by default. But Stephen does not help this, just preferring to inst…

The types of posts that get downvoted on here is at times maddening. This to me, is the only reply thus far that addresses what I also perceive to be the fundamental problem with Haskell - it doesn't provide any new convenient tools to solve real world problems, while requiring one learns a bunch of useless abstractions that aren't used anywhere else in industry as a default (monads, laziness, immutability)

"Favor Immutability" - Effective Java, circa 2001

Should not be controversial at this point.

Re: Haskell for a New Decade [pdf]

#52
post #37

I think the focus on Haskell is missing the mark a bit. Haskell is about programming language researchers and enthusiasts having a excellent example language to try out ideas. Over the years it has turned into a production ready platform. As the PDF shows there are many languages spun off Haskell and it doesn't even mention them all. Then there are language features in C# and Java, Typescript etc. that are coming acr…

Counter point on "investment": I was in a Haskell team at Google, and have trained groups at various companies professionally. From that experience, for a normal developer with working experience in Java, Python, or C++: * It takes 2-3 weeks of full-time onboarding (half with a coach, half self-study) to work on a typical industrial Haskell project. * It takes around 3 months of full-time participation in such a proj…

It was google, a bad sample of programmers.

Re: Haskell for a New Decade [pdf]

#53
post #6

I've heard from some long-time Haskellers that there is no point in continuing using the language after the advent of Rust. EDIT: I should have clarified I guess - interested to hear the opposite arguments (as a neutral (C++) person :)).

For me it's been the opposite. Rust was the first programming language I learned back in 2014, and it's what I've mainly been using until recently. Rust is still my go-to for situations where performance is key, but my most used language today has become Haskell.

Rust is very nice, but when you've used it for long enough you start noticing the warts. I especially miss Higher Kinded Types from Haskell, and I'm constantly reminded of the lack of Functor and Monad etc. At some point I simply realized that for most applications, the generally lower performance of Haskell and the GC is really not a problem at all. I mean, it's not like it's Python slow—it's just a bit slower than C/Rust. The more advanced type system of Haskell is just so nice, that I feel it's worth it.

Re: Haskell for a New Decade [pdf]

#54

I think the focus on Haskell is missing the mark a bit. Haskell is about programming language researchers and enthusiasts having a excellent example language to try out ideas. Over the years it has turned into a production ready platform. As the PDF shows there are many languages spun off Haskell and it doesn't even mention them all. Then there are language features in C# and Java, Typescript etc. that are coming acr…

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. How do we make immutability easy and ergonomic and get rid of nulls in C#?

F# pretty much plays this role within the .NET ecosystem. Almost all of the important advancements in C# over the last few years originated in F# (and FP in general).

Re: Haskell for a New Decade [pdf]

#55
post #37

Earlier quoted context omitted.

Counter point on "investment": I was in a Haskell team at Google, and have trained groups at various companies professionally. From that experience, for a normal developer with working experience in Java, Python, or C++: * It takes 2-3 weeks of full-time onboarding (half with a coach, half self-study) to work on a typical industrial Haskell project. * It takes around 3 months of full-time participation in such a proj…

Thanks for that. Everything you said is from the perspective on being not only in a Haskell job but in a Haskell team. Your 3 months is 5 years for someone trying to learn on their own in their spare time. And then they need this to get a Haskell job due to the competition for such job and the queue of super smart people lining up for a Haskell job. And the pay cuts are brutal. Now you are an outlier, working on a Ha…

> For example a lot of libraries use Lens. I want to understand Lens? It is not simple: check out the diagram on https://hackage.haskell.org/package/lens.

You're making it seem harder that it really is. Yes, it's hard if the package documentation is all you have, but that's the hard way to learn. There are other online unofficial documentation and tutorials (of diverse quality). There's also a book (https://leanpub.com/optics-by-example) that I find adequate for a reasonable learning experience (I think I would have saved much time if I had started learning lens using this book.). And, you don't need to know the entire lens package to use it. The most commonly used part of lens (Lens proper, not Prisms, Isos, etc) is only a small fraction of the whole thing.

Re: Haskell for a New Decade [pdf]

#56

I think the focus on Haskell is missing the mark a bit. Haskell is about programming language researchers and enthusiasts having a excellent example language to try out ideas. Over the years it has turned into a production ready platform. As the PDF shows there are many languages spun off Haskell and it doesn't even mention them all. Then there are language features in C# and Java, Typescript etc. that are coming acr…

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. How do we make immutability easy and ergonomic and get rid of nulls in C#? F# pretty much plays this role within the .NET ecosystem. Almost all of the important advancements in C# over the last few years originated in F# (and FP in general).

Almost all of F# features originated in OCaml, since F# is just a limited copy of OCaml.

Re: Haskell for a New Decade [pdf]

#57

Earlier quoted context omitted.

I can't speak for everyone but for me the type system is not what made Haskell difficult. I loved it. What made it difficult was laziness. I'd find myself always trying to reason about execution (even though most of the time you probably shouldn't). Laziness might even be fine in a world built around it, but for a language to be practical it has to interface with systems that are not designed that way (numerous exter…

Is laziness at all related to IO/effects libraries in Scala like cats-effect or zio? Like where you have to switch your mental model to view a program as something that just describes an eventual outcome but doesn't actually "do" it until some last-minute side effect thing that is bolted on?

In a lazy-by-default language (Haskell) you absolutely have to use those kind of approaches, because you can't write code where effects are important any other way. You have no control over evaluation order (other than dirty hacks), so you can't rely on that to control effect sequencing.

Of course in a strict language with a decent type system like Scala you eventually find you want to use that style anyway. But you can come to it in your own time and see the benefits for yourself rather than having it forced on you.

Re: Haskell for a New Decade [pdf]

#58
post #6

I've heard from some long-time Haskellers that there is no point in continuing using the language after the advent of Rust. EDIT: I should have clarified I guess - interested to hear the opposite arguments (as a neutral (C++) person :)).

Rust doesn't even have higher-kinded types, yet alone kind polymorphism. That means no proper do notation, so look at the complete mess of macro-based syntaxes you have for things like error propagation, async or transactions. Things like recursion-schemes are impossible, and the borrow checker is kind of ad-hoc, meaning the control flow keywords are special cases and you often can't do what should be a very simple substitution when you want to add an effect (e.g. if -> ifM is not possible because if is not an expression and the borrow checker wouldn't be able to handle it if it was).

Rust may be the language that has finally dragged mainstream programming kicking and screaming into the 1970s (it's more or less the equal of Standard ML). It still has a ways to go to catch up with Haskell.

Re: Haskell for a New Decade [pdf]

#59
post #15

I think the focus on Haskell is missing the mark a bit. Haskell is about programming language researchers and enthusiasts having a excellent example language to try out ideas. Over the years it has turned into a production ready platform. As the PDF shows there are many languages spun off Haskell and it doesn't even mention them all. Then there are language features in C# and Java, Typescript etc. that are coming acr…

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. I see a lot of this happening in Kotlin and Rust (not too mainstream, but clearly more mainstream than Haskell). Also FB putting it weight behind Reason/OCaml clearly shows the movement. To be fair: sdiehl did mention in the preso that copying these concept over to other languages t…

> I see a lot of this happening in Kotlin and Rust (not too mainstream, but clearly more mainstream than Haskell).

But only at the most superficial level. It was heartbreaking to hear Kotlin ignore decades of Haskell and Scala experience when it couldn't be condensed into a 10-line example. They've adopted a fundamentally broken approach to representing absence and they'll regret it in 10 years, but it's already too late to fix it. Heck, look at Go ignoring Java's experience with not having generics.

Re: Haskell for a New Decade [pdf]

#60
post #52
post #37

Earlier quoted context omitted.

Counter point on "investment": I was in a Haskell team at Google, and have trained groups at various companies professionally. From that experience, for a normal developer with working experience in Java, Python, or C++: * It takes 2-3 weeks of full-time onboarding (half with a coach, half self-study) to work on a typical industrial Haskell project. * It takes around 3 months of full-time participation in such a proj…

It was google, a bad sample of programmers.

It's odd how the various smaller companies I referred to, many of which are normal enough that you may never have heard of them, get summarised as "It was Google". I only mentioned it to also include the largest org I know where onboarding onto a Haskell project was not a problem.
Post reply on HN