(fixed - I forgot to convert it to plain text!) - I forward an email
conversation that I had with matz:
Dear Yukihiro,
I find Ruby to be an incredible language, and I thank you for creating
it.
If we take the programming paradigm to be divided into three sections,
we find the first section to be dedicated to the most intuitive and
elegant (in my opinion) language, Ruby - an interpreted and reflective
language.
In the second section, we find the low-level programming types, C and
Assembly, that are dedicated to minimum low-level performance
optimization.
In the final section, we find a macro (programs that write programs) /
proceduralist type of programming language - Common Lisp. When used
properly, it enables amazing feats of abstraction, programmer
productivity, code efficiency, and safety. This is because it is
inherently proceduralist in nature.
In the ideal programming paradigm, 75% of the programmer’s time is
dedicated to Ruby, and the remaining 25% of the time is dedicated to a
serious proceduralist language - Common Lisp.
I could include a fourth section on parallel programming, except that
this section is fundamentally related to an ideal multi-core processing
unit (the ideal one being the Intel Larrabee).
Have you read Paul Graham’s “On Lisp: Advanced Techniques for Common
Lisp” (Paul is distributing a free copy of the book on his website,
although 9 diagrams are missing, which can be found in the original book
- note for the Ruby community: if you are new to Common Lisp, it would
be better to start with Peter Seibel’s “Practical Common Lisp”, which
you can also find for free on the author’s website,
Practical Common Lisp ) and Doug Hoyte’s “Let over Lambda”
(another excellent book, that pushes the boundaries of programming)?
In terms of an ideal programming paradigm, what do you think of adding a
serious macro complement to Ruby? Basically, add a complementing unit to
it that is Common Lisp. The objective is to let the users of Ruby have a
Common Lisp choice in order to be as productive as possible. This will
really help in Ruby’s expansion, especially given that many programmers
are ignorant of Common Lisp’s groundbreaking potential. It is as simple
as adding a Common Lisp module to Ruby.
If you have not done so, please read “On Lisp: Advanced Techniques for
Common Lisp” and “Let over Lambda”. You will understand why I feel that
this is very important.
Thanking you,Marco
/
Marco,
Macro is a great power, but at the same time, it makes the language
syntax different for each application. You will have hard time to read
the program without knowledge of the application/framework macros. So I
am not going to add macro to Ruby.
matz.
/
Dear Yukihiro,
I believed that you would say something like this, given that it seems
like an orthogonal concept. Adding it would make people more confused as
to the syntax used, I agree. However, you cannot disagree that
proceduralism is the key to the programming language’s future. Just like
a higher-level language like Ruby has replaced C except for
performance-oriented tasks, real-world needs are going to dictate that
proceduralism via a macro-based interface is going to be needed for the
languages of tomorrow.
Yukihiro, I am in the camp that says that you cannot change a language
for too long - you would go in circles, or even worse, ruin what makes
the specific language great. In this case, Ruby is the most intuitive
and elegant language, and any search for improvements risk making the
language go in circles.
However, you cannot deny the power that proceduralism holds. In a
theoretical sense, the only improvement that a high-level language can
have is to add what would most likely seem as an orthogonal concept -
proceduralism via a macro-based interface. This is a concept of balance - after this, improvements won’t most likely exist.
I ask you to please read Paul Graham’s “On Lisp: Advanced Techniques for
Common Lisp” (for free on Paul’s site - note for the Ruby community: if
you are new to Common Lisp, it would be better to start with Peter
Seibel’s “Practical Common Lisp”, which you can also find for free on
the author’s website, Practical Common Lisp ) and Doug
Hoyte’s “Let over Lambda” (a Japanese translation exists - however I
would advice you to buy the original English version, as it is important
to understand the author’s words as he meant them to be written).
Think of it like this. Ruby is a non-proceduralist language with
proceduralist elements. Common Lisp is a proceduralist language with
non-proceduralist elements. You can’t be one without the other - it is a
concept of balance and completion. What makes a programming language
great? To be as natural and intuitive as possible. Therefore, what I
said is reasonable, and disagreeing with me would only be contradictory.
Sincerely,Marco
/
Hi,
I have read the books. In fact, I am in part a Lisp programmer. So I
understand the power and the future of programming with macros. But
still, I don’t believe the power of Ruby and the power of macro
wouldcoexist well in a language. I would be happy to be proved wrong
though.
matz.
/
Yukihiro,
Do you agree that a set of problems is best solved with Ruby, and
another one is better solved with Common Lisp? Let’s take out the
performance-related part, and parallel programming with it.
You do agree, and that is because as you said, you are in part a Lisp
programmer. Now, think of it like this. Ruby does certain things really
well, and Common Lisp does other things really well. For the programmer
starting with Ruby, what happens when he doesn’t get to know of Common
Lisp? He gets to know of only 3/4 of a way to solve a problem, but is
ignorant of the remaining 1/4. He would love to learn Common Lisp, as it
would almost double his productivity even though it only solves 1/4 of
his problems.
Because it only solves 1/4 of his problem, the almost entirety of the
world around him proclaims it to be “dead”, that it is useless, or that
a better implementation of it is needed, even though it is very often
the case that the almost entirety of the world has not actually taken
the time to learn this language as well as possible.
Now, think of it like this. Common Lisp is a method to solve problems.
Ruby is another method to solve problems. Together, they solve the
almost entirety of problems. What remains? Performance-oriented tasks.
In an ideal paradigm, these low-level and / or parallel programming
types of problems, don’t exist anymore.
So what do you have remaining?
If I were that programmer, I would be very angry if I missed the
opportunity to learn or use such a language. As is often the case, this
is what is exactly happening in the world. Proceduralism is the future
of a programming language. A programming language can only be like Ruby - but on the other hand, a programming language needs to be
proceduralist in order to maximize its potential. Make Common Lisp a
complement to Ruby, call this Ruby, and you will be there.
In case that you would argue that it is the programmer’s fault that he
doesn’t know of Common Lisp, I would then say that any programmer does
not need Ruby, but can instead easily create a language like Ruby on his
own.
Sincerely,Marco
/
Hi,
Yukihiro, Do you agree that a set of problems is best solved with Ruby, and another one is better solved with Common Lisp? Let’s take out the performance-related part, and parallel programming with it.<<
I do agree that some problems can be solved well using Ruby, and other
problems can be solved well with Common Lisp. IN THEORY, if you can
combine the two languages together WELL, you can solve broader domain of
problems with one language. But if you fail to combine well, you would
kill the future of the language. So without the image of good
combination, it is no use discussing vague imaginary language.
I don’t think simply adding defmacro makes Ruby any better.
matz.
/
Yukihiro,
You are proving what I have said, because you use both Common Lisp and
Ruby. Do you see now what I am saying?
Sincerely,Marco-
In terms of real-world needs, and theoretical perfection, I would like
to ask the Ruby community, what do you think of this?
Sincerely,Marco