Python or PHP?

[Mike Meyer]

John Bokma <postmaster at castleamber.com> writes:

> Mike Meyer wrote:
>
>> "Simon John" <simoninusa2001 at yahoo.co.uk> writes:
>> 
>>> I still love Perl, it's a bit of an art form, as "there's more than
>>> one way to do it", whereas Python usually only allows one way to do
>>> it, which may or may not be a better mantra....
>> 
>> The Python mantra leads to 1) less programmer overhead, and 2) faster
>> improvements in the language.
>> 
>> To be a Perl expert, you have to know which of the many ways to do
>> various things is the fasted under what conditions.
>
> Why?

One of the stated conditions for more than one Perl position I've
looked at.

>> Python programmers
>> seldom have to worry about that - there's usually only one [obvious]
>> way to do things, so you just do it that way.
>
> I doubt that :-D. I have never seen a programming language that forced
> me in such a way :-D. 

I'd say you haven't seen a lot of languages - including Python. COBOL,
Eiffel, Rexx, Scheme, APL and a few others come to mind as "there's
usually only one way to do things". Python is one of them.

As a programmer, I find this very *freeing*. I can quite worrying
about implementation minutia - just do things the obvious way - and
worry instead about the "big picture"

>> Having only one obvious way
> I doubt that too ;-)

Try programming in older Python for a while. You'll quit doubting it.

>> to do things means developers only have to
>> worry about impact on that way when making improvements, which will
>> speed them up.
> Yeah, Perl programmers are extremely slow ;-)

Nah, they aren't slow. They just have to worry about more things than
the Python developers.

>> The problem these days is that there are now multiple ways to do a
>> variety of things, because we have the "new, pythonic" way and the
>> "old, backwards-compatible way". So it's no longer clear which is the
>> fastest -
> In most cases, why worry? If speed is an issue you should probably have
> picked a different programming language in the first place (for that
> part of the code). 

You apparently haven't been programming in Python very long. If speed
is an issue, you should probably pick a different
algorithm. Well-written Python programs use the C-coded parts of
Python for the time-critical part of the code.

>> and in the case of generators versus list comprehensions,
>> it's not clear which you should be using. To bad.
> Use the one that is the easiest to read and understand by yourself.
> That's how I program Perl, and that's how I am going to program Python. 

The thing is, in Python there usually is one obvious way to do
things. That's changed in recent years as improvements have been added
without dropping the features they replaced so as not to break old
programs.

> An overloaded toolbox doesn't mean that if you have to hang a painting
> on the wall that you have to think for 6 hours which tool you should
> use. You just take the one that does the job in a way you feel
> comfortable with. I know that the Perl mantra is often misunderstood,
> but in my experience only by people who have very little experience with
> the language. 

The problem with using "the way you feel comfortable with" is that it
may not be comfortable for the maintainer - even if that's you six
months from now. My Perl evolved from very shell script like (lots of
backticks and passing around the full text of files) to one more
C-like as I used the language. That change was largely driven by
performance concerns as my understanding of the language grew.

            <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.