python vs perl lines of code

[John Bokma]

Re: python vs perl lines of code

"Michael Tobis" <mtobis@gmail.c om> wrote:
[color=blue][color=green]
>> According to your silly rule the shortest book on a subject would be
>> the best. Now why is that false?[/color]
>
> No, according to the rule, the shorter of two books **containing the
> same information** would be best.[/color]

What is "the same information"?
[color=blue]
> 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)[/color]

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.
[color=blue]
> while Python makes no special effort in
> that direction.[/color]

Nor does Perl. That one can do something doesn't mean one has to do it.
[color=blue]
> If real world Python code is substantially more terse *despite* this
> cultural difference, it is a fact worthy of some note.[/color]

Maybe you got the Perl culture wrong. I think you do.
[color=blue]
> Let me add my voice to those clamoring for Edward to release his code
> while I'm here, though.[/color]

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?

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

[Terry Hancock]

Re: python vs perl lines of code

Michael Tobis wrote:
[color=blue]
>John Bokma wrote:[color=green]
>>"akameswaran@ gmail.com" <akameswaran@gm ail.com> wrote:[color=darkred]
>>>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.[/color]
>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"?[/color]

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.

--
Terry Hancock (hancock@Anansi Spaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[Edward Elliott]

Re: python vs perl lines of code

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

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.

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

[akameswaran@gmail.com]

Re: python vs perl lines of code

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]

Quoting relevant material for response (was: Re: python vs perllines of code)

"akameswaran@gm ail.com" <akameswaran@gm ail.com> writes:
[color=blue]
> Hmm, and I thought it was respectful to actually address someone you
> are talking to.[/color]

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.
[color=blue]
> Must every statement be a reaction to a quotable comment?[/color]

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.
[color=blue]
> In any case, I realize I was completley wrong. Please allow me to
> retract my statement.[/color]

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?

--
\ "Not using Microsoft products is like being a non-smoker 40 or |
`\ 50 years ago: You can choose not to smoke, yourself, but it's |
_o__) hard to avoid second-hand smoke." -- Michael Tiemann |
Ben Finney

[akameswaran@gmail.com]

Re: python vs perl lines of code

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

Re: Quoting relevant material for response (was: Re: python vs perl lines of code)

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.
[color=blue][color=green]
>> In any case, I realize I was completley wrong. Please allow me to
>> retract my statement.[/color][/color]
[color=blue]
>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?[/color]

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

[John Bokma]

Re: python vs perl lines of code

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

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 MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[John Bokma]

Re: Quoting relevant material for response (was: Re: python vs perl lines of code)

"akameswaran@gm ail.com" <akameswaran@gm ail.com> wrote:
[color=blue]
> quoting mechanism is available on the web interface and I haven't found
> it - I'd love to know how to use it.[/color]

http://groups.google.com/support/bin/answer.py?answer=14213

[color=blue]
> Also i use the threaded view on
> the web client, so I have little trouble figuring out what is being
> referenced.[/color]

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.

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

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 MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[John Bokma]

Re: python vs perl lines of code

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

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 :-)
[color=blue]
> The fact that you many ppl will state the shorter line count of
> rewrites is a sign of improving skill[/color]

I disaprove if you want to make it a general rule. I have seen too many
exceptions.
[color=blue]
> My skill level increases a lot faster than my coding style changes over
> time.[/color]

After 10 years that will change the other way around I guess. At least
that's my experience.
[color=blue]
> 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.[/color]

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.

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

[Terry Hancock]

Re: python vs perl lines of code

Edward Elliott wrote:
[color=blue]
>For inquiries into real-world code, it's enough to
>believe that I'm not lying
>[/color]
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.

--
Terry Hancock (hancock@Anansi Spaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[Edward Elliott]

Re: python vs perl lines of code

Terry Hancock wrote:
[color=blue]
> Edward Elliott wrote:
>[color=green]
>>For inquiries into real-world code, it's enough to
>>believe that I'm not lying
>>[/color]
> 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.[/color]

So lookup my post history in comp.lang.pytho n 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.

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

[Michael Tobis]

Re: Quoting relevant material for response (was: Re: python vs perl lines of code)

OT, sort of, but...

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

Click "show options" and THEN hit "reply". It's a bit counterintuitiv e,
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@gmail.com]

Re: python vs perl lines of code


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

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.


[color=blue]
> 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 :-)
>[color=green]
> > The fact that you many ppl will state the shorter line count of
> > rewrites is a sign of improving skill[/color]
>
> I disaprove if you want to make it a general rule. I have seen too many
> exceptions.[/color]

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

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]

Re: python vs perl lines of code

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

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.
[color=blue]
> Two points here. I have since the beginning stating a HYPOTHESIS - a
> theory. One which my experince leads me think MIGHT be true.[/color]

Enough to bet on it ;-)
[color=blue][color=green]
>> 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.[/color]
>
> Please note my original hypothesis was maintainability - not quality![/color]

Aren't those closely related?
[color=blue]
> 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.[/color]

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.

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