Looking for a newbie Haskell book

Learn
#10

Learn You a Haskell is the one that I used, but there are a variety of books, depending on your needs.

Why have you decided to learn Haskell? What are you trying to get out of it?

I love Haskell, and I found it to be superior (at least in a great many ways) to languages I already knew. But if you feel that Smalltalk is better than any other language out there, I suspect that learning a new language will be frustrating.

For Haskell, we have the Hackage website for that.

I recommend against writing Makefiles to build Haskell code. The idiomatic way is to write Cabal files.

Check out the platforms that GHC supports. If you are not on a Tier 1 or Tier 2 platform, Haskell probably won’t work for you. Even among Tier 2 platforms, you will be much happier if your platform supports GHCi. Not only is GHCi support necessary to run GHCi itself, but GHCi support is also necessary to use Template Haskell. (There are a number of packages on Hackage that use Template Haskell, so those packages won’t be usable on a platform without GHCi support.)

1 Like
#11

Awesome! The book you recommended is by Jose Nuno Oliveira is like none other. Thanks so much.

#12

I’m going through Effective Haskell, Effective Haskell: Solving Real-World Problems with Strongly Typed Functional Programming by Rebecca Skinner

1 Like
#13

I never claimed Haskell was stupid. I just said that your IDEs eight do not work on Ubuntu MATÉ or are 40 years out of date. The lack of a functioning IDE makes designing programming difficult.

If Haskell was stupid, I would not invest time in trying to learn it.

The books that I have read believe that if you know Haskell syntax, then the design of your program will magically appear. I saw the same magical thinking when I learned OOP.

In my graduate Software Engineering course, the professor actually believed that if you specified a problem in enough detail, a solution would magically appear. I would like to see him produce a SLR0 parser for C. Or produce a program to compare two programs and decide if they do the same thing.

#14

I have Graham Hutton’s book Programming in Haskell.
I am only to page 106. There is nothing on actually designing a program. Just some Haskell syntax.

His concept of a “parser” dates back to 1968. Since 1972 parsers are a composition of a lexical analyzer and a parser.

#15

That’s about the end of “Part I: Basic Concepts” isn’t it? Sounds about right that you’ve mostly seen syntax (and semantics) of some very simple programs.

It sounds great to me that Hutton uses a simplification in an introductory programming book that is otherwise unrelated to parsing.

1 Like
#16

You can try Haskell Bookcamp on Manning, which is a project-based approach.

The important thing to remember is that Haskell can’t be learned from books alone; you should get hacking and make simple Haskell programs as you learn the language. Haskell is becoming comparable to C++ in terms of learnability, unfortunately, so you should expect to be limited to some productive dialect for an extended period of time.

#17

Most serious applications of parser combinators will often build up parsers for lexemes and then combine those to build parsers for syntax productions. Because of (I guess?) laziness and a much more compositional abstraction, the difference between scanner and parser can appear blurry at first glance, but most well-factored applications using parser combinators will still have that separation as a matter of software design.

#18

Ironically, this is the precept of Type Driven Development; i.e, specify the problem well enough in types and the types of functions, use undefined or error “Todo” to get the compiler to accept partial programs, then the rest of your program will write itself as you remove the undefineds, possibly through the typed-hole feature (stand-ins where the compiler will suggest possible solutions).

Of course, this is an ideal; the type system isn’t powerful enough or ergonomic enough for this to work, so you still need to work out the details, and there are people who feel TyDD is too constraining, just as there’s people who dislike Test Driven Development.

Every Haskeller is using TyDD to some extent; even if you reject it and try to program based on pure type inference (which is not 100% reliable), you still have traces of TyDD via the “build outline, fill in outline” schema.

It’s also amusing that Rustacaeans seem to be adopting TyDD, but don’t call it such; Rust community is hilarious in that way.

For Bookcamp:

Haskell blog generator newbie introduction:

Here’s graninas’ book on how he thinks Haskell programs should be structured, but be aware that Haskell program design has multiple, clashing philosophies, and the only real constant is the separation of the side-effecting layer from the calculation layer. Hence, graninas is controversial.

#19

I’m surprised it was only mentioned once but I highly recommend Will Kurt’s Get Programming with Haskell. I don’t necessarily think that it’s actually a bad thing, but I would agree with criticism of Hutton’s book that the end of chapter exercises are more akin to homework problem sets than actually writing a full program. Kurt’s book isn’t like that, it has a lot of projects that require you to create something bigger than just a few functions that solve exercise problems.

Additionally, I also fully recommend Finding Success (and Failure) in Haskell. It’s specifically aimed at people who have gotten the Haskell basics down (e.g., having worked through most of Hutton’s book) but haven’t ever made a full project. You may or may not be ready for it right now (I don’t know where you are on your Haskell journey), but I think it’s a great project-oriented book once you’re comfortable with typeclasses. Small quote from the preface: “This book is for people who have just started getting into Haskell but would like to move quickly and understand by doing.”

1 Like
#20

Thanks for mentioning my book, I appreciate this.

Your comment makes me think that my points in the book are very convincing and you’re afraid a reader will stop learning and questioning after reading the book. I hope the reader will continue learning the subject after my book, and certainly, they will have a lot of ideas I haven’t touched.

P.S. I wouldn’t call it “controversial”. My book is not controversial, it’s opinionated at most. I myself don’t think I’m “controversial”, but rather consistent in my views for a decade, and not afraid of sharing them.

#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.