Python or PHP?

[John Bokma]

Mike Meyer wrote:

> John Bokma <postmaster at castleamber.com> writes:
> 
>> Mike Meyer wrote:
>>> 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
> 
> Perl's "There's more than one way to do it" attitude.

There's doesn't mean that you have to use or know them all. I think 
every language here and there more ways to do something. And at a 
broader scope, e.g. a simple algorithm, it doesn't matter that much 
anymore.

>> ( sort @alist, split ' ', $astring, grep criteria, @list, etc )
> 
> In the one case where perl provides you two ways to do things, you
> chose the one that doesn't solve the problem. You want map, not grep.

You think? Please read perldoc -f grep (and map).

If you guess extra ways, you make Perl more complicated than it is :-D.

> You also chose the wrong way to do things globally, by leaving off the
> optional parens on the function invocations. That makes the list a
> PITA to parse,

First of all, who cares? Not the programmer. But I doubt if you are 
correct; why is 

OP PARAMETER, LIST

a PITA to parse, and

OP( PARAMETER, LIST )

not? I would even say that the former is easier to parse, since there is 
no need for checking the ( and ) (and matching them).

Moreover, if it's perfectly normal to write:

1 + 4 * 7

why would

OP PARAMETER, LIST

be any problem?

> in that you have to know the number of arguments to
> each function in order to parse the list you provided.

It has been a while since I wrote a lexer, but uhm, you set up a rule?

LIST := ITEM
LIST := LIST,ITEM

(I made up the syntax, but I guess it's clear)

> Consider the python version:
> 
>          (alist.sort(), astring.split(), [x for x in alist if
>          criteria(x)])

( told you it was grep ;-) )
 
> This list can be parsed by a machine. Given proper bindings for all
> the variables, Python will turn it into a tuple.

What makes you think a machine can not parse Perl? I didn't get a Larry 
Wall with my version of Perl :-D 

> N.B.: split(' ', $astring) is wrong as well. In this case, Perl
> doesn't provide the right tool for the job; you have to build it from
> parts.

You either misread your own problem specifications, or you should read 
perldoc -f split (near the end, it starts with "As a special case," )

> And those trivial variations are enough that you chose the wrong
> ones. And you're (by your own admission) an experienced Perl
> programmer.

And you don't even come close :-D.

>> One could say (and should) that the regular expression thingy in Perl
>> is a language on its own :-)
> 
> It is. For what Perl was designed for, having that be part of the
> grammar of the language makes sense. For a general-purpose programming
> language, I'm not so sure.

Same could be said of floating point numbers, or complex numbers, or 
lists, dictionaries, etc. etc.

>> 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 don't agree. The better alternative is to look for a faster
> algorithm.

"The programmer's skills are not the issue"

> Now, I could have recoded it in C and gotten *much* faster. But then
> I'd have to deal with all the dynamically allocated objects (millions
> of them!) by hand,

weird, I let the computer do that :-D.

[ skilled Perl programmers use similar or same idioms ]

> My experience with Perl is just the opposite. Everytime I have to
> maintain Perl code, I come across a different set of idioms - with no
> obvious downside to them. You can, of course, define "skilled
> programmers" as those who use your idiom set. This makes the set of
> skilled Perl programmers very small. That few programmers are skilled
> is a downside of TMTOWTDI, as the only time I see new idioms in Python
> are newbies doing very odd things here.

If I could have a peek at the Perl code you maintained I could tell you 
(often by just seeing 3-5 lines) the status of the programmer who wrote 
it :-)

As I wrote before, I have little experience with Python (one could say I 
only read 2 books on it, and haven't written a stand alone piece of code 
myself). But I have the feeling that the percentage of badly skilled 
Perl programmers is way higher compared to Python for two reasons:

Quite some people have been "tweaking" CGI scripts
Quite some people "know" PHP, and hence consider themselves Perl 
programmers.

> part of the grammar of the language, and are a recent addition. It's
> not clear how Python should evolve with them added to the language.

More fat: so I would say: learn to live with it. I only see advantages. 
If you want a minimal set of operations, I recommend programming ARM 
assembly, and don't go beyond ARM3 :-D.

>>> 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).
> 
> I, on the other hand, feel that adding something to the language just
> because you can is a *really* bad idea.

As I said: the sugared versions of goto very likely solves all problems 
that need (or "need") a goto.

> you run into it in someone elses code. I never saw a good use case for
> goto in Python (as opposed to C, where it's clearly needed).

I can only speak for Perl, and indeed, I never used a real goto.

>> 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.
> 
> There's a difference between "making up for the understanding a
> programmer lacks" and "handicapping the programmer". Missing gotos is
> like missing explicit pointer manipulation.

Neither has ever handicapped me in any way. I remember how Sun claimed 
that their language was safe from memory leaking. I could come up with a 
simple example that leaked memory like crazy in a few seconds. Moreover, 
garbage collection gives newbies the impression that everything is 
handled automatically, and hence, they forget that other resources are 
less unforgiven, and *have to be* released.

> Carefully designed
> features added to the language (or restrictions removed from it) can
> provide the same functionality as those features, without exposing
> programmers to all the potential bugs that can occur when those
> features are used.

A beginner will find a way. A nice example is garbage collection, 
beginners think they don't have to think. And then suddenly things pop 
up like: memory leaking, how are circular references handled, and oops, 
suddenly things like weak references are needed. Add, things like 
threading, and shared resources, resources that are limited in one way 
or another and I doubt programming has become easier, or less error 
prone.

Has anyone ever did serious research to the number of bugs per 10k lines 
for several programming languages?

I remember to have read that air bags makes people drive more reckless. 
I am quite convinced the same holds for programming languages. A 
language can't cover your behind, so to speak.

> Adding something that doesn't extend the language and creates
> potential bugs is a *mistake*. You run that risk every time you add
> just another way to do something.

potential bugs is often equal to something people *think* a beginner is 
going to make.

>>> 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
> 
> I disagree. If there's not one obvious way to do things, experienced
> programmers tend to choose the one they are most comfortable with, and

and if they are not hermits, they choose the ones they see the most 
often used (unless it's Perl golf).

> will have to work out what all the others mean. This has been my
> experience with Perl and Common LISP, and from what I hear is true of
> C++ as well.

If I look at which things I have to work out the most: libraries. It 
sounds a lot like you want an extremely pure language. I almost get the 
impression that you hand code almost everything yourself. It doesn't 
matter how clean you make the language, the libraries will be fat. I 
rarely have to "work out" a piece of Perl. The "there is more than one 
way to do it" is much more about the combination of basic blocks. Perl 
is like legos. What you want sounds a lot like legos that can instead of 
round thingies to connect them uses triangles, so there is only one way 
to stack them. Oh, and you want them dull grey.

> On the other hand, my experience with languages that provide one
> obvious way to do things (Python, Scheme, Eiffel) is that experienced
> programmers tend to find that way, and beginners quickly become
> frustrated when they fight the language.

I wonder how much this has to do with how you learned Perl, and how you 
learned Python.

>>>>> 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.
> 
> No, you said "one can do that with Python", leaving the word "that"
> open to interpretation. I assumed you meant "migrate from writing sh
> to writing C", which, as I said, hasn't happened.

But it doesn't mean that one can't do ;-)

> If you meant writing sh or C in Python, try it.

You talked about "lots of backticks and passing around etc." I am sure 
one do things that are similar to backticks in Python, and also do the 
passing around thing.

> You'll find it clumsy and frustrating.

Yes, most languages make it clumsy and frustrating. Perl is a rare 
exception.

> Python wasn't *designed* to make it comfortable to
> write that way. Perl was - just a couple of more ways to do things.

But not clumsy, nor frustrating ;-) Perl is like a nice toolbox, and you 
want Python to be just one of this tools. Moreover, written on it: 
guarantee is void if used in any other way then stated in the manual.

>> 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). 
> 
> The only one of those that really matters is "changing your mind on
> certain things".

To you.

> The only way to do that is if there's more than one
> way to do those things in the first place.

yup, the number of whitespace for example. Even python lets you free in 
the number of spaces here and there ;-)

> My Perl style changed
> radically over the years. My python style has as well, but only
> because the language has changed as time passed. In the cases where a
> new construct/module hasn't been added, the idiom that was obvious
> with Python 1.4 is still the right choice with Python 2.4. With Perl,
> there's no obvious right choice,

To a newbie, nothing is obvious right, and a skilled programmer is able 
to find the obvious right choice. You make it sound like the perl 
community leaves people in the dark, and they have to find out what 
everything means and does by trial and error. As I already wrote: the 
more than one way is more often the *combination* of well known building 
blocks.

>>> 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.
> 
> Um - this sentence isn't complete. It doesn't keep those people from
> *what*?

Trying to

> A langauge can make it easy to write ugly code, or it can make it hard
> to write ugly code.

But who writes this code? The language, or the programmer? A programmer 
who writes ugly Perl code is suddenly going to be a skilled Python 
programmer? Are you serious?

> After all, "You can write FORTRAN in any
> language(*)". If I have to maintain the code, I'd *much* prefer that
> the language make it hard to write ugly code, as I'm that much less
> likely to get ugly code to maintain.

Nonsense.

> TMTOWTDI makes it easy to write
> ugly code. TOOWTDI makes it hard to write ugly code.

And the funny thing is: it shouldn't matter to a skilled programmer. And 
an unskilled programmer will make up for the TOOWTDI restriction in more 
ways than you and I can imagine.

>> 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 Perl only borrowed a lot of it's syntax from C,

You can not borrow only a lot. Where is the rest coming from?

> this wouldn't be a
> problem. But it borrows a lot of it's syntax from sh as well,

Yeah, it has to come from somewhere. So either borrow it from some well 
know "language", or make up a new syntax.  It doesn't matter either way.

> sometimes supporting both (because TMTOWTDI). If it had done one or
> the other, it would have been a better language.

In your opinion, which sounds quite restrictive.

[ new things ]
> I will agree that adding new idioms from other programming paradigms
> is a good thing (see <URL:
> http://en.wikipedia.org/wiki/Programming_paradigm >). In theory, the
> reason for that is that changing paradigms changes the set of things
> you do, so you aren't adding more ways to do things, you're adding
> more things to do.
> 
> The reality is that such changes often do introduce new ways to do
> things that already exist.

Which is no problem at all. The new way is either better, or the old 
way. One way will be picked up more. As I already stated: the more than 
one way is more the combination of basic blocks.

> There have already been threads where it's
> been argued (by others - I just read them) that this is detrimental to
> Python.

There are always language purists, who prefer a minimal set of 
statements, 1001 restrictions, and move everything to libraries. Often I 
have the idea that they don't use libraries at all, but prefer to write 
their own, pure, language.

> Right. But read <URL: http://www.python.org/peps/pep-3000.html > and
> you'll see that many of the things that are now redundant are
> scheduled to go away when we break backwards compatability. The
> philosophy is still that "There should be one-- and preferably only
> one --obvious way to do it." (from "import this"), even if we are
> drifting from that in the current implementations.

:-) I will stay tuned, since I want to add Python to my skill set.

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