This is probably old news to many here, but I found it
to be an interesting read, with implications for Ruby.
“Succinctness is Power”
Paul Graham
http://www.cfcl.com/rdm Rich M.
http://www.cfcl.com/rdm/resume [email protected]
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development
Rich M. wrote:
This is probably old news to many here, but I found it
to be an interesting read, with implications for Ruby.“Succinctness is Power”
Paul Graham-r
I’m totally underwhelmed by Paul Graham’s writings. First of all,
succinctness in programming languages gives rise to languages like
Forth, Scheme/Lisp, and APL. While all three have their cults, and all
three are still in use in their well-defined niches, they are not viable
candidates for most programming projects for one reason or another.
Second, the “conventional wisdom” is that the power of Ruby comes from
dynamic typing, flexible syntax, metaprogramming, and a kind of “upward
compatibility” from Perl.I don’t think succinctness is a factor.
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!
If I was to make a string in Java I would say:
String myString = new String(“foo”);
But if I was in Ruby I would just say:
myString = “foo”
I know it’s not like I’m typing the Rosetta Stone, but Ruby saves me a
lot of needless typing (bad pun intended perhaps).
On 9/29/06, gregarican [email protected] wrote:
If I was to make a string in Java I would say:
String myString = new String(“foo”);
No, you would say
String myString = “foo”;
Java does have literal strings, you know.
On 9/30/06, gregarican [email protected] wrote:
If I was to make a string in Java I would say:
String myString = new String(“foo”);
But if I was in Ruby I would just say:
myString = “foo”
I know it’s not like I’m typing the Rosetta Stone, but Ruby saves me a
lot of needless typing (bad pun intended perhaps).
In the old days we used to day “Strong typing breaks keyboards!”
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
gregarican wrote:
I know it’s not like I’m typing the Rosetta Stone, but Ruby saves me a
lot of needless typing (bad pun intended perhaps).
Funnily enough, I find full autocomplete saves me more net keystrokes.
And reaching for the Shift key. And I find keystroke arguments silly
overall.
However, type inferencing local variables I’d still stab for.
David V.
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 B.
http://www.gilesgoatboy.org
Giles B. wrote:
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.
Perhaps he’s inferring a non-equivalence relationship, but perhaps a “is
propotional to” relationship, or similar based on how you go about
measuring succinctness and power in the first place.
Nic
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 Y.
Well, considering that Paul Graham is a Lispnik, I think we can infer
what his definitions of “powerful” and “succinct” in a programming
language are. What would be interesting to me would be where he stands
on the great “Common Lisp vs. Scheme” divide.
He’s definitely from the Schemer tradition; Favouring recursion over
iteration even though Common Lisp is not tail-recursive; Eschewing
Common Lisp’s powerfool ‘Loop’ construct because it’s not lispish
enough; Frequently explaining how using OO, and in especial, CLOS,
are simply artifacts of not knowing how to use macros and lambdas
properly; Listing a feature set for that ‘dream lisp’ you’re going to
create one day which has almost a one-to-one feature parity with
Scheme R6RS.
Perhaps more to the point would be a comparison of Lisp, Scheme and
Ruby
as hosts for internal domain-specific languages. Didn’t somebody do
that
already?
Down that way lies flamewars, madness and death. I reckon it is
sufficient to notice that Scheme is a little too minimalist to be a
useful general-purpose language, the relative paucity of Lisp’s
library ecosystem works against its chances of ever breaking the
mainstream and that Matz admits himself to borrowing good things
liberally from Lisp(s) just as from Smalltalk and Perl, Ruby’s two
other formidable forbears.
In any case, there’s a question about about to what extent you
should host DSLs internally. It’s my feeling that if you want to
inline a DSL in your code, make sure that language is still
syntactically recognizably a Ruby. Ruby on Rails is a classic example.
If you want to create a non-idiomatic, syntactically strange DSL and
inline it in your code via abuse of language facilities, that’s how
you end up with Common Lisp’s ‘Loop’ Macro. It’s not good, and it’s
definitely ugly, as Paul Graham says.
Once you cross that line where your DSL is no longer ‘a Ruby’, create
a grammar for it and knock together a parser for it in Racc.
Martin
Dr Nic wrote:
Giles B. wrote:
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.Perhaps he’s inferring a non-equivalence relationship, but perhaps a “is
propotional to” relationship, or similar based on how you go about
measuring succinctness and power in the first place.Nic
Well, considering that Paul Graham is a Lispnik, I think we can infer
what his definitions of “powerful” and “succinct” in a programming
language are. What would be interesting to me would be where he stands
on the great “Common Lisp vs. Scheme” divide. Or what he thinks of
Forth, the “other succinct and powerful language.” 
Perhaps more to the point would be a comparison of Lisp, Scheme and Ruby
as hosts for internal domain-specific languages. Didn’t somebody do that
already?
Martin C. wrote:
In any case, there’s a question about about to what extent you should
host DSLs internally. It’s my feeling that if you want to inline a DSL
in your code, make sure that language is still syntactically
recognizably a Ruby. Ruby on Rails is a classic example.
The problem I have with the two best-known Ruby DSLs, Rails and Rake, is
the somewhat non-intuitive mix of words that don’t begin with colons,
and symbols, which do. And Rails requires YAML in some places that are
jarring to the reader. Why is the database connection description file
in YAML and not in “a Ruby”?
If you want to create a non-idiomatic, syntactically strange DSL and
inline it in your code via abuse of language facilities, that’s how you
end up with Common Lisp’s ‘Loop’ Macro. It’s not good, and it’s
definitely ugly, as Paul Graham says.Once you cross that line where your DSL is no longer ‘a Ruby’, create a
grammar for it and knock together a parser for it in Racc.
Ah, but once you cross that boundary and start building an external DSL,
what does Ruby have to offer that other compiler-compiler tools don’t
have? Mind you, I haven’t yet tried to build anything with Racc, so I
don’t know if it’s a significant improvement on Yacc, Bison or the Java
thingie – is it Antlr??
On 1 Oct 2006, at 11:40, M. Edward (Ed) Borasky wrote:
the somewhat non-intuitive mix of words that don’t begin with colons,
and symbols, which do.
True, but at least it’s recognizably, syntactically, Ruby. I’m not
sure there’s a way round the colon issue, you just have to live with it.
And Rails requires YAML in some places that are
jarring to the reader. Why is the database connection description file
in YAML and not in “a Ruby”?
I guess, because the feeling is that YAML is more recognizable as
user-editable config than a Ruby script, which would tend to frighten
some people off?
Once you cross that line where your DSL is no longer ‘a Ruby’,
create a
grammar for it and knock together a parser for it in Racc.Ah, but once you cross that boundary and start building an external
DSL,
what does Ruby have to offer that other compiler-compiler tools don’t
have?
Easy integration with the rest of your Ruby codebase, mainly.
Mind you, I haven’t yet tried to build anything with Racc, so I
don’t know if it’s a significant improvement on Yacc, Bison or the
Java
thingie – is it Antlr??
Well, C is not a great language for writing parsers in, and in my
experience neither is Java. The best language I’ve seen for writing
language parsers is Haskell. Though Racc does a competent job. I
don’t think it’s antlr, though.
Martin
Martin C. wrote:
On 1 Oct 2006, at 11:40, M. Edward (Ed) Borasky wrote:
…
Well, C is not a great language for writing parsers in, and in my
experience neither is Java. The best language I’ve seen for writing
language parsers is Haskell. Though Racc does a competent job. I
don’t think it’s antlr, though.Martin
A nice example of a pure succinct Ruby parser is Dennis Ranke’s
recursive descent parser
written for his solution to the Dice Roller Ruby Q.
http://www.rubyquiz.com/quiz61.html
And yet another language parser (for C) is
Just my two cents!
Cheers,
verno
Martin C. wrote:
the somewhat non-intuitive mix of words that don’t begin with colons,
and symbols, which do.True, but at least it’s recognizably, syntactically, Ruby. I’m not sure
there’s a way round the colon issue, you just have to live with it.
Yeah … as does the person who’s trying to put a timestamp like ‘10:30’
into a DSL in the “natural way”. That “natural way” would work in Forth,
by the way, and is in fact the historical way to do things in Forth. In
Forth
from 10:30 to 11:30
the ‘from’ word would scan and parse the ‘10:30’ word to its right, etc.
And Rails requires YAML in some places that are
jarring to the reader. Why is the database connection description file
in YAML and not in “a Ruby”?I guess, because the feeling is that YAML is more recognizable as
user-editable config than a Ruby script, which would tend to frighten
some people off?
I was actually going to post this as a separate question for David
Black, since it arose in my reading of the section in his book
describing how Rails uses the Ruby syntactic freedom to make programming
more like editing a config file. My conjecture was that the database
config file was in YAML rather than Ruby because YAML is a more
user-friendly way to represent a nested set of key/value pairs than
the Ruby code.
In fact, maybe YAML is another shortcut in constructing DSLs, since
everything is text in a YAML file without all those nasty single or
double quotes getting in the way.
Well, C is not a great language for writing parsers in,
K & R and the rest of the UNIX founders apparently thought otherwise.
K & R and the rest of the UNIX founders apparently thought
otherwise.
The K&R C specification is tiny. I wouldn’t want to write a parser
for a language spec of the magnitude of C++ or Perl 6 in C.
Others would though, and those people are bonkers.
Martin
M. Edward (Ed) Borasky wrote:
The people who designed C++ and Perl 6 are the ones who are bonkers, not
those who would parse them with C.
Hey, but if you ever need a protected abstract virtual base pure virtual
private destructor, you’ll be thankful to the former ones 
David V.
On 10/1/06, M. Edward (Ed) Borasky [email protected] wrote:
in YAML and not in “a Ruby”?
DHH mentioned at Canada on Rails (if I recall) that having
database.yml instead of database.rb was basically a beginner’s
mistake, and that distant-future plans include turning that into a
Ruby script.
So, at least the rails core team agrees with you. Heh.
Martin C. wrote:
The people who designed C++ and Perl 6 are the ones who are bonkers, not
those who would parse them with C.
David V. wrote:
M. Edward (Ed) Borasky wrote:
The people who designed C++ and Perl 6 are the ones who are bonkers, not
those who would parse them with C.Hey, but if you ever need a protected abstract virtual base pure virtual
private destructor, you’ll be thankful to the former onesDavid V.
C++ is a destructor.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs