python vs perl lines of code

[Edward Elliott]

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 pissing 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

[John Bokma]

Edward Elliott <no****@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 pissing 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

[Edward Elliott]

John Bokma wrote:

Edward Elliott <no****@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 pissing 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

[Charles DeRykus]

Edward Elliott wrote:

John Bokma wrote:

Edward Elliott <no****@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 pissing contest.

Without seeing the actual code this is quite meaningless.

Evaluating my experiences yes, relating your own no.

But why would anecdotal accounts be of interest... unless there's
an agenda :) Differing skill levels and problem scenarios would
tangle the results so much no one could ever unravel the skein or
pry out any meaningful conclusions. I'm not sure what's to be gained
....even if you're just evaluating your own experiences. And, as you
suspect, it almost certainly would devolve into a pissing contest.

This subject thread may be of great interest but I think an language
advocacy mailing list would be a better forum.

--
Charles DeRykus

[Ala Qumsieh]

Edward Elliott wrote:

John Bokma wrote:

Without seeing the actual code this is quite meaningless.

Evaluating my experiences yes, relating your own no.

Well, quality of code is directly related to its author. Without knowing
the author personally, or at least seeing the code, your anecdote
doesn't really mean anything.

A colleague of mine, who is efficient at programming, and pretty decent
at Perl, routinely does something like:

if ($var =~ /something and something else/) {
$var =~ /(something) and (something else)/;
my $match1 = $1;
my $match2 = $2;
...
}

Needless to say, this adds a lot of unnecessary redundancy, which will
go towards increasing your character count. Being an avid Perl Golfer
(although not one of the best) I can almost guarantee that any python
code can be written more succinctly in Perl, although readability will
suffer. Plus, the extensibility argument is very subjective, and is
closely related to personal coding style.

Btw, do you include space chars that go toward indentating Python code
in your count? If not, you should since they are required. Not so for Perl.

--Ala

[Edward Elliott]

Charles DeRykus wrote:

This subject thread may be of great interest but I think an language
advocacy mailing list would be a better forum.

Fair enough, but advocacy isn't at all what I'm after. Anecdotes are fine,
after all what is data but a collection of anecdotes? :) Seriously,
anecdotes are valuable: they give you another perspective, reflect common
wisdom, and can tell you what/where/how to look for hard data. Of course
if anyone already has hard data that would be welcome too, but it's hard to
even pin down what 'hard data' means in this situation.

I'll grant you though, asking for non-value-judgement-laden anecdotes on
newsgroups may be asking too much.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net

[Edward Elliott]

Ala Qumsieh wrote:

Btw, do you include space chars that go toward indentating Python code
in your count? If not, you should since they are required. Not so for
Perl.

All chars are counted on lines which are counted. The perl and python
versions use the same amount and type of indentation, which in this case is
tab characters. In any case, I wouldn't strip the whitespace out of the
perl code just because it's unnecessary for the interpreter. How people
deal with code is far more interesting than how machines do, and for us
whitespace is necessary (not strictly, but a really really good idea).

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net

[Mirco Wahab]

Hi Edward

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

Maybe somebody would change his style
and had a lot of such statements before:

if ( something )
{
do_something()
}

which can be expressed in one
line:

do_something() if ( /something/ );

This has a 1:4 line count then.

Or, somebody used identifier like:

sub GetTheseSamples HereOut {
...
...
}

and later:
sub SampleExtract {
...
...
}

and saved ~40% characters.
You got my point? ;-)
Regards

M. Wahab

[John Bokma]

Edward Elliott <no****@127.0.0 .1> wrote:

John Bokma wrote:

Edward Elliott <no****@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 pissing contest.

Without seeing the actual code this is quite meaningless.

Evaluating my experiences yes, relating your own no.

What would the point be? Most important to me would be: am I happy with
the result? And that rarely has to do with the number of lines of actual
code or the programming language. A language is just a tool.

--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/

[Edward Elliott]

Mirco Wahab wrote:

Maybe somebody would change his style
and had a lot of such statements before:
which can be expressed in one
line:
This has a 1:4 line count then.

Or, somebody used identifier like:
and later:
and saved ~40% characters.
You got my point? ;-)

Hey I completely agree that line counts leave out a lot of information.
Measures of the code like complexity, readability, work performed, etc
hinge on many more important factors. I don't pretend that lines of code
represents any indication of inherent superiority or fitness.

But line counts do convey some information. Even if it's only how many
lines a particular programmer used to convey his ideas. Real-world and
average-case data are more compelling than theoretical limits on how
compact code can be. Besides compactness isn't the point, communication
is. Maybe line count is a good rough first-cut approximation of that.
Maybe it's not. Probably it's both, depending on the case. Talking about
the numbers can only shed light on how to interpret them, which as always
is 'very carefully'.

I'm not saying lines of code necessarily reflects anything else. All I'm
saying is, I noticed some properties of my code. I'd like to know what
objective properties others have noticed about their code. This is not
meant to be a comparison of languages or programming technique, just a
sampling of collective wisdom. That always has value, even when it's
wrong.

By the looks of it, this group is uninterested in the discussion. Which is
fine.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net