I'll say this upfront, I fucking love the language but hate the tooling. I've completed a few projects in Haskell, nothing big, but usable software and here are some of my thoughts.
>cabal is the worst packaging system ever imagined >stack uses cabal >a simple stack project uses gigabytes of disk space for a small project >build times are really really bad >bindings to gui libraries are generally shit >haskell qt bindings are especially shit, try getting them to work on something other than linux and you'll know what I'm talking about >there are no ghc builds that are compatible with the official qt builds, so you have to build both qt and ghc yourself on windows and make that work with stack. have fun. >ghc's build system is atrocious, especially so on windows (this is also acknowledged by the development team, but they don't have anyone that actually wants to revamp it) >hackage sucks. there is no way to know what library to use or which one is good and before you know it, you're using a library that isn't a good fit for your project and you waste time. the rating system is also useless.
My biggest gripe with Haskell however, is that you don't actually learn the language, you learn the library that you are using.
Every library does everything differently. There are thousands of different concepts which are used by libraries and you'll have to learn every single concept because there is no standard or generalized way to use the libraries. Some libraries use lenses, some use StateT, some use EitherT, some use ReaderT, some use WriterT, some use ExceptT, etc. etc. etc. the possibilities are endless.
Now, when you have learned the concepts and how to use a library, you have to learn to make them work nicely with each other. The most fun part about that? Some concepts are mathematically incompatible with each other and can not be combined.
What are your thoughts on Haskell? Have you written a program with it?
>you don't actually learn the language, you learn the library that you are using. Isn't that the case for all languages?
Liam Lewis
I didn't learn it, but I don't like purism. Some algorithms are just so simple to be implemented procedurally (iterative loops), why would you force a recursive solution?
Christian Phillips
Not really. The libraries for imperative languages generally have a very simple way to use and combine them. Look at any C libary and the pattern is usually the same: create resource, call function and pass resource and a few variables as arguments, destroy resource. Even in more complicated cases it doesn't take very long to figure out how to use a library, because the concepts are all very similar.
You can program imperatively in Haskell if you really wanted to. It even has libaries fot loops.
Ryan Smith
Been using it for work and it's been pissing me off. As soon as you touch any moderately powerful language extensions, or even use libraries that use extensions (even basic shit like ST or StateT), the type inference stops "just werking". But the whole language is designed around the assumption that type inference always works, so when it breaks, getting the right type signatures down is a pain in the ass (and sometimes literally impossible, unless you turn on even more shitty language extensions).
At least with Coq, they know their type inference is shit, and they make it easy to provide partial annotations for the inference to fill in later. Plus, Coq is actually designed for doing complicated things with type variables, so you don't need a god damn language extension just to refer back to a type variable bound in an outer scope.
Also, kind of this: . Any nontrivial imperative code with monads is awkward as fuck, and yet monadic Haskell has basically no real benefits (safety or otherwise) over imperative Rust, unless you start getting into the real wacky monads like Cont or reverse state.
BTW, pro tip for you OP: install nix, delete cabal. If you use nix to set up all your build environments, you can literally build your project with ghc --make, and never need to touch cabal.
Brayden Jenkins
There was some partial type annotations extension for GHC.
Ayden Foster
I refuse to give Haskell a try until I can hear 1 fucking half-competent explanation of what the FUCK monads are.
Jordan Foster
Because recursion is kinda like induction and you can reason inductively on your function. Proving that it does what you think it does is much easier with recursion that with loops. Actually if you wanted to prove that a loop does what you think it does you'd fall back to induction and end up with a proof similar to recursive program. Recursion leaves less space for guesswork. Note that purely iterative loops are trivial in Haskell: iterate :: (a -> a) -> a -> [a] -- e. g.: iterate (+1) 1 = [1, 2, 3, ...]
It's when there are complex effects that Haskell gets complicated because you need to very precisely describe them.
Colton Kelly
>Any nontrivial imperative code with monads is awkward as fuck True, there's no denying that it's awkward at best. >Haskell has basically no real benefits (safety or otherwise) over imperative Rust I was thinking about giving Rust a shot, do you have any experience with it and would you recommend it over Haskell? What really blew my mind the first time I used Haskell was that after writing my program and it successfully compiled, it "just werked" and even to this day it doesn't have a single bug (that I found) and I've been using my own program more than half a year by now. Is Rust similar in that regard?
>BTW, pro tip for you OP: install nix, delete cabal. If you use nix to set up all your build environments, you can literally build your project with ghc --make, and never need to touch cabal. I've heard good things about nix for Haskell so I'll give it a shot. It doesn't work natively on Windows though, does it? I need my programs to work on Windows as well, as I mainly create cross platform software. I'd probably still consider it for development only, even if it doesn't work on Windows.
Logan Murphy
All told, a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor.
