That's probably pretty on-the-mark.

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.)

I don't mind writing boring code provided that I'm working on my own idea.

Don't generalize, they're hard in different ways.

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.

Nice minefield metaphor. I usually call C++ a pointless annoying trivia contest but I really like the image of a minefield. Maybe programming in C++ is like a game show where if you get all the answers right the grand prize is not having to go in to work every weekend for a month to hunt down memory leaks but if you get even a single one wrong you have to walk through a minefield while a bloodthirsty studio audience cheers you on.

"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!

Parsec is indeed a pain in the behind -- it could have been written as a monad transformer (with the current version implemented as a transformation of the Identity monad). It takes a bit of work to make a monad transforming version out of the Parsec source code, a bit more if you want to generalize it out to support parsing byte vectors (as opposed to linked lists of characters) or other things, and overall it's just a pain, and you end up with three monad transformers atop one another, if you do it "right." So then you think, "ok, I'll just make a general parsing typeclass so I can newtype derive solid parsing types," and then boilerplate instances begin, and that takes O(n^2) code overall, where n is the number of monad transformer typeclasses you want to have playing nice with each other. And don't get me started on functional dependencies.

Alright I admit it, I'm one of these crazy people. I've been programming in C/C++ since junior high. It was the second language I learned (the first being Pascal.) I guess because of that I never really saw it as "difficult." Everything is at least somewhat difficult when you're just starting out. Since C was one of the first things I learned that's where all my intuition about languages came from, so everything seemed "natural."

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 wonder if you looked at Lush? (http://lush.sourceforge.net)? Created by Yann LeCun, a prominent Machine Learning researcher, it is one of the quirkier lisps but it interfaces with C/C++ easily and takes away some of the pain. I have used it to work with OpenCV . You can prototype like in MATLAB and end up with very optimized C code for deployment.

Sounds cool. I'll definitely look into it. Thanks!

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.

Part of it, for me, is that you know a C++ version is the /final/ version, it's as fast and efficient as it can be. It's canonical, you won't have to do it again.

But if you have to do new features, you're screwed. So, yeah, I guess it is the final version...new ones are such a pain. (I don't dislike C++. It's fine for systems-level programming. But I'm not using it for anything else.)

C is not C++. You sound like a C programmer more than a C++ programmer.

Nah, I use C++ features pretty heavily. I'll even admit that I use Boost. I use STL when possible, because it's usually more efficient than hand coding and saves some time on implementing common algorithms.

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.

STL and boost are the future of C++.

Better question: why do people continue to waste time starting language advocacy wars, when they could be learning new languages?

I think you'd get more interesting answers if the question were asked like this: Why do people discuss the relative merits of programming languages instead of spending that time learning a new one?

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.)

Why is it so important to learn new languages all the time? Wouldn't you rather just get your startup going as quickly as possible?

The implementation is not inherently interesting. It's just a means to an end.

"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.

I don't program in Haskell, but I find the language to be incredibly alluring and appealing because it seems almost like a way to access the Comp. Sci. gnosis. It's so different, and so incredibly elegant and amazing in what it does and how it does it, that it feels as tho it reveals some arcane, secret knowledge that, once appreciated, will change how you view every aspect of reality itself.

Haskell is fun in that you get to write things using combinators, through abusing laziness, and in a style that feels very mathematical. It makes me program utility function combinators in other languages, which is excellent.

It's not so fun the moment you want to use more than one Monad at once, though.

Dude...get a grip...it's a programming language, not LSD.

Damn, now I have to learn Haskell.

Programming in Haskell is not difficult. It is easier to program in Haskell than it is in most other languages, or at least the ones I know of. I don't find Haskell particularly interesting for any of its so-called mind-blowing features, it's just a practical programming language that lets you get stuff done and communicate your intent to the computer.

I do not want the programming part to be harder.

Really good C++ programmers are often unwilling to give up the control and power (in practical terms) of the language + libraries. Any piece of code written in a higher level language can always be 'improved' upon / optimized in C/C++, while still remaining reasonably generic. This over time pretty much guarantees that 'timeless' code, like math and graphics libraries, ip stacks etc. will have their canonical representations in C or C++, with 'easier' languages simply linking to those, instead of bothering to provide their lesser own. Soo, those who want to write timeless code do it in C / C++, hard or not.

I think Haskell's appeal lies in being everybody's favorite local maximum, while remaining only a very select few's global one.

Haskell is mathematical sound. At least it tries to be.

People enjoy programming in C++?

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.

Some C++ wizards took Greenspun's 10th rule as a challenge and developed template metaprogramming libraries like Loki and Boost :P

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.

Now that's an interesting thought--a two-stage compiler to replace C++: C with a LISP preprocessor.

> Languages like C++ and Java are difficult simply because they're big and inconsistent - memorizing them is not very rewarding.

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.

If you want hard, use Malbolge. http://en.wikipedia.org/wiki/Malbolge

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.

Why do some people consider %w{ Haskell C++ Blub } difficult?

And why do they believe the difficulty is intrinsic to the language and not a result of their own preconceptions and assumptions?