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.

Sadly, no:

 irb(main):001:0> (1..10).max
 => 10
 irb(main):002:0> (1...10).max
 => 9

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.

Python does the same thing with range:

 >>> range(1,10)
 [1, 2, 3, 4, 5, 6, 7, 8, 9]

Leaving out the starting value starts at zero:

 >>> range(10)
 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Which is like dotimes:

 [1]> (dotimes (i 10) (format t "~d" i))
 0123456789
 NIL

There's an implied "less than the supplied high value" in all cases.

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 think you missed part of my point, which is that "..." vs. ".." is a subtlety introduced by the mantra of high-density syntax seen in LFSP design.

The 10 doesn't print, btw.

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:

http://brl.codesimply.net/brl_4.html#SEC31

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.

I agree, the for loop is not intuitive at all, just historically present. However, try comparing the ruby against:

for x in range(10): print x

Actually Vanier may have a point that LFMs make programmers more interchangeable at big cos. So ultimately the argument against them may be startups.

Having a language that is massively popular is one factor in making it easier to find someone to take over code, but I think many managers have an unrealistic estimate of how much it helps. In some ways it actually hinders, by putting more noise into the hiring process.

In my day job, the ultimate argument was hiring a new graduate who was writing good production code in the LFSP on his second day. An LFSP lets you create a language that fits the problem domain nicely. This works both in normal companies and in startups.

If you're saying that startups can prove the value of an LFSP by being successful with it, I agree. If you're saying that doing a project as a startup eliminates the risk of having code that is hard for someone else to maintain, then I disagree. There are plenty of reasons why a startup might need to find someone capable of working within their codebase.