This is a fairly interesting discussion. I'm not a Haskelite (if I had to pick a favourite language it would be OCaml, with Common Lisp and plain-old-C being close seconds), but I can understand where he's coming from. I'd imagine most people on this site at in the same boat: we don't get to have full freedom to choose our tools (in some cases even if we're running our own companies: there are many interesting projects where our favourite tools are the wrong tools for the job). That doesn't mean we should lose passion for those tools, nor does it mean that we can't find meaning and enjoyment in our work.

Oddly enough, I've found this sort of inspiration when I was reading "Programming Pearls". The author managed to maintain an very upbeat and enthusiastic tone, pointing out clever hacks, even when he talked about programming in Cobol and BASIC. That helped me regain the sight of the fact that as a professional programmer and a (for lack of a better word) computer nerd, I was lucky enough to be in a place where I could make a profession out of my passion. Most people aren't that lucky. The fact that I don't always get to choose my tools shouldn't let me get in the way of enjoying programming: I love to program, when I drive in to the office, I'm going to be programming.

Ultimately, though, the advice I would give is:

* Look for interesting and non-trivial work, irrespective of what language is used (that criteria does generally disqualify some of the most frustrating and boring "niche" languages e.g., SAP, ASP, Coldfusion, PHP, Visual Basic).

A common pattern I've noticed when interesting languages are used for mundane problems in start-ups is that as soon as the initial generation of developers leaves (and the start-up becomes a modestly profitable midsize company: most stay that way, rather than become "the next Google") management pressure grows to switch to blub.

* Consider non-blub languages that on .NET and JVM: F# (being worked on by Peyton-Jones!), Scala (surprisingly many Haskell hackers are involved in it, despite Scala being far closer to OCaml), Clojure (borrows several ML family concepts in a very interesting way -- that alone would actually make it interesting even if it didn't run on the JVM)

* Additionally, consider a full time job rather than projects and free lancing. If technology is a company's core competency, they're going to be very reluctant to outsource its development (typically exceptions are only made for exceptional individuals who are unwilling to sign on full time and even then it's often difficult to do).

Almost axiomatically, some of the most interesting software work is generally done by companies where software is the core competency (the big exception being things like computational finance and scientific/medical computing or highly innovative enterprises such as Amazon [pre-AWS -- AWS made them a genuine tech company] or PayPal). Thus, if you only choose to work on a freelance/project basis you're likely locking yourself out of very interesting jobs. Of course, this doesn't apply if you're in an area where most of the full-time jobs are in the outsourcing industry (either in offshoring firms or in off-shore offices of foreign firms).

* Use Haskell (or whatever else you like) as your secret weapon. Build prototypes in it and then once you have a clear mental picture implement them in another language. Write tools in it to automate away the drudgery (code analysis, debugging, verification: things Haskell is great at).

I should add that C and C++ shops tend to be slightly more open to this use of Haskell, OCaml, Scheme and other uncommon languages: C/C++ are not very scalable languages when it comes to "scaling down" to scripting and automation work. Nonetheless I also know of people prototyping Java and Scala code in Haskell as well.

* Don't forget that Haskell, Common Lisp etc... jobs are out there. They're just rare. They also typically look for individuals with specific skills rather than individuals skilled at specific languages e.g., you're more likely to find a Haskell job if you've written static analysis tools in Java than if you've written web apps in Haskell. ITA software very specifically stated that they don't require new hires to know Lisp, they want smart people whom they're willing to invest in and educate. "I really want to program in X language and you're one of the few places that uses it", unfortunately, won't persuade them if you can't pass their technical interview (unless they're specifically looking for an evangelist rather than a developer).

If you can manage to provide a more or less stable situation for yourself which lets you develop new skills, you can always switch when tgw opportunity comes. Technology job market is usually fluid. If you're not constantly thinking "how will I get the next contract, what money will I live on" you don't have to keep taking jobs you don't like (only to discover a posting for a "perfect job" a week after you begin a new six month contract).

Finally, remember that there are people who hate Haskell, Lisp etc.. too when they are forced to use it. There's no better example than university students. I was unfortunate enough to be exempt (as a CS major in School of Arts and Sciences vs. a CSE student in the School of Engineering) from taking a specific undergrad course (the equiv of 6.001 or CS68a) that was taught in Haskell. I couldn't enroll in the course, as the priority went to students from whom it was required. I was green with envy, but most students absolutely hated it. I volunteered to help out my Berkeley friends with CS68a (their SICP class), but they endlessly complained of not knowing what the point of the course was (especially the non-CS students who had no prior or following programming experience).