The task at hand and libraries available also affects how "hard"/"easy" a language can seem. There are many tasks where higher level languages have more facilities available to help you. Building a web app will be easier in Python than C, for example. On the flip side, good luck writing a device driver in Ruby.

On top of the task-driven reasons, I think the other big reason people find languages easier/harder than others is really a sort of emotional connection. The number of Ruby docs that use the word "joy" or something close speaks to this. Similarly, the people who have emotional responses both for and against Python's syntax and white space might speak to it.

The amount of knowledge you have to keep in your head in order to use the language (this includes syntax, conventions, idioms, gotchas you've got to watch for).

How well the language fits brain (which mostly reduces to how similar it is to other languages you're used to; think imperative versus functional programming).

The ease or difficulty of recovering from an error (C++'s error messages that involve STL templates are notorious for being incomprehensible, but I'm also thinking about things like mysterious crashes you can get if you make a memory-management error at an unrelated point earlier during program execution).

I don't think documentation is a significant issue. It's more important for learning a language than for using it. Once you know a language you'll be able to use it without having to refer to the documentation.

Consistency can be an issue, languages which break from standards, or even what you're used to can be difficult. I grew up on C/C++, and it was the first real language I learned, so anything in that realm (Java, PHP, Perl, etc) is like riding a bike. For that same reason, Ruby was kinda hard to grok for me.

But I think documentation (books, available source code, tutorials) is the biggest issue. Finding a practical PHP or Ruby tutorial is way easier than a Scala or LISP one. I'm the kind of person who learns by reading other people's code, so I've never been interested in the more obscure languages because of that.

Ludicrously complicated syntax being required to refer to something simple, like a pointer to a member function.

Python:

sort(my_list, key=my_instance.sort)

C++/Boost:

sorry, I had only had 2 hours and couldn't work it out (it's 10 years since I did any real C++).

std::vector<std::string> v = getList(); std::for_each(v.begin(), v.end(), boost::mem_fn(&std::string::sort));

Hadn't used it in, well, forever, but have done something similar. Pretty much stolen straight off of http://live.boost.org/doc/libs/1_34_1/libs/bind/mem_fn.html . For non-boost solution: http://www.cplusplus.com/reference/std/functional/mem_fun/

One thing that always made me scratch my head and say, "that seems hard" is Perl vs Ruby. I've done a bit of both, but Perl just looks confusing in comparison.

I know Ruby and Perl as supposed to be close, but when I look at your average Perl script, I just get confused instantly. Ruby of course I get. Yet when I try to read Python (which doesn't have a direct heritage), I quickly get what's happening.

Some languages are closer to how you see a problem. Therefore they're going to be "easier" for you to program in.

"Some languages are closer to how you see a problem."

And how you see a problem is strongly influenced by prior programming language experience.

You often need to determine if a language will become easier for you once your mind groks how it represents problems, and if, in the long run, the effort to reach this comprehension is worth it.

The tricky thing is determining if a language will become easier once you reach that Ah Ha! moment, or if it is intrinsically hard (for whatever reason; typically poor design).