python vs perl lines of code

[John Bokma]

Re: python vs perl lines of code

Edward Elliott <nobody@127.0.0 .1> wrote:
[color=blue]
> John Bokma wrote:
>[color=green]
>> Edward Elliott <nobody@127.0.0 .1> wrote:[color=darkred]
>>> Evaluating my experiences yes, relating your own no.[/color]
>>
>> 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.[/color]
>
> The point is knowing how to pick the right tool for the right job.[/color]

True, and I don't think that the number of lines is going to be a good
guideline.
[color=blue]
> Anecdotes aren't the answer but they can be the beginning of the
> question. Besides, whatever happened to pursuing knowledge for its own
> sake?[/color]

Sure, but research without being able to peer review the set up is a bit
difficult. If you want an anecdote: three years ago my Perl coding was
different from now, and I am sure that my Python coding (when I get
there), will be different compared to if I had learned the language 3
years ago. Mind, I am not saying that I am going to program Python the
Perl way, just that in 3 years I have learned stuff I can use in other
languages as well.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[Michael Tobis]

Re: python vs perl lines of code

"The plural of anecdote is not data."

It's a pithy quote, but it isn't QOTW in my book, simply because it
isn't true in general. Talk to some paleoclimatolog ists.

There is no way to get uniform measures of ancient climate. What should
we do then? Should we ignore the information we have? Are the
fortuitously preserved fossils of the very deep past to be ignored just
because we can't get an unbiased sample?

In fact, the more difficult it is to get systematic data, the more
valuable the anecdote.

There is a number that represents the character ratio for equivalent
skill applied to equivalent tasks across all domains to which both
languages are applied. A single programmer's results on this matter do
in fact constitute a sample. A single sample is not a very good
estimator, but it is not devoid of skill or information either.

In the present case Edward gave us some advice that he thought he was
making a fair comparison, one which would appear counterintuitiv e to
anyone who has worked in both languages. Perlists tend to giggle and
cackle every time they save a keystroke; Pythonistas do not have this
personality quirk. If Python is nevertheless terser it is a strong
argument in Python's favor vis-a-vis Perl.

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.

My only data point, er, anecdotal evidence, is this. To take things to
an unrealistic extreme, consider the puzzle at http://pycontest.net
(Python Golf). When I first thought about this, I assumed that Perl
would defeat Python in the character count, but as I worked at the
puzzle I came to the (to me) counterintuitiv e realization that it
probably would not. I'd be interested in seeing the results of an
inter-language golf contest.

Of course, such games don't tell us much about real code, but I'm
inclined to agree with Edward's impression that Python is, in practice,
terse compared to Perl, and I, too, would like to hear about other
examples, and because I think the plural of "anecdote" is, in fact,
"data".

mt

[Edward Elliott]

Re: python vs perl lines of code

brian d foy wrote:
[color=blue]
> 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.[/color]

I completely agree. But you have to start somewhere.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

Of course. Extreme cases are just that.

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

[Ben Finney]

Re: python vs perl lines of code

"Michael Tobis" <mtobis@gmail.c om> writes:
[color=blue]
> "The plural of anecdote is not data."
>
> It's a pithy quote, but it isn't QOTW in my book, simply because it
> isn't true in general. Talk to some paleoclimatolog ists.
>
> There is no way to get uniform measures of ancient climate. What
> should we do then? Should we ignore the information we have? Are the
> fortuitously preserved fossils of the very deep past to be ignored
> just because we can't get an unbiased sample?[/color]

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

--
\ "I know you believe you understood what you think I said, but I |
`\ am not sure you realize that what you heard is not what I |
_o__) meant." -- Robert J. McCloskey |
Ben Finney

[Edward Elliott]

Re: python vs perl lines of code

achates wrote:
[color=blue]
> 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.[/color]

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

[John Bokma]

Re: python vs perl lines of code

Edward Elliott <nobody@127.0.0 .1> wrote:
[color=blue]
> But again, the interesting thing to me isn't what could one do, it's
> what are people actually doing in the real world?[/color]

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

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

[Edward Elliott]

Re: python vs perl lines of code

Adam Jones wrote:
[color=blue]
> 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.[/color]

I am in complete agreement with that statement.
[color=blue]
> 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.[/color]

Absolutely.
[color=blue]
> 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.[/color]

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.
[color=blue]
> The real important question is: what has perl done in
> the last five years to make writing these scripts easier?[/color]

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

[Edward Elliott]

Re: python vs perl lines of code

Michael Tobis wrote:
[color=blue]
> 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.[/color]

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

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

[Edward Elliott]

Re: python vs perl lines of code

Ben Finney wrote:
[color=blue]
> Those samples can be independently verified by any skilled observer at
> another time. This is what distinguishes them from anecdotes, and
> breaks your analogy.[/color]

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.

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

[Ben Finney]

Re: python vs perl lines of code

Edward Elliott <nobody@127.0.0 .1> writes:
[color=blue]
> Ben Finney wrote:
>[color=green]
> > Those samples can be independently verified by any skilled
> > observer at another time. This is what distinguishes them from
> > anecdotes, and breaks your analogy.[/color]
>
> Anyone who has my source files can run the same tests.[/color]

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.

--
\ "It is hard to believe that a man is telling the truth when you |
`\ know that you would lie if you were in his place." -- Henry L. |
_o__) Mencken |
Ben Finney

[Edward Elliott]

Re: python vs perl lines of code

Ben Finney wrote:
[color=blue]
> 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.[/color]

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.

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

[Ben Finney]

Re: python vs perl lines of code

Edward Elliott <nobody@127.0.0 .1> writes:
[color=blue]
> Ben Finney wrote:
>[color=green]
> > 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.[/color]
>
> 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.[/color]

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.
[color=blue]
> It's a stupid argument anyway. Anecdotes *are* data.[/color]

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.

--
\ "The reward of energy, enterprise and thrift is taxes." -- |
`\ William Feather |
_o__) |
Ben Finney

[Michael Tobis]

Re: python vs perl lines of code

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@gmail.com]

Re: python vs perl lines of code

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]

Re: python vs perl lines of code

"akameswaran@gm ail.com" <akameswaran@gm ail.com> wrote:
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.'[/color]

And not by Python advocates?
[color=blue]
> 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.[/color]

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.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html