There are always people who are fans of LISP family languages, who boldly claim their language is "the most powerful", and "easily readable". I will grant you that Lisp and its descendants is powerful, but readable? Utter rubbish. Human languages either read left to right (European languages) or right to left (Arabic & Hebrew), or in any direction (Chinese), but no language reads from the inside-out like Lisp. You peel an onion from the outside-in, but inside-out is so unnatural and awkward that from the beginning Lisp was doomed by its syntax.
Certainly the most readable language I have encountered was Modula-2, the successor to Pascal. It was very easy to read, because it was one of the simplest, leanest languages ever devised. Prof. Wirth concentrated on data structure improvements rather than fancy program constructions which are nothing more than complex subroutines promoted to first class citizens. He took the instruction set of the computer, and mapped it into a higher level language with the minimum of extra stuff. I wrote huge programs in that language and it was decades ahead of its time with symbolic debugging and such strong checking that C programmers can only dream about. Null pointer detection, range checking, no implied type conversions, isolation of definition from implementation of modules, automatic dependency analysis, it had it all in 1974. Bjarne is just now planning to implement the definition/implementation module system of Modula-2, that is how pathetic C++ is in terms of its speed of evolution. C++ is truly a dinosaur language.
As for readability, none of the transformation languages like Lisp are particularly readable. Sure, if you have the knack, but few people have the knack. It is like juggling 5 apples. People who can do it say it is no problem. But take the average man off the street, and give him 5 apples to juggle. It doesn't happen. A lot of people can juggle 3 things, but 5, the difference in difficulty between juggling 3 balls and 5 balls is about 50:1 according to experts. Same with reading LISP, Haskell, Elm, etc.; these languages introduce a set of abstractions that is not natural to people trained in high school algebra, nor are they natural to people who have learned any of the Algol family of languages, so any assertion that large Haskell programs are easy to read has no evidence whatsoever.
Take the source code for Light Table. Written in Clojure. Give that code to a person, and ask for some minor cosmetic change. Then prepare to wait for a decade while they figure it out.
Let me point out something that few people in the programming industry grasp. There are two phases of a program's existence. The first phase, i call original authoring, is where you go from problem concept, to specification, to implementation. I call that the forward direction. The second phase is you have a program and you want to make some change to it, either to fix a problem or to update it to adapt to changed business conditions. I call this the reverse direction, where you go from what you see on the screen or printout, and then try to figure out where it happened in the code, and make adjustments from the output inward. Almost every language in the hands of an experienced author is great in the forward direction. People get very good at cranking out products in the forward direction. But take your code and give it to a stranger, cold turkey, and see what they make of it, going backwards. Not so easy is it?. Even the simplest languages are hard in the reverse direction, because looking at the output, how do you figure out where the decisions were made? the more powerful the language, the harder it can be sometimes to go in the reverse direction. More than 80% of the total lifecycle cost of a software product is consumed by work in the reverse direction, yet language aficionados only ever talk about the forward (authoring stage) of the process.
All of the current crop of languages stink because they don't address the reverse direction, and continue to pretend that authoring was the problem area. Efficiency of software no longer matters in most applications, and what we need desperately is a way to write software that makes it easier in the reverse direction. There is a dawning realization that object-oriented programming was a disaster for maintenance costs, and that great improvements lie ahead in a new software technology.