as a new haskell learner who started this month, I've really learned empathy from banging my head against the language
the docs have a specific tone or pattern that's everywhere (and by docs I mean everything -- library readmes, examples, language intros, and stackoverflow posts)
they all read like 'well, you probably haven't been introduced to monads yet. I can't answer your question directly in a short post (these posts are all like 6 paragraphs, nothing short about them), but I'll tell you why you can't do what you're trying to do and I'll also explain why I can't tell you what a monad is'
also my laptop battery keeps dying because the builds are so expensive
The lecture videos are short, about 10mins each, and Professor Grossman explains the concepts carefully and succinctly, within a fixed teaching framework so you have a predictable learning experience with each concept. It's by far the best way to get into the mindset of typed FP.
Type classes, functors, and monads are assumed knowledge in most documentation, as they are foundational concepts in Haskell. Just like math, you must know addition, subtraction, multiplication when learning algebra.
A bunch of languages have some special syntax to solve hairy problems. Async await, yield for generators, ? for dealing with errors in rust, etc.
If those deal with composition and variable scoping in an intuitive way it's a monad. This "intuitive way" is equivalent to changing block scoping in imperative languages.
{
let x = foo()
let y = bar(x)
let z = baz(x,y)
...
}
should stay equivalent to
{
let x = foo()
let z
{
let y = bar(x)
z = baz(x,y)
}
...
}
and you should be able to add empty scopes without changing anything so
{
foo()
}
should still equal
{
{}
foo()
{}
}
And that's the entire definition of monads. The abstract monad interface is useful to let users define new interpretations for the syntax sugar but not necessary when getting started with haskell - you will pick up intuitions while using it.
I’d just recommend skimming over something like Haskell book to gain some vague familiarity with what concepts exist, then just write code and learn applicative/monad/monoid etc as you run into walls.
Generalizations are notoriously hard to describe as they become more general. Better to understand where and when to use those patterns over being able to write a blog post about what a monad is.
I don't know if they're good for others, but I read Real World Haskell[1] and Learn You a Haskell[2]. There's also Graham Hutton's book which people like and which is free to read this month or something[3].
In principle, you wouldn't do any logging, even debug logging, in a pure function. It always returns the same output for the same input anyway. You'd just check its output.
and they all have easy, one-line, correct examples of how to do it, within the first 20 seconds of reading.
(This is not to criticise -- sometimes one misses the forest for the trees -- as a professional Haskell consultant who runs trainings I am genuinely interested into what problems people face and why.)
If you're serious about picking up the language, I urge you to simply start building something. Build something you can relate with, something similar that you've already built with a different toolset. Like a web server.
A lot of the fancy abstractions don't make sense until you have a problem where you'll actually need them. Artificial problems, like some algorithmic assignments in books just don't click nearly as well to many of us.
Monads are very simple. If you know how futures / promises work (the chain of .then), you already have enough intuition about them.
Also, (Glasgow) Haskell has ghci, a rather nice REPL. You only need to learn to use :{ ... :} for multiline stuff. It's very good for quick experimentation with zero build time.
I worked as a Haskell developer for a year and a half. The best productivity boost I had was switching to compiling on an EC2 instance. I saved battery, sped up compiles with greater parallelism than my XPS had cores for, and didn’t have to worry about cleaning up ~/.stack
Could you give a short explanation or link to a write up? Which size of EC2 instance works well for compiling Haskell? Does the EC2 live only for the duration of the compile, or permanently? If only for the duration, how do you deal with persisting the installed libraries to disk? Thanks!
I can’t recall exactly, I want to say 16 vCPUs and 64GB. How well a project can make use of the cores depends on how wide your dependency graph is vs how tall, as the unit of parallelism is a package.
The EC2 instance was on continuously, and I would ssh+tmux in. You could probably replace this with a server plugged in under your desk, depending on how much you trade off operational costs and capital costs.
More often than not I wanted passing tests to send something for review. If I needed an artifact, I would publish a docket image on an internal registry.
the docs have a specific tone or pattern that's everywhere (and by docs I mean everything -- library readmes, examples, language intros, and stackoverflow posts)
they all read like 'well, you probably haven't been introduced to monads yet. I can't answer your question directly in a short post (these posts are all like 6 paragraphs, nothing short about them), but I'll tell you why you can't do what you're trying to do and I'll also explain why I can't tell you what a monad is'
also my laptop battery keeps dying because the builds are so expensive