Python or PHP?

[Mike Meyer]

John Bokma <postmaster at castleamber.com> writes:

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

The things is - it doesn't matter nearly as much in Python. Since
there's only one obvious way to do most simple things, that's the one
that most programmers will choose, and that's the one the developers
will worry about making faster.

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

Yeah - they expect their people to be on top of such things. I've
never run across a Python position where knowing which of several ways
was faster was an important criterion - because there usually aren't
several ways.


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

Depends on the problem. If it's one of the things for which Python has
an obvious solution (sort a list; split a string on whitespace; pull
select list elements based on a criteria of some kind; search a file
for lines with a given word in them; etc.) you'd get back the same
answer from almost all of them.

As I've said a number of times, this has changed lately as new
features have been added without removing their older counterparts.

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

I'm talking about the people developing the language, not the ones
developing in the language. And this is just my impression from
watching the developers lists.

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

Because then they'd be slower. A good scripting environment has lots
of operations available that are coded at a low level. Since this code
is usually hand-tuned and optimized over time (like the dictionary
lookup or string operations in Python, or regular expressions in Perl
- I'm not sure about the RE library in Python), it may well be faster
than what you'd write in the low level language if you did it
yourself.

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

Just because there's only one obvious way to do things doesn't mean
it's obvious to everyone. Witness the recent spate of people asking
for "goto".

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

Of course not. The best you can do is provide one obvious way to do
things, and then hope most people find that.

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

That hasn't happened in 9 years of Python. Some of the idioms have
changed because the language has changed, but not because my
perceptions/expectations/etc have changed.

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

Right. But Perl makes it *easy* to program in bash or C while staying
in Perl, and provides no obvious drawbacks from doing so - all because
it's trying to be comfortable to sh and C programmers by providing
ways to do things that those users are comfortable with. Trying to
write sh or C in Python is painfull, and you usually run into
problems/drawbacks fairly quickly - because that's not the obvious way
to do things.

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