Looking for a newbie Haskell book

Learn
#21

Introductory books don’t tend to cover this, but there are some more recent articles on how to structure Haskell programs. Two classics to get you started are The ReaderT Design Pattern and the Three Layer Haskell Cake.

However, one key advantage of Haskell is that it’s very easy to refactor Haskell programs. So having a good design up-front is not always as important as it is in other languages: you can always change it later on. The strong type system means that if you forget to change a part of the program, the compiler will generally catch errors for you. (This has saved me numerous times when refactoring.)

1 Like
#22

If you want to learn the foundation of haskell (i.e syntax and how it works regardless of the ecosystem) I would recommend A gentle introduction to Haskell. It is the book who got me hooked to Haskell. You might not like it, but you should realize pretty soon if it is the book for you.

#23

Afaik Haskell program design is split into ReaderT IO camps (monad that can do unrestricted side effects as well as read from an environment constant), MTL (monad transformers stacks), free / freer monad (monadic eDSL with interpreter), and effect systems (higher performance MTL). Parenthesis comments here for newbies.

I agree that we do need a standard production idiom, and sticking to one program design paradigm instead of twenty helps with the experience curve (the more experience production users have with making Haskell work, the better production Haskell becomes) for Haskell in production.

I personally prefer straight IO + pure or frameworks + pure, but whatever the Haskell production community standardizes on is fine by me.

1 Like
#24

I don’t think it’s possible or desirable to standardise on a single approach to software design. The requirements of applications are just too diverse for one strategy to fit everything. What’s appropriate for a small interpreter won’t necessarily work for a large webserver.

2 Likes
#25

Furthermore, having more than one approach was considered by some to be an asset for Haskell, at least in the early days - for example, listed here are “emulations of Actors, UNITY, CSP, CCS and Linda”, using dialogue-based I/O (with the replication of said emulations using monadic I/O left as an exercise :-)

But there have also been attempts to find that One True Way to develop software in languages like Haskell:

1 Like
#26

This is only true if you misconstrue what I mean by standardization.

It’s not an either-or binary; standardization in a production dialect of a research language doesn’t mean wiping out “non-standard” methodologies. It simply means having a default that’s well-tested; i.e, it doesn’t mean that freer monads, effect systems etc are useless and shouldn’t be used, but a bean-counter considering Haskell can be directed to, say, a standard architecture and design, be told this is well-tested and the drawbacks are well-known, as are the workarounds.

As a research language, Haskell is always going to have experimentation and diversity. The moment the experimentation and weird approaches stop, Haskell is dead as a research language. But industry wants a warranty, it wants documentation, and having a default dialect and design pattern for production Haskell use meets these needs. They can always be upsold to more experimental approaches later, but not before they’re locked into a Haskell ecosystem.

@atravers So it’s not about the One True Way, but rather about a brain-dead default that’s easy to adopt and is a form of best practices: i.e, we want a Haskell design pattern that approximates “No one ever got fired for buying IBM” (safe, cover-my-ass choice).

#27

I feel like this conversation has gotten very far astray from the topic of this thread and should probably be made into its own.

4 Likes
#28

Duly noted. Just be aware that for most people here, the word “standard” usually evokes thoughts about ISO Pascal or Prolog, along with Standard ML: all these usually being “either-or binary” situations.

Perhaps a better choice of word here would be “uniformity” rather than “standardisation”.

With that segue over…back to the topic of this post: is there any other Haskell-centric literature out there? From being here on this Discourse, right now I can only remember:

#29

For a self-proclaimed “newbie” you’re “the exception, not the rule”, which would explain the lack of results when I used Haskell for mathematicians as a search term - so far, the only content I’ve found that appears to be relevant is this interactive course. Because of your mathematics experience, another option would be to find a suitable text(book) on discrete mathematics…if Programming in Haskell isn’t for you.

o_0 …I’m going to guess here: someone suggested you try building an interpreter for that particular language in Haskell; clearly the part about you having a degree in mathematics was lost on that individual.

…and many non-G/Linux users would probably agree with you - this recent topic provides a hint as to why this is (unfortunately) so:

…based on this article, Squeak probably doesn’t have the same “rate of feature-change” as GHC now has.