An opinionated guide to Haskell
lexi-lambda.github.io
lexi-lambda.github.io
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.
The fact that haskell users seem to think these things are completely obvious and doesn't need to be explained is frankly a big part of the problem.
stack new my-project
cd my-project
stack ghci
> main
Haskell’s community evolved very differently from JS and the rest of open source. What seems simple to many isn’t necessarily what seems simple to the rest of us. Much of what this community considers simplicity is just convention and familiarity.
But so many people from our world are using it now that things are slowly becoming more “intuitive”!
I understand your frustration. It took me a lot of effort to get over the learning curve. Well worth it. But trust me, it’s easier than ever and getting better
[0] https://marketplace.visualstudio.com/items?itemName=UCL.hask...
[1] https://marketplace.visualstudio.com/items?itemName=Vans.has...
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
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
I'm honestly not sure I'm interested in learning haskell if this is considered an acceptable situation.
It is annoying to not have the high quality of IDE tooling you'd enjoy with Java, but in contrast to Java you can be very productive in Haskell even without advanced IDEs (though you would be even more productive with them).
There will be IDE tooling eventually.
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.
VSCode as an editor that just works.
Opam for package management
JBuilder for managing builds.
Stdlib situation is still kind of a mess, but I think Base (which is just a stripped down Core) solves a lot of the current issues.
On the other hand I'm more pessimistic about the stdlib situation because Base breaks compat with the stdlib, thus making the migration impossible (or really painful) for a lot of projects. I'll therefore stick to my own extension of the stdlib (containers) in the foreseeable future…
I still can't get point-at type to work in emacs/vim for rust reliably(macros make it even worse).
Haskell tooling is good enough(i haven't worked on big projects, so maybe it doesn't scale) now with intero if you use emacs.
That‘s something Rust got very right from the beginning.
The learning curve is definitely, shamelessly high. We've been slowly polishing it to make it easy for complete beginners to fully up-to-speed on a project in minutes, but it's a lot of work that happens mostly on weekends.
Watch this space!
All of the functionality is just leveraging nix's powerful declarative model which easily defines the build artifacts of a project along with the environments necessary to hack on or compile them.
This sits on top of cabal and stack, actually. Within a project shell provided by Nix, I'll use cabal to get a repl, for example. But since Nix is handling all the dependency management, cabal doesn't have to do any work in that regard.
And, Nix doesn't work well with existing tools like intero, it requires troubleshooting to get working with ghc. You can pick either stack or cabal and both sort of support Nix, but in every case some tooling will not quite work right.
Further, if you're not doing 100% open development, Nix's delivery story is also complicated. It's further challenged for projects using private docker or GitHub repos, where in many cases there is simply no support in Nix.
No one does Haskell newbies any favors by suggesting they learn a whole new package expression language and toolchain (that they will be interacting with deeply and constantly) in addition to a language that is full of fundamentally novel concepts and a vast breadth of new libraries, techniques, and a distributed documentation style.
Please. Stop recommending Nix to new Haskell users until at least the new porcelain commands are shipped.
That sounds like a recommendation.
Everyone has different priorities. I know some users who started using Haskell at all with reflex-platform despite the difficulty because it scratched exactly their itch.
Webpack: it's like lens error messages for your builds, at runtime!
But your experience and your requirements differ from mine, and in a professional capacity I could never recommend Nix for an organization.
[1] - http://haskellformac.com
From the tutorials they give, you can build all types of stuff. It looks like the IDE supports game development as well as some data analytics tools. In Haskell for Mac, the right side is like Swift Playgrounds (REPL) and the left side is like IntelliJ (IDE). It's actually kinda weird but that's how it's setup.
[1] - https://cryptomiso.com
This is my recipe for starting with haskell and intellij: - install stack, run `stack new helloworld simple-hpack` - make sure it builds: `cd helloworld && stack test --exec helloworld` - install https://github.com/rikvdkleij/intellij-haskell and follow the `Getting started' guide
Interesting. I would advice to start with plain cabal. One has to learn how to deal with cabal anyway, so there's no point adding stack on top of it from the start.
Nah, I haven't used cabal-install in years now. Because of hpack, you don't even need to write .cabal files.
The only time I touch cabal is when I need to write Setup.hs files, which is, mercifully, quite rare.
With *.cabal project files yes, for sure.
But `stack` has completely replaced `cabal` command for me. I don't even have it installed.
I'd estimate 80% of the time I fail to compile. Typical reasons are errors from Cabal, stack is wrong version, things like that.
If it was C or Python or even Rust I'd forge ahead and make it work. But with Haskell's tooling I'm too far out of my depth to bother.
Stack (and stackage) is the best nicest, most-reliable build-system of any language.
So far, just in these comments I've seen:
1. just use plain cabal
2. use stack, you don't need cabal
3. use gchid
4. haskell+nix is best
5. use hpack
PS. I bought HaskellForMac and it's great. It ties you a Haskell version a little older than the latest but that's OK too.
1. Don't touch Haskell platform. Install Stack.
If you did, Uninstall it.
https://mail.haskell.org/pipermail/haskell-cafe/2011-March/0...
Why? It is considered harmful
https://mail.haskell.org/pipermail/haskell-community/2015-Se...
2. Install Stack:
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...
3. Learning resources:
I'm thinking the consensus is that this is good advice.
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.
> 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.
Sure, but that's like saying "you can die to cancer even if you drive around in a Volvo."
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
[1] https://twitter.com/timperrett/status/957493915937943554
To stretch your analogy further "Having an expensive camera does not prohibit you from also taking photography lessons".
Hence, my original point: This goes to show that no amount of static typing can save you from implementing badly-designed software.
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?
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.
Though, if anyone has got any high-quality quick resources handy that’d be appreciated!
Thank you in advance!
However, it was written a long time ago, and is missing a lot of Haskell's recent history. The book targets GHC 6.8, whereas I'm running 8.2.2. There's a summary at [1]
Again, it's a great book and the price is right, but caveat lector.
[1] http://support.oreilly.com/oreilly/topics/when-will-it-be-an...
Check here for a review that really resonated with my experiences about LYAH:
http://bitemyapp.com/posts/2014-12-31-functional-education.h...
Note the author of that post is also the author behind the Haskell book, which is also what I'd recommend currently.
Allen can argue that LYAH is incomplete, and he seems to think the university courses he mentions are the best way to learn Haskell. But not all developers want to go down that route, at least not as a first step. For me, LYAH was an important stepping stone to getting productive, while at the same time fully understanding that it was not the final word on anything.
This is, I suspect, what Allen doesn't get. His Haskell book is actually yet another example of why many developers find Haskell daunting to learn; it starts at the deep end, like many books before it. LYAH succeeds precisely because it doesn't go into several pages about beta reduce before explaining how variables are declared. Sure, it's chatty, it likes to rely on the REPL to show evaluations, and it also doesn't start with a formal introduction to functional languages or lambda theory. But it's a book written for programmers who already know how to code. It's approachable, doesn't go into unnecessary detail (if you want to know everything about List, go somewhere else; the Haskell Book has 59 pages devoted to it!), and lets you get up to speed fast without falling off along the way. It's an introductory mini course, and by the end of it you'll be able to write programs.
I don't buy Allen's arguments about it being "unpedagogical". I've never used book exercises and I never will, yet I didn't have any issues learning Haskell, or any other programming book for that matter. The absence of exercises in LYAH doesn't make it a bad book.
As an aside, Allen co-wrote what he claims is a superior book, and then published it as... a PDF. I just purchased it, and was immediately disappointed I had paid $59 for what amounts to a paper book in digital form, with no web version (the "online" version on gumread.com doesn't even provide hyperlinks within the book). LYAH is great because it's adapted to the web. I'm sure the Haskell Book is wonderful (and I'm reading it), but this is another way he misses the point of LYAH.
I was also recommended LYAH when I started, and it was only around the middle of the book when I started to get lost. I remember actually going along a GH repo somebody had made for "haskell exercises companion to LYAH", but I still found myself reading a chapter, and then having no idea how to actually use the concepts learned. Especially the concepts that are really "barriers" to understanding Haskell (monads, applicative, etc.)
The problem with LYAH is that it teaches you "what" haskell is, but not "why" haskell is the way it is, nor "how" you should you think about Haskell. If you're not at least familiar with another FP language in the same space (probably a ML language), Haskell is not a language you "get up to speed" in.
LYAH is not for everyone, but that also means it's not bad for everyone, either. There's more than one way to teach computer languages.
If you learned Haskell using LYAH and you could write non-trivial software in Haskell right after finishing it - I'm very happy for you. But know that you are in the minority from what i got to witness.
Overall, it's not a waste of time, but I'm sure there are more stimulating Haskell books out there that'll better lead you to think in a functional way.
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?
Is this method documented anywhere? Sounds interesting.
The general feature is called 'typed holes', and there's a wiki page here: https://wiki.haskell.org/GHC/Typed_holes
If you want to have some on by default, you can set that up easily in your cabal file.