Thanks for the comments and encouragement, it really helps a lot!

What you describe is precisely what we've aimed at the whole time, but there is a reasonable amount of work that the absolute beginner has to get through before one can tackle anything at that level. The work we've done so far is about as real world as a beginner could hope for, we think. Mind you, up to section 8 pretty much has to be toyish programs of a few lines of code so as not to bamboozle the reader, because they know very little up to there. These sections are tiny for that reason - to keep them interested.

We're slowly releasing the sections for free. Just released another one today (Section 8). It won't be until Section 9 that we start to encounter programs that one could see how they might be truly useful if more work was done on them.

Finding all the movies in your movie collection that start with a letter in the first half of the alphabet is pretty toy, for example (in Section 9) :) - that's the next section we'll release for free on the site. However, we can start to see how that could easily become something useful - like maybe a DVD collection manager database kind of thing, with a bit more coding.

Then, when at around Section 17, we know enough Haskell to be able to read small, but real programs: a times-table "game", and a tiny adventure game (it only has 2 rooms). These are trivial non-real programs from a real-world perspective, but they contain a lot of the elements needed for real programs, and are the precursor to reading beginner to intermediate programs.

We think that our book is unique, because we don't see anything like it anywhere else. Here's why:

The frustrations with the Haskell ecosystem up to this point is that learning from nothing is a real chore. LYAH and RWH are the only free to read purportedly-beginner books, but both of them start assuming that Haskell is the second language, and they're both very out of date.

LYAH doesn't use full programs to illustrate topics, so gives no context (which means things don't stick in your mind), while RWH does do this, but manages to put the reader to sleep while they're reading it because it's not written well and poorly edited (not to be mean here... Bryan O'Sullivan has actually said on his blog that they should have edited it more carefully: http://www.serpentine.com/blog/2014/03/18/book-review-parall... - in comparison, this book by Simon Marlow that he's writing a review for where he complains about his own writing, is excellent writing).

However, none of the books or tutorials around seem to take the time or care to explain the absolute basics: things like the fact that Haskell operates in a massively different way than almost every other single programming language there is: a world that is entirely pure. Where in order to do IO, you don't write commands, but rather, you have to use pure functions to compose building blocks (IO values) which are descriptions of execution, for later execution. We bandy about phrases like "purely functional", but don't tackle this head on.

To our mind, this is one of Haskell's greatest strengths, yet it's usually shunted to the mid or back of books because it's difficult to explain, or an advanced topic, or it's been misunderstood in the past, or because authors feel like they need to get readers to Monad before or when they get to IO. We don't agree with this.

By separating out the passive (reading programs) from the active (creating programs), we think learning can be rapid and things can be understood through large amounts of examples. In the 80's, this is how we learned to program, and it works. You take someone else's program and you type it in! You adjust it, and see what happens. Once you've done that about 50 times, you start to understand what's going on. Take that and add an explaining commenter, and you have our methodology for teaching :)

So the IO thing alone, we believe, is a reason our material is fundamentally better. Couple that with practice and example-first teaching (showing examples before, or with theory, not after), appropriate drawings, subject-driven learning (rather than programming-topic-driven), and breadth-first rather than depth-first teaching, and we feel like this series is completely unique. LYAH in contrast does depth-first, and the example code suffers from it massively, not to mention the impact on the reader's attention span in the latter half of the book.

What we mean here by subject-driven learning is interesting. Say we want to show the reader a number of things, so we introduce them in the guise of a program that "happens" to need to use those things (we've selected it precisely because it does, actually). That way, their focus is on the topic of the example programs, rather than something related to programming like "singly linked lists" or "Functor", or "folds". We introduce several topic that deal with a particular programming topic, and before you know it, they understand how Lists work, because they've seen them explained 10 times in different examples. We call this "Using interest to drive repetition".

Each section includes (mostly) at least one "full" program. That is, a program you can enter and run yourself if you have Haskell installed. Granted, they're very small programs up to section 8 or 9, but the sections are very small, too. That's the idea. We want examples to drive the education, and then introduce theory to back it up later.

Yeah, so, Volume 1 (this one) is primarily about building the reader up to where they can make sense of beginner level programs, and start to construct the absolute basics themselves (essentially "what's your name"-like programs with input). We've purposefully kept it light and small to increase motivation.

The next _Volume_, though, will likely get to the point where we'll introduce some much more useful beginner programs, and get the reader to be able to write some basic beginner programs. We're pretty limited with the sorts of things we can introduce at the very beginning because IO is such a difficult and loaded topic in Haskell, and we want to keep the amount of information covered in each section down to a bare minimum to keep interest high.

There's a lot one has to understand to be able to just understand what's going on with how to read IO actions, let alone to use them, so we introduce "just enough" so that the reader can understand programs written with it, but not necessarily fully understand what's happening behind the sugar of a do block (let alone trying to comprehend what's going on in something "real world" like a Snap web application).

Sorry for the diatribe :) I obviously find this stuff massively fascinating, and it seems you do, too.

We'd absolutely love it if the sales for the book took off. Maybe they will once we release more of the book for free. We're working on it as quickly as we can, so we'll see I guess :) Exciting!