Python or PHP?

[John Bokma]

Mike Meyer wrote:

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

Of course the same holds for Perl. I remember thing that got quite 
faster (I made up 10%), which is a map in void context. I guess it was 
done because it's quite easy to do, not because it was on top of the 
"this must be made faster" list :-)

I quickly read over http://www.xml.com/pub/a/2004/03/31/pycon.html

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

I have no idea about the number of Perl programmers v.s. Python 
programmers, but I can imagine if one wants to hire a Perl programmer 
that one goes at great length to drop the "I downloaded 7 CGI scripts, 
and managed to make them even more insecure" people.

If I had to write a Perl test, a lot of people who *call* themselves 
Perl programmers would fail :-). (I was tested once for Perl, and I was 
shown snippets from badly written source, and had to tell what certain 
things did, which is quite hard if the source is written by people 
clearly knew less of Perl than I do of Python :-) )

I guess that Python suffers less from this, but I am just a beginner 
:-).

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

And what makes you doubt it would be different with Perl? :-D

( sort @alist, split ' ', $astring, grep criteria, @list, etc )

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

The only variation I expect for the above Perl solutions is the use of 
(), and the first argument of split. However, the last one might show 
some exotic solutions :-)

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

I have no idea, since I read neither list. I have the idea that Perl is 
indeed more fat, especially since the (too big) number of built in 
stuff, that Python has in libraries (where it should be IMNSHO).

One could say (and should) that the regular expression thingy in Perl is 
a language on its own :-)

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

Agreed, I forget to write down that it was a joke. Some time ago someone 
asked that question to me, with the Python relaced with Perl. And I gave 
a similar answer. 

But you probably agree, that if speed is an issue, and the programmer's 
skills are not the issue, that the only thing one can do is code it in a 
different language (probably by another programmer).

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

My point. Moreover, most skilled Perl programmers (or at least the ones 
I know) fall back to a shared common set of idioms, which probably are 
not always the fastest one (which I consider a good thing)). So to them 
there are often obvious ways to do things. Put them together, and for 
the small problems you gave they very likely will come up with similar 
results.

So restrictions on the number of ways fails for beginners, because: life 
will find a way. And skilled programmers don't need it, because they 
somehow stick together.

> Witness the recent spate of people asking
> for "goto".

I was a witness, moreover I stated my opinion, which in short stated 
that there is nothing wrong with goto as a statement. Keeping a 
statement from a language because beginners don't understand it, and 
write bad code with it, is wrong. Moreover, every time I see some kind 
of protection in a language, I see people who consider them safe, and 
make other, equally bad (or worse) mistakes. (See my other replies in 
this thread regarding the special "protection" PHP has).

You either understand why something is bad at a given moment, or not. If 
a language must make up for the understanding a programmer lacks, 
something is very very wrong.

I doubt that Python needs a goto, since I am sure it has enough "syntax 
sugared" versions of goto to solve most, if not all things that one 
needs a goto for.

I never used goto in Perl, but I do use early return, break, continue, 
last, next. Some are called bad, because they make more then one exit 
point. There was a time I belonged to the same camp, until I discovered 
that my C code started to move off the right of the screen, and all the 
if, else, etc stuff only made it unreadable, moreover:

            }
          }
        }
      }
    }
  }
}

Didn't help either (almost each and every one needed a comment, adding 
more clutter)

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

Beginners get lost anyway, experienced programmers don't need it

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

That was not what I wrote: I am sure one can program that way in Python 
too.

> Some of the idioms have
> changed because the language has changed, but not because my
> perceptions/expectations/etc have changed.

In 9 years? I learned so much in 9 years about programming that I 
probably am ashamed to show Perl code I wrote 9 years back :-) (Even if 
I left out the Perl 4 syntax). Moreover, I think that my current Perl 
code is quite different from 3-4 years back. And no, not all is related 
to the "there are more ways to do things". I changed my mind on certain 
things (mostly style issues), learned new modules (some are really new, 
others I just didn't know about), but also: I learned new programming 
techniques, or other ways to look at a problem, and hence, write a 
different solution (but using the same idioms as 3-4 years back).

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

But again, it doesn't keep people who want to do this. And moreover, I 
think beginners are able to write even worse code, wether it provides 
sh/C support or not. Some people are extremely good at inventing their 
own syntax, and ideas of what certain things do (or don't).

Also, Perl borrows a lot of its syntax from C, which Python (as far as I 
have seen) does extremely little, if at all. So it's already easier to 
program C-like in Perl, by design, even if Perl was as "restrictive" as 
Python.

If the current direction of Python means relaxing it a bit, I personally 
think that is a good thing. Sometimes more than one way makes it 
possible to introduce a construction that's well known in another 
language, and turn it into an idiom for the "more than one way" 
language, and hence, teach "new" ideas to people.

And my quick peek at http://www.xml.com/pub/a/2004/03/31/pycon.html 
gives me the impression that the current direction of Python is to make 
such things available (for example more lazy, which I like thanks to my 
functional programming experience :-) )

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