Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I Wish I Knew When Learning Haskell

dev.stephendiehl.com

Post reply on HN
Print view View original

111–120 of 149 posts

Re: What I Wish I Knew When Learning Haskell

#111

Post by cle »

stavros wrote: post #92
mlthoughts2018 wrote: post #82

Earlier quoted context omitted.

I learned Haskell and used it (and heavily functional Scala) professionally for about 6 years. I feel learning Haskell was worthless. It did not teach me anything about decomposing problems into function units, compositional sequences, pure functions / immutable data structures, lazy evaluation or asynchronous programming that I have found useful in modeling solutions to software problems. Guarantees from the compile…

Why is this downvoted? It's pretty extensive and well thought-out, which should be upvoted. If you disagree, post a rebuttal.

Because these language wars are mostly about people defending their group identity that they've invested a lot of effort into forming. If you want to have focused, fact-based discussions about language tradeoffs, it's more likely to be successful if you stick to small groups of people who are mindful of their egos.

Re: What I Wish I Knew When Learning Haskell

#112

Post by mlthoughts2018 »

jmeister wrote: post #91
mlthoughts2018 wrote: post #82

Earlier quoted context omitted.

I learned Haskell and used it (and heavily functional Scala) professionally for about 6 years. I feel learning Haskell was worthless. It did not teach me anything about decomposing problems into function units, compositional sequences, pure functions / immutable data structures, lazy evaluation or asynchronous programming that I have found useful in modeling solutions to software problems. Guarantees from the compile…

Thank you. This is an important point that deserves to be discussed more. Would you mind sharing what business domain you were working in? I’ve seen static FP being used/popular in finance but not much elsewhere. Also, do you have a favourite language now?

Jobs that exclusively or almost exclusively used Haskell & Scala: (1) backend engineering for a large bank (you can likely guess), (2) machine learning at a large education technology company, (3) machine learning at an ad tech company.

My favorite two languages are Python and C. There are certain things I like about Rust, Go and Julia.

I dislike Java and C++ (just personal preference).

I dislike Scala a ton. Really disergonomic and overly complicated.

I like Haskell a lot. Very clean, fun to write, it just doesn’t confer any serious advantages over other language choices and does suffer from difficult-to-extend designs in business use cases, but probably very good for academic work, pure software or research projects. It’s very nice language, I just wish it wasn’t hyped as a transformational way of thinking or as a panacea for all the normal annoying problems with business software.

Re: What I Wish I Knew When Learning Haskell

#113

Post by hopia »

mlthoughts2018 wrote: post #82
eklavya wrote: post #46

Really just learn it. It's a pity I don't use Haskell at work and yet learning Haskell was the single most bang for buck exercise I have ever done. "Parallel and Concurrent Programming in Haskell" is the best resource I have ever read on parallel and concurrent programming concepts. Every programmer should learn this language even if they never plan/get to use it.

I learned Haskell and used it (and heavily functional Scala) professionally for about 6 years. I feel learning Haskell was worthless. It did not teach me anything about decomposing problems into function units, compositional sequences, pure functions / immutable data structures, lazy evaluation or asynchronous programming that I have found useful in modeling solutions to software problems. Guarantees from the compile…

> yet is an area where functional languages are uniquely poorly suited

Can you clarify if you mean that the type system gets in the way here, or the same would apply to even dynamically typed functional languages?

I'm trying to understand if you think a static type system is the hindrance here, or the language being functional in paradigm.

Re: What I Wish I Knew When Learning Haskell

#114

Post by harry8 »

If you're thinking of learning Haskell you should consider the software written in haskell as an indicator of, well, something.

List all the programs useful for something other than programming a computer written in haskell:

Xmonad window manager Git annexe Pandoc

What else, let's get the full list. Exclude anything that we can't directly see or use.

I say, yes! Learn Haskell! Just don't expect to write any useful programs because they're pretty rare for people to have written when they've doesn't time learning Haskell.

It is great fun. Do it!

Re: What I Wish I Knew When Learning Haskell

#115

Post by Ericson2314 »

harry8 wrote: post #114

If you're thinking of learning Haskell you should consider the software written in haskell as an indicator of, well, something. List all the programs useful for something other than programming a computer written in haskell: Xmonad window manager Git annexe Pandoc What else, let's get the full list. Exclude anything that we can't directly see or use. I say, yes! Learn Haskell! Just don't expect to write any useful pr…

And how many programmers are paid to write anything anyone has heard of? And how many new well-known not-de elopement-related tools have been written in the last few years?

Re: What I Wish I Knew When Learning Haskell

#116

Post by 0_gravitas »

lonelappde wrote: post #80
mikorym wrote: post #67

Earlier quoted context omitted.

If I am not mistaken, Dijkstra advocated for Haskell to be used as a language of instruction at universities. There is an essay somewhere online about it. What I could find is this: [1]. Edit: Indeed, the PDF that is linked to in [1] looks like a scan of the original. [2] [1] https://chrisdone.com/posts/dijkstra-haskell-java/ [2] http://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budg...

Note that Dijkstra recommendes Haskell over Java because Haskell is arcane and mathematical, which is good for learning computer science, not because it's good for writing software.

I'm gonna need a quote on that one

Re: What I Wish I Knew When Learning Haskell

#117

Post by StavrosK »

cle wrote: post #111
stavros wrote: post #92

Earlier quoted context omitted.

Why is this downvoted? It's pretty extensive and well thought-out, which should be upvoted. If you disagree, post a rebuttal.

Because these language wars are mostly about people defending their group identity that they've invested a lot of effort into forming. If you want to have focused, fact-based discussions about language tradeoffs, it's more likely to be successful if you stick to small groups of people who are mindful of their egos.

Sure, but it's also more likely to be successful if you remind people to mind their biases.

Re: What I Wish I Knew When Learning Haskell

#118

Post by mlthoughts2018 »

cle wrote: post #111
stavros wrote: post #92

Earlier quoted context omitted.

Why is this downvoted? It's pretty extensive and well thought-out, which should be upvoted. If you disagree, post a rebuttal.

Because these language wars are mostly about people defending their group identity that they've invested a lot of effort into forming. If you want to have focused, fact-based discussions about language tradeoffs, it's more likely to be successful if you stick to small groups of people who are mindful of their egos.

This is a fact-based discussion of language trade-offs. The strength of a statically typed functional language, that you are forced to specify correctness of the program at increasingly abstract levels of the type system, is also its downfall because this is inherently inflexible if the business use case of that software suddenly demands incrementally mutating some part or introducing subtle violations of the constraints the system was designed to enforce. The entire goal of encoding correctness and rendering it difficult or impossible to violate a given notion of correctness is intrinsically at odds with the business purpose of software. This is fundamental. It is a real, physical problem that makes strict functional languages significantly worse suited to business settings than imperative or even object-oriented paradigms, and is supported by language popularity, adoption and success rates.

The fact that classes of bugs prevented by compilers are not very important and are just as adequately caught with lightweight unit tests is more empirical but critical nonetheless.

These are real problems with the arguments in favor of strict functional programming. But instead of engaging with them, they are disingenuously called “language wars” as if they are less legitimate just by using this phrase to describe them.

Re: What I Wish I Knew When Learning Haskell

#119

Post by mlthoughts2018 »

hopia wrote: post #113
mlthoughts2018 wrote: post #82

Earlier quoted context omitted.

I learned Haskell and used it (and heavily functional Scala) professionally for about 6 years. I feel learning Haskell was worthless. It did not teach me anything about decomposing problems into function units, compositional sequences, pure functions / immutable data structures, lazy evaluation or asynchronous programming that I have found useful in modeling solutions to software problems. Guarantees from the compile…

> yet is an area where functional languages are uniquely poorly suited Can you clarify if you mean that the type system gets in the way here, or the same would apply to even dynamically typed functional languages? I'm trying to understand if you think a static type system is the hindrance here, or the language being functional in paradigm.

Type system designs in statically typed functional languages are intended to represent increasingly abstract correctness constraints by transforming the business logic of the problem at hand into rules subject to the validation of the compiler.

This is quite different than object oriented or even compiled imperative languages where type system constructs contain data and function units that represent internalized constraints.

In functional programming you set up types and their constraints such that the business logic you require is a derivable consequence of the system and any other outcome is as close to provably impossible as can be. The less of this you choose to enforce, the more “imperativy” or “objecty” your use of that functional language is.

In imperative or OO languages you choose to make atomic units that have internal structure, but whose behavior across the interaction of the units is not itself a derivable consequence of any more abstract set of rules. Not even interfaces or templates represent this - they govern how components can communicate but do not limit what components can do.

You use the program’s structures to carry out the required business logic, but you cannot truly prove you haven’t allowed for some different logic or edge case instead.

In this sense, safety is a resource rather than a requirement, and if you learn that a previously unsafe operation is now safe, because the real world circumstances changed around you, you are free to have your program units do the previously-unsafe -now-safe thing without needing to remove expensive abstractions that had been set up to cause the previous notion of safety to be a consequence of your program.

Re: What I Wish I Knew When Learning Haskell

#120

Post by UncleMeat »

shahbaby wrote: post #98

A few years ago I accidentally deleted my entire Haskell assignment about 1 day before it was due. Within a few hours I rebuilt it from scratch. That's when I realized the power of functional programming. There's no way I have been able to recover that quickly if I had used an imperative programming language. Since that experience I've tried to follow a functional programming style whenever I can. I've realized that…

But it was a programming assignment. Building a thing fast is, outside of very few situations, not a thing to optimize for. Building something to be maintained and evolved over time by non rockstars is far far more important, IMO. Perl is great for ripping through some script quickly but it has problems for long term maintenance.
Post reply on HN