So they actually want the programming part to be harder!
A better solution would be to take a more difficult course or find a job with more rewarding work. It's better to work on more difficult algorithms and/or more creative specs.
I know that for me, most of the appeal of Haskell is that every new language feature I learn is something mind-expanding. It's not just that it's difficult, though - it's that it's conceptually mindblowing, where each concept is widely applicable to a bunch of different programming situations. And it doesn't do anything like other languages, so you have that feeling of clawing your way up the learning curve and exercising your brain at every step.
I know a decent amount of C++ too, but not enough to be an expert at it. In my view, life's too short to get good at C++. It feels like when I learn a new C++ feature, it was bolted on to solve somebody's particular problem, and isn't conceptually educational like Haskell.
And I did end finding (well, making) a more rewarding job, and am perfectly happy using Python & JavaScript for it, but it remains to be seen whether this "job" will ever make any money. There's a set of hard problems, and a set of problems people will pay you to solve, and fairly little overlap between the two of them. If you're in the overlap (like Google), good for you. However, even in a startup, about 95% of the work is dealing with nitty-gritty details that really aren't that difficult or exciting. (The remaining 5% is what makes you rich, but you can't ignore the boring 95% without having all your customers ignore you.)
C++ is hard like tiptoeing across a minefield is hard. "Don't forget to make destructors virtual! Use auto_ptr! But don't put it in an STL container! Don't subclass the STL containers! Watch out for that implicit copy constructor!"
I found Haskell to be hard like trying to take a walk in the fourth dimension would be hard. "Okay, I want to do I/O, wrap that in a monad. I want to use the Parser monad too, Parsec is so nice! Ok, now I need a monad transformer to work with the I/O and the Parser. Oh yeah, and I want to pass a State around, another monad. How do I get anything done at all with all these monads?!" It was fun writing pure functional code in Haskell, real world interaction seemed to melt down into a horrible mess.
I think the true easy languages are Python and LISP, mostly because they're consistent and pragmatic. Even C or Java are easier to use than C++ because they're more consistent and predictable.
"Oops, sorry contestant #1. You forget to say that what you were deleting is an array. Since your code compiled you can still stay in the game by walking across that minefield."
Step, step, pause, step, pause, breathe deeply, step, step, KABOOM!
I still program in C++ as my primary language, but that's mainly because of the area that I work in - computer vision. In this field your production code has to run fast. Using something like Python or Java is just not an option (unless you want to wait 3 days to process an 8 hour video.) All the major computer vision libraries - OpenCV, Gil, ITK etc. are in C/C++ so I'm pretty much stuck. Prototyping is done in MATLAB so that speeds up development a bit.
Still, I love it. I don't even know if I can really articulate why, but there is just something fun about having to work with a language that's so close to the hardware. My undergrad degree was in electrical engineering, so to me the low level behavior of the processor is just something that's always in the back of my mind, and with C you can clearly see the assembly level code right through every line - and that's kind of pleasant.
I've always been kind of a math guy - so I have a bit of an obsessive need to understand how every element of the system I'm working with functions, right down to the physics of the transistors. If I don't understand something it's kind of like using a theorem or formula that you have never seen the proof for, or don't really understand. I'll be honest, that kind of scares the shit out of me.
Anyway, so that's a look into the psyche of a person who likes to program in C :)
That being said, nothing beats a nice high level language like Python, and for most tasks that's the best choice. But there will always be room in the world for a highly optimized language like C.
I actually haven't looked at Lisp at all, but Paul's enthusiasm about it is pretty contagious, so it's next on my list of skills-to-learn.
C++ gives you the ability to put together really powerful frameworks to work with, but deep within the code you're still working with the same fundamentals.
As currently stated, it's loaded with presuppositions that are hard to overcome if you want real answers. (eg: This post is language advocacy, language advocacy is a waste of time.)
The implementation is not inherently interesting. It's just a means to an end.
If no one on your team finds implementation details inherently interesting, your implementation is likely to suffer, perhaps to the point of being uncompetitive.
It's not so fun the moment you want to use more than one Monad at once, though.
I do not want the programming part to be harder.
I think Haskell's appeal lies in being everybody's favorite local maximum, while remaining only a very select few's global one.
Many people enjoy learning difficult things for the challenge of it, but no sane person enjoys using tools that remain difficult once understood. There are concepts in Haskell (and Lisp, ML, Smalltalk, etc...) that are considered difficult or confusing by the mainstream. They're also powerful, making it rewarding to learn them. Languages like C++ and Java are difficult simply because they're big and inconsistent - memorizing them is not very rewarding.
Its kind of interesting to observe how C++ typelists do compile-time metaprogramming, they use a cons linked-list of types in templates. Its kind of sad to watch though because there's no REPL to set the cons free.
Your 'programming body memory' memorizes the language, and the mines, no biggie - you just program a certain way. What /sucks/ about C++ is the amount of boilerplate you have to write - in, probably, most interactions with the STL, and in class definitions, there's a thought-interfering degree of mandatory (or 'good style mandatory') boilerplate. At least 'for' loops will get cleaner with C++-0x.
Wanting to code in a 'hard' language is just stupid. You'll only code in a hard language because it's able to something you want that 'easy' languages can't do, or do as efficiently.
And why do they believe the difficulty is intrinsic to the language and not a result of their own preconceptions and assumptions?