python vs perl lines of code

[Edward Elliott]

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.

 

[John Bokma]

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

In that case: there is probably more Perl out there that makes us cry
compared to Python :-D.

 

[Edward Elliott]

Edward also asked if others had similar experiences. If others did, the
assemblage of their opinions would in fact consttitute data. I have no
idea why people are giving him such grief over this request.

Thank you, Michael. It was starting to feel like I'd asked about the best
way to club baby seals in here.

 

[Edward Elliott]

Those samples can be independently verified by any skilled observer at
another time. This is what distinguishes them from anecdotes, and
breaks your analogy.

Anyone who has my source files can run the same tests. The measures are
repeatable and reliable, even if at the moment few can perform them on my
code. They don't just let anybody walk into the Louvre and cut off a piece
of the Mona Lisa for spectral analysis.

Before the days of cheap video, lots of scientific data was gathered by lone
observers recording unrepeatable events. You build statistics by
accumulating a vast number of such observations over time.

In any case, I never asked for scientific-quality data in the first place.

 

[Ben Finney]

Anyone who has my source files can run the same tests.

Which we don't. Currently all we have is an anecdote. I'm making no
comment on the veracity or interest of the anecdote, but currently
that's all we have.

I responded to a post that seemed to claim that anecdotes about events
can be treated as data about events. They can't; that's what I'm
arguing.

 

[Edward Elliott]

I responded to a post that seemed to claim that anecdotes about events
can be treated as data about events. They can't; that's what I'm
arguing.

And conveniently ignoring the key part of my post. Here it is again for
those who missed it:

"Before the days of cheap video, lots of scientific data was gathered by
lone observers recording unrepeatable events.  You build statistics by
accumulating a vast number of such observations over time."

Sounds like anecdotes can become data to me. It's a stupid argument anyway.
Anecdotes *are* data. Some data is repeatable, some is not. All data has
an associated confidence level. Single anecdotes are relatively low, as
you gather more the confidence level rises (for the aggregate). Eventually
you reach the maximal level by definition: the sum of all anecdotes is the
universe of available data.

No one's saying anecdotes are 100% reliable. But they aren't 0% reliable
either.

 

[Ben Finney]

And conveniently ignoring the key part of my post. Here it is again for
those who missed it:

"Before the days of cheap video, lots of scientific data was gathered by
lone observers recording unrepeatable events.  You build statistics by
accumulating a vast number of such observations over time."

Sounds like anecdotes can become data to me.

Note the transformation though. You're not collecting data *about the
unrepeatable events*, you're collecting data *about the reports*.

Thus my assertion: anecdotes about events cannot be treated as data
about those events. At best, they are data about *reports* of events.

It's a stupid argument anyway. Anecdotes *are* data.

They're a different kind of data though. Anecdotes about UFO sightings
says *nothing* for or against the existence of UFOs, only about the
incidence of people reporting sightings of UFOs.

Treating an anecdote about X as though it were a data point about X is
a fallacy. Treating an aggregate of anecdotes about X as though it
were data about X is a very common practice, but is equally a fallacy.

 

[Michael Tobis]

Sorry, data about reports about X *is* data about X unless you believe
the reports are uninfluenced by X. Like any proxy measure, it
introduces noise and uncertainty, but it is still data.

I can't imagine a motivation for Edward to make this up, so I accept
his anecdotes as data.

While it is possible to imagine developing a lab experiment to compare
the terseness of Python and Perl, it is unlikely that funding is or
should be available for the effort. This doesn't make it an
uninteresting question. Is the widely held belief that real-world Perl
is terser than real-world Python true? So far we have only the two
reports from Edward. Still anyone programming in the dynamic languages
world would acknowledge that they are quite striking and provocative.

I don't see the purpose of this controversy, but it reminds me of some
rather cynical attacks on climate science, and I don't like it at all.
We don't always have the luxury of vast data of impeccable quality, but
we still need to make judgements about the world.

mt

 

[akameswaran]

I am trying to understand why Edwards post generated such a negative
response. I am neither agreeing or disagreeing with his statement -
because I don't think he is making one. He posted a data point, and
asked others to post the samething. About the only thing he could say,
is that for his coding style, Python appears to be more terse. He went
out of his way to describe mitigating factors and didn't draw any
general conclusions.

It seems to me the discussion could actually be beneficial. If several
different coders gave similar responses, ie code line/character count
comparisons, we might be able to see if there is a trend of any sort -
the more "anecdotes" given and we start to have trends - or maybe we
don't.

The UFO comparison is silly, UFO sightings being based on time and
space coordinates are inherently unreviewable. Ed's code and his
analysis methods can be repeated (didn't say they were repeated, just
they can be).

Perhaps some ppl who switched from python to perl could do something
similar, reversing the skill bias Edward admitted too? If we wanted to
pursue more study of the phenomenon we could choose some stylistic
rules about perl and python for test code, etc to help normalize the
data.

Lastly, Ed - can you post the code? That may be putting your head in
the lion's mouth so to speak and make the whole thread even worse - and
your coding style will get shredded by perl advocates... ok nevermind
don't post it.'

Ok I'm going to end with a flamebait - but I would posit, ALL OTHER
THINGS BEING EQUAL - that a smaller number of characters and lines in
code is more maintainable than larger number of characters and lines in
the code.

<duck>

 

[John Bokma]

It seems to me the discussion could actually be beneficial. If several
different coders gave similar responses, ie code line/character count
comparisons, we might be able to see if there is a trend of any sort -
the more "anecdotes" given and we start to have trends - or maybe we
don't.

What's the point? So you can say: Perl code has on average 1.727 more
lines compared to Python?

What's the point, both are tools. People who use both Perl and Python pick
one to solve a problem because they want to pick what they believe is the
right tool. I doubt that the number of lines is often on their mind.

People who just know either Perl or Python don't care much about such
figures, or so I hope.

Lastly, Ed - can you post the code? That may be putting your head in
the lion's mouth so to speak and make the whole thread even worse - and
your coding style will get shredded by perl advocates... ok nevermind
don't post it.'

And not by Python advocates?

Ok I'm going to end with a flamebait - but I would posit, ALL OTHER
THINGS BEING EQUAL - that a smaller number of characters and lines in
code is more maintainable than larger number of characters and lines in
the code.

And I think that's why a lot of people posted very negative, in the hope
that people would not be tempted to make the above very dumb statement.

 

[Ben Finney]

The UFO comparison is silly, UFO sightings being based on time and
space coordinates are inherently unreviewable. Ed's code and his
analysis methods can be repeated (didn't say they were repeated,
just they can be).

Until we get the code to examine independently, all we have is an
anecdote. Thus the comparison to UFO sightings.

 

[akameswaran]

THe interest, on my part, is more academic than practical. I find
data, particularly "dirty" data very fascinating, and I like trying to
find ways to make useful statements when all you have is bad data.
Maybe a pipe-dream, but it's still fun to try. So this little exercise
would be quite enjoyable - a horribly dirty data set that nobody thinks
could be useful. The good guys always fall for the bad data!!
At an architectural or even development management perspective - there
is always someone, somewhere who wants to evaluate "developer
efficiency" or something similarly vague concept for which there aren't
good tools for evaluation. Let's face it in the corp world these kind
of figures are sometimes percieved to have value. SO if I were a corp
programmer in python and a manager says to me my output is way behind
the perl guys - I could pull this silly fact and .... well you see.

My quick comment about his code being torn apart by perl advocates was
mainly because his post seems to be complimentary to python - but your
right both sides would tear him apart.

ANd you took the flame bait so I'll respond
Perhaps - ALL OTHER THINGS BEINGS EQUAL - should better be read as
WRITTEN BY ME!! For the most part I have found it easier to maintain
the shorter programs I have written and found it more time consuming to
maintain longer programs. Really what's so dumb about this? Have you
found, as a general trend you spend more time maintaining your shorter
programs? I did say it was flame bait, and I never said the statement
is useful - all other things are never equal in the real world. I am
constantly amused by how we, as programmers, spend so much time
quantifying everything else, react so negatively when anyone suggests
quantitative analysis of code for anything except execution time.

Course what interests me now - is how could we prove if my statement
was in fact very very dumb or not? In all honesty I don't know, but it
sure tastes good grilled.

 

[akameswaran]

Until we get the code to examine independently, all we have is an

anecdote. Thus the comparison to UFO sightings.

touche!

Ed post the code, please - it'll be fun. We won't hurt you.

 

[Edward Elliott]

What's the point? So you can say: Perl code has on average 1.727 more
lines compared to Python?

That's more than we know right now. You never know what data will reveal
until you collect and analyze it.

BTW I'm not limiting this discussion to lines of code. That was simply the
most convenient metric available. If people have other metrics to
consider, by all means post them.

What's the point, both are tools. People who use both Perl and Python pick
one to solve a problem because they want to pick what they believe is the
right tool. I doubt that the number of lines is often on their mind.

What's the point in learning trigonometry? People who survey land just want
to mark off boundaries, not solve a bunch of equations.

The Pythagoreans built a religious cult on the study of geometric figures.
They didn't know or care that their discoveries would be useful in
engineering and science.

More knowledge = more choice = better tools. When all you have is a hammer,
everything looks like a nail. It's as simple as that. If you're happy
playing with your hammers, fine. Go away and post in some other thread.

People who just know either Perl or Python don't care much about such
figures, or so I hope.

I don't know Ruby, but if you could show me it produced significantly
shorter code with comparable readability to Python, I'd certainly look into
it.

And not by Python advocates?

I don't care who rips my code to what. I haven't posted code because people
will dissect it to death and lose sight of the big picture. Code can
always be improved, it's a question of resources. The point is not what
could be done better in my code, but what was done with my skill and my
time committment, and what others have done with their skill and their time
committment.

At some point I may post small snippets of each so others can gauge my style
and experience, but I'm afraid it will devolve into a code crtitiquing
fest.

And I think that's why a lot of people posted very negative, in the hope
that people would not be tempted to make the above very dumb statement.

That's not a dumb statement, it's a sensible and testable hypothesis. The
more people post their own experiences, the more patterns emerge and
testable hypotheses form, which can then be confirmed or debunked with
further study. The journey of 1000 miles starts with a single step, etc,
etc. Didn't your mother ever tell you how science works? It's not all
bunsen burners and test tubes.

To everyone who thinks this thread is pointless or a bad idea: please just
go away. Your objections have been noted, at this point you're not
contributing anything to the discussion.

 

[akameswaran]

Thank you Ed for your eloquent statement. From now on I will avoid
humor in posts on this thread , my previous attempts were not useful or
productive - and I think there is something interesting in this
discussion.

It might be interesting to come up with a coding assignment for
developers to attempt in both perl and python. Ask the developers to
submit such items as length of time coding in each language, which they
think is their "stronger" language, age, level of formal education in
computer science and related, number of years programming all together,
country of origni, Operating System perference, etc.

Then perform analysis on the code an attempt to normalize for the above
factors. In addtion to line/char counts we could look at execution
time, memory consumption, number of detected bugs.

Of course this means getting a bunch of developers interested in the
task - and the words of Andrew Tannenbaum come to mind. But it would
still be interesting - perhaps nothing could be proven - but that in
itself might be useful. Physical beauty in humans is an area where
some quantitifiable analysis can be performed (referring to a strong
correlation between symmetry and percieved beauty). Beauty in poetry -
to the best of my knowledge - has never been shown itself to be subject
to quantitative analysis. Sometimes knowing what doesn't work - and
proving it doesn't work - can be very useful.

Don't believe me? Thgis is a bad example, but look at hidden variables
theorems in quantum physics. Back the 40's Turing provided (a flawed)
proof that no hidden variables theory could explain the quantum effects
witnessed. Hence no viable hidden variable theories were even posited
and this area of research nearly died out. It has had a slight
resurgance, after Turing's proof was found to relate to specific subset
of hidden variable theorems, rather than a truly generic proof. But I
think it illustrates the value of proving a negative.

 

[Michael Tobis]

And I think that's why a lot of people posted very negative, in the hope
that people would not be tempted to make the above very dumb statement.

Since it's too late to avoid such temptation, could you explain why you
are willing to go so far as to call that statement "very dumb"?

I, for one, consider it rather wise. When I am teaching programming, or
advocating Python, I generally try to include the following advice,
attributed to A. de St.-Exupery:

"La perfection est atteinte non quand il ne reste rien à ajouter, mais
quand il ne reste rien à enlever."

The relevant corrolary is, "he programs best who programs least". I
would have thought this was conventional wisdom among all dynamic
language communities. Isn't that the whole point? By all means go back
to C++ if you like to have three lines for each idea instead of the
other way around.

However, since I habitually make such a fuss about this, I'd hate to be
wrong. Please do explain why you think this idea that terseness is a
virtue is foolish.

mt

 

[John Bokma]

THe interest, on my part, is more academic than practical. I find
data, particularly "dirty" data very fascinating

Me less, maybe that's why I originally had gg kill filed...

I prefer quotes.

 

[John Bokma]

That's more than we know right now. You never know what data will
reveal until you collect and analyze it.

1.727 is meaningless. It says nothing about your code, nor mine.

BTW I'm not limiting this discussion to lines of code. That was
simply the most convenient metric available. If people have other
metrics to consider, by all means post them.

The number $ characters per square furlong.

More knowledge = more choice = better tools. When all you have is a
hammer, everything looks like a nail. It's as simple as that. If
you're happy playing with your hammers, fine. Go away and post in
some other thread.

At least I am not as silly to claim that hammer A is better then hammer
B because the handle of hammer A came from an oak tree that had a owl
hooting 13 times at the full moon 7 times a year.

I don't know Ruby, but if you could show me it produced significantly
shorter code with comparable readability to Python, I'd certainly look
into it.

Yeah, I could have guessed that.

[ .. ]

Code can always be improved, it's a question of resources. The point
is not what could be done better in my code, but what was done with my
skill and my time committment, and what others have done with their
skill and their time committment.

If we have no way to see your skills, there is not really a point.

At some point I may post small snippets of each so others can gauge my
style and experience, but I'm afraid it will devolve into a code
crtitiquing fest.

At least people can learn from that. If you don't understand that
everbody has his/her own coding style, you have a lot to learn.

That's not a dumb statement, it's a sensible and testable hypothesis.

So you *do* still have a lot to learn. Isn't one Xah Lee enough?

step, etc, etc. Didn't your mother ever tell you how science works?
It's not all bunsen burners and test tubes.

Nor is it: I have have examined some random samples of which I give only
a vague description. Now get your own random samples, and lets talk
science.

To everyone who thinks this thread is pointless or a bad idea: please
just go away. Your objections have been noted, at this point you're
not contributing anything to the discussion.

Welcome to Usenet. How it really works can be seen by having a peek at
the archives. Since you love science, you'll will find the answer very
fast.

 

[John Bokma]

The relevant corrolary is, "he programs best who programs least". I
would have thought this was conventional wisdom among all dynamic
language communities. Isn't that the whole point? By all means go back
to C++ if you like to have three lines for each idea instead of the
other way around.

You disagree: go back.

A true zealot.

Programming is about writing down ideas in a *clear* and *consistent way*,
so that not only the original author is able to read and understand it
after 3 months, but also peers.

According to your silly rule the shortest book on a subject would be the
best. Now why is that false?

Why are Perl golf scripts so hard to understand?

 

[Edward Elliott]

Until we get the code to examine independently, all we have is an
anecdote. Thus the comparison to UFO sightings.

Except UFO sightings comprise a large body of data containing a vast number
of known false reports and others that appear to be in the same vein with
no verified positives despite many concerted efforts to produce such
evidence.

Here we have a single data point with no positive or negative
corroborations. It's like a guy saying he saw a cloud that looks like a
python. The cloud's gone now, but other people can watch other clouds and
report what they see.