You point us to the Blub essay as if that settles the matter. It doesn't. I think the Blub essay is wrong.
Here's the Lisp people. They're sure that they are at the top of the power curve (including compared to Haskell), and they can tell you exactly why. "How can you get anything done in Haskell? It doesn't even have macros."
Over here are the Haskell types (pun intended). They're sure that they are at the top of the power curve (including compared to Lisp), and they can tell you exactly why. "How can you get anything done in Lisp? It doesn't even have a decent type system."
This situation - two different languages each looking down at the other - reveals the problem in pg's Blub Paradox. The problem is this: The idea that all languages can be ranked on a one-dimensional axis called "power" is wrong.
You can see this with hardware, for instance. We know what power is in hardware - it's MIPS. But once you think a bit deeper, you might remember that your workload contains a fair amount of floating point, so you have to worry about FLOPS... and there's that one data set that doesn't fit into cache, so you have to worry about memory bandwidth... or would it be worth lower MIPS to have a bigger cache? Now "power" has at least four dimensions (MIPS, FLOPS, memory bandwidth, and cache size). Even more (but for the same reasons), it's naive to say that programming languages can be strictly ordered according to on a one-dimensional "power" axis.
So now you have to start asking "power for what"? I think this is the right question, because nobody ever writes a general computer program. We always write specific ones. We want a programming language that has the most power for that specific problem we're trying to solve.
Once you crack open that door, in walks (for example) a Fortran person, who asks, "How can you get anything done in Haskell or Lisp? They don't even have decent matrix packages!" And before you say "of course they can do matrix math", by "decent" the Fortran person meant a package that can, for example, efficiently handle a banded hermitian matrix with complex elements, and still get good answers even if it turns out to be a stiff problem. I strongly suspect that Lisp and Haskell matrix packages aren't yet up to that standard. (And if you're going to say, "Well, that's just a niche", I suspect that niche is at least as big as the entire Haskell universe.)
Then a hard-real-time embedded programmer comes through the door, and says that their world needs a language that not only doesn't garbage collect, but doesn't cons either. (That niche is probably also as big as the Haskell or Lisp universe.)
And so on.
Think of programming languages as a tree. Think of your problem as a vector. Use whatever branch of the tree gets you the furthest along the vector of your problem. In other words, the best tool for the job. It's not always Haskell. It's not always anything. Learn more than one tool.
Your point that there is more than one axis on which to measure the power of a programming language is well-taken. That said, you can normalize to one axis. The point of pg's essay is that only people who have learned the relevant tools are qualified to judge them.
The solution to your Lisp v. Haskell dilemma is simple: ask the people who know both. I agree with Lispers that macros are powerful, and the stuff in the book Let Over Lambda is ridiculous and awesome. I also think that macros are dangerous, and I prefer to only use them if there's no other alternative. I pick Haskell over Lisp, having used them both extensively, and I've seen far more people come to Haskell from Clojure than the other way around.
With regard to Fortran, embedded, etc, see my response to marcosdumay. Yes, those niches are sizeable and you should use the correct tool for the job. That has no bearing, though, on the question of which programming language is better.
True, but such a normalization is not unique. That is, one language or the other can come out as "more powerful", depending on the normalization chosen.
Your point about "ask those who use both" is harder to refute...
Here's the Lisp people. They're sure that they are at the top of the power curve (including compared to Haskell), and they can tell you exactly why. "How can you get anything done in Haskell? It doesn't even have macros."
Over here are the Haskell types (pun intended). They're sure that they are at the top of the power curve (including compared to Lisp), and they can tell you exactly why. "How can you get anything done in Lisp? It doesn't even have a decent type system."
This situation - two different languages each looking down at the other - reveals the problem in pg's Blub Paradox. The problem is this: The idea that all languages can be ranked on a one-dimensional axis called "power" is wrong.
You can see this with hardware, for instance. We know what power is in hardware - it's MIPS. But once you think a bit deeper, you might remember that your workload contains a fair amount of floating point, so you have to worry about FLOPS... and there's that one data set that doesn't fit into cache, so you have to worry about memory bandwidth... or would it be worth lower MIPS to have a bigger cache? Now "power" has at least four dimensions (MIPS, FLOPS, memory bandwidth, and cache size). Even more (but for the same reasons), it's naive to say that programming languages can be strictly ordered according to on a one-dimensional "power" axis.
So now you have to start asking "power for what"? I think this is the right question, because nobody ever writes a general computer program. We always write specific ones. We want a programming language that has the most power for that specific problem we're trying to solve.
Once you crack open that door, in walks (for example) a Fortran person, who asks, "How can you get anything done in Haskell or Lisp? They don't even have decent matrix packages!" And before you say "of course they can do matrix math", by "decent" the Fortran person meant a package that can, for example, efficiently handle a banded hermitian matrix with complex elements, and still get good answers even if it turns out to be a stiff problem. I strongly suspect that Lisp and Haskell matrix packages aren't yet up to that standard. (And if you're going to say, "Well, that's just a niche", I suspect that niche is at least as big as the entire Haskell universe.)
Then a hard-real-time embedded programmer comes through the door, and says that their world needs a language that not only doesn't garbage collect, but doesn't cons either. (That niche is probably also as big as the Haskell or Lisp universe.)
And so on.
Think of programming languages as a tree. Think of your problem as a vector. Use whatever branch of the tree gets you the furthest along the vector of your problem. In other words, the best tool for the job. It's not always Haskell. It's not always anything. Learn more than one tool.