
An opinionated guide to Haskell - kryptiskt
https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/
======
resoluteteeth
I've tried messing around with haskell a few times, but the biggest problem I
have is the tooling.

I just tried to get haskell set up a few days ago and I couldn't get it
working with either vscode or Idea. I also couldn't get ihaskell (jupyter
notebook) installed successfully.

I might give it another shot based on these instructions, but the fact that
pretty much every program seems to make different assumptions about whether
you're using cabal or stack and how you have them set up is really annoying. I
assume if you are really knowledgeable about this tools it's not that bad, but
as a haskell beginner they are completely impenetrable. (Even just the yaml
files used by stack seem completely incomprehensible compared to the formats
used by most languages' build tools.)

Considering that the language itself has a pretty steep learning curve, it's
really frustrating wasting several hours just trying to get the haskell
environment set up without success and not even getting the point of being
able to try to actually use it.

I've had a pretty bad opinion of the Ocaml and F# tooling in the past, but the
haskell tooling is just so, so much worse. (F# seems to have gotten to a point
where the tooling if you can just use .net core, although it gets horrible
again if you then need to also use mono at the same time so you can use the
interpreter.)

It's especially bad if you compare it to something like rust where cargo works
so well it's actually in itself a reason to use rust.

~~~
platz
ihaskell is a somewhat fragile project briding several disparate
ecosystems/languages. I'm not really sure the value-add is there yet; in any
case it is not a tool for beginners or the preferred method to get feedback
from your programs.

Haskell proper is pretty turn-key these days with stack.

Stay away from edgelord / niche projects.

Stay away from most of the IDE tooling, including ghc-mod. You don't need to
be fighting the tooling when starting. The repl and "ghcid" should be all you
need (though I grant it takes some learning to use these as effectively if
you're used to an IDE- you will learn with experience).

Just use the "ghcid" cli tool to get compile errors and feedback. It is rock
solid.

[https://github.com/ndmitchell/ghcid](https://github.com/ndmitchell/ghcid)

Your experience will be much smoother.

It takes a bit getting used to if you're used to an IDE, but with Haskell it's
usually a better to go for a multi-terminal/repl kind of setup

~~~
resoluteteeth
> Stay away from most of the IDE tooling. You don't need to be fighting the
> tooling when starting. The repl and "ghcid" should be all you need.

I'm honestly not sure I'm interested in learning haskell if this is considered
an acceptable situation.

~~~
platz
There _is_ editor tooling, you can look at intero or dante for that. It works.
My point is as a beginner, it is added friction when the focus should be on
learning how to use the repl and the language. If you absolutely require an
IDE, Haskell is probably not going to be your favorite language.

~~~
twic
I make the same recommendation for people learning Java, and Java has the best
IDE support there is. The fact is that an IDE is a large and complex tool with
a lot of details to understand, and jt will sap mental energy that is needed
for dealing with the new language.

When starting out, pick a common programmer's editor you already know, find a
syntax highlighter for it, and turn on auto-indentation. If there's a plugin
or tool which does auto-formatting and doesn't need a lot of tweaking, add
that too. Learn an IDE once you understand the language and are getting
frustrated by boilerplate, navigation, etc.

------
allenleein
For people who wanna learn Haskell:

1\. __Don 't touch Haskell platform. Install Stack. __

If you did, Uninstall it.

[https://mail.haskell.org/pipermail/haskell-
cafe/2011-March/0...](https://mail.haskell.org/pipermail/haskell-
cafe/2011-March/090170.html)

Why? It is considered harmful

[https://mail.haskell.org/pipermail/haskell-
community/2015-Se...](https://mail.haskell.org/pipermail/haskell-
community/2015-September/000014.html)

2\. Install Stack:

[https://haskell-lang.org/get-started/osx](https://haskell-lang.org/get-
started/osx)

If you do not wish to install these dependencies, you may use a virtual
machine instead

[https://github.com/data61/fp-
course/blob/master/ops/README.m...](https://github.com/data61/fp-
course/blob/master/ops/README.md)

3\. Learning resources:

[https://github.com/allenleein/brains/projects/9](https://github.com/allenleein/brains/projects/9)

~~~
aaronchall
I consulted with one of the co-organizers of the Haskell meetup here in NYC,
and while he seems to have a nuanced view that is anti-stack for professional
Haskellers, he also recommends stack for new people.

I'm thinking the consensus is that this is good advice.

------
Cieplak
A lot of people use Atom, but I think emacs + intero is currently the best
Haskell tooling. I use it with spacemacs. Has everything I would need from an
IDE, including highlighting errors on the fly, auto completion, jump to
definition, auto formatting. It’s no intellij, but I’ll take Haskell’s type
safety over that any day of the week, and twice on Sunday.

[http://commercialhaskell.github.io/intero/](http://commercialhaskell.github.io/intero/)

~~~
s4vi0r
+1, emacs+intero is the way to go.

Emacs in general is highly underrated due to years of RSI/muh loading time
shitflinging. Evil mode is by far the most complete vim emulation out there,
and other than JS pretty much every language I write has been a more
enjoyable/easy experience on Emacs than it was on vim or st3.

~~~
james-mcelwain
I'm writing a lot of Java right now, and it's frustrating that the experience
is so horrible on Emacs -- or so much better in Intellij. I tried using Eclim
with Emacs for a while, but it's so tedious moving through Java without a
specialized IDE. Still, I keep Emacs open on Java code solely for the git
interface (magit) and helm integration with `ag`, which I find vastly superior
to find-in-path / regex search capabilities in Intellij.

------
dmitriid
> There was a time when cabal-install had a (warranted) reputation for being
> nearly impossible to use and regularly creating dependency hell

> You almost certainly do not want to use stack install.

> The .cabal file is, ultimately, what is used to build your project, but
> modern versions of stack generate projects that use hpack, which uses an
> alternate configuration file, the package.yaml file, to generate the .cabal
> file. This can get a little bit confusing, since it means you have three
> configuration files in your project

> Frankly, I think the UX around this is terrible.

This goes to show that no amount of static typing can save you from
implementing badly-designed software.

~~~
Devac
> This goes to show that no amount of static typing can save you from
> implementing badly-designed software.

Sure, but that's like saying "you can die to cancer even if you drive around
in a Volvo."

~~~
dmitriid
This analogy (as any analogy) is wrong. A slightly better one would be "an
expensive camera doesn't automatically make you a great photographer".

There's a long running tradition of languages with static typing and better
type systems making fun of dynamically typed languages and those with "worse"
type systems.

A good example is[1]: """ It's 2018 - static type systems are not optional...
It is especially worrying that these people think they are gaining velocity by
trading correctness. """

And yet I'm seeing more and more examples where (often preceived) correctness
is often offset by much bigger problems. Another example is mini-thread on how
horrible DateTime is in Haskell:
[https://twitter.com/chris__martin/status/956002730778288128](https://twitter.com/chris__martin/status/956002730778288128)

[1]
[https://twitter.com/timperrett/status/957493915937943554](https://twitter.com/timperrett/status/957493915937943554)

~~~
tome
Any weaknesses with the Haskell "time" library have nothing to do with static
types in particular nor the language in general.

To stretch your analogy further "Having an expensive camera does not prohibit
you from also taking photography lessons".

~~~
dmitriid
> Any weaknesses with the Haskell "time" library have nothing to do with
> static types in particular nor the language in general.

Hence, my original point: This goes to show that no amount of static typing
can save you from implementing badly-designed software.

~~~
tome
If your point was literally "no amount of static typing can save you from
implementing badly-designed software" then yes, that's correct and beyond
challenge. I perceived a hint of "and therefore we may as well just use
dynamic types" or "but proponents of static types are too ideological to
accept this" in your subtext. I apologise if I was mistaken in my perception.

~~~
dmitriid
I have to admit, there was a hint of such subtext :)

------
audiolion
Wow, I wish this existed when I was wprking with Haskell a few years ago. This
is a compendium of useful information. I really love how Haskell makes me
think and code in an entirely different way. It is fun, and I hope the
language continues to grow.

------
resoluteteeth
OK, I am trying to install haskell again using the instructions given in this
guide.

I removed my existing stack installation and my .stack directory, installed
stack again, created a new stack project and then ran the recommended command
in the guide to install ghc-mod and related tools: "stack build -j 8 --copy-
compiler-tool ghc-mod hoogle weeder".

I get an error:

Error: While constructing the build plan, the following exceptions were
encountered:

In the dependencies for ghc-mod-5.8.0.0: Cabal-2.0.1.1 from stack
configuration does not match >=1.18 && <1.25 (latest matching version is
1.24.2.0)

...etc.

Can someone explain what's causing this?

~~~
s4vi0r
Cabal version too high. Did you have a pre existing cabal installation
independent of stack or something?

~~~
resoluteteeth
I don't think that I do. Is it possible that ghc-mod is broken on lts-10.5?

~~~
lexi-lambda
It isn’t broken in lts-10.5, it just isn’t in lts-10 at all. Go to
[https://www.stackage.org/lts-10.5](https://www.stackage.org/lts-10.5) and
search for ghc-mod—it just isn’t currently available.

Unfortunately, the reason for this is that ghc-mod still isn’t updated for GHC
8.2. It’s almost there—a package candidate has been uploaded that works
alright—but it hasn’t made it into the LTS yet. There’s a way to build and
install the package candidate in a way that will work with stack, which I have
done on my personal machine, but honestly I decided it was just too much for
this (already overly long) blog post.

------
cauterize
This is really great. I'd love to see a follow up covering other topics. Such
as testing (with hedgehog), modeling SQL, etc. Or -- anything that helps open
up the world to see how Haskell is a beautiful language to build on.

------
dvddgld
Learning Haskell is one of those two weeks things that’s been on my interests
list for a long time, but will likely stay there for awhile yet.

Though, if anyone has got any high-quality quick resources handy that’d be
appreciated!

~~~
cauterize
[http://haskellbook.com/](http://haskellbook.com/) is a great modern deep dive
catered to folks like you! It is long, but guides you along the way

~~~
pimeys
Need to reply after one day, but I read the sample, figured out an environment
for Haskell using Spacemacs and bought the whole book. Because of your link, I
decided to be proficient with Haskell in 2018. 2016 was the year of Clojure,
2017 Rust and now Haskell.

Thank you in advance!

------
latte
How good is the static analysis tooling (IDE / editor plugins) for Haskell?

Given Haskell's powerful type system, I imagine that it must be possible to
see warnings, hints, autocompletion and other early feedback about the code in
the editor before compilation, like in Java, Kotlin etc. or even better - is
that the case?

~~~
tathougies
I use emacs + intern and it’s great. Type errors are underlined immediately,
warnings and lint messages are marked. Half the time I let the compiler write
the code by using ghc placeholders and playing type golf

~~~
AlexCoventry
> Half the time I let the compiler write the code by using ghc placeholders
> and playing type golf

Is this method documented anywhere? Sounds interesting.

~~~
tathougies
Just put in an underscore where you want to write code. If you compile the
code, GHC outputs an error with the expected type as well as all bindings in
scope. Then, just work backwards. If you use intero, then all type errors are
underlined, including placeholders.

The general feature is called 'typed holes', and there's a wiki page here:
[https://wiki.haskell.org/GHC/Typed_holes](https://wiki.haskell.org/GHC/Typed_holes)

~~~
AlexCoventry
Thanks.

------
jadbox
When I look at many modern Haskel guides, they all seem to recommend adding
all these extensions/sugar into your code. If these things are so common to
use, why doesn't Haskel adopt them into core?

~~~
badwebsite
Haskell is a standardized language that moves very slowly. Some of the
extensions may be integrated into Haskell2020.

~~~
Buttons840
The most recent progress on Haskell 2020 seems to be a GitHub issue in which
the committee members admitted work had stalled and put forth some ideas to
improve things. That was 9 months ago though.

