On 29/01/07, Michael T. Richter
I started, given that I could actually have the free time now, looking at Haskell again about a year ago. (It's a major point in Haskell's favour that it always stuck around in my mind after first encountering and rejecting it, incidentally!) The documentation situation is better now, yes. Far better. But still not useful for people who are actively developing software in the C++/Java/C#/crap-"solution"-of-the-day daily grind. Now, at least, there actually *is* useful information. Finding it, however, takes up valuable time when you've got Yet Another Laughable Deadline ahead of you from your boss who is still unfamiliar with the Triangle of Quality (Fast <=> Cheap <=> Good : pick any two) and who has no patience for your strange ideas which you can't explain *because you yourself aren't sure of the ideas yet*. And I'm positive that this drives people off. I'm positive because it drove me off and I'm far more prone to experimentation with oddball technologies than most of the people I've ever worked with.
Agreed. I'm in the same boat. I can't realistically use Haskell at work until I can pull together the building blocks *fast*. That means, half an hour grabbing a reference and fiddling a bit to get a trivial database query working. Another half hour checking up on how I bolt together the boilerplate needed to add logging to a server. Etc. It *has* to be possible to do this - I can do it in Python, or Perl, or even Java. So if I can't do it in Haskell, then I'm back stuck with one of those languages. I may not like it, but it's a practical reality in my job. I can try to learn at home (and I do!) but I don't have the same sort of issues at home, or the resources to simulate them (100+ databases running over a WAN that I need to query simultaneously, in parallel, just to provide viable response times, for example :-)). So home problems end up being "toy" problems, and I'm only learning for the intellectual exercise (a good reason, but not helping with work). I'm very serious about the need for a "Haskell for the Working Programmer"
book. And by this I mean a book and not a tutorial on some part of Haskell which proves difficult.
Agreed. Something I can keep on my desk for reference, as well as browsing. ... and closing with a cookbook of Haskell solutions to real-world problems
(networking, database, general I/O, common algorithms, etc.) featuring Best Known Approaches (which remain, nonetheless approachable) to them.
Yes, a cookbook approach is an excellent resource. It doesn't have to cover everything, but it needs to focus on practical problems, and "just do this, and you're started" solutions. The other thing that is needed, IMHO - and this is visibly improving, but can still get better - is availability and ease of use of libraries. I'd like to be able to "just download" a Windows binary for libraries I need - logging, DB access, HTTP, client access to Windows COM objects, a GUI framework, sending emails, etc ... Again, it's the "I need it now" issue - I can spend time searching out or even developing such things, but when I don't even have the time to write the code I need for my job (hence wanting a high-level language like Haskell to speed up development :-)) what chance do I have if I have to spend time locating libraries as well? Python does well here with its "batteries included" approach, and the cheeseshop package index. Perl has CPAN, but quality and ease of installation issues have hit me there in the past. Haskell seems to be getting there, but it feels to me like there's a "critical mass" point it still has to get over. But there's clearly an interest in the community for this type of thing, so I suspect it's only a matter of time. I'll stop rambling now. Paul.