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 languagesyntax different for each application. You will have hard time toread the program without knowledge of the application/frameworkmacros. 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 Iunderstand the power and the future of programming with macros. Butstill, 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 otherproblems can be solved well with CommonLisp. IN THEORY, if you cancombine the two languages together WELL, you can solve broader domainof problems with one language. But if you fail to combine well, youwould kill the future of the language. So without the image of goodcombination, 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