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

91–100 of 149 posts

Re: What I Wish I Knew When Learning Haskell

#91

Post by jmeister »

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…

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?

Re: What I Wish I Knew When Learning Haskell

#92

Post by stavros »

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…

Why is this downvoted? It's pretty extensive and well thought-out, which should be upvoted.

If you disagree, post a rebuttal.

Re: What I Wish I Knew When Learning Haskell

#93

Post by Koshkin »

kadoban wrote: post #53
Drakim wrote: post #17

Earlier quoted context omitted.

What I think he meant is more like "either do things the functional Haskell way or you don't do them", as in, there is no non-functional fallback or alternative in the language, which some functional languages have.

There's escape hatches here and there. If you need imperative code, use IO or ST. If you need to debug output something, Debug.Trace. If you need to temporarily bypass purity there's unsafePerformIO and friends (or they can occasionally be used permanently if you do a lot of analysis I believe). It's a pretty practical language compared to its reputation.

Actually, someone said, “Haskell is the world’s best imperative programming language.”

Re: What I Wish I Knew When Learning Haskell

#94

Post by diegoperini »

goto11 wrote: post #87
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...

> Colleagues from outside the state (still!) often wonder how I can survive in a place like Austin, Texas, automatically assuming that Texas’s solid conservatism guarantees equally solid mediocrity. My usual answer is something like “Don’t worry. The CS Department is quite an enlightened place... Very Dijkstra to start by insulting the intended audience. Wonder if it had the intended effect?

I'm not a native English speaker. Where is the insult?

Re: What I Wish I Knew When Learning Haskell

#95

Post by Koshkin »

tossup8536 wrote: post #74
remcob wrote: post #62

Earlier quoted context omitted.

What's wrong with it?

Performance. Internal representation. You are not actually modifying things in place. Those are the equivalent of linked lists not arrays. That quicksort is not quick at all because the append operation in Haskell is linear. You can't use those lists to implement quicksort.

“Modifying things in place” is, from the logical standpoint, an unnatural and even dangerous thing. A person that is not familiar with (imperative) programming often has a hard time understanding variables and assignments (similar to some programmers not understanding pointers). Mathematics doesn’t have assignments, either. That should tell you something...

Re: What I Wish I Knew When Learning Haskell

#96

Post by rrobukef »

zetalemur wrote: post #89
DavidWoof wrote: post #69

Earlier quoted context omitted.

I agree with this, learning Haskell was transformative for me. It changed the way I approached problems in every other language. I treat learning it as one of the 2 or 3 things that has most influenced my development skills. But the truth is that I still don't feel comfortable writing anything more than toy apps in Haskell. I'm not really sure how to unit test things when I'm passing complex monad transformers around…

> I treat learning it as one of the 2 or 3 things that has most influenced my development skills. If you don't mind, what were the other 1 or 2 things?

Personally: Prolog in addition to Haskell and SCIP.

Re: What I Wish I Knew When Learning Haskell

#97

Post by erik_seaberg »

Koshkin wrote: post #90
lonelappde wrote: post #80

Earlier quoted context omitted.

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.

No one would recommend a language “because it’s arcane.”

I would recommend a language because it's different than anything you're familiar with. It gives you more approaches to solving problems.

Re: What I Wish I Knew When Learning Haskell

#98

Post by shahbaby »

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 every variable is another state which adds to the complexity of the code.

Re: What I Wish I Knew When Learning Haskell

#99

Post by ampdepolymerase »

diegoperini wrote: post #94
goto11 wrote: post #87

Earlier quoted context omitted.

> Colleagues from outside the state (still!) often wonder how I can survive in a place like Austin, Texas, automatically assuming that Texas’s solid conservatism guarantees equally solid mediocrity. My usual answer is something like “Don’t worry. The CS Department is quite an enlightened place... Very Dijkstra to start by insulting the intended audience. Wonder if it had the intended effect?

I'm not a native English speaker. Where is the insult?

Mediocrity is not praise.

Re: What I Wish I Knew When Learning Haskell

#100

Post by pwm »

DavidWoof wrote: post #69
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 agree with this, learning Haskell was transformative for me. It changed the way I approached problems in every other language. I treat learning it as one of the 2 or 3 things that has most influenced my development skills. But the truth is that I still don't feel comfortable writing anything more than toy apps in Haskell. I'm not really sure how to unit test things when I'm passing complex monad transformers around…

From my experience the key to becoming comfortable writing "real" apps in Haskell, or any language for that matter, is to just do it and keep at it. The easiest path, and the one I chose, is to do it full time as your day job. When you write Haskell all day every day you'll get comfortable with it surprisingly quickly. You also realise that it's not a panacea, it's just a language but a damn fine one at that. You can (and should!) write super simple, unceremonial Haskell the vast majority of the time if you are writing "real" apps as opposed to pushing theoretical boundaries.

Re code architecture and arranging code - It's not that different from what you'd do in any other language and it's more of a domain question (a webapp?, a game?) then a language one. If and when you change your mind though to move things around/re-architecture your code that is when Haskell really shines. Compiler assisted refactoring is one of the superpowers. It's like having google maps in a foreign city, it guides you to whatever your destination is.

Post reply on HN