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