On Sun, 2007-28-01 at 17:28 +0100, Chris Eidhof wrote: 
For example, if you know one imperative language, you can switch to  
another without taking too much risk. On the other hand, if you  
switch to a language that is completely different, you don't know if  
it will get your job done. It doesn't feel safe.

I first looked at Haskell about... 2001?  While I was still working in the grinding world of too-short this and too-little that.  I looked at Haskell (and a whole bunch of other languages/technologies) because I knew that my imperative languages couldn't get the job done at all.  I was facing increasingly unmanageable code bases (the Anti-Pattern in question was called "Lava Flow", paired with "Golden Hammer" for the most part) and the alternative languages I was looking at initially were just slight improvements on the situation.

Haskell was one language I looked at, but in the end I rejected it and adopted Dylan instead.  (Just in time to watch it die. :()  And the biggest problem with Haskell?  There was little in the way of useful and practical explication of The Haskell Way.

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.

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.  And I'm also serious about potentially writing such a book myself when I get confident enough to work at it.  Because despite some of the things I've said in this thread, I really like Haskell and what I see of as The Haskell Way.  I want to see Haskell -- or something very, very, very similar -- take over from crap like C++.  I'm thinking a structure along the lines of using YAHT as an opening section, followed by some of the Haskell for <Foo> Programmers information in a second, followed by a decent reference 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.

-- 
Michael T. Richter
Email: ttmrichter@gmail.com, mtr1966@hotpop.com
MSN: ttmrichter@hotmail.com, mtr1966@hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr1966@jabber.cn

"Thanks to the Court's decision, only clean Indians or colored people other than Kaffirs, can now travel in the trams." --Mahatma Gandhi