Python or PHP?

John Bokma postmaster at castleamber.com
Sat Apr 23 23:03:30 EDT 2005


Mike Meyer wrote:

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

That's weird, since some can differ between versions of Perl like for 
example a map in a void context. And I am sure Python has now and then 
improvements which make one operation suddenly 10% faster in a new 
version.

So it tells you a lot about the people providing the position ;-)

>>> Having only one obvious way
>> I doubt that too ;-)
> 
> Try programming in older Python for a while. You'll quit doubting it.

Again I doubt that. I doubt that if I give 100 old Python programmers a 
certain computer science problem I will see 100 exactly the same 
solutions, which when benchmarked run equally fast.

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

Do you have references to this? I would love to see if indeed 100 Python 
programmers do implement, say 5 CS tasks faster compared to 100 Perl 
programmers, on average.

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

Nope. I think I copied 3 examples and had a peek at it. I did read the 
tutorial (twice) and am rereading Dive into Python.

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

Why are those time critical parts not written in Python ;-)

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

I know to little about Python, especially about old Python, to have an 
idea of what you mean. I only saw, quite recently, someones solution to 
a problem that used 30 lines of Python, and I am sure I could have 
written it in 3-4. And I doubt that's because he was using, or I was 
thinking in, new Python
:-D.

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

After 5 years one gets comfortable with most constructions in a 
language. I am more often uncomfortable with the way someone translates 
a problem into code. And there is no way how you can force people with a 
language that is, to do that the same, not even close.

> My Perl evolved from very shell script like (lots of
> backticks and passing around the full text of files)

I am sure you can do that with Python too.

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

Yup, in Perl one should program Perl, not bash, not C. Same for Python.

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



More information about the Python-list mailing list