python vs perl lines of code

[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.

 

[akameswaran]

John,
Your hilarious... I mean it, and as a compliment.

But seriously, I think your taking a discussion about trends and
twisting them to be about absolutes. Maybe others are too.

But, forgive the cheesy paraphrasing, but the solution should be as
simple as possible, and no simpler.

There is no real problem with choosing a set of coding principals and
sticking with them. Honestly, I don't think there currently exists a
good method of comparing true software quality. So most discussion on
which coding principals are actually useful, is kinda like talkin to
miss Cleo.

Still there is some value in seeing how closely software can align with
certain principals. Right now we are asking questions about terseness.
The obvious follow up is what relation does terseness have to quality?
We are in a better postition to answer the second question if we know
the first.

When our preconceived notions cause us to study something, they should
be encouraged. When our preconceived notions cause us to say, "forget
it, a waste of time", we should question them.

I don't think anyone in this discussion has shown themselves to be a
zealot. For the most part we've just been asking questions.

 

[John Bokma]

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.

Good comparison, now does the cloud gazing make them better programmers?

 

[Michael Tobis]

According to your silly rule the shortest book on a subject would be the

best. Now why is that false?

No, according to the rule, the shorter of two books **containing the
same information** would be best.

I don't think I'm a zealot. The original quote said "all else equal".
Certainly legible code is better than, hence not equal to, illegible
code.

I would say that having played Python golf once, the complexity of the
competitive keystroke-minimizing code is much higher than the
complexity of the equivalent sane, readable, maintainable code.
(Actually, it also turns out to involve a good deal of coding that
isn't in the final source, but let's not go there.) The point is I did
NOT say he programs best who *types* least, and I don't believe that.

In fact, that's what makes the comparison interesting. I had always
thought that Pythonistas type more than Perlists, though I prefer
Python anyway. The presumption was based on the fact that Perl (as
language and culture) takes delight in saving keystrokes at the expense
of clarity ($_ and all that) while Python makes no special effort in
that direction.

If real world Python code is substantially more terse *despite* this
cultural difference, it is a fact worthy of some note.

Let me add my voice to those clamoring for Edward to release his code
while I'm here, though.

mt

 

[John Bokma]

John,
Your hilarious...

If you learn to quote, you don't need to address me. But it's beyond you I
understand, so bye.

 

[John Bokma]

No, according to the rule, the shorter of two books **containing the
same information** would be best.

What is "the same information"?

In fact, that's what makes the comparison interesting. I had always
thought that Pythonistas type more than Perlists, though I prefer
Python anyway. The presumption was based on the fact that Perl (as
language and culture) takes delight in saving keystrokes at the
expense of clarity ($_ and all that)

Then you're very mistaken about the Perl culture, or you consider a
small group *the* Perl culture, which is also a mistake IMNSHO.

I have never see someone recommend unclear Perl code over clear code,
except in golf. But we're not talking about golf here.

while Python makes no special effort in
that direction.

Nor does Perl. That one can do something doesn't mean one has to do it.

If real world Python code is substantially more terse *despite* this
cultural difference, it is a fact worthy of some note.

Maybe you got the Perl culture wrong. I think you do.

Let me add my voice to those clamoring for Edward to release his code
while I'm here, though.

Yup, I agree on that. Since I am learning Python (well, I read Dive into
Python, and the Python documentation), and have quite some Perl
experience, I am curious.

Yes, I might comment on the Perl code, but isn't the goal to learn?

 

[Terry Hancock]

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"?

The problem with the idea is that "simplicity" is not quite equal
to "a smaller number of characters". For example, of each of the
following pairs, which is "clearer":

ls list
cp copy
mv move

Or to ask it another way, "Which is easier to *read*?"

Although I have long since come to take the former spellings for
granted, and they are undeniably shorter, the latter would've actually
been easier for people to remember. The insistence of using the
longer, more mnemonic form is a major characteristic of Python.

The wisdom behind this is that Python's design takes into account
the observation that source code is read many times more than it
is written. To do this, it sacrifices some brevity compared to other
languages (the classic example being Perl which uses lots of arcane
symbols and tends to use shorter, more Unix-like naming).

However, this turns out to be a big win, in that you don't waste so
much time trying to remember abbreviated names. There are, for
example several ways of abbreviating a word like "quantity":

q
Q
quant
qtty
quanty
qnty
Qtty
QNT

etc.

But there's only one "standard spelling". If I only have to remember
that "Python prefers to use the standard spelling" as a rule of thumb,
then I will usually get the right answer (there are still significant
exceptions such as "dict" instead of "dictionary" and "def" instead of
"define" -- but they are fewer than in most languages).

Anyway, since humans tend to parse whole words as symbols when
reading, rather than individual characters, the choice between using
symbols or abbreviations versus whole standard-form words is not
believed to matter (I think it would be a strong claim to say that this
is proven, but it does seem likely to me).

Frankly, even when typing, I find it slightly easier to type "unmount"
than "umount" -- I always pause after the "u" to remember the funky
Unix spelling. It's only a split-second delay, but those things add up,
and each one represents a possible bug, if the output is source code.

Even "dictionary" is hardly different from "dict" -- I've already
learned to type common English morphemes without thinking about the
process, so it just doesn't make any difference from my PoV. That's
why I always find the hoops people will jump through to avoid typing
a couple of extra keystrokes to be silly (are they typing with their
noses?* ;-) ). It would frankly be harder for me to remember the
extra mechanics than to just type the extra letters.

The claim is ironic -- even counter-intuitive -- considering this
conventional lore. But the real point is that no one here can make
any reasonably objective assessment of whether your "data" is
meaningful unless you post examples. That's what creates the
hostility, I think.

Cheers,
Terry


*With apologies to anyone who's actually using assistive tech to
type their code -- but I'm sure you already know how to use macros
to get what you want typed.

 

[Edward Elliott]

But the real point is that no one here can make
any reasonably objective assessment of whether your "data" is
meaningful unless you post examples. That's what creates the
hostility, I think.

Fair enough. But see my other posts on why I'm not interested in objective
assessments of my code. For inquiries into real-world code, it's enough to
believe that I'm not lying, e.g. that I have the programs and ran the tests
described. The actual file contents are almost irrelevant. Nothing one
can say about my code tells us anything about typical code in the wild.
Producing more data points _will_ tell us that. If my data are an outlier,
they may be worthless anyway.

That's what I'm interested in. Others are interested in analyzing my code.
Which is fine, it's just not what I'm after.

 

[akameswaran]

Hmm, and I thought it was respectful to actually address someone you
are talking to. Must every statement be a reaction to a quotable
comment? In any case, I realize I was completley wrong. Please allow
me to retract my statement.

 

[Ben Finney]

Hmm, and I thought it was respectful to actually address someone you
are talking to.

On Usenet, it's respectful to all readers if you give a short quoted
passage from the message you're responding to, so we can follow the
discussion with context.

gmail allows you to do this. You have the option to edit a quoted
version of the message, removing the parts irrelevant to your
response, and putting your response following each relevant part.

Must every statement be a reaction to a quotable comment?

Not necessarily. But if you're only making new statements, you should
compose your message as a new topic, instead of as a reply to an
existing message.

In any case, I realize I was completley wrong. Please allow me to
retract my statement.

It's hard to see what that is, since you don't provide any
context. Are we expected to re-read the entire thread to guess what
you're referring to?

 

[akameswaran]

As a coder, I wouldn't normally use the two different conventions. you
show in your examples. So it does little to tell us about the
importance or lack there of line count.

Let me state clearly - to use line count , in absence of other
considerations, IS meaningless.

But if a 1 person, using 1 language, with the same set of tools withing
a 3 month period implements the same algo without bugs - I'll bet you
the shorter one was theone written second.

The fact that you many ppl will state the shorter line count of
rewrites is a sign of improving skill I think actually presents some
"anecdotal" evidence that there is some truth that shorter code is
better code.

My skill level increases a lot faster than my coding style changes over
time. So while far from conclusive, the fact that I find my code gets
shorter the second time - and it is usually done more skillfully, it
seems there is a correlation of some sort between lines of code and
quality.

 

[akameswaran]

Thanks Ben,
I actually don't spend a whole lot of time on newsgroups. I don't use
my gmail account and use the groups thru the web interface. If that
quoting mechanism is available on the web interface and I haven't found
it - I'd love to know how to use it. Also i use the threaded view on
the web client, so I have little trouble figuring out what is being
referenced.

My comment about John being funny in fact was a generic comment, and
while the remainder of my response was on topic - it still was not in
response to 1 specific statement or another. Quoting previous comments
is useful, but not required to be in thread - IMHO.

It's hard to see what that is, since you don't provide any
context. Are we expected to re-read the entire thread to guess what
you're referring to?

Secondly, I meant I was wrong about John being hilarious - and in that
context the quotes would have been useful.

 

[John Bokma]

Fair enough. But see my other posts on why I'm not interested in
objective assessments of my code. For inquiries into real-world code,
it's enough to believe that I'm not lying, e.g. that I have the
programs and ran the tests described. The actual file contents are
almost irrelevant. Nothing one can say about my code tells us
anything about typical code in the wild. Producing more data points
_will_ tell us that. If my data are an outlier, they may be worthless
anyway.

That's what I'm interested in. Others are interested in analyzing my
code. Which is fine, it's just not what I'm after.

In that case I think it's safe to say that a majority of Perl code out in
the wild is extrememly badly coded. Just download 10 free Perl CGI scripts
to see my point.

I wouldn't be amazed if this is not the case for Python, or at least way
less.

But be very carefull to draw any conclusion out of this :-D.

 

[John Bokma]

quoting mechanism is available on the web interface and I haven't found
it - I'd love to know how to use it.
http://groups.google.com/support/bin/answer.py?answer=14213

Also i use the threaded view on
the web client, so I have little trouble figuring out what is being
referenced.

I mark messages as read when I have read them, so without a context I have
no idea what "Joh, I disagree" (for example) is about, especially since I
don't just post one message a day.

Also, due to how Usenet works, not everybody sees the messages in the same
order as you do, or might even miss out a message or two (or several).

Finally, since Google provides a search engine for Usenet, it might be
perfectly possible that your reply without a quote is the first result in
such a search.

I always recommend to write your reply in such a way that when you print
it, and read it 3 months later you're able to understand the message when
you read it top down.

My comment about John being funny in fact was a generic comment, and
while the remainder of my response was on topic - it still was not in
response to 1 specific statement or another. Quoting previous comments
is useful, but not required to be in thread - IMHO.

True, but if it's not a reply to the previous person, then you might want
to start a new thread, or you're replying to the wrong person.

 

[John Bokma]

But if a 1 person, using 1 language, with the same set of tools withing
a 3 month period implements the same algo without bugs - I'll bet you
the shorter one was theone written second.

You might lose that bet very often. I see often that additional checks are
added to algorithms to handle special cases overlooked, or documentation
added because a co-worker had problems with the notation.

I rarely see my scripts shrink, they often grow. The only time they shrink
is when I factor one or more modules out of it

The fact that you many ppl will state the shorter line count of
rewrites is a sign of improving skill

I disaprove if you want to make it a general rule. I have seen too many
exceptions.

My skill level increases a lot faster than my coding style changes over
time.

After 10 years that will change the other way around I guess. At least
that's my experience.

So while far from conclusive, the fact that I find my code gets
shorter the second time - and it is usually done more skillfully, it
seems there is a correlation of some sort between lines of code and
quality.

Yup, and this is exactly what frightens me the whole time in this thread.
People looking for quality rules based on line count. It's wrong.

 

[Terry Hancock]

For inquiries into real-world code, it's enough to
believe that I'm not lying

Yeah, well, this is the internet -- I've gotten emails trying to
sell me ex-soviet rocket-launchers and child porn.*

So I don't make assumptions about people without some kind
of evidence. There *are* plenty of "bad guys" out there, so
one learns both to have a thick skin and to rely on that which
is reasonably proven, rather than making casual assumptions
of good will. That'd be like leaving your car in downtown LA
overnight with the doors unlocked.

Cheers,
Terry

*In the same email, no less. This is of course an extreme
example, but there are *loads* of merely irritating behaviors
like trolling.

 

[Edward Elliott]

So I don't make assumptions about people without some kind
of evidence. There *are* plenty of "bad guys" out there, so
one learns both to have a thick skin and to rely on that which
is reasonably proven, rather than making casual assumptions
of good will. That'd be like leaving your car in downtown LA
overnight with the doors unlocked.

So lookup my post history in comp.lang.python on google groups. Do I behave
like a scammer or troll? Have I wasted time posting in other threads just
to build credibility and dupe everyone here? You make judgements about
people in the real world all the time on significantly less information.
If you really think I'm making all this up, feel free to ignore to me. Or
reserve judgement until you have more data for comparison.

 

[Michael Tobis]

OT, sort of, but...

If that
quoting mechanism is available on the web interface and I haven't found
it - I'd love to know how to use it.

Click "show options" and THEN hit "reply". It's a bit counterintuitive,
but the entire message to which you reply is then shown. It is best to
(as I've just done) erase the parts you aren't replying to.

If you are replying to multiple selected parts of the message it is
good form to indicate the gaps with ellipses ("...").

It's worth noting that this group predates Google by severalyears, that
usenet predates it by well over a decade, and that Google is only one
of several alternative ways of participating (though it is my own
preference) and that its conventions have emerged for good reasons.

see http://en.wikipedia.org/wiki/Usenet
and
http://en.wikipedia.org/Google_Groups

mt

 

[akameswaran]

You might lose that bet very often. I see often that additional checks are
added to algorithms to handle special cases overlooked, or documentation
added because a co-worker had problems with the notation.

I am not the one generalizing my statement. Adding the things above,
does not count as implementing the same thing. It would implementing a
new thing. And what you describe could be just be more bloat - not
indicating quality.

I rarely see my scripts shrink, they often grow. The only time they shrink
is when I factor one or more modules out of it


I disaprove if you want to make it a general rule. I have seen too many
exceptions.

Two points here. I have since the beginning stating a HYPOTHESIS - a
theory. One which my experince leads me think MIGHT be true. I am
much more interested in figuring out a way to validly compare line
counts (a distinct challenge in itself) Then we might be able to test
the hypothesis. Two -I am not trying to declare an absolute rule.
Would I advocate someone think about line count when implementing? No.
Do I think there might be some useful analysis of code that includes
line count and char count - yes. Is it proven - no.

Yup, and this is exactly what frightens me the whole time in this thread.
People looking for quality rules based on line count. It's wrong.

Please note my original hypothesis was maintainability - not quality!
important important distinction - and one I may have muddles myself as
I got drawn into the conversation.
And what frightens me are people who are so dogmatically convinced
becasue of their long 10 years of experience - that they know exactly
what does and doesn't matter, and have no intellectual curiosity
anymore. There are no objective tests for maintainability that I am
aware of. So neither of us is arguing from a position of evidence -
just experience.

 

[John Bokma]

I am not the one generalizing my statement. Adding the things above,
does not count as implementing the same thing. It would implementing
a new thing. And what you describe could be just be more bloat - not
indicating quality.

Yes, like the shorter version might be overlooking many real world
situations and is naive code. As for generalization, if you bet that the
shorter one is later written, that's to me a generalization. I agree that
there is a change that after reexamining the code, and algorithm can be
written shorter, but I have also seen algorithms refactored for better
readability.

Two points here. I have since the beginning stating a HYPOTHESIS - a
theory. One which my experince leads me think MIGHT be true.

Enough to bet on it ;-)

Please note my original hypothesis was maintainability - not quality!

Aren't those closely related?

important important distinction - and one I may have muddles myself as
I got drawn into the conversation.
And what frightens me are people who are so dogmatically convinced
becasue of their long 10 years of experience - that they know exactly
what does and doesn't matter, and have no intellectual curiosity
anymore. There are no objective tests for maintainability that I am
aware of.

Because it depends a lot on the skill level of the maintainer. By just
counting lines and characters you can't measure quality IMO. It's a naive
way of measuring and it reminds me of the early days of search engines.

And if you mistake understanding that it's not a good way to measure
things as having no intellectual curiosity, you're again mistaken.