u/Mob_Of_One

It's only available via the website at the moment, located at http://haskellbook.com/

C++ Primer at 938 pages.

C++ Primer was one of my favorite C++ books. However, it is focused on the language and STL. It covers none of the ecosystem or how to deal with common problems. There's not much "idiom" outside of the STL coverage from what I recall either. It's also mostly appropriate for intermediate readers. We have to do a great job of the beginning and the intermediate parts, or people get stuck.

We're not only taking you through the ins and outs of the language, but also the sticky bits people get stuck on like Functor/Applicative/Monad/Foldable/Traversable, but also stuff you'd need for practical projects like parsing, transformers, performance, and some kickers like "so how does IO work, really?"

What we target content-wise is based mostly on what we've seen sends new people into death-spirals with trying to learn or use Haskell.

I don't think anyone that has used the book and is familiar with the other resources would say we were verbose. Most of the page count is due to the copious amounts of code and numerous examples and exercises. That stuff bulks out the page count because of how much space it takes. It's not wordy and tedious like some Haskell books.

The Learn Python book by Lutz is 1,600 pages. Our book is 950-1000 pages right now with the current rendering, so by all rights, our book gets more done in fewer pages than Learn Python or C++ Primer.

We're using the objectives of the people that sign up to decide what we cover.

We've got a small team that has signed up and they'd like to know how to make a basic API server that can handle processing events pushed by devices. So, we'll be looking at everything new Haskell users are likely to get stuck on in the process of building that sort of thing.

People that sign up for training earlier will get to influence the curriculum more.

We'll have more specifics as we get closer and get more feedback from the people that have signed up.

Can I signup only for the course and not the conference?

Yes.

Is there a way to signup for both beginner and intermediate tracks?

You sign-up for one course, we place you in the course based on where you are with the material. The tracks are guidelines rather than rigid.

Are these tracks going to be concurrent?

Yes.

I think we'll just be doing beginner and intermediate tracks. (There's two of us anyway)

Intermediate track starts with monad transformers and works forward from there. What is it you'd want to learn?

Oh sorry, let me provide some background there.

I can't speak to Kmett's motivations, but Trifecta has replaced Parsec (but not attoparsec) for my purposes. The excellent error messages and clean API (parsers) make me much happier.

So, I use attoparsec for fast-path code, if something fails, I re-run it with Trifecta and dump the error. This works better because AFAICT Attoparsec and Trifecta have the same backtracking behavior, unlike Parsec.

It's just an upgrade from Parsec - for me anyway. YMMV.

Edit: More specifically to your situation - the way Trifecta tracks parser state for nice errors is impressive. As are the faculties it exposes for marking, highlighting, etc.

Another option for this that might work better for some: https://github.com/reiddraper/ordeal

There's more information here: http://haskellbook.com/training.html

Good grief this thing must be amazing if people trudge through all this just to figure out how to use trifecta.

The book covers what we think anybody from "very beginner" to "somewhat intermediate" might need to know to use Haskell. Parsing/marshalling is a common software need and it lends good intuition for applicative and monad so we covered it. If you're already quite comfortable with the previous topics you don't have to read them, but a lot of experienced Haskellers have told us they still learned stuff from the first half of the book. shrug

There's no way I could have known that I was supposed to look at parsers.

Yes explaining that was a little annoying. Motivating that is partly why we demonstrated writing a parser polymorphically and then running it under attoparsec and trifecta with no code changes in that chapter. So that it seemed less artificial.

yeah. I liked ProductProfunctor btw. Please keep it coming :)

No, are there any good docs or tutorials for it?

Well...our haskell book, but otherwise, nothing thorough. Learning to muck about with parsers and trifecta is about it. There's not much example code and the way Idris et al. use it is idiosyncratic and hard to understand whe you're starting out.

/me checks his notes

This thread lists about all you're going to find: https://www.reddit.com/r/haskell/comments/2uc6kp/are_there_any_tutorials_or_introductions_to_the/

Because we have different aims, and because I've read HFFP quite a few times.

I don't think that makes any difference to the content of what you were proposing he add.

Granted, he didn't know I'd read it.

Again, I don't think knowing this changes anything. Listening to Bach when I was younger didn't make me a composer, but it did spur a brief dalliance with composition software and MIDI.

He also recommended I read "On Writing Well", one of whose core proposals is for writers to be as brief as possible. HFFP is not brief.

This is uncharitable. HPFFP is not brief in terms of page count because it:

1. Covers a lot

2. Has a lot of code and examples.

Strip the latter out and match coverage and HPFFP is quite a bit shorter than RWH. There is not much more prose in HPFFP than is necessary to cover the topic at hand. The chapters start shorter when we initially write them and it's because we test our material that content explaining things more clearly gets added or existing material gets rewritten.

Perhaps it's not irony?

I don't think so, no. Please do not use us or mention us when promoting your webpage.

Seems reasonable, I'm looking forward to trying this out :)

I'm still bitter that ArgumentDo won't even be an extension despite ~50% of people liking it, but TypeRep is coming despite everyone agreeing it's ugly...

Och. I feel you.

The original Grammar of graphics book has been around since 1999 I think.

(call an hpack executable instead of using it as a library)

That would be unfortunate unless it was a prelude to getting phased out. Pathing issues stymie beginners a lot. Bolting together known-good (Stack <> hpack) versions seems worth potentially delayed updates of either.

(a touch ironic considering I helped provide extensive feedback on that work)

How is it ironic?

ReadtheDocs doesn't support HTTPS properly, sorry :\

Our Haskell book has made a lot of people happy, which we started because we weren't content with how well LYAH and other resources were working for beginners.

Have you tried Trifecta or looked at how it is implemented?

Ad server (ours was considerably faster than the DSPs we integrated with. It wasn't close), web app (with database access, frontend stuff, all the usual), streaming analytics, web spiders, command-line applications, parsing...everything I did in Clojure and Python before Haskell really.

Edit: I have opinionated library/kit recommendations at haskelliseasy.com if that's something you're looking for.

I use it in production, have at multiple companies. I've helped a few companies move over too.

It's been very pleasant. I don't really know what else to say. It doesn't feel any different in my head than writing code in any other language, the pay off is in not having to think about irrelevant details when I do not want (fmap wooooo) and in stuff just working more often. Cheap refactors too.

I haven't suffered from a production memory leak in 2 years I don't think, but I exercised good habits - (strict in the leaves for long-lived data, use streaming when appropriate).

Ideally, zero guns equals zero shootings.

And then physical strength and time spent training for violence becomes primary again.

They seem like traversable'ish common-cases having to do with existence/non-existence, applicative, and traversable.

I've run into this before from a different angle - when mixing prisms and traversals with lens. Hard to explain without a concrete example...and I do not have one at the moment - sorry.