If the latter, pg makes a good argument in section 4.8 of On Lisp:

"So yes, reading a bottom-up program requires one to understand all the new operators defined by the author. But this will nearly always be less work than having to understand all the code that would have been required without them.

If people complain that using utilities makes your code hard to read, they probably don’t realize what the code would look like if you hadn’t used them. Bottom-up programming makes what would otherwise be a large program look like a small, simple one. This can give the impression that the program doesn't do much, and should therefore be easy to read. When inexperienced readers look closer and find that this isn’t so, they react with dismay."

You know, I don't think this is true at all. Concision can make things harder to read, because you have to understand everything you read from scratch. A language where some common patterns come with a bit of boilerplate allow you to orient yourself via that boilerplate. The visual representation of a common pattern provided by the sugary syntax of some languages is, in one sense a waste of space and typing, but it can make code easier to read than a more concise language would be.

Compare a language which forces you to write this

    ll = []
    for x in xx:
      if bar(x):
        ll.append(x)

Contrast the above with

    ll = [x for x in xx if bar(x)]

    filter bar xx

I find Ruby way much more natural.

xx.select { |x| bar(x) }

Even Clojure is better

(filter (fn[x](bar x)) xx)

or

(filter #(bar %) xx)

That said, in Python, you have to take what you can get, though. And generally I expect more people are familiar with Python than Haskell. Probably I should've used Ruby. Oh well.

  filter foo xx

    filter foo xx

Pseudocode is better expressed in Python than Lisp, therefore much better in the academic world.

My point stands: READABILITY.