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

51–60 of 149 posts

Re: What I Wish I Knew When Learning Haskell

#51

Post by CyberDildonics »

tmountain wrote: post #23
giantDinosaur wrote: post #18

Earlier quoted context omitted.

I imagined it was more in the sense of the 'Have fun implementing Quicksort!' variety, where you're fighting the language constructs, basically, to do what you want.

Haskell has a huge catalog of libraries you can reach for, so you don’t have to reinvent the wheel. That said, the Haskell way can seem very different than what you see in most languages. As an example, IO—or anything causing a side effect—has to happen in the IO Monad. There are good reasons for this, but it takes some getting used to.

But you do have to invent something or you wouldn't be writing a program in the first place.

As soon as you need to control the order of execution, memory usage, IO, or any combination of those, you are fighting the language and into territory of things you can technically do and out of the realm of things the language makes easy.

Re: What I Wish I Knew When Learning Haskell

#52

Post by hopia »

lonelappde wrote: post #31
willtim wrote: post #24

Earlier quoted context omitted.

Debugging declarative code is always hard, whatever the language. Haskell does allow you to use trace expressions which will output values to standard out, see Debug.Trace. This is no reason to avoid arguably the most popular (and state-of-the-art) function language and implementation out there.

Debug.Trace won't solve the space leaks lurking around every corner of your program, and won't shave the hundreds of megabytes to gigabytes of RAM the compiler needs for compiling a non trivial program with dependencies.

It's for runtime debug logging after all, not intended to solve those issues.

Space leaks I'd like to read more about but writings about them are a bit hard to come by. Recommendations?

Re: What I Wish I Knew When Learning Haskell

#53

Post by kadoban »

Drakim wrote: post #17
marceloabsousa wrote: post #14

Earlier quoted context omitted.

What do you mean by "either do things the Haskell (way) or you don't do them"? Isn't that the same with every language? I still don't understand why people put all sorts of unfair labels on Haskell. By labelling Haskell with "fun", we almost make it sound like it can't be used in production.

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.

Re: What I Wish I Knew When Learning Haskell

#55

Post by CyberDildonics »

tmountain wrote: post #34
vkou wrote: post #25

Earlier quoted context omitted.

The parent poster is not lamenting that Haskell lacks a trivial sorting function. They are lamenting that implementing a trivial sorting function in Haskell is difficult.

I disagree. quicksort [] = [] quicksort (x:xs) = let smallerSorted = quicksort [a | a x] in smallerSorted ++ [x] ++ biggerSorted

Won't this have to iterate through linked lists and create multiple new heap allocations on each recursive step? Doesn't that imply n log n heap allocations just to sort a list?

Re: What I Wish I Knew When Learning Haskell

#56

Post by efnx »

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.

Agreed. The concepts are very useful and applicable elsewhere.

Re: What I Wish I Knew When Learning Haskell

#57

Post by mFixman »

CJefferson wrote: post #3

I feel this might have grown beyond its title. Picking the point where I gave up, giving me a list of 7 vscode plugins, without any guidance as to which are more mature, doesnt feel like a thing anyone would wish to know before they start.

What's the point of using 7 VSCode plugins for a language you don't even know? Just pick up any terminal, any text editor, and the freshest stable copy of GHC.

Re: What I Wish I Knew When Learning Haskell

#58

Post by gstipi »

CJefferson wrote: post #3

I feel this might have grown beyond its title. Picking the point where I gave up, giving me a list of 7 vscode plugins, without any guidance as to which are more mature, doesnt feel like a thing anyone would wish to know before they start.

The VS Code plugin listed (haskell-ide-engine, https://github.com/haskell/haskell-ide-engine - to be more precise, it's a language server supporting many editors) is probably the one which sees the most development at the moment and comes with many of the other plugins listed or equivalent functionality (syntax highlighting, tab completion, linting via hlint, code formatting, refactoring) included. It certainly is the tool I would recommend to VS Code users.

Re: What I Wish I Knew When Learning Haskell

#59

Post by gstipi »

lonelappde wrote: post #32
CJefferson wrote: post #3

I feel this might have grown beyond its title. Picking the point where I gave up, giving me a list of 7 vscode plugins, without any guidance as to which are more mature, doesnt feel like a thing anyone would wish to know before they start.

No one said it's what they would wish to know before they start. Take it from someone who spent 10 years on and off learning Haskell: It's a guide to navigating the boobytrapped minefield of the Haskell ecosystem, from the difficulties of installing it for the first time, to the confusing type theory. Those aren't 7 plugins to choose from. Those are 7 plugins you should use all 7 of because there is no unified cohere…

Please take a closer look at the first plugin listed for VS Code, haskell-ide-engine, https://github.com/haskell/haskell-ide-engine

It is under active development and is the closest you can get to a "unified coherent Haskell plugin" - it comes with all the features you would get from installing the 7 plugins individually.

Re: What I Wish I Knew When Learning Haskell

#60

Post by dan-robertson »

Random_ernest wrote: post #22
dcl wrote: post #2

Great timing. I was just pondering what functional programming language I should attempt to learn in all my new downtime.

I tried to learn FP multiple times by learning haskell. Never clicked, tried clojure and I was productive after roughly 2 days.

As a counterpoint, I picked up (some) haskell pretty quickly.

I read a lot of code and didn’t get bogged down reading explanations of what a monad is. I also avoided trying to understand too well what the evaluation semantics of the language were.

When I read code, I focused on looking at the type signatures and understanding what they meant, then I would stare at the code and try to work out in my head why those definitions would get those types.

I did this at a time when there were lots of “I wrote a program in Haskell. Let me explain how it works” blog posts on this site.

I defined some data structures and solved a bunch of project euler problems as practice

Post reply on HN