One of the features of LFSP's is that the code density is higher, which I'd argue is a good way to make the code harder to read, not easier.
Here's an example in ruby:
(1...10).each{ |x| print x }
Tell me, does the 10 print or not? You'll need a second glance plus a good memory to answer that question.
Here's the same code in C++:
for (int x = 1; x < 10; x++)
cout << x;
Verbosity makes it easier for the non-you programmer to look at a random piece of code and decipher it. You feel smarter for having written that Ruby code (and the C++ is boring, I'll agree). But I'm gonna have to say the Ruby code has less readability outright just because it's so dense.
If (1...10) doesn't yield a list of numbers from 1 to 10 inclusive, that's a bug in Ruby. The problem is not density. It's perfectly clear what this code example should mean.
Ruby suffers from a bit of Perl-syndrome, and relies too much on magic syntax and "conventions" created by library authors. It's a nice language and all, but I still prefer Python over Ruby since Python is a simple, clean and elegant language with just a small number of elegant concepts.
I'm not claiming that that example is dense code in and of itself, merely that encoding important differences in subtle ways is a by product of the LSFP way of thought. Verbose code is the opposite of clever code, so far as I can see.
Ruby and C++ both have a complex syntax, nevermind that being superficial. The LFSP example in the article was Ocaml, which doesn't even have operator overloading! What makes Ocaml an LFSP - the little I know about it - includes a nice combination of FP and OO plus a powerful type system.
The only reason I can think of why someone would look at the Ruby code and not be immediately sure that the 10 prints, is if they've become very accustomed to for loops like the one in the C++ example. It's conditioning, not intelligence, that makes the difference.
I don't think the ".." vs "..." level of density is universal in LFSP design. Macros in Lisp/Scheme are words. See the sql-repeat macro with group-beginning? and group-ending? for example. It makes things more transparent than your typical LFM implementation would:
Then by your measure, is Perl the most-LFSP language out there? I think Perl reads like line noise. High-density syntax with clear, simple concepts is a desirable feature in a language. Assigning some function to every possible permutation of symbols (a la Perl) is just stupid. Ruby falls into the "just stupid" bin in this case.
Here's an example in ruby:
Tell me, does the 10 print or not? You'll need a second glance plus a good memory to answer that question.Here's the same code in C++:
Verbosity makes it easier for the non-you programmer to look at a random piece of code and decipher it. You feel smarter for having written that Ruby code (and the C++ is boring, I'll agree). But I'm gonna have to say the Ruby code has less readability outright just because it's so dense.