Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Lisp and Ruby 336

Posted by kdawson from the sittin'-in-a-tree dept.
sdelmont writes "The developers of Rubinius, an experimental Ruby interpreter inspired by SmallTalk, have been discussing the possibility of adding a Lisp dialect to their VM. Pat Eyler collected some ideas and opinions from the people involved and it makes for some interesting reading. For many, Ruby already is an acceptable Lisp, and the language itself started as a 'perlification' of Lisp (even Matz says so) so it is perhaps fitting and might help explain why the whole idea feels right. Now, if someone added support for VB and gave it the respect it deserves, the world would be a better place."
This discussion has been archived. No new comments can be posted.

Lisp and Ruby More

Lisp and Ruby

Comments Filter:

  • Yeah, it's cool to virtualize, introduce dialects, interpret, etc. etc. Now, for the first time ever, we have cheap mainstream computer hardware that's capable of handling all these ideas in an acceptable way. But, isn't it a huge waste of resources? What about performance?

    I mean, take Lisp and its performance. Compare it to Ruby's. Matz said himself that Ruby started as a kind of Lisp reconsideration. And you call this progress?

    The thing is that you can implement a dynamic language that isn't painfully s

    • Re: (Score:2, Funny)

      by fatphil ( 181876 )
      This reminds me of Greenspun's Tenth Rule:

      Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

      As long as it can send mail, that's the only feature that matters (and whose rule is that?).

      • Re: (Score:3, Funny)

        by marcosdumay ( 620877 )
        The question is: Is half lisp better or worse than a full one?

      • Re:Performance, anyone? (Score:4, Interesting)

        by Lucas.Langa ( 922843 ) on Sunday January 14, 2007 @09:28AM (#17602148) Homepage

        As funny as your comment is, it made me wonder... There is a very loud pro-Lisp community that tells everyone who is not using Lisp that they should since it solves most of the problems they have in the first place. OK, fair enough. But I have that strange feeling that assuming the developers to be usually very smart and very lazy, we would see them all convert to Lisp if it really was the ultimate answer [1].

        And what makes me think that Lisp was and still is widely ignored? There are a couple of points here but the most important is: we don't really see a large, consistent standard library for Lisp. So we could easily turn the Greenspun's 10th Rule backwards to say: any sufficiently complicated Common Lisp program contains an ad hoc, informally specified, bug ridden, slow implementation of half of Java's standard library.

        So, where's the catch? Why isn't Lisp popular if it's so 1337?


        [1] But we know it's 42.

        • Re: (Score:3, Interesting)

          by bhima ( 46039 )
          I'll hazard a few guesses:

          1: It is popular among people who are solving problems LISP is well suited for.
          2: There are other languages that are more suited for what most developers do.
          3: There are other languages that are more successfully marketed.

          I've earned more money in less time using COBOL than any other language but you don't hear me telling kids to pick it up.
          Nor do you see me selling COBOL for new projects.

          I don't think all of this "what language is 'leet" talk is productive or illuminating. You ha

          • Re: (Score:2)

            by pivo ( 11957 )
            I agree with the marketing point, but disagree with points 1 & 2. Lisp is a general purpose language that I find to be well suited to a large variety of problems. Lisp has an unfortunate association with AI from the 1980s, but it is not specifically an AI language, it's just a language that makes hard problems like AI possible.

            I think the real reason Lisp isn't more popular is that most developers don't want to spend the time to learn to write code that uses parenthesis instead of curly braces and semic
      • Actually, Greenspun was only partly right, the true gospel should read:

        Any sufficiently complicated C, Fortran or Lisp program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

    • Re: (Score:2)

      by suv4x4 ( 956391 )
      Yeah, it's cool to virtualize, introduce dialects, interpret, etc. etc. Now, for the first time ever, we have cheap mainstream computer hardware that's capable of handling all these ideas in an acceptable way. But, isn't it a huge waste of resources? What about performance?

      Ruby manages to be slower than PHP, and sometimes considerably, which is a true achievement (I can say, as a PHP developer, unfortunately).

      Also from friends who had played more with Ruby and with Rails, Ruby's ability to create dialects m

      • Ruby manages to be slower than PHP, and sometimes considerably, which is a true achievement (I can say, as a PHP developer, unfortunately).

        What are you trying to do with Ruby that's making it so much slower than PHP? The great computer language shoot out seems to indicate it's very close [debian.org] (i.e. PHP only performs >5x better than ruby on one task), although ruby's memory usage seems to be regularly better.

        • Re: (Score:2)

          by suv4x4 ( 956391 )
          What are you trying to do with Ruby that's making it so much slower than PHP? The great computer language shoot out seems to indicate it's very close (i.e. PHP only performs >5x better than ruby on one task), although ruby's memory usage seems to be regularly better.

          Single when should a language be >5x better to be considered "faster"? With the exception of the new meteour test (which I saw the PHP code for is poor and soon will be updated I guess), PHP is on average 2-3 times faster than Ruby.

    • Re:Performance, anyone? (Score:5, Informative)

      by Wolfbone ( 668810 ) on Sunday January 14, 2007 @09:28AM (#17602152)

      "I mean, take Lisp and its performance. Compare it to Ruby's."

      Which Lisp? One which (as most implementations of Common Lisp do these days) appropriately and reasonably gets compared to the output of a C compiler?:

      http://www.lrde.epita.fr/cgi-bin/twiki/view/Public ations/200606-IMECS [epita.fr]

      I wouldn't have thought that would be a very fair comparison to make for Ruby.

      • Ruby is even slower than Phyton.

        It's simply that a lot of though has been put into those Lisp compilers as they used to run in very small computers compared with the ones we have.

    • Re: (Score:3, Interesting)

      by TheRaven64 ( 641858 )

      I mean, take Lisp and its performance. Compare it to Ruby's. Matz said himself that Ruby started as a kind of Lisp reconsideration. And you call this progress?

      Right. Common Lisp is very fast; on an architecture that's not register-starved the Steel Bank compiler can produce code that is faster than C++ running the same algorithms, and Lisp is a lot more flexible. While I like the Lisp semantics, I find the syntax a little, uh, minimalist, and I prefer Smalltalk[1], which has a similar amount of flexibility. Smalltalk running in the Squeak VM is fast enough to run video CODECs written in Smalltalk on a relatively modern laptop, and is faster than Ruby.

      I still

      • I still don't seem what advantage Ruby has over Lisp or Smalltalk; it is no more expressive, and current implementations generate slower code.
        It has one main implementation, with those libraries. Maybe it's slow, but at least it's universal.

    • Re: (Score:3, Interesting)

      by tacocat ( 527354 )

      True Dat. Between Perl, Python and Ruby. Ruby is the slowest by far. And be careful how you write your code. Sometimes attaching method.method.method is about the worse way you can go, even though they claim it is the Ruby Way. Bah! I'll take perl. At least it has docs.

    • A decent implementation of common lisp tends to perform about as well or better than optimized compiled C. And most of the big implementations are decent in that regard.
    • Saying "take lisp" means nothing. Lisp is a family of languages. Some dialects have fast implementations and some don't. Common Lisp, as an example, have both really fast implementations (CMUCL and SBCL) and kind of slow though extremely portable ones (Clisp and a few others). You have the same duality with Scheme (another Lisp dialect). Gambit C is pretty darn fast while Guile is slower but easier to embed into another program. Don't take my word for it, check the existing benchmarks [debian.org]. Keep in mind t

  • Genuine question about perl vs ruby (Score:4, Interesting)

    by thanasakis ( 225405 ) on Sunday January 14, 2007 @08:50AM (#17601978)
    I am not trying to start a holy war thread about perl vs ruby, just looking for someone that can enlighten me regarding the following question.

    Having perl as it is, what are the reasons to take a look at ruby. Mind you, I am not saying that these reasons do not exist, I guess I was just lazy to find it out by myself and then again, nobody has yet offered any compelling reason. I have taken a good look at ruby, clean syntax and all, but really I couldn't find something really compelling.

    An interesting phenomenon is that most stuff that people perceive as a reason to go to ruby from perl, are available in perl too, but somehow they offer those stuff an novel.

    Please don't take me the wrong way, I can testify that ruby is indeed a kick ass piece of work, I am trying to find real reasons to use it along side with perl.

    So, fire away your opinions!

    • Re:Genuine question about perl vs ruby (Score:5, Insightful)

      by JanneM ( 7445 ) on Sunday January 14, 2007 @09:18AM (#17602114) Homepage
      To me, as an old Perl programmer, Ruby basically feels like what Perl 6 should have become: keeping with the idea of making things discoverable for the programmer and not having to work around syntax, but greatly cleaned up and with objects as an integrated part of the language, not so tacked-on as in Perl 5.

      Ruby still has some pretty significant drawbacks, of course; it's slow, and has little support for Unicode (not that surprising, seeing it's from Japan). The libraries aren't as mature yet either; Perl has many year's headstart there so again no surprise. All of these are improving, though.
      • Hi,

        It becomes crystal clear very soon when you look at ruby that its syntax is not even in the slightest sense as complicated as perl's. But then again, most people went to perl in the first place to be able to leverage that characteristic. So why move away from it?

        The only real reason that I can think of, it that as someone progresses as a programmer, he/she may find that his/her tastes change gradually.

      • Re: (Score:3, Interesting)

        by wootest ( 694923 )
        I agree with part of your comment. Ruby is my Perl 6 until Perl 6 comes along. I'm okay with Perl's eclectic syntax and I know some other people aren't, but for now Ruby is one of the best Perl 5 alternatives.

        The thing with Ruby this far is that it's still in its first major version by version number. There's not one bit of the Ruby design that I'd like to change dramatically, but there's a bunch of problems that arise from its current implementation. The one-pass compiling (which while surely easier to imp
      • it's slow, and has little support for Unicode (not that surprising, seeing it's from Japan).

        I stumbled on that. Why does coming from Japan make it not surprising that it's slow and has little support for Unicode?

        Ian

        • Why does coming from Japan make it not surprising that it's slow and has little support for Unicode?

          The Japanese do not like Unicode. They prefer using one of their own encodings (I believe there are two major ones). From what I can gather, the reason is not-invented-here syndrome or a strawman argument against Unicode's ideograph system.

          Of course, it could just be a vocal minority. I don't live in Japan myself, so I can't tell.

          • Re: (Score:3, Informative)

            by Anonymous Coward
            the reason is not-invented-here syndrome or a strawman argument against Unicode's ideograph system.

            Asians complain about having to share codepoints for characters (see Han Unification). A lot of people think the whining is mostly racist in nature; however, there are a few legitimate complaints in there, for instance many characters that Han Unification forced to share codepoints actually have different glyphs depending on which language it's written in, even if they all shared a similar source. Unicode's

    • Re:Genuine question about perl vs ruby (Score:4, Informative)

      by morgan_greywolf ( 835522 ) on Sunday January 14, 2007 @09:24AM (#17602132) Homepage Journal
      Having perl as it is, what are the reasons to take a look at ruby. Mind you, I am not saying that these reasons do not exist, I guess I was just lazy to find it out by myself and then again, nobody has yet offered any compelling reason. I have taken a good look at ruby, clean syntax and all, but really I couldn't find something really compelling.


      Having Perl as it is, what are the reasons to take a look at Python? Having Python as it is, what are the reasons to take a look Ruby? Having Ruby as it is, what the reasons to take a look at Perl? Having Python as it is, what are the reasons to take a look at Perl?

      Because they're different languages with different strengths and weaknesses. Just as Lisp and Ruby are different, and Python and Perl are different, so is Perl and Ruby.

      A good staring point for you would be to read this article differentiating Perl and Ruby [ruby-lang.org]. Working back from that description, if you have experience in programming in languages other than Perl, you should be able to figure out what the advantages are of Ruby over Perl and vice-versa.

      • Re: (Score:3, Insightful)

        by tacocat ( 527354 )

        Actually there is a good reason to look at Perl given Ruby. Regular Expressions. Ruby has a object and method for doing regular expressions but compared to Perl it's very combersome and is even lacking some of the properties that Perl's regex has. Since I tend to use a lot of my programming time dealing with text of some kind, regular expression are important to me.

        Ruby is a nice language. It's easy to work with. But it's got some maturing to do and I do hope they spend at least a version working on s

        • Re:Genuine question about perl vs ruby (Score:4, Interesting)

          by CoughDropAddict ( 40792 ) on Sunday January 14, 2007 @11:59AM (#17603294) Homepage
          Actually there is a good reason to look at Perl given Ruby. Regular Expressions. Ruby has a object and method for doing regular expressions but compared to Perl it's very combersome and is even lacking some of the properties that Perl's regex has.

          Cumbersome? Which is this, Perl or Ruby?

          "Hello, World!" =~ /Hello, (\w+)!/;
          print $1;
          Trick question -- it's both. What exactly about Ruby's way is cumbersome?

    • Re:Genuine question about perl vs ruby (Score:5, Informative)

      by Jonathan ( 5011 ) on Sunday January 14, 2007 @09:30AM (#17602172) Homepage
      1) Object Orientation is consistent throughout the language. Perl provides ways to make objects, but none of the built in functions or datatypes are objects, making your code a schizophrenic mess of objects and non-objects.

      2) Consistency -- In Perl it is needlessly difficult to do ever simple tasks like making arrays of arrays or arrays of hashes -- you have use a weird syntax to get at references. I never could remember it and always had to look it up whenever I needed an array of arrays in Perl. In Ruby, everything is a reference to an object so you don't have to worry about it -- a[0] = [1, 2] does exactly what you want -- puts an array [1, 2] in the first element of array a.

      I used to be a big Perl fanboy -- I did most of my programming in Perl from 1992-1999. But when I discovered Ruby I went for it and never looked back. What's cool about it is that its syntax is so clean that it is basically a version of the pseudocode I have in my head. In the Ruby community there's a phrase for it -- "the principle of least surprise" -- things just work.

      Obviously, if you really like Perl, nothing is going to make you change. But if you are just keeping with Perl because of inertia, then you ought to look around at other scripting languages. Ruby is my favorite, but most modern scripting languages are cleaner than Perl.

      • Re: (Score:2)

        by Goaway ( 82658 )
        In the Ruby community there's a phrase for it -- "the principle of least surprise" -- things just work.

        And 0 being true is the least surprising behaviour, now?

        • Re: (Score:2)

          by Jonathan ( 5011 )
          And 0 being true is the least surprising behaviour, now?

          Because 0 is defined. It exists. In most programming languages either 0 is true or the notion of considering a number to be true or false is not allowed. It's basically C that decided to declare 0 to be false instead of defining a boolean datatype.

          • Re: (Score:2)

            by Goaway ( 82658 )
            Which "most languages" are those? For reference, here is a list of popular languages:

            * C
            * C++
            * Java
            * Perl
            * Python
            * PHP
            * Javascript
            * Visual Basic
            * C#
        • And 0 being true is the least surprising behaviour, now?

          Yeah, I hate that! It is supposed to be "0 but true" that is true.

    • Re: (Score:2)

      by tacocat ( 527354 )

      Perl is a great language with some amazing capabilities. They have managed to do a great job refining the real world experiences into a practical language that doesn't do very many kludges with the glaring exception of Objects.

      Ruby is a new language with a pristine implementation of what objects are supposed to be without all the cruft of Java.

      When Java started, it was also pristine and cruftless. Over time I suspect Ruby may do that same thing, bloat. It's going to take some careful management of the

    • I used to do PHP. Black days really. In retrospect I can no longer understand how I could stand it at all. I wasted so much time on idiosyncrasies of the interpreter it hurts to think about it. Ever wondered why your variables suddenly, unexpectedly changed only to find out some nutter activated register_globals on this particular installation. Btw. try this: if ("0" == false) print "This sucks!";

      Then I really discovered Perl5. Played with it before, but never really used it much. Anonymous subs! Closures!
    • I'm actually more interested in what will happen one Perl6 is finally released and brings a much needed syntax reform and performance boost to Perl. Perl will finally get over being just a shell language of sorts to become a true programming language as well as being a shell language of sorts for those who want it to.

      I enjoy very much Ruby's syntatic clarity + its many Perlisms. But Perl6 is likely to surpass or match Ruby's features and charm, so it'll be an interesting fight.

      Right now, i'd say Ruby's ma
      • Very good comment, I would definitely mod it up if I could.

        Indeed named function parameters are missing in Perl5.

        There is ofcourse Damian Conway's recommendation from "Perl Best Practices":

        Use a hash of named arguments for any subroutine that has more than three parameters.
        OTOH, perl6 has "real" named parameters.

        On the question of syntax, I don't feel that perl6 is too much clean compared to ruby. Just my impression, could be wrong.

  • wow, I have no idea what that just meant! (Score:5, Funny)

    by tommyhj ( 944468 ) on Sunday January 14, 2007 @09:03AM (#17602040)
    This is just one of those stories that us non-linux, non-programmers have absolutely no idea of what means! Which insidentally makes it rather funny to read :-) I mean, adding Lisp to Ruby's SmallTalk?

    • Re:wow, I have no idea what that just meant! (Score:4, Informative)

      by kruhft ( 323362 ) on Sunday January 14, 2007 @11:05AM (#17602890) Homepage Journal
      Lisp is the oldest, still in use, high level programming that exists today. It's the core of emacs, and was standardized into Common Lisp in the early 90's. It basically has no syntax other than words and nested parenthesis (() :-), has an extrememly powerful macro system, and a loyal following of elders that hang out in comp.lang.lisp on usenet. As well, the great Emacs is basically a lisp interpreter (or Operating System) that happens to have a text editor above it.

      Smalltalk is another high level language where everything is an object. It has syntax, supports many interesting high level concepts like persistance, and has some nice development environments and pseudo OS projects, one of which is called Squeak.

      Ruby is a newer high level language from Japan, that was designed to combine the high level concepts of Lisp, but added some syntax to reduce code verbosity and increase expressiveness. The Lispnicks say this is unnecessary complexity that reduces the power of the language; people that were raised on languages with syntax find the expressiveness more familiar, easy to use and powerful.

      I'm still undecided.
      • ``Lisp is the oldest, still in use, high level programming that exists today.''

        That's debatable. FORTRAN was there first, but I guess you could argue that it is not a high level programming language. On the other hand, what is Lisp? Common Lisp is from 1984, R5RS (Scheme) is from 1998. That's not exactly old. On the other hand, many features that are in Common Lisp now were already in MacLisp in the 1960s or 1970s, and, of course, the key ideas of Lisp are from the 1950s. However, I have difficulty calling,

  • why not go all the way? (Score:3, Informative)

    by oohshiny ( 998054 ) on Sunday January 14, 2007 @09:24AM (#17602130)
    If you're gonna have a "Ruby inspired by Smalltalk", why not be done with it and give it Smalltalk syntax as well? Smalltalk syntax is great: very readable, very simple. And with Objective C, it has enjoyed some resurgence.

    • Because you'll end up at Lisp. (Score:5, Insightful)

      by Anonymous Coward on Sunday January 14, 2007 @09:38AM (#17602226)
      What most people don't realize is that Lisp is the inherent representation of virtually all programming languages. This is even true for languages like C, Java, Smalltalk, and Ruby. We can plainly see this by the very fact that basically every compiler or interpreter for those languages parses the language into an abstract syntax tree. And that's exactly what Lisp is: a textual representation of an AST. It is so powerful because it directly allows the programmer to access and modify what amounts to the AST of his or her program. This is something that a language like C isolates to the compiler, or at best the preprocessor.

      What fewer people realize is that Smalltalk is Lisp with a slightly different syntax. The concepts are basically identical, however. So suppose the Ruby developers do all the hard work needed to switch their language over to a Smalltalk-like syntax. Do you know what will happen next? They'll ask themselves what could be improved next. And the first thing that'll happen is a consideration of making the syntax and semantics of the language more Lisp-like. And that's just because Lisp represents the most inherent aspects of what a programming language is.

      • Re: (Score:3, Interesting)

        by TheRaven64 ( 641858 )

        It is so powerful because it directly allows the programmer to access and modify what amounts to the AST of his or her program.

        If you want a really good demonstration of this, take a look at Erlang. Erlang has a feature as powerful as Lisp macros called Parse Transforms. The compiler spits out the parse tree as a set of nested tuples and passes this to a user-suppled function. This then returns a transformed version of the parse tree. This has exactly the same power and expressiveness as Lisp Macros. The difference is that every Lisp programmer uses macros, because they are as easy to use as function, while almost no Erlang p

      • What most people don't realize is that Lisp is the inherent representation of virtually all programming languages. This is even true for languages like C, Java, Smalltalk, and Ruby. We can plainly see this by the very fact that basically every compiler or interpreter for those languages parses the language into an abstract syntax tree. And that's exactly what Lisp is: a textual representation of an AST.

        You say that like it's a good thing. Look, assembly language is the inherent representation of all code. A

        • Re:Because you'll end up at Lisp. (Score:4, Insightful)

          by calambrac ( 722059 ) on Sunday January 14, 2007 @04:02PM (#17605710)
          I would have to disagree with your statement that Lisp doesn't let you group things. Not only does it let you group things, it lets you write entire languages built specifically for the things you want to group. Macros in Lisp are effectively little compilers that are very easy to write, that let you make whatever language is most useful for working with the concepts you want to "collect, isolate, and distinguish". Combine this with CLOS and generic and functional programming techniques, and you have one of the best languages around for dealing with concepts at a very high level.

          Lisp has its weaknesses, but expressiveness and abstraction are not among them.
  • I love programming in Ruby and use it a lot for both small utilities and some Rails web apps.

    The problem is that Ruby has very poor runtime performance. As a result, I often use Common Lisp (Franz for commercial development, but also LispWorks, and SBCL). What kind of runtime performance will this proposed Lisp (it is all just talk for now) have?

    Common Lisp is a great language. Several years ago, with some great input from the Lisp community, I wrote a free 50 page tutorial "Loving Lisp, or the Savvy Progra
    • BTW, I started work on a second edition of "Loving Lisp, or the Savvy Programmer's Secret Weapon" two weeks ago - if you download the PDF for the current edition and like it, then check back in a couple of months.

    • Re:I use Common Lisp because of its 'white hot' sp (Score:5, Insightful)

      by Not_Wiggins ( 686627 ) on Sunday January 14, 2007 @11:10AM (#17602916) Journal
      The problem is that Ruby has very poor runtime performance.

      Not so much in response to the post, but to add to it...
      I'm not that old, but I remember the same being said for:
      • C++ compared to C
      • Interpreted compared to Compiled
      • Java compared to C++
      • Servlets compared to CGI
      The list could continue. Just wanted to highlight that "performance" is a short-lived reason to avoid a language. 8)

      • Re: (Score:3, Interesting)

        by The_Wilschon ( 782534 )
        Interpreted is still slower than Compiled. Always will be. However, the reason that that problem has *somewhat* gone away is that machines are fast enough now that for *most* situations (UIs being one example), that is not a problem. However, for some problem domains (eg scientific programming), speed will never cease to be an issue. The faster the machines we have, the more we will throw at them. Lattice calculations work better with a smaller lattice spacing, and a faster machine allows a smaller spa
  • Maybe what is meant is that Ruby's usefulness in many situations is acceptable when compared to LISP. I'd even disagree with that because Ruby lacks what good LISP implementations have: a way to declare types and thus make it easy for the compiler to optimize crucial code and avoid the slowness of dynamic typing. Also its approach to objects is entirely totally different from Ruby's. LISP's option to declare variables and hint the compiler, together with its extensive support for macros is second best when

    • Re: (Score:2)

      by MenTaLguY ( 5483 )
      Actually, what it means is that we're toying with the idea of implementing a Lisp dialect using the Rubinius runtime. Ruby obviously isn't Lisp, even though the first iterations of it really were just a Scheme dialect (before SmallTalk-isms took over).

      As far as performance issues go, please don't conflate the interpreter with the language. The stable matz interpreter is slow, but YARV (its direct bytecode-based successor), Rubinius, and JRuby look like they'll have considerable performance advantages when

      • Re: (Score:2)

        by jopet ( 538074 )
        OK -- I was referring to the "Ruby already is an acceptable LISP" article here, not the idea of running LISP on top of an Ruby interpreter. I have not the slightest idea how the interpreter is designed, so I cannot say anything about this.

        You are right about not confusing the language with the interpreter, but what I was trying to say is that language can help to make performance optimizations easier or possible at all: the LISP declare mechanism makes this quite explicit and gives the details in the hands

      • Re: (Score:2)

        by MenTaLguY ( 5483 )
        Ow, and there I go CamelCasing "Smalltalk". Bad habit these days.
  • As a programmer and programming language enthusiast, and being intimately familiar (hmm) with both Ruby and Common Lisp, there are a couple of things I miss in either language.

    In Ruby, I miss macros and the consistent, simple syntax that makes Lisp code so easy to parse and generate And, of course, I miss the Lisp reader. I've created a Lisp reader and writer for Ruby, but they produce (or print) Ruby _data_, not code.

    In Common Lisp, I miss all the practical things that come with Ruby; mostly networking and
  • We might see an upsurge of interest in functional programming soon because it lends itself to parallelization. Clock speeds are no longer going to improve exponentially, and pure FP languages like Haskell and Erlang are naturally positioned to take advantage of multicore machines. For someone like me, who's interested in grokking FP better for that reason, neither Lisp nor Ruby seem like a natural choice, since both have side-effects. To me, Ruby is just another scripting language: a Perl with a cleaner syn
  • I think Rubinius is a great project in its own right. Ruby is a very nice language to work with, but the current "official" implementation is terribly slow. Implementing it on top of a Smalltalk VM should give quite a speed boost, which should help make Ruby more useful for more applications. Of course, speed improvements and lots of other Good Things are also planned for Ruby 2.0 (AKA Rite).
  • Great! The three things I miss most from Ruby are (1) the ability to easily read and write programs (which Lisp provides, both through the built-in reader and printer and by virtue of the syntax being really simple and consistent), (2) macros (which Lisp provides, but can also be easily implemented once you have (1)), and speed (which will probably be severely improved by Rubinius).

    Many Lisp implementations lack practical things like networking and string manipulation functions or integration with Unix. A L

Slashdot Top Deals

"Tell the truth and run." -- Yugoslav proverb

Close