|
Re: Perl vs Lisp/Java/C/C++
by blakem (Monsignor) on Sep 09, 2001 at 02:21 UTC
|
| [reply] |
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. | [reply] |
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.) | [reply] |
|
|
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...)
| [reply] |
|
|
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.
| [reply] |
|
|
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.
| [reply] |
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
Greetz
Beatnik
... Quidquid perl dictum sit, altum viditur. | [reply] |
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 | [reply] |
|
|
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.
| [reply] |