From: NF BetaK Date: 2010-08-18T22:56:00+09:00 Subject: Adding Common Lisp to Ruby --_7775656d-141d-4f65-b21f-4cb79affb7af_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I forward an email conversation that I had with matz: -Dear Yukihiro=2C I find Ruby to be an incredible language=2C and I thank you for creating it= . If we take the programming paradigm to be divided into three sections=2C we= find the first section to be dedicated to the most intuitive and elegant (= in my opinion) language=2C Ruby - an interpreted and reflective language. In the second section=2C we find the low-level programming types=2C C and A= ssembly=2C that are dedicated to minimum low-level performance optimization= . In the final section=2C we find a macro (programs that write programs) / p= roceduralist type of programming language - Common Lisp. When used properly= =2C it enables amazing feats of abstraction=2C programmer productivity=2C c= ode efficiency=2C and safety. This is because it is inherently proceduralis= t in nature. In the ideal programming paradigm=2C 75% of the programmer's time is dedica= ted to Ruby=2C 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=2C except that thi= s 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=2C although 9 = diagrams are missing=2C which can be found in the original book - note for = the Ruby community: if you are new to Common Lisp=2C it would be better to = start with Peter Seibel's "Practical Common Lisp"=2C which you can also fin= d for free on the author's website=2C http://www.gigamonkeys.com/book/ ) an= d Doug Hoyte's "Let over Lambda" (another excellent book=2C that pushes the= boundaries of programming)? In terms of an ideal programming paradigm=2C what do you think of adding a = serious macro complement to Ruby? Basically=2C add a complementing unit to = it that is Common Lisp. The objective is to let the users of Ruby have a Co= mmon Lisp choice in order to be as productive as possible. This will really= help in Ruby's expansion=2C especially given that many programmers are ign= orant of Common Lisp's groundbreaking potential. It is as simple as adding = a Common Lisp module to Ruby. If you have not done so=2C please read "On Lisp: Advanced Techniques for Co= mmon Lisp" and "Let over Lambda". You will understand why I feel that this = is very important. Thanking you=2CMarco / Marco=2C Macro is a great power=2C but at the same time=2C it makes the languagesynt= ax different for each application. You will have hard time toread the progr= am without knowledge of the application/frameworkmacros. So I am not going = to add macro to Ruby. matz. / Dear Yukihiro=2C I believed that you would say something like this=2C given that it seems li= ke an orthogonal concept. Adding it would make people more confused as to t= he syntax used=2C I agree. However=2C you cannot disagree that proceduralis= m 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=2C= 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=2C I am in the camp that says that you cannot change a language fo= r too long - you would go in circles=2C or even worse=2C ruin what makes th= e specific language great. In this case=2C Ruby is the most intuitive and e= legant language=2C and any search for improvements risk making the language= go in circles. However=2C you cannot deny the power that proceduralism holds. In a theoret= ical sense=2C the only improvement that a high-level language can have is t= o add what would most likely seem as an orthogonal concept - proceduralism = via a macro-based interface. This is a concept of balance - after this=2C i= mprovements won't most likely exist. I ask you to please read Paul Graham's "On Lisp: Advanced Techniques for Co= mmon Lisp" (for free on Paul's site - note for the Ruby community: if you a= re new to Common Lisp=2C it would be better to start with Peter Seibel's "P= ractical Common Lisp"=2C which you can also find for free on the author's w= ebsite=2C http://www.gigamonkeys.com/book/ ) and Doug Hoyte's "Let over Lam= bda" (a Japanese translation exists - however I would advice you to buy the= original English version=2C 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 procedural= ist elements. Common Lisp is a proceduralist language with non-proceduralis= t 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=2C what I said is reasonable=2C and di= sagreeing with me would only be contradictory. Sincerely=2CMarco / Hi=2C I have read the books. In fact=2C I am in part a Lisp programmer. So Iunder= stand the power and the future of programming with macros. Butstill=2C I do= n'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=2C Do you agree that a set of problems is best solved with Ruby=2C and another= one is better solved with Common Lisp? Let's take out the performance-rela= ted part=2C and parallel programming with it. You do agree=2C and that is because as you said=2C you are in part a Lisp p= rogrammer. Now=2C think of it like this. Ruby does certain things really we= ll=2C and Common Lisp does other things really well. For the programmer sta= rting with Ruby=2C 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=2C but is ignorant= of the remaining 1/4. He would love to learn Common Lisp=2C as it would al= most double his productivity even though it only solves 1/4 of his problems= . Because it only solves 1/4 of his problem=2C the almost entirety of the wor= ld around him proclaims it to be "dead"=2C that it is useless=2C or that a = better implementation of it is needed=2C even though it is very often the c= ase that the almost entirety of the world has not actually taken the time t= o learn this language as well as possible. Now=2C think of it like this. Common Lisp is a method to solve problems. Ru= by is another method to solve problems. Together=2C they solve the almost e= ntirety of problems. What remains? Performance-oriented tasks. In an ideal = paradigm=2C these low-level and / or parallel programming types of problems= =2C don't exist anymore. So what do you have remaining? If I were that programmer=2C I would be very angry if I missed the opportun= ity to learn or use such a language. As is often the case=2C this is what i= s exactly happening in the world. Proceduralism is the future of a programm= ing language. A programming language can only be like Ruby - but on the oth= er hand=2C a programming language needs to be proceduralist in order to max= imize its potential. Make Common Lisp a complement to Ruby=2C call this Rub= y=2C and you will be there. In case that you would argue that it is the programmer's fault that he does= n't know of Common Lisp=2C I would then say that any programmer does not ne= ed Ruby=2C but can instead easily create a language like Ruby on his own.=20 Sincerely=2CMarco / Hi=2C |Yukihiro=2C|Do you agree that a set of problems is best solved with Ruby= =2C and another one is better solved with Common Lisp? Let's take out the p= erformance-related part=2C and parallel programming with it. I do agree that some problems can be solved well using Ruby=2C and otherpro= blems can be solved well with CommonLisp. IN THEORY=2C if you cancombine th= e two languages together WELL=2C you can solve broader domainof problems wi= th one language. But if you fail to combine well=2C youwould kill the futur= e of the language. So without the image of goodcombination=2C it is no use = discussing vague imaginary language. I don't think simply adding defmacro makes Ruby any better. matz. / Yukihiro=2C You are proving what I have said=2C because you use both Common Lisp and Ru= by. Do you see now what I am saying? Sincerely=2CMarco- In terms of real-world needs=2C and theoretical perfection=2C I would like = to ask the Ruby community=2C what do you think of this? Sincerely=2CMarco = --_7775656d-141d-4f65-b21f-4cb79affb7af_--