Why did Quora choose Python for its development?

[Chris Angelico]

Yes, I believe that was Perl. And an amusing quote. But most of the
point of it comes from the fact that Perl uses punctuation for most of
its keywords,

For example?

whereas (say) Python uses English words; it's a lot more
fun to crunch something down when you can use $|

That's not a keyword but a special (global) variable. On top of that,
you don't have to use it [1] and most people most likely encounter this in
(badly) written CGI scripts originating in the last century.

Okay, poor example. But there's a lot of Perl that uses concise
notation for things that in Python are keyworded; for instance,
regular expressions. I'm insufficiently fluent in Perl to quote good
examples; mainly what I'm referring to is the notion of operators that
are separators, as opposed to keywords that get blank-delimited. I
generally prefer syntactic elements to be punctuation (eg { } rather
than BEGIN and END (or DO and END)). It does also make things easier
to crunch, for better or for worse.

Perl has also the and logical operator. This is legal Perl:

if ( $x and $y ) {
 print "yes\n";
}

That's at a completely different precedence level, isn't it? For
operators up where you expect them to be, there's && and ||. A bit of
digging (why isn't this sort of thing always the first hit for "<name
of language> operator precedence" in Google?) brought up:

http://perldoc.perl.org/perlop.html

For instance:

$a = $b && $c ? $e : $f;
# versus
$a = $b and $c ? $e : $f;

The first one is an assignment to $a, conditional on two variables.
The second is an unconditional assignment to $a, and then based on
that, evaluates either $e or $f and does nothing with it.

Python:
a = e if b and c else f

It's pretty similar, actually (although, coming from a C background, I
do prefer to have the condition first); but I could crunch the first
one down a lot, while the last one is almost as tight as it can be.

$a=$b&&$c?$e:$f;
a=e if b and c else f

It's that crunched appearance that makes Perl look like line noise,
and the open keyworded appearance that makes Python look like
pseudocode. But that's not necessarily a good thing; a courteous
programmer can space out Perl to keep it readable, and he then has the
option of crunching pieces that are 'logically one' and spacing out
the parts that aren't:

$a= $b&&$c ? $e : $f;

Silly, contrived example, but in production code I've often had
situations where it makes sense to space out one part of an expression
and crunch another. And when everything's an English word, that's not
an available option.

Oh, and that's ignoring the issue that not everyone is fluent in English.

That said, though, I do find Python a lot easier for reading other
people's code in. A LOT easier.

Chris Angelico

 

[John Bokma]

Yes, I believe that was Perl. And an amusing quote. But most of the
point of it comes from the fact that Perl uses punctuation for most of
its keywords,

For example?

whereas (say) Python uses English words; it's a lot more
fun to crunch something down when you can use $|

That's not a keyword but a special (global) variable. On top of that,
you don't have to use it [1] and most people most likely encounter this in
(badly) written CGI scripts originating in the last century.

Okay, poor example. But there's a lot of Perl that uses concise
notation for things that in Python are keyworded; for instance,
regular expressions.

Perl does have indeed operators for matching and substitution. It's:

( my $foo = $bar ) =~ s/ ... / ... /;

versus

foo = re.sub(r" ... ", " ... ", bar )

and:

my $foo = qr/

....

/xi;

versus:

foo = re.compile(r"""

....

""", re.IGNORECASE|re.VERBOSE)

It's just a matter of taste IMO. The regular expression noise stays the
same ;-).

That's at a completely different precedence level, isn't it?

Yes, /but/ in this case it doesn't matter. Of course there are cases
that it /does/ matter:

For instance:

$a = $b && $c ? $e : $f;
# versus
$a = $b and $c ? $e : $f;

The first one is an assignment to $a, conditional on two variables.
The second is an unconditional assignment to $a, and then based on
that, evaluates either $e or $f and does nothing with it.

Python:
a = e if b and c else f

Yes, "recently" added to the language, before that you had to and or
your way out of it (or use lambdas).

It's pretty similar, actually (although, coming from a C background, I
do prefer to have the condition first); but I could crunch the first
one down a lot, while the last one is almost as tight as it can be.

$a=$b&&$c?$e:$f;
a=e if b and c else f

It's that crunched appearance that makes Perl look like line noise,

So you just agree with what I earlier wrote: one /can/ write harder to
read in Perl, like you can jump off a cliff. And I have seen a lot of
extremely badly written Perl code, but never seen a disaster like the
one above ;-).

and the open keyworded appearance that makes Python look like
pseudocode. But that's not necessarily a good thing; a courteous
programmer can space out Perl to keep it readable, and he then has the
option of crunching pieces that are 'logically one' and spacing out
the parts that aren't:

$a= $b&&$c ? $e : $f;

Silly, contrived example, but in production code I've often had
situations where it makes sense to space out one part of an expression
and crunch another. And when everything's an English word, that's not
an available option.

I would write it like

$a = ( $b and $c ) ? $e : $f;

That said, though, I do find Python a lot easier for reading other
people's code in. A LOT easier.

Like I wrote earlier: I find Perl easier to read. And honestly, I don't
know why. Partially it might have a lot to do with having been exposed
to it much more. But many years back, when I could pick between several
languages, Perl was the one that stuck with me. And that was before
everybody and his mom was hacking CGI scripts in Perl (badly).

And while I do want to switch to Python (or use it more often), for one
reason or another it's hard. Maybe it's for similar reasons that one
loves Spanish but hates German as a second language (or vice versa)?

Both Perl and Python are evolving. Perl has a lot of bagage from the
beginning, and more so since a lot got slapped on later on. Things are
changing, but you just can't make major changes since people, like me I
guess, are used to how things are right now.

I now and then have peeks at Perl 6 and each time my first reaction is:
this is Perl only in name; it's very, very different. On the other hand
it still shares what I consider warts with Perl 5.

 

[Dennis Lee Bieber]

My point was that even proponents of the language can make a
significant error based on the way the variable is named. It's like
the old Fortran IV that I first learned where the name of the variable
determined whether it was an integer or a floating point.

Only if one didn't declare the type ahead of time...

And even then it wasn't that hard to remember (using a non-PC
mnemonic): Indian's are integer (variables starting I to N inclusive
were integers)

 

[Thorsten Kampe]

* Chris Angelico (Wed, 25 May 2011 08:01:38 +1000)

One of my favorite quotes (not sure if it was about Perl or APL) is "I
refuse to use a programming language where the proponents of it stick
snippets under each other's nose and say 'I bet you can't guess what
this does.'"

Yes, I believe that was Perl. And an amusing quote. But most of the
point of it comes from the fact that Perl uses punctuation for most of
its keywords, whereas (say) Python uses English words; it's a lot more
fun to crunch something down when you can use $| and friends than when
you have to put "x and y", complete with spaces, for a simple boolean.
But that says nothing about which language is actually better for
working with... [...]

It does say something about readibility. And yes, "readability counts".
And yes, readability says a lot about how good a language is for reading
and working with.

Thorsten

 

[Roy Smith]

Only if one didn't declare the type ahead of time...

And even then it wasn't that hard to remember (using a non-PC
mnemonic): Indian's are integer (variables starting I to N inclusive
were integers)

Remembering that I, J, K, L, M, and N were integer was trivial if you
came from a math background. And, of course, Fortran was all about
math, so that was natural. Those letters are commonly used for integers
in formulae. If I write $ x sub i $, anybody who knows math would
immediately assume that the range of x was reals and the range of i was
integers.

 

[Chris Angelico]

Remembering that I, J, K, L, M, and N were integer was trivial if you
came from a math background.  And, of course, Fortran was all about
math, so that was natural.  Those letters are commonly used for integers
in formulae.  If I write $ x sub i $, anybody who knows math would
immediately assume that the range of x was reals and the range of i was
integers.

When I studied maths, x and y were reals, and i wasn't. But it wasn't
integer either...

Chris Angelico

 

[John Bokma]

* Chris Angelico (Wed, 25 May 2011 08:01:38 +1000)

One of my favorite quotes (not sure if it was about Perl or APL) is "I
refuse to use a programming language where the proponents of it stick
snippets under each other's nose and say 'I bet you can't guess what
this does.'"

Yes, I believe that was Perl. And an amusing quote. But most of the
point of it comes from the fact that Perl uses punctuation for most of
its keywords, whereas (say) Python uses English words; it's a lot more
fun to crunch something down when you can use $| and friends than when
you have to put "x and y", complete with spaces, for a simple boolean.
But that says nothing about which language is actually better for
working with... [...]

It does say something about readibility. And yes, "readability counts".
And yes, readability says a lot about how good a language is for reading
and working with.

To people used to the latin alphabet languages using a different script
are unreadable. So readability has a lot to do with what one is used
to. Like I already stated before: if Python is really so much better
than Python readability wise, why do I have such a hard time dropping
Perl and moving on?

 

[Roy Smith]

When I studied maths, x and y were reals, and i wasn't. But it wasn't
integer either...

I was talking of i in the context of a variable, not as a constant. If
I write $ 3 + 7i $ in one place and $ x sub i $ in another, most people
will figure out from the context which is which.

 

[D'Arcy J.M. Cain]

Remembering that I, J, K, L, M, and N were integer was trivial if you
came from a math background. And, of course, Fortran was all about

The easiest way to remember was that the first two letters of INteger
gave you the range.

 

[Chris Angelico]

The easiest way to remember was that the first two letters of INteger
gave you the range.

G for Green and R for Right, which are the first two letters of Green.

(I wonder how many Pythonistas are familiar with that?)

Chris Angelico

 

[Steven D'Aprano]

The easiest way to remember was that the first two letters of INteger
gave you the range.

Huh. I never knew that. I just learned from use that I, J, K, M and N
were traditionally integers. I never used L for an integer variable, and
don't know anyone who does.

I for integer is obvious. If you need a second one, you use the next
letter J, and if you need a third, the one after that, K. If you need
four, you're probably doing something wrong.

Likewise, N for number (as in, *counting* number). If you need two, using
N and O is stupid, because O can be confused with 0, so you go backwards
and use M.

However, using P and Q for integers is merely arbitrary convention.

 

[Matty Sarro]

I hate using L for anything, namely because if you type it lowercase
you always have to wonder if its an l or a 1 in a terminal window.
-Matthew

 

[Terry Reedy]

to. Like I already stated before: if Python is really so much better
than Python readability wise, why do I have such a hard time dropping
Perl and moving on?

[you meant 'than Perl'] You are one of the people whose brain fits Perl
(or vice versa) better than most. So enjoy it. Ignore anyone who says
otherwise.

 

[Ethan Furman]

to. Like I already stated before: if Python is really so much better
than Python readability wise, why do I have such a hard time dropping
Perl and moving on?

[you meant 'than Perl'] You are one of the people whose brain fits Perl
(or vice versa) better than most. So enjoy it. Ignore anyone who says
otherwise.

+1

If everybody's brain worked the same, we wouldn't have so many different
languages to choose from.

~Ethan~

 

[John Bokma]

to. Like I already stated before: if Python is really so much better
than Python readability wise, why do I have such a hard time dropping
Perl and moving on?

[you meant 'than Perl'] You are one of the people whose brain fits
Perl (or vice versa) better than most. So enjoy it. Ignore anyone
who says otherwise.

+1

If everybody's brain worked the same, we wouldn't have so many
different languages to choose from.

So, this means that in general language readability is not as clear cut
as some seem to advertise ;-).

 

[Matty Sarro]

On 5/25/2011 8:01 AM, John Bokma wrote:

to. Like I already stated before: if Python is really so much better
than Python readability wise, why do I have such a hard time dropping
Perl and moving on?

[you meant 'than Perl'] You are one of the people whose brain fits
Perl (or vice versa) better than most. So enjoy it. Ignore anyone
who says otherwise.

+1

If everybody's brain worked the same, we wouldn't have so many
different languages to choose from.

So, this means that in general language readability is not as clear cut
as some seem to advertise ;-).

--
John Bokma                                                              j3b

Blog: http://johnbokma.com/        Perl Consultancy: http://castleamber.com/
Perl for books:    http://johnbokma.com/perl/help-in-exchange-for-books.html

General readability is a farce. If it was true we would only have one
section to the library. Different people enjoy reading, and can
comprehend better in different ways. THat's why some people are super
verbose - hell, just look at this here post!

 

[thegist]

On 5/24/2011 1:39 PM, D'Arcy J.M. Cain wrote:
[snip]

One of my favorite quotes (not sure if it was about Perl or APL) is "I
refuse to use a programming language where the proponents of it stick
snippets under each other's nose and say 'I bet you can't guess what
this does.'"

I dunno. That sounds about like how most programming course
exams are written, no?
The point is that puzzling through arcane bits of code are crucial to
learning
any language. It's a valuable exercise.

 

[Steven D'Aprano]

if Python is really so much better than Python [Perl]
readability wise, why do I have such a hard time dropping
Perl and moving on?

My guess is that you have an adversarial view of computer languages,
therefore after investing so much time and energy and, most importantly,
self-image into becoming a Perl programmer, dropping it and moving on
would be tantamount to admitting to yourself that you were "wrong" to
have wasted so many years on the wrong language.

Whether it is objectively "wrong" or not rarely enters into these things.

That *you personally* can't or won't let go of Perl says nothing about
the relative readability of Perl and Python code.

 

[Steven D'Aprano]

When I first looked at assembly language it looked like random junk left
behind in memory. When I first looked at COBOL it looked like ... COBOL.
Doesn't make either of them better or worse.

Er, yes it does.

Writing code is primarily for *human readers*. Once you've compiled the
code once, the computer never need look at it again, but human being come
back to read it over and over again, to learn from it, or for
maintenance. We rightfully value our own time and convenience as more
valuable than that of the computer's, which is why we use programming
languages at all, instead of having custom-made hardware built for every
task we want the computer to do:

"I have to rename a file before August 2015, but the rename itself needs
to be done in under a picosecond. Know any bespoke chip manufacturers who
do small runs?"

From that perspective, COBOL is an improvement on assembly, which is why
there are probably still more COBOL programmers around than people who
work exclusively on assembly.

Sometimes we compromise, or even subvert, that trade-off: for speed
critical code where we do care more about the computer's time than our
own, or for esoteric languages designed to be as hard to read as
possible. My personal favourites, Oook and Whitespace.

But generally, people spend more time reading code than writing it,
therefore we should weigh "ease of reading" higher than "ease of
writing". (My guess is, the weights should be about 5:1.)

Pseudo-code is not a viable language for a computer to parse,

Only because "pseudo-code" implies that the code is ambiguous or
otherwise cannot be parsed. If it could be, it wouldn't be *pseudo*, it
would be real code (possibly for some compiler that hasn't been written
yet).

but it's a
good language for scribbling down comments in. That doesn't necessarily
mean that a programming language that's "closer to" pseudo-code is good.

That depends on the nature of pseudo-code. "Pseudo-assembly" has all the
disadvantages of assembly with none of the advantages, i.e. it doesn't
actually work. So in that sense, pseudo-code is not necessarily a good
thing nor a bad thing.

But in general conversation, pseudo-code is usually implied to mean that
the language is as close to human language as you can make it, while
still be parsable by a compiler.

And verbosity doesn't necessarily equate to quality; for instance, when
I'm working in both Python and PHP, I find it FAR tidier to use Python's
{1:2,3:4] notation than PHP's array(1=>2,3=>4) - but on the flip side, I
would prefer to have program structure defined by keywords like "if" and
"while" than obscure random line noise. (Fortunately, most sane
languages do indeed use keywords there.)

True. That's one of the limitations of the xtalk family of languages
derived from Apple's (defunct) Hypertalk: it's awfully verbose, which is
good for newbies but not quite so good for experts.

 

[Steven D'Aprano]

On 5/24/2011 1:39 PM, D'Arcy J.M. Cain wrote: [snip]

One of my favorite quotes (not sure if it was about Perl or APL) is "I
refuse to use a programming language where the proponents of it stick
snippets under each other's nose and say 'I bet you can't guess what
this does.'"

I dunno. That sounds about like how most programming course exams are
written, no?
The point is that puzzling through arcane bits of code are crucial to
learning
any language. It's a valuable exercise.

You seem to miss the point that a good language shouldn't make it
possible to write arcane code that needs to be puzzled out.

Although in fairness, what's arcane to me might be straightforward to
you... and vice versa.

In that sense, there probably aren't any "good languages", because it is
impractical to have a language that cannot be obfuscated in any way.
Nevertheless, we can distinguish "less good" from "more good" in
languages in the sense of readability. The fact that some languages not
just allow such obfuscation but encourage it makes the language great for
puzzles but not so good for when you actually want to get work done and
have to deal with code written by someone else. *Especially* if they're
significantly smarter, or dumber, than you.

Worst of all is dealing with code written by somebody who *thinks*
they're smarter but is actually dumber.