By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,677 Members | 1,272 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,677 IT Pros & Developers. It's quick & easy.

python vs perl lines of code

P: n/a
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
May 17 '06 #1
Share this Question
Share on Google+
82 Replies


P: n/a
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
May 17 '06 #2

P: n/a
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
May 17 '06 #3

P: n/a
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
May 17 '06 #4

P: n/a
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

May 17 '06 #5

P: n/a
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
May 17 '06 #6

P: n/a
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
May 17 '06 #7

P: n/a
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 GetTheseSamplesHereOut {
...
...
}

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

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

M. Wahab
May 17 '06 #8

P: n/a
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/
May 17 '06 #9

P: n/a
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
May 17 '06 #10

P: n/a
John Bokma wrote:
Edward Elliott <no****@127.0.0.1> wrote:
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.


The point is knowing how to pick the right tool for the right job.
Anecdotes aren't the answer but they can be the beginning of the question.
Besides, whatever happened to pursuing knowledge for its own sake?

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
May 17 '06 #11

P: n/a
In article <At*******************@newssvr14.news.prodigy.com> ,
Edward Elliott <no****@127.0.0.1> wrote:

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? :)


"The plural of anecdote is not data."
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"I saw `cout' being shifted "Hello world" times to the left and stopped
right there." --Steve Gonedes
May 17 '06 #12

P: n/a
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.

May 17 '06 #13

P: n/a
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.

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.

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

May 17 '06 #14

P: n/a
In article <IR******************@newssvr11.news.prodigy.com >, 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.

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.


You've got some hidden assumptions in there somehere, even if you
aren't admitting them to yourself. :)

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.

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.

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.

*** Posted via a free Usenet account from http://www.teranews.com ***
May 17 '06 #15

P: n/a
Edward Elliott <no****@127.0.0.1> wrote:
John Bokma wrote:
Edward Elliott <no****@127.0.0.1> wrote:
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.


The point is knowing how to pick the right tool for the right job.


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


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
May 17 '06 #16

P: n/a
"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 paleoclimatologists.

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 counterintuitive 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) counterintuitive 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

May 17 '06 #17

P: n/a
brian d foy wrote:
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.
I completely agree. But you have to start somewhere.
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.
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.
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.


Of course. Extreme cases are just that.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
May 17 '06 #18

P: n/a
"Michael Tobis" <mt****@gmail.com> writes:
"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 paleoclimatologists.

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?


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

May 17 '06 #19

P: n/a
achates wrote:
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.


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
May 17 '06 #20

P: n/a
Edward Elliott <no****@127.0.0.1> wrote:
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.

--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
May 17 '06 #21

P: n/a
Adam Jones wrote:
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.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
May 17 '06 #22

P: n/a
Michael Tobis wrote:
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
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
May 18 '06 #23

P: n/a
Ben Finney wrote:
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.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
May 18 '06 #24

P: n/a
Edward Elliott <no****@127.0.0.1> writes:
Ben Finney wrote:
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.


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

May 18 '06 #25

P: n/a
Ben Finney wrote:
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.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
May 18 '06 #26

P: n/a
Edward Elliott <no****@127.0.0.1> writes:
Ben Finney wrote:
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.


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.

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

May 18 '06 #27

P: n/a
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

May 18 '06 #28

P: n/a
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>

May 18 '06 #29

P: n/a
"ak*********@gmail.com" <ak*********@gmail.com> wrote:
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.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
May 18 '06 #30

P: n/a
"ak*********@gmail.com" <ak*********@gmail.com> writes:
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.

--
\ "Madness is rare in individuals, but in groups, parties, |
`\ nations and ages it is the rule." -- Friedrich Nietzsche |
_o__) |
Ben Finney

May 18 '06 #31

P: n/a
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 :D
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.

May 18 '06 #32

P: n/a
>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.

May 18 '06 #33

P: n/a
John Bokma wrote:
"ak*********@gmail.com" <ak*********@gmail.com> wrote:
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?


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.

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?


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.

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.


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.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
May 18 '06 #34

P: n/a
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.

May 18 '06 #35

P: n/a
John Bokma wrote:
"ak*********@gmail.com" <ak*********@gmail.com> wrote:
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.


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

May 18 '06 #36

P: n/a
"ak*********@gmail.com" <ak*********@gmail.com> wrote:
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 MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
May 18 '06 #37

P: n/a
Edward Elliott <no****@127.0.0.1> wrote:
John Bokma wrote:
"ak*********@gmail.com" <ak*********@gmail.com> wrote:
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?


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


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


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

P: n/a
"Michael Tobis" <mt****@gmail.com> wrote:
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?

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
May 18 '06 #39

P: n/a
Ben Finney wrote:
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.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
May 18 '06 #40

P: n/a
Ben Finney wrote:
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.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
May 18 '06 #41

P: n/a
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.

May 18 '06 #42

P: n/a
Edward Elliott <no****@127.0.0.1> wrote:
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?

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
May 19 '06 #43

P: n/a
> 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

May 19 '06 #44

P: n/a
"ak*********@gmail.com" <ak*********@gmail.com> wrote:
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 MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
May 19 '06 #45

P: n/a
"Michael Tobis" <mt****@gmail.com> wrote:
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.


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?

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
May 19 '06 #46

P: n/a
Michael Tobis wrote:
John Bokma wrote:
"ak*********@gmail.com" <ak*********@gmail.com> wrote:
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.

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.

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

May 19 '06 #47

P: n/a
Terry Hancock wrote:
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.

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
May 19 '06 #48

P: n/a
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.

May 19 '06 #49

P: n/a
"ak*********@gmail.com" <ak*********@gmail.com> writes:
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?

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

May 19 '06 #50

82 Replies

This discussion thread is closed

Replies have been disabled for this discussion.