Adding Common Lisp to Ruby (fixed)

(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,
    http://www.gigamonkeys.com/book/ ) 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, http://www.gigamonkeys.com/book/ ) 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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs