Hacker News Reader

Environment setup has been heavily discussed[1] in the community and is definitely a pain point when getting started with Haskell. Unfortunately there are several sides with differing opinions on how to bootstrap a user and get them using Haskell, although the new Downloads page seems to be a good first step towards achieving a more unified goal.

The opinions kind of break down as:

1. Simply get GHC on their machine - Typically academic instructors trying to get their students started with low overhead. They simply want GHC and GHCi available so an assignment can compile, or code can be tested in the repl.

2. Install Haskell Platform - This has been strongly supported by what I would call the older Haskell community, although admittedly share your confusion as to its point. This seems to target point-and-click users and give them every tool in the ecosystem so that when they reference the random blogs/documentation out there they aren't confused by missing a command.

3. Use Stack - This has been heavily pushed by people trying to help Haskell grow in the programming industry. It's a fantastic tool and I recommend everyone use it if they plan on doing complex projects, especially in a team setting.

My hope is that over the next year or so we'll see more stack adoption, ideally because there are more consistent tutorials/guides/documentation published which target it as the basic tool to start developing Haskell in.

[1] https://www.reddit.com/r/haskell/comments/50prvg/haskellcomm...

You bring up good points! As a beginner, you are uniquely poised to observe these things, so thanks for sharing! I think a big part of the install problem is that some of the options (stack, platform) are fairly recent.

I recently got a new machine and decided to try _only_ using stack. All I had to run to get started was

    $ curl -sSL https://get.haskellstack.org/ | sh

The advantages of stack are that:

  * I have an easy upgrade path for GHC (no need to install or uninstall) - I just change the global resolver
  * I can have multiple GHC versions installed at once (great for debugging)
  * getting rid of old versions (to clear up space) is just deleting a folder
  * most of my dependency problems get solved by resolvers

The only downside I've encountered so far is that building GHC itself is quite finicky with this setup. Unlike the Haskell Platform, I will have to install manually the libraries I need - that makes development offline quite tough (you find yourself without internet and without the library you need installed).

That aside, one good starting point for building up Haskell is the 99 problems [1]. Haskell is more general purpose than Elixir, so past that, it really depends on what you want to do with it.

[1] https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems

> Haskell is more general purpose than Elixir

why do you say so? elixir seems pretty general-purpose...

I'm in the same boat as you. I learning Haskell earlier this year, and while I really really want to like it (if nothing else, I'm a sucker for type systems) and even start using it for projects I can't when, IMO, there are languages out there that feel so much more productive to me. A few key concerns I have with the language and community:

1. I feel like there is a really strong push towards writing concise code, which make it really hard to approach for me. I've seen a lot of code which substitues words as function names for 2 or 3 character symbols. I'm okay with learning `>>=` and the like, but when every library want to invent its own symbol-functions, I feel like the barrier to entry for me becomes much higher. This occours in just about every high profile library I've seen, from parsers to web frameworks; everyone wants to invent their own DSL.

2. For as much as Haskell seems to pride it self on function composition I don't think `.` is the best way to do so; Clojure's threading macros are much more readable to me. Comparing the thread-last macro ``` (->> (range 10) (filter odd?) (map #(* % %)) (reduce) ``` to Haskell's composition operator `(sum . (map (\x -> x * x)) . (filter odd)) [1..10]`. (Please correct me if there is a clearer way to write this.) The former is much more readable from and LTR English language PoV. In Haskell I need to start from the right and work my way left; and this become even more harder for me to decipher when function operator precedence starts coming into play. It's small quality of life things life this which makes all the difference IMO.

3. The millions of syntax extensions in ghci, some of which are incompatible with each other. This means ProjectA and ProjectB can be written in completely different, possible incompatible, 'dialects' of Haskell. Now I have to learn the base Haskell languge and whatever language extensions that project has dedcided to use just so I can start reading and understanding the code.

4. AFAIK, there is now easy way to get function documentation in the repl. Sometimes types aren't enough for me and I would like to have some human written documentation guide me when I'm trying to use a library.

Your example can be written more clearly (IMO) in Haskell like this:

  sum $ map (^2) $ filter odd [1..10]

Or, defined as a function:

  > let foo = sum . map (^2) . filter odd
  > foo [1..10]
  165

You can write it without using the composition operator at all, if you prefer:

  > let bar xs = sum (map (^2) (filter odd xs))
  > bar [1..10]
  165

In general, you can write out your programs as crazy sequences of operators (whose precedence may not be obvious to the reader):

  > take 5 . unfoldr (Just . next) <$> getStdGen >>= putStrLn . show
  [1336079013,234736121,108049288,410228860,1573295749]

But you don't have to:

  > let infiniteRandoms = unfoldr (Just . next) :: StdGen -> [Int]
  > gen <- getStdGen
  > let fiveRandoms = take 5 (infiniteRandoms gen)
  > putStrLn (show fiveRandoms)
  [1336079013,234736121,108049288,410228860,1573295749]

People seem to think Haskell is all about writing your whole program in a single hideous line of code with incomprehensible sequences of arcane operators glued together by a glut of anonymous functions, but that's just bad code.

As for left-to-right vs right-to-left, I have never had a problem with the way Haskell does it. I think if you're coming from a language that does it differently, it makes sense that Haskell would trip you up in that regard. Haskell's composition operator matches the way it's usually written in mathematics, but there's nothing special about it and you could change it to go the other way if you really wanted to (but please don't):

  > let g . f = \x -> f (g x)
  > let foo = filter odd . map (^2) . sum
  > foo [1..10]
  165

`(>>>)` from `Control.Arrow` is a more reasonable way to get that sweet left-to-right action but using it might still throw people off:

  > let foo = filter odd >>> map (^2) >>> sum
  > foo [1..10]
  165

To add to that from someone who went into programming after math grad school, composition is actually much more natural in the way to think about functions. When putting together functions, and where they map to, it is more natural to think about functions the way Haskell thinks about them, but more natural when writing them to go the other way at first. This is because when one is working at the lower level of just writing code it becomes easier to move from one data state to another, but at the high level, you lose some flexibility in seeing the high level structure and it becomes more difficult to figure out how to move things around if it turns out you have to modify the code.

In math, the preferred way of writing functions is via composition, as then it enables tools of visualization such as commutative diagrams. One thing to note is that in general mathematicians have a history of picking the right choice in notations for thinking about abstractions at an intuitive level in the world of mathematics (when there is a choice and it matters), and IMO they were correct about how they chose to represent function composition, although it is not immediately obvious unless you start talking about function domains and ranges - the composition notation matches the flow of reading how functions map values from one set to another.

That Clojure version reads like a complete mess to me personally.

> The former is much more readable from and LTR English language PoV. In Haskell I need to start from the right and work my way left;

For short chains, pronouncing `.` as "of" works well in English, e.g. `sum . tail $ foo` is "the sum of the tail of foo`, and it follows the same order as nested function application: `sum (tail foo)`.

I agree the the other way around, e.g. a "then" operator `>>>`, is easier to understand with long chains: with `f . g . h . ...` we have to remember `f`, `g`, `h`, etc. in a "mental stack", until we get the the end. With the other way round, `... >>> h >>> g >>> f` we can "mentally apply" each function to a "mental accumulator" as we encounter it.

Operation precedence in Haskell is hard to get used to, but it leads to very clean code after you get used. Try:

  sum . map (\x -> x * x) . filter odd $ [1..10]

Function composition leads to a very stable right-to-left syntax. It also takes some practice, but in Haskell you almost never have to go hunting for operators or remember if something is infix or prefix (except for the shameful single argument '-', as in '-1').

> The millions of syntax extensions in ghci, some of which are incompatible with each other. This means ProjectA and ProjectB can be written in completely different, possible incompatible, 'dialects' of Haskell.

To my knowledge, there are no GHC extensions that are incompatible on a project level (that is, you could have one enabled in one file, another enabled in another, and it would break things). I'm much less confident that there are no extensions that are incompatible if you try to use them within the same file, but I am not able to think of any off the top of my head.

I think the haskell-lang.org [0] people did a good job trying to get a better "getting started" [1] experience for new haskellers.

[0] https://haskell-lang.org

[1] https://haskell-lang.org/get-started

Although I recommend stack heartily, note that haskell-lang is hosted by FP complete, and IIRC they either fully developed or had a big part of developing stack. Just FYI.

Some of them are from FPCo and some are not. But why does this matter? Why did you mention it?

> One of the small bumps I had was getting my environment setup. Based on my experiences with Ruby and Node, I knew I'd want to have a tool for managing the language's version and dependencies per-project, so I ended up going with stack [0]. Arriving at that decision required a bit more reading than with other languages.

I don't really write much haskell - but last I checked, the "howistart.org"-article seemed reasonable:

http://howistart.org/posts/haskell/1

I think it's actually harder to figure out how one (should) start with python an venvs than it is to "find" a reasonable approach for haskell.

On what building tool to choose:

Stack creates reproducible builds (AKA frozen dependencies), but instead of you freezing everything, the community creates some frozen sets for you, and you choose one. That avoids the dependency hell that happen on other environments when your dependencies list gets big.

Cabal is much more like a run of the mill dependency management system. You'll declare everything in the usual way, it will resolve the dependencies (in a much better than usual way, but still looks like everything else), and make them available for you.

Both systems can manage dependencies globally or in a project by project basis.

I've found that for creating libraries and publishing them on hackage one is almost certainly better off with bare cabal. For creating binaries for distribution, one is almost certainly better off with stack.

About installation, every road will take you to a system with at least ghc, and cabal. Getting stack too is very desirable. I've found that on windows it's easier to run the stack installer, and install everything from it. On Linux it's easier to compile (yes, it's that bad) your own GHC and cabal, and get stack from cabal. The Haskell Platforms looks to be meant to distro package maintainers - I have never had good results from trying to install it from the site.

> On Linux it's easier to compile (yes, it's that bad) your own GHC and cabal, and get stack from cabal.

I had no issues setting up my dev environment with stack on Ubuntu 16.04 as documented on haskellstack.org. What Linux distro do you use?

Tried it on Debian 8.

I've installed GHC from binaries more than once without a problem, same for cabal. But I've concluded it's not reliable.

Finding the setup to be more than a small bump. Running this on Mac Sierra, and running into resolver issues everywhere. Latest was using stack setup with a specific resolver, and having the version it installed be the wrong one (at least, according to the stack documents).

Just a bit frustrating.