I think he's onto something but that there's more to the picture.
Actually what I found more interesting was one of the links off the
essay, though, specifically this one:

http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf

In which a study of the same problem solved by many different
programmers in many different languages found that there were definite
productivity differences between languages, but that the productivity
differences between programmers were much more significant.

I think it's obvious that succinctness is a particular power, but the
question of succinctness being equivalent to power, I'm still somewhat
unconvinced.


-- 
Giles Bowkett
http://www.gilesgoatboy.org


On 9/30/06, Pete Yandell <pete / notahat.com> wrote:
>
> On 30/09/2006, at 2:40 PM, gregarican wrote:
>
> > Agreed. The only way that I consider Ruby as being more succinct
> > compared to other languages such as C++, C, Java, VB, etc. is that
> > there's less curly braces, and no redundant typing of new static
> > variables. God, I'm glad I can choose what I program in!
>
> While I don't think Paul Graham's idea of succinctness is the only
> measure of the value of a programming language, I think he's on to
> something. Succinctness can give you an idea of the level at which
> concepts can be expressed in a language.
>
> By way of example, here's some code from one of my production Ruby
> apps that takes an array of different versions of a Monkey object
> (don't ask), and returns a new array containing the changes between
> each version and the next:
>
>      monkeys.enum_cons(2).collect {|a, b| b.differences_from(a) }
>
> This is a lot more succinct than any way I can think to write the
> equivalent in C++, C, Java, VB, etc. precisely because Ruby has
> constructs that let me express the ideas of "step through pairs of
> elements in this array" and "collect the results of applying an
> operation to each one". In most languages, of course, I'd have to
> write my own loop and do this step by step.
>
> This is powerful because I'm expressing things in the same way I
> naturally think about the problem: step through the array in pairs,
> collecting the results of taking the differences between each pair.
> That means fewer errors, simpler testing, more confidence in the
> code, and better readability and maintainability.
>
> So we have some good succinct code. Is the succinctness what's good
> about it? Not in itself, but the succinctness certainly hints that we
> must be describing our solution at a fairly high level, and that's a
> good thing.
>
> Pete Yandell
>
>
>