What I would like (and in my opinion what Haskell needs to grow), is a more practical introduction, like doing a database conversion, or writing some network service. Syntax can be explained in passing. Does this exist?
He steps the reader through writing a program that reads in and then divides an arbitrary park map into small, roughly equivalent picnic plots with colored SVG output along the way. The code takes center stage and is presented to the reader with the why and a good/bad analysis afterward.
I'm not sure whether this is what you're after, but at the very least it's worth a glance.
Aside from that I would recommend the cis194 Lectures [2] if you do feel ready to take a slightly more thorough top down approach. There are exercises for every almost every lecture and you can even peak at your digital neighbours to compare solutions [3].
[1]: https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...
[2]: http://www.seas.upenn.edu/~cis194/lectures.html
[3]: https://github.com/search?q=cis194&type=Everything&repo=&lan...
This isn't a criticism of Haskell or Haskellers. It's more an observation that the current makeup of the Haskell community might prove to be a drag on its appeal.
It's not exactly Haskell but Elm is a fun way to get into Functional and Functional Reactive programming while drawing some things on screen and making them move.
There are probably more graphical tutorials for Haskell too. I recently found some good examples for Gloss [2] and am moving from Elm to that right now. There is an "Elm for Haskell" called HElm [3] too.
[1]: http://elm-lang.org
I can't even remember the last time it was cold-suggested to somebody.
The last person I knew to do so, did so knowing they were going about it the "hard way". They also did it with the intent of actively upgrading/updating the code WYASI48H as they went into a more modern style. They gave a talk on it after.
It's a good way to firm up your knowledge if it's the sort of project that interests you, but needs love and isn't a good introduction for most.
You also have a lot of good resources for Cabal and for development environments. That's appreciated.
But a lot of developers' bread and butter is "this data is here; I need to grab it from this place, make appropriate changes to it, and put it in this other place." They might use an HTTP client and a JSON parser for it, or FTP and an image processing library, a database or two, etc.
Unless I'm mistaken, the first place new Haskellers would run into the first inkling of that kind of stuff would be in chapter 5 of RWH, which you describe as a "thick book" and a "reference". The first appearance of a database is in chapter 20.
This is stuff that you can find about PHP, Ruby, Python, etc. by drooling into the keyboard while Google is open. It is comparatively _exceptionally_ hard to find the same kind of nuts-and-bolts material about Haskell.
I think the different approaches lead to a different environment in terms of libraries available and the types of learning guides available.
https://www.youtube.com/watch?v=0I90MTip-OQ - Implement a sed clone in Haskell (a bit broken towards the end but a great look at a small incremental project)
https://www.youtube.com/watch?v=zZ_nI9E9g0I - implementing redo in Haskell
I don't take a particular view on which is the better way. The distance from the fundamentals up to something superficially impressive seems a very long way to me. So I think probably the realistic approach for most will be to start of the bolt things together and then discover a desire to understand the fundamentals.
I think to start at the fundamentals end needs a lot of patience but it probably suits those intolerant of magic.
I think to start at the fundamentals end needs a lot of patience but it probably suits those intolerant of magic.
On the other hand, while Haskell is several times harder for it, it does eventually quench the thirst to connect every new thing I learn with the foundational things I already know (and which are in fact a set of simple rules - lambda calculus).
It's more like learning to program again, not just a language.
The course I lay out is because it's what I've found to work best. Part of the priority is minimizing dropout rate.
Trying to shove people through a 'practical' project had one of the worst dropout rates of any of the approaches I tried.
Just accept that you're going to learn some basics before dazzling the world with your web app and you'll be much happier for it.
It doesn't take long anyway, if you have a well-designed course and/or experienced people helping you. [1]
I've been thinking about writing a book to address some of the pedagogical problems. I don't know if it'll work out, but I have a few ideas.
So far, the course I recommend not having enough "practical" examples has been pretty far down the list of problems. I'd rather focus on the rough edges that I've observed tripping people up.
Are you learning Haskell right now?
[1]: http://engineering.imvu.com/2014/03/24/what-its-like-to-use-...
The catch in your approach is that it doesn't really offer an incentive for people to learn Haskell other than "it's really good, believe me". The best incentive I know of is to demonstrate that people are solving the problems that the potential Haskeller wants to solve, and that there are tools, resources, and even sample code available.
Just a little while ago there was a goddamn GIF encoder in JavaScript on the HN frontpage. There was a text editor in Go. Does anyone really need that stuff? Probably not. But the visibility of people solving so many familiar problems in these languages gives newcomers the impression that JavaScript/Go/whatever are powerful, popular languages suitable for a broad array of tasks.
Seeing that kind of thing -- that the Haskell community does more than write language parsers and terse implementations of interesting algorithms -- is what's going to convince a newcomer that it's worth the investment to start from scratch on a new, unfamiliar language. At that point they're going to be happy to learn about typeclasses and functors and monoids as stepping stones to the cool stuff they want to do (and in the process, maybe learn that they're more than stepping stones).
I have been saturated and have had to scale how I teach for the last 9-12 months, so marketing hasn't been a first-order concern.
There are "ooh" and "ahh" demos I could put up, but other people are doing that work better than I could. I'm just the funnel catching people already sold.
Teaching is hard and isn't done well. I like working on this problem and would like to focus on it for the time being.
Division of labor yo.
You should check out #haskell-beginners on Freenode if you decide to pick up some Haskell.
Enjoy your day. :)
RWH is not where you should be turning for up-to-date info on library support for stuff - a lot of it is pretty out of date (which is not to say that there's not plenty of value to be learned there).
Sidebar to everybody else who might this thread: don't just read cis194, that's a terrible waste of time. You have to do the exercises, including the very first ones.
This is why I'm always tempted to drop non-comment prose. People just starting out think reading will do something for them.
It won't, generally.
The Haskell community has an inofficial motto that reads "avoid success at all costs," from an old presentation by Simon Peyton-Jones. The correct interpretation is "avoid (success at all costs)," that is, don't make decisions for "populistic" reasons, and don't be afraid to take the "high road."
Of course, it would be amazing to see much more "practically" oriented teaching material, because as you say there's quite a bit you just have to figure out. But I don't think Haskell is uniquely bad at this. It's just bad in different ways...
Documentation for dynamically typed, "pragmatic" things – like jQuery, many Node libraries, etc – often confuses and annoys me, because I'm so used to Haskell's type specifications and clear abstractions. Granted, I've been coding Haskell for years, and went to a university that uses it as the primary language for students, but I think Haskell libraries are often very clear and easy to use.
Haskell also has truly excellent frameworks and libraries for things like concurrency and parallellism. Simon Marlow's book is exemplary and wonderful; it should qualify as a very good resource for practicing developers.
Yet another point: GHC's type errors can seem obscure for a beginner, and sometimes they're indeed very tricky, but largely, the compiler actually provides loads of helpful information in a clear and well-presented way (searching for contextual info, spell checking, etc). I can't properly express how much I prefer fixing GHC type errors over debugging JavaScript type errors...
Honestly, I think the state of teaching programming is not great in general. I remember the Java courses at university... Learning how to use Swing, UML diagrams, sockets... It's kind of a nightmare.
But regardless of all of this, it's evident that more and more people are attracted to using Haskell for "real-world" systems, and I believe that Haskell's incubation period as an academic language was utterly crucial to its maturation as a novel and strong technology.
(I'm not accusing you of this by any means, but sometimes there's an anti-academic tone in criticisms of Haskell, which I think is completely misguided and frankly dangerous.)
Conversations with this type tend to go along the lines of "Haskell is the best"/"Why"/"Static typing, lazy evaluation, purity"/"Why are those good things"/"derisive snort". Usually "blub" gets tossed in there for good measure.
Agreed on the generally dismal state of programming education. Usually I'm pretty glad I didn't go to college -- those four years were better spent working on real projects with smart people. But I have been trying to backfill the interesting and useful academic material as I go.
I'm also using wreq[1] recently which has a great intro tutorial and is very concise with the help of lenses[2]. Mind you, I only use the most basic lenses but that has been enough for me so far.
I look forward to trying taggy-lens[3] in the future which is a more lens based approach of parsing html. Though it's hard to imagine anything being more concise than the dom-selector approach.
To go back to your question again though, Haskell has enabled me to write mostly bug-free code quickly and there was more than enough library support for screen scraping. The biggest problem was trying to pick the tools/libraries to use for my task.
0: http://hackage.haskell.org/package/dom-selector 1: http://www.serpentine.com/wreq/tutorial.html 2: https://hackage.haskell.org/package/lens 3: http://hackage.haskell.org/package/taggy-lens
But I've found it semi-refreshing to be confronted with something that is different enough that I have to sit down with it regularly to practice. It isn't just another language, and it really isn't amenable to just fiddling with things until they work.
That said, the gap from newbie to competent is big, an I feel like this is mostly a documentation issue. I've only started very recently and I have awhile to go. You can't expect to grok the implications of monads, laziness, immutability, and pure functional style immediately. But hat doesn't mean they aren't worthwhile, or interesting.
Now if you'll excuse me, I need to harass, er, ask for help on some Haskell I'm stuck on. (BTW: the community is really helpful. There are no charlatans or self-promotional jerks like you'll find elsewhere.)
f(a, b, c)
But not in Haskell, where you do it like this:
f a b c
Of course, there is a reason for doing things this way in Haskell, namely making currying a natural part of the language. If f is a function of three variables, f a b binds values to the first two parameters, yielding a function of one variable.
But it's still a change and a bit of a hurdle.
and FP complete have put a huge effort into putting up tutorials that you can run through interactively https://www.fpcomplete.com/