Beefy Boxes and Bandwidth Generously Provided by pair Networks Bob
There's more than one way to do things

Perl vs Lisp/Java/C/C++

by RhetTbull (Curate)
on Sep 09, 2001 at 01:47 UTC ( #111207=perlmeditation: print w/ replies, xml ) Need Help??

No, this isn't an attempt to start a flamefest about the best language! There was an interesting article on slashdot today about a somewhat old (circa 1999) article comparing Lisp to Java and C/C++. The author worked for NASA's Jet Propulsion Lab at the time and the article was in response to a study done comparing Java and C/C++. Although not statistically meaningful (there were 14 self-selected participants) the article showed that Lisp did quite well when stacked up against Java and C++ (for this particular problem statement) Anyway, it got me thinking -- hmm, how does perl stack up against all of those languages. The factors measured included development time, size of code, memory consumption, image size (meaningless for perl I suppose) and execution speed. It would be an interesting non-scientific study to see what the perlmonks can come up with for the same problem statement. The only thing I'm not sure about is would it be fair to allow (non-core) modules? It might be fun to see how perl stacked up. Any takers?


Comment on Perl vs Lisp/Java/C/C++
Re: Perl vs Lisp/Java/C/C++
by blakem (Monsignor) on Sep 09, 2001 at 02:21 UTC
    Erudil's home node has several links to language comparison studies that include Perl. It might be a good place to start, since at least one of these papers uses a methodology similiar to the one you mentioned above.

    p.s. he's got a new picture up as well. ;-)


Re: Perl vs Lisp/Java/C/C++
by jryan (Vicar) on Sep 09, 2001 at 02:22 UTC
    I would expect Perl to do quite well in comparisons to other languages. Much of the langauge is EXTREMELY optimized, so programs written in Perl would run at least 80% as fast as a comparable one written in C/C++. Besides, you can always compile Perl into C for even a faster runtime. I've also heard that a Perl interpreted program runs faster than a comparable Java bytecode program as well. In the size of code catagory, Perl would win hands down (can anyone say "one liners"? :p ). Finally, I don't see why modules wouldn't be allowed. Modules are one of Perl's main strenghts, and speed up development time tremendously. All in all, I think Perl would stack up very well.
Re: Perl vs Lisp/Java/C/C++
by archen (Pilgrim) on Sep 09, 2001 at 06:22 UTC
    Yeah, I saw that article too... but I'm not sure I really buy it. Development time is okay and all, but how about maintainability? I want to see these guys write a 500,000 line lisp program and come back to it 5 months from now, and then maybe they'll wish they'd have used Java. I'm not sure execution is quite as big of an issue as it once was. Scripted languages pay for an overhead in loading and such but for a language such as perl which usually runs off the command line, this isn't all that noticeable. Hell, a lot of compiled languages tend have so much stuff thrown in that they the computer ends up spinning it's wheels just loading unnessary junk. All in all, I'd rather shoot myself before I'd start programming in Lisp (lets just say I was scarred for life in college and leave it at that.)
      You may have had a miserable experience with Lisp, but I think that you are writing it off far too easily. First of all a 500,000 line Java program is likely to be about a 50,000 line Lisp program. The factor of 10 difference in code size for the same task will pay for itself in maintainability. OK, since the lines will do more they will be harder to follow. Say a factor of 3. But that makes the overall code base about a factor of 3 easier to understand.

      Of course just glancing at the code base what you first notice is that you have to think. As petral pointed out to me once, this is analagous to the division between readable and legible fonts. Legible fonts are ones which can be seen easily from a distance and under poor viewing conditions. A readable font is one which you can easily read large quantities of. They are not the same. Lisp is very definitely not legible. But it lends itself to readable code.

      And it gets better. Your reduced code size makes it possible to work with a smaller team. Since intrateam communication has been known for decades to be the biggest bottleneck on large projects, that is an even bigger win. Therefore you have less code, your code base is easier to understand, and you have a smaller team that can work faster. Who would you bet on?

      This isn't just theory. Read Paul Graham's article Beating The Averages about the history of ViaWeb. One of the many points that he made is that they found that any competitor who was advertising for Java programmers could just be written off. They simply weren't going to be serious competition...

      (Many of the same points apply to Perl of course...)

        I probably am writing Lisp (and don't get me started on Prologue either) off to easily. I didn't exactly mean how many lines it takes to make a program - although that's a very good point! I meant just a raw count of 500,000 lines. I don't much like Java, but supposidly one of Java's selling points is that it can scale to be extremely large and still be reasonably maintainable. Truth be told I'm not sure I buy into that myself.

        Perl and Lisp do have similarities in how cryptic a program can look. But I think the recursive nature in lisp tends to add a degree of compexity, compaired to languages that are a bit more strait foreward.

      I can't point to any scientific studies, but I find it a lot easier to read old Lisp code that I've written than old Java code that I've written. Of course, there's not all that much old Java code that I've written, so it may just be a matter of familiarity, which may also explain why you believe Lisp to be hard to read. I suspect part of it, though, is that Lisp lets me more directly translate how I think about a problem into its solution as a program, which means that the program, viewed at a later time, will more naturally correspond with what is in my mind, even at that later time.

Re: Perl vs Lisp/Java/C/C++
by Beatnik (Parson) on Sep 09, 2001 at 12:37 UTC
    This all reminds me of tchrists X versus Y Section on FMTEYEWTK

    ... Quidquid perl dictum sit, altum viditur.
Re: Perl vs Lisp/Java/C/C++
by stefp (Vicar) on Sep 09, 2001 at 20:09 UTC
    Testing the time for writing sample programs is an interesting and practical metric. But it depends as much on the programmer abilities than on the language tested. I am confident that perl expressivity permits to write good programs quite fast but I am well aware that many people don't even know about perl5 features (complex data structure handling including OO). The language quality is one thing, the general level of its programmer communauty another. I hope that perl mongers and monks are instrumental in raising awareness of good perl programming practices. Perl has not any signifiant marketting and logistic strengh behind it so grass roots movements are the only way.

    -- stefp

      To emphasize this point, I point to a section in Code Complete. This stated that a number of studies have concluded that programmer skill is the largest factor in efficiency. Using identical problems, environments, languages, etc ... the best programmers were 10 times faster with roughly 80% fewer errors, the code was much more readable, and used about 50% less lines.

      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://111207]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (6)
As of 2014-04-19 10:09 GMT
Find Nodes?
    Voting Booth?

    April first is:

    Results (480 votes), past polls