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.
Haskell + Nix is the best environment I've ever used for any development. My go-to project manager is this script in the reflex-platform, which is a bit poorly named (it will change eventually), because it's actually an environment for doing general cross-platform full stack Haskell development: https://github.com/reflex-frp/reflex-platform/blob/develop/p...
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.
I couldn't disagree more. Nix doesn't make development easier. In fact, it substantially complicates development to ease open source delivery and client dependency management. These are things that are of questionable value to the Haskell or product dev ecosystem, as people far more often prefer fully static (admittedly large) binaries anyways.
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's because it's spefically optimized for my needs: writing Reflex apps. It's what I do for a living.
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.
Well, as complex as Nix+whatever-you-have-cobbled-together-to-build-and-editor-instrument-ghcjs is, it pales in comparison to the sheer ferocious confusion granted to the ecosystem by tools like webpack, so I can see where it might seem like an improvement in some regards.
Webpack: it's like lens error messages for your builds, at runtime!
It sure read like that to me, but given the international nature of this forum, I'll take you at your word. Nor do I disagree with you about your assessment of your experience.
But your experience and your requirements differ from mine, and in a professional capacity I could never recommend Nix for an organization.
Your go-to project manager is a script? Even if you did not intend it that way that is my impression of the reflex platform. Many have heard about the divide in Haskell package management between cabal-install and stack, but there is also reflex, which seems to rely on running arbitrary bash scripts and using Nix, thus leading to a third method of package management in Haskell. It's a big mess.
Ok so, calling it a script was wrong. It's a nix function which takes arguments specifying various configurations about the project I'm working on, such as any dependency overrides. It then provides a nix derivation which can define shells and compile to whatever platforms I need. No bash scripting is necessary to use this machinery except a convenience script to install Nix if you don't have it.
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.
I find it odd you are recommending this setup to someone who isn't even comfortable with the Haskell language yet, who now must learn this tooling as well.
I just wish the reflex maintainers would push new changes to Hackage once in awhile. From GitHub I gather that reflex 0.5 was finished over a year ago but that version is not available on Hackage.
My advice would be start with stack and hpack, and remain with your editor or IDE of choice to start with. Learning any new language is difficult enough without having to also deal with a different workflow.
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.
I agree that jbuilder (dune) more or less solved the fragmentation problem for build systems, and is nice to use. I switched most of my projects to it.
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…
It takes a while for the Haskell community to reach consensus. Stack is definitely recommended by almost everyone for both beginners and production projects. It is used on every project I’ve run in to lately. Sure there are different ways to configure it, but these days there’s really one way to get started. Just download stack, make a new project, and start coding
I get that Stack is what people should be using now but it's still not that helpful if I can't actually get actual instructions for setting up vscode, etc. based on using stack without "stack install."
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.
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
A very quick Google search found Haskelly [0] and Haskero [1] for VS Code, both of whose installation instructions say to install Intero [2] locally in your project directory with "stack build intero" if you don't want to use "stack install" to install Intero globally.
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.
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.
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.
In practice, it is an acceptable (as in, not great, but sufficient) solution.
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).
I don't think it's fair to say IHaskell isn't for beginners, I found it invaluable when I was starting out as a richer REPL than GHCi. I agree with everything else you say about it though. I help maintain the project now and would love to know how I could make it easier to install and use.
Thanks and fully and completely understand why and how the current situation happened. And I fully appreciate the efforts people make to alleviate it. My sole concern is that the situation is accurately seen for what it is.
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
To emphasise again, this is not a severe criticism. I've been around for too long not to know that this is an almost inevitable result of people working in open source with disparate purposes and heterogeneous environments.
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.
What operating system are you running on? I paid for and downloaded Haskell For Mac[1] and it's been a great dev experience so far. The IDE is similar to Xcode (I'm an iOS developer) and the REPL is great for trying stuff out.
You have access to all of Haskell. I built a command line utility that downloads GitHub status from different cryptocurrency repos and ranks how productive each tokens development team is. It's similar CryptoMiso[1] but I have my own formula for figuring out what's valuable.
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.
I help maintain IHaskell and I'm sorry to hear you had trouble setting it up. If you'd like to open an issue on the IHaskell repo I can try to help you troubleshoot your install.
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.
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.
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.
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.
> 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.
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
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.
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.
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)
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 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.
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.
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.
Haskell is so far the language that has blown my mind the most, and it's not even close. Admittedly, I haven't learned that many (esoteric) languages (I found Prolog very peculiar, for example), but if you have never done any functional programming before, Haskell will (hopefully) blow your mind as well.
This is a great book. I brought it on vacation once, read it end to end, and was a much better Haskeller afterwards.
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.
If you’re in it for the two-week thing rather than the long term, “learn you a Haskell for great good” is a good choice. Not terribly informative if your goal is writing large applications, but pretty good introduction to the mindset that goes with writing haskell
To elaborate on LYAH, I think it's a pretty bad resource for actually learning Haskell. It's very "here's a feature, now copy it". Which works fine for learning syntax, but works poorly for learning Haskell.
Check here for a review that really resonated with my experiences about LYAH:
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.
Out of curiosity, did you finish LYAH? And have you actually started using Haskell for any substantial projects?
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.
I did finish it, and I thought the introduction to monads more helpful than anything else I'd come across, as it's focused on the practical use of them.
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.
Almost all of the people that I've met that read LYAH (including myself) could hardly even write trivial projects in haskell upon finishing it. this is in my book (heh) a failure and why i recommend people to avoid LYAH. If you finish HPFFP you have everything you need to be productive and contribute to a production code base.
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.
Yeah that's what my experiences have been too. It's one thing to feel like you understand Haskell after finishing LYAH; it's another to actually understand it.
I'd have to agree with you. Having read the entirety of LYAH as an introduction to Haskell and functional programming, I felt introduced to a-lot of functional concepts and Haskell syntax. That's unfortunately it. With the absence of practice problems, nothing really stuck, and I'm nowhere near prepared to create a project myself.
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.
I'm reading LYAH at the moment, and I think it's great if you're familiar with functional programming already, and just want an introduction to haskell. It's incredibly verbose, but I just read the code, and resort to the text when I don't understand what's going on. Haskell Programming From First Principles takes a socratic approach which seems like it could be good for very dedicated students who need to learn the fundamentals of functional programming in addition to haskell.
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?
Maybe things have changed, but not a couple years ago when I was working with Haskell. No IDE story at all, which is just a crying shame when you think about the kind of refactoring and powerful features you could support. The fact that vim or other text editors were typically what was used was just odd and a waste IMO...like having a rocket propulsion system strapped to a Huffy.
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
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.
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?
The standardization process is really slow and conservative, and making it faster is not a priority for anyone because—at least at the moment—GHC is the only meaningful compiler, so the standard wouldn't be doing more than explicitly recording how GHC's extensions work.
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.
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.