Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > python vs perl lines of code

Reply
Thread Tools

python vs perl lines of code

 
 
Edward Elliott
Guest
Posts: n/a
 
      05-17-2006
This is just anecdotal, but I still find it interesting. Take it for what
it's worth. I'm interested in hearing others' perspectives, just please
don't turn this into a ****ing contest.

I'm in the process of converting some old perl programs to python. These
programs use some network code and do a lot of list/dict data processing.
The old ones work fine but are a pain to extend. After two conversions,
the python versions are noticeably shorter.

The first program does some http retrieval, sort of a poor-man's wget with
some extra features. In fact it could be written as a bash script with
wget, but the extra processing would make it very messy. Here are the
numbers on the two versions:

Raw -Blanks -Comments
lines chars lines chars lines chars
mirror.py 167 4632 132 4597 118 4009
mirror.pl 309 5836 211 5647 184 4790

I've listed line and character counts for three forms. Raw is the source
file as-is. -Blanks is the source with blank lines removed, including
lines with just a brace. -Comments removes both blanks and comment lines.
I think -Blanks is the better measure because comments are a function of
code complexity, but either works.

By the numbers, the python code appears roughly 60% as long by line and 80%
as long by characters. The chars percentage being (higher relative to line
count) doesn't surprise me since things like list comprehensions and
explicit module calling produce lengthy but readable lines.

I should point out this wasn't a straight line-for-line conversion, but the
basic code structure is extremely similar. I did make a number of
improvements in the Python version with stricter arg checks and better
error handling, plus added a couple minor new features.

The second program is an smtp outbound filtering proxy. Same categories as
before:

Raw -Blanks -Comments
lines chars lines chars lines chars
smtp-proxy.py 261 7788 222 7749 205 6964
smtp-proxy.pl 966 24110 660 23469 452 14869

The numbers here look much more impressive but it's not a fair comparison.
I wasn't happy with any of the cpan libraries for smtp sending at the time
so I rolled my own. That accounts for 150 raw lines of difference. Another
70 raw lines are logging functions that the python version does with the
standard library. The new version performs the same algorithms and data
manipulations as the original. I did do some major refactoring along the
way, but it wasn't the sort that greatly reduces line count by eliminating
redundancy; there is very little redundancy in either version. In any
case, these factors alone don't account for the entire difference, even if
you take 220 raw lines directly off the latter columns.

The two versions were written about 5 years apart, all by me. At the time
of each, I had about 3 years experience in the given language and would
classify my skill level in it as midway between intermediate and advanced.
IOW I'm very comfortable with the language and library reference docs (minus
a few odd corners), but generally draw the line at mucking with interpreter
internals like symbol tables.

I'd like to here from others what their experience converting between perl
and python is (either direction). I don't have the sense that either
language is particularly better suited for my problem domain than the
other, as they both handle network io and list/dict processing very well.
What are the differences like in other domains? Do you attribute those
differences to the language, the library, the programmer, or other
factors? What are the consistent differences across space and time, if
any? I'm interested in properties of the code itself, not performance.

And just what is the question to the ultimate answer to life, the universe,
and everything anyway?

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
 
Reply With Quote
 
 
 
 
John Bokma
Guest
Posts: n/a
 
      05-17-2006
Edward Elliott <nobody@127.0.0.1> wrote:

> This is just anecdotal, but I still find it interesting. Take it for
> what it's worth. I'm interested in hearing others' perspectives, just
> please don't turn this into a ****ing contest.


Without seeing the actual code this is quite meaningless.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
 
Reply With Quote
 
 
 
 
Edward Elliott
Guest
Posts: n/a
 
      05-17-2006
John Bokma wrote:

> Edward Elliott <nobody@127.0.0.1> wrote:
>
>> This is just anecdotal, but I still find it interesting. Take it for
>> what it's worth. I'm interested in hearing others' perspectives, just
>> please don't turn this into a ****ing contest.

>
> Without seeing the actual code this is quite meaningless.


Evaluating my experiences yes, relating your own no.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
 
Reply With Quote
 
brian d foy
Guest
Posts: n/a
 
      05-17-2006
In article <IRuag.28298$(E-Mail Removed) >, Edward
Elliott <nobody@127.0.0.1> wrote:

> This is just anecdotal, but I still find it interesting. Take it for what
> it's worth. I'm interested in hearing others' perspectives, just please
> don't turn this into a ****ing contest.
>
> I'm in the process of converting some old perl programs to python. These
> programs use some network code and do a lot of list/dict data processing.
> The old ones work fine but are a pain to extend. After two conversions,
> the python versions are noticeably shorter.


You've got some hidden assumptions in there somehere, even if you
aren't admitting them to yourself.

You have to note that rewriting a program, even in the same language,
tends to make it shorter, too. These things are measures of programmer
skill, not the usefulness or merit of a particular language.

Shorter doesn't really mean anything though, and line count means even
less. The number of statements or the statement density might be
slightly more meaningful. Furthermore, you can't judge a script by just
the lines you see. Count the lines of all the libraries and support
files that come into play. Even then, that's next to meaningless unless
the two things do exactly the same thing and have exactly the same
features and capabilities.

I can write a one line (or very short) program (in any language) that
does the same thing your scripts do just by hiding the good stuff in a
library. One of my friends likes to talk about his program that
implements Tetris in one statement (because he hardwired everything
into a chip). That doesn't lead us to any greater understanding of
anything though.

*** Posted via a free Usenet account from http://www.teranews.com ***
 
Reply With Quote
 
achates
Guest
Posts: n/a
 
      05-17-2006
It probably says something about your coding style, particularly in
perl. I've found (anecdotally of course) that while perl is potentially
the more economical language, writing *legible* perl takes a lot more
space.

 
Reply With Quote
 
Adam Jones
Guest
Posts: n/a
 
      05-17-2006
Without any more information I would say the biggest contributor to
this dissimilarity is your experience. Having spent an additional five
years writing code you probably are better now at programming than you
were then. I am fairly confident that if you were to take another crack
at these same programs in perl you would see similar results.

One of the bigger differences might have been language changes over
time. If you had written this in python five years ago (assuming the
python rewrites are relatively current, otherwise this list gets
bigger) you would not have generators, iterators, the logging package,
built in sets, decorators, and a host of other changes. Some of these
features you may not have used, but for every one you did python would
have had more weight.

Other than that it all boils down to how the algorithm is implemented.
Between those three factors you can probably account for most of the
differences here. The real important question is: what has perl done in
the last five years to make writing these scripts easier?

 
Reply With Quote
 
Edward Elliott
Guest
Posts: n/a
 
      05-17-2006
brian d foy wrote:

> You have to note that rewriting a program, even in the same language,
> tends to make it shorter, too. These things are measures of programmer
> skill, not the usefulness or merit of a particular language.


I completely agree. But you have to start somewhere.

> Shorter doesn't really mean anything though, and line count means even
> less. The number of statements or the statement density might be
> slightly more meaningful. Furthermore, you can't judge a script by just
> the lines you see. Count the lines of all the libraries and support
> files that come into play. Even then, that's next to meaningless unless
> the two things do exactly the same thing and have exactly the same
> features and capabilities.


For an objective measure of which language/environment is more optimal for a
given task, your statement is completely accurate. OTOH for a
quick-and-dirty real-world comparison of line counts, and possibly a rough
approximation of complexity, the libraries don't matter if they offer
more-or-less comparable functionality. Especially if those libraries are
the standard ones most people rely on.

I'm not attaching any special significance to line counts. They're just a
data point that's easy to quantify. What if anything do they mean? How
does one measure statement density? What's the divisor in the density
ratio - lines, characters, units of work, etc? These are all interesting
questions with no easy answers.

> I can write a one line (or very short) program (in any language) that
> does the same thing your scripts do just by hiding the good stuff in a
> library. One of my friends likes to talk about his program that
> implements Tetris in one statement (because he hardwired everything
> into a chip). That doesn't lead us to any greater understanding of
> anything though.


Of course. Extreme cases are just that.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
 
Reply With Quote
 
Edward Elliott
Guest
Posts: n/a
 
      05-17-2006
achates wrote:

> It probably says something about your coding style, particularly in
> perl. I've found (anecdotally of course) that while perl is potentially
> the more economical language, writing *legible* perl takes a lot more
> space.


I'm sure it does. My perl (from 5 years ago) may be considered verbose (or
not, I don't know). I avoid shortcuts like $_, use strict mode, etc. Then
again I frequently use short forms like "statement if/unless (blah);" when
appropriate. So there's a big personal component in there.

But again, the interesting thing to me isn't what could one do, it's what
are people actually doing in the real world?

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
 
Reply With Quote
 
Edward Elliott
Guest
Posts: n/a
 
      05-17-2006
Adam Jones wrote:

> Without any more information I would say the biggest contributor to
> this dissimilarity is your experience. Having spent an additional five
> years writing code you probably are better now at programming than you
> were then. I am fairly confident that if you were to take another crack
> at these same programs in perl you would see similar results.


I am in complete agreement with that statement.

> One of the bigger differences might have been language changes over
> time. If you had written this in python five years ago (assuming the
> python rewrites are relatively current, otherwise this list gets
> bigger) you would not have generators, iterators, the logging package,
> built in sets, decorators, and a host of other changes. Some of these
> features you may not have used, but for every one you did python would
> have had more weight.


Absolutely.

> Other than that it all boils down to how the algorithm is implemented.
> Between those three factors you can probably account for most of the
> differences here.


s/probably/maybe. The factors you list are certainly big contributors, but
are they most of it? I don't know, there are good arguments both ways. If
you removed those factors, would the resulting python be shorter, as long
as, or longer than the corresponding perl? Would that mean anything about
code complexity, readability, maintainability, etc? I'm not comfortable
drawing any conclusions, but asking the questions is good.

> The real important question is: what has perl done in
> the last five years to make writing these scripts easier?


That's another very good question. One I can't answer.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
 
Reply With Quote
 
Larry Bates
Guest
Posts: n/a
 
      05-20-2006
Edward Elliott wrote:
> This is just anecdotal, but I still find it interesting. Take it for what
> it's worth. I'm interested in hearing others' perspectives, just please
> don't turn this into a ****ing contest.
>
> I'm in the process of converting some old perl programs to python. These
> programs use some network code and do a lot of list/dict data processing.
> The old ones work fine but are a pain to extend. After two conversions,
> the python versions are noticeably shorter.
>
> The first program does some http retrieval, sort of a poor-man's wget with
> some extra features. In fact it could be written as a bash script with
> wget, but the extra processing would make it very messy. Here are the
> numbers on the two versions:
>
> Raw -Blanks -Comments
> lines chars lines chars lines chars
> mirror.py 167 4632 132 4597 118 4009
> mirror.pl 309 5836 211 5647 184 4790
>
> I've listed line and character counts for three forms. Raw is the source
> file as-is. -Blanks is the source with blank lines removed, including
> lines with just a brace. -Comments removes both blanks and comment lines.
> I think -Blanks is the better measure because comments are a function of
> code complexity, but either works.
>
> By the numbers, the python code appears roughly 60% as long by line and 80%
> as long by characters. The chars percentage being (higher relative to line
> count) doesn't surprise me since things like list comprehensions and
> explicit module calling produce lengthy but readable lines.
>
> I should point out this wasn't a straight line-for-line conversion, but the
> basic code structure is extremely similar. I did make a number of
> improvements in the Python version with stricter arg checks and better
> error handling, plus added a couple minor new features.
>
> The second program is an smtp outbound filtering proxy. Same categories as
> before:
>
> Raw -Blanks -Comments
> lines chars lines chars lines chars
> smtp-proxy.py 261 7788 222 7749 205 6964
> smtp-proxy.pl 966 24110 660 23469 452 14869
>
> The numbers here look much more impressive but it's not a fair comparison.
> I wasn't happy with any of the cpan libraries for smtp sending at the time
> so I rolled my own. That accounts for 150 raw lines of difference. Another
> 70 raw lines are logging functions that the python version does with the
> standard library. The new version performs the same algorithms and data
> manipulations as the original. I did do some major refactoring along the
> way, but it wasn't the sort that greatly reduces line count by eliminating
> redundancy; there is very little redundancy in either version. In any
> case, these factors alone don't account for the entire difference, even if
> you take 220 raw lines directly off the latter columns.
>
> The two versions were written about 5 years apart, all by me. At the time
> of each, I had about 3 years experience in the given language and would
> classify my skill level in it as midway between intermediate and advanced.
> IOW I'm very comfortable with the language and library reference docs (minus
> a few odd corners), but generally draw the line at mucking with interpreter
> internals like symbol tables.
>
> I'd like to here from others what their experience converting between perl
> and python is (either direction). I don't have the sense that either
> language is particularly better suited for my problem domain than the
> other, as they both handle network io and list/dict processing very well.
> What are the differences like in other domains? Do you attribute those
> differences to the language, the library, the programmer, or other
> factors? What are the consistent differences across space and time, if
> any? I'm interested in properties of the code itself, not performance.
>
> And just what is the question to the ultimate answer to life, the universe,
> and everything anyway?
>

Sorry, I don't buy this. I can write REALLY short programs that don't handle
exceptions, don't provide for logging for debugging purposes, don't allow
for future growth, etc. I find that 60% of my code has nothing to do with
the actual algorithm or function I'm trying to accomplish. It has more to
do with handling user's bad input, exceptions, recovering from hardware or
communications failures, etc. Inexperienced programmers can write some
pretty short programs that get the job done, but can't handle the real world.

Also, many years ago I wrote a number of applications in APL. We often
referred to programs written in APL as "write only code" because going back
to read what you had written after-the-fact was very hard. You could write
in one line of APL what takes 1000's of lines of C or even Python and it was
pretty efficient also (for applications that needed to manipulate vectors or
matrices).

I understand what you are trying to say, but I can't support your conclusions
as presented.

-Larry Bates
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
perl -pe for blocks of lines instead of single lines Markus Dehmann Perl Misc 1 09-26-2006 07:28 PM
python vs perl lines of code Edward Elliott Python 82 05-21-2006 11:13 PM
Asp.Net Calender, how to display 5 lines if there are only 5 lines in one month? Jack ASP .Net 9 10-12-2005 03:44 AM
Modems, Analog Lines and ... Electrical Lines? Sens Fan Happy In Ohio Computer Support 5 09-02-2004 04:15 AM
Re: how to read 10 lines from a 200 lines file and write to a new file?? Joe Wright C Programming 0 07-27-2003 08:50 PM



Advertisments