[ruby-talk:18459] Re: Ruby as opposed to Python?

HarryO <[e-mail]> wrote:
: In article <9jfvq1$ac4$[e-mail]>, "Todd Gillespie"
: <[e-mail]> wrote:

:> It would behoove you to read the second half of Paul Graham's recent
:> paper 'Beating the Averages', at http://www.paulgraham.com/avg.html. In
:> a nutshell, programmers that have not understood a particular facility
:> in a language are likely to treat it as unimportant, because they know
:> how to think about programs using the idioms of the languages they
:> already know, but not in these unfamiliar features.  To quote:

: That's an interesting article.  I hope Paul doesn't strain his neck
: looking up to Ruby :-).

You are a Blub programmer and I claim my 2 dollars.

I do hope you are joking, btw.  I would hate to see you read the whole
article and then repeat the behavior he rails against: "I don't understand
your language features therefore my language is better than yours."

: Seriously, though, he mentions as one of the big features they used in
: their development was the ability to define macros.  Not knowing anything
: much about LISP, I was wondering whether you can tell me whether ruby's
: eval (perhaps along with otherruby  features) can be used to achieve the
: same functionality as LISP's macros, or are they more complex beasts than
: that?  Ie, do they provide something we're missing out on?

LISP macros offer an elegant way to dynamically redefine the
language.  Their viability may be a consequence of the uniformity of LISP
syntax which I will define here as:

a prefix function call with n arguments bounded by parentheses;
any argument surrounded by parentheses is a function call evaluated before
the enclosing function.

There are no precendence rules, whitespace significance, side effects,
non-function control blocks (if, for, while in C), etc.  As you can
imagine, manipulating the parse trees is fantasically simple.
This is either a cause or an effect of LISP programmers being more
familiar with code generation than almost anyone else.  Perhaps both.

This is basically impossible (in terms of economic time usage) in a
language with syntax less regular than LISP, like C, Ruby, Algol spawn,
etc.  I have written code generators in Tcl, Perl, and C, and they were
all a major PITA.  So there is a choice here in language design, namely,
to use constructs familiar to human users (a la Perl) and difficult on the
machine, or simple to the machine and pedantic/excessive/boring on the
human.  The choice looks simple in favor of the former, but the latter
offers, if one is sufficiently formal, a way to specify needs in a very
concise manner.  And speaking sufficiently formally to computers is what
programming is all about.

Obviously this conflict will never end.  I hope I illustrated the other
side for you.

HTH.