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:
>>>> 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.
>> Except that, as I said elsewhere, that having more than one way to do
>> it bloats the language processor
> do you really think that for / foreach and things like if / unless bloat 
> a language processor? I think you take your "pure programming lanuage" 
> way to far, and really don't understand your choice of Python in your 
> crusade.

I don't think I take it to far. All my experience dealing with
languages that took the opposite tack (i.e. - Perl and Common LISP)
demonstrate that such things are a bad idea.

Python got chosen for this discussion for two reasons. One, we're
posting in comp.lang.python. Two, part of the Python philosophy -
which you can get by doing "import this" - is:

There should be one-- and preferably only one --obvious way to do it.

>> and increases the semantic load on
>> the programmer. The best the programmer can do, as you imply, is to
>> ignore the extraneous methods.
> I am curious of a list of extraneous methods in Perl (more about the 
> size by the way)

Methods isn't a very good word choice on my part, as it has to many
meanings. But saying "extraneous ways to do it" is a bit wordy. I
already gave you one such list, covering just the syntactic elements
of the language.

>> Then the poor programmer has to puzzle
>> over them every time they show up in someone else's code.
> A poorly skilled programmer has to puzzle about a lot of more things. Or 
> you think list comprehension (sp?) and all the tricks with it are clear? 
> or the and or trick? I just had a glance on Python, but what probably to 
> you is one clear path isn't clear to me yet. And I doubt that can all be 
> blamed on unpure new Python.

Correct - newbies have to puzzle about a lot of things. A good
language design won't add to that set of things without a good
reason. Adding features because you can is adding things to puzzle
about without a good reason.

List comprehensions are part of that "new, unpure python". They
duplicate functionality that was already in the language. Of course,
they are a lot clearer than what was there, and if Python were a
research language rather than a production language, map, filter and
lambda would be gone.

>> No, one I blew. One you still got wrong.
> Which one?

Faling to put in the parens that would have distinguished the argument
lists from the list of operators.

Actually, it's not clear the grep was right either. The return value
of grep (and map) isn't always the right thing. You have to force the
return value into a list context to get the right result. Oh
well. Just one more thing for the programmer to worry about.

>>> 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 :-)
>> So you'd either say you were wrong, or that my second contention was
>> right. Either one would be a bad side effect of TMTOWTDI.
> I am right, and you are wrong ;-)

In which case, I'm right in claiming that having more than one way to
do things fragments the community - which is *still* a bad thing for
the people writing the language.

>>> Quite some people have been "tweaking" CGI scripts
>>> Quite some people "know" PHP, and hence consider themselves Perl 
>>> programmers.
>> 
>> Quite right. Neither is in the set of Perl things I maintain.
>
> Does that matter? What matters is what are the skills and background of 
> the Perl programmer who wrote the code you maintain.

They all come from different backgrounds, which is why they all use
different subsets of the language. Having a language that makes such
division of the community easy is a *bad* thing. Look at the history
of LISP to see why.

>>>> 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.
>> 
>> You could also say more bloat. It's not a good thing. I don't want a
>> minimal set of operations; I want an orthogonal 1-1 coverage of
>> operations.
>
> ARM assembly, told you ;-)

That's not a coverage. Unless ARM assembly includes garbage
collection, dictionaries and similar things.

>>> 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.
>> 
>> Other resources are less forgivving only if they are badly
>> designed.
>
> Sure, a resource outside of your program that has certain limits is 
> badly designed. Yup, a database for example.

Nope, the resource is the interface to the database. If it's
well-designed, then you won't have to worry about shutting down the
connection. It'll get shut down when it's garbage collected.

>> That means they *should* be released, but not *have to be*
>> released.
> Trust me: they *have to be* released.

Then the interface is badly designed.

>> Consider the file type in Python. It'll be closed after
>> you're through with it, guaranteed. However, garbage collection isn't
>> triggered by running out of file descriptors, so you *should* close
>> them.
> Or otherwise?

Depends on how the garbage collector is implemented. In CPython, with
reference counting, the files will get closed as soon as the
descriptor is no longer referenced, and nobody will be any the
wiser. In Jython, which used the Java garbage collector, you can run
out of file descriptors, meaning your file opens will start failing. I
have no idea what IronPython does.

You *should* close the files. There are external conditions that make
not doing so perfectly safe. For instance, you could know your code
will only be run on CPython, or you could know that it will only be
run on platforms with many file descriptors and you only use a few.

As a program maintainer, I'll tell you the conditions will almost
certainly change in ways you don't expect, and you *should* close the
files.

>>> 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.
>> 
>> Having dealt with memory leaks in C (and other such languages) for a
>> decade, I'd say programming is *much* easier than it would be if you
>> didn't have some form of garbage collection.
>
> Easier, sure. But does it turn beginners in rock solid programmers?

It means they never make errors like using free'd memory, or failing
to free allocated memory. So in that since, yes, they are rock solid.

>>> Has anyone ever did serious research to the number of bugs per 10k
>>> lines for several programming languages?
>> 
>> Yeah. The LISP community did some research on garbage collection
>> vs. explicit allocate/free a couple of decades ago. The explicit
>> allocate/free methodology was found to be noticably more bug
>> prone. Like I said, those date from a couple of decades ago, so I've
>> lost the reference and google didn't turn anything up.
>
> So they looked close at one aspect of the language. But you think that 
> 10k lines of, say Java, has less bugs then 10k lines of C?

Nah. Then again, counting lines of code is a silly thing to do. You
think 10K lines of C does as much as 10K lines of Java? The crucial
question isn't how many bugs you get per line of code, it's how many
bugs you get to achieve a given functionality. You can improve this
number by cutting down the number of bugs per line of code, or by
cutting down the number of lines of code needed to acheive a given
functionality. Modern programming environments clearly improve the
latter.

Of course, you can take terseness to far. Just ask anyone who's ever
written TECO or APL.

>>> 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.
>> 
>> Could you provide examples of what kind of behavior you're talking
>> about? What would be the analog of "driving more reckless" given that
>> I've got a garbage collector?
>
> I already gave that one: forgetting to release resources which are not 
> unlimited.

And I already pointed out that if that's a serious problem, your air
bags are poorly designed. The wrapper around the resource should hide
that problem for you. Can you come up with another one?

>>> potential bugs is often equal to something people *think* a beginner
>>> is going to make.
>> 
>> Yes, but potential bugs even more often turn up in *real*
>> programs. I've fixed enough bogus pointer/using free'd memory/memory
>> leaks in C to know that.
>
> And I am sure that you fixed enough bugs in the same *real* programs 
> that were in no way related to this. I have fixed enough bugs in Perl, 
> Java, etc, to know that "life will find a way", so to speak.

We both agree you're always going to have bugs. I think that
programming languages designed to eliminate whole classes of bugs are
good thing, because bugs are a bad thing. You seem to argue that
because we can't elimnate all bugs, we shouldn't eliminate any. That's
simply silly.

>>> and if they are not hermits, they choose the ones they see the most 
>>> often used (unless it's Perl golf).
>> 
>> Which means they adopt to their subset of the community. Which means
>> that supporting code from another community will in practice require
>> learning a new programming language that happens to have a syntax they
>> are familiar with.
>
> What makes you think there are isolated communities?

Let's see. LISP - some of the communities were MacLISP, InterLISP,
Zeta LISP, and Standard LISP. There are certainly others I
forgot. Perl - they don't have names, they just show up in the code I
have to maintain. C++ - all I have is hearsay.

>> But
>> it does try to avoid that. It also tries to come with "batteries
>> included". You can get an aweful lot done in Python without ever going
>> to third party libraries. With Perl, you wind up going to CPAN for a
>> lot of things - which puts you back into TMTOWTDI land.
> How long haven't you been in touch with Perl? 

Oh, are you claiming that PERL ships with HTML and XML parsers, SMTP
clients and web servers in the standard library? That's odd - all the
packages I see seem to want to install those things from CPAN.

>> I want programming to be the professors route. I don't want to worry
>> about which for loop to use - I want there to be just one for loop, so
>> I take that one and *get on with solving the problem*. Having multiple
>> for loops (or other TMTOWTDI things) bloats the language
>> processor/library and increases the load on the programmer to no
>> benefit.
> I use either for or while. 

You never use the Perl foreach loop? That doesn't sound like a skilled
Perl programmer to me.

>> True. The WWW was extant when I learned Python, so I could learn it by
>> reading the documention on the web site, and looking through the
>> library. Perl, on the other hand, I had to learn from the
>> documentation that shipped with it, and the library that shipped with
>> it. Come to think of it, Python has a larger library than Perl as
>> well.
> How did you measure this? And which distribution of Perl are you talking 
> about?

By looking at the functionality installed programs used from third
parties (i.e. - CPAN in recent version) vs. what they used from the
standard library. And in Perl 4 and 5.

>>> Yes, most languages make it clumsy and frustrating. Perl is a rare 
>>> exception.
>> 
>> Right - Perl makes writing ugly,
> Nope, the programmer does that.

No, the programme writes the ugly code. Perl makes it easy.

>> slow code easy. Python makes it
>> hard. I think this makes python the superior language.
>
> And I think that there is the main problem in your whole story. You 
> think this is a quest for superiority. It isn't.

What? You're not trying to find the superior tool for the application
domain? Then what *are* you doing?

> But if this all bothers you *this* much, I am afraid that the problem is 
> really behind the keyboard :-)

No, what bothers me *this* much is that every time I have to maintain
a Perl program, I have to learn somebody else's subset/idioms/etc of
the language. "All this" is the cause of that.

>>>> 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.
>> 
>> I make that claim based on experiene maintaing both Perl and Python
>> code. What basis do you have for calling it nonsense.
>
> If you are talking about maintaining your own code, maybe you are right. 
> But I claim that it's nonense that code written by other people, with 
> clearly different programming skills compared to the maintainer are a 
> PITA, no matter what language is used.

Yes, but the language influences how much of a PITA it is, and how
often it's a PITA. I prefer languages that make it less and infrequent
to languages that make it more and frequent.

>>>> 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.
>> 
>> I don't agree. It doesn't say "There's one obvious to the skilled
>> programmer way to do it." It says "There's one obvious way to do it."
>
> Yup, to pick a tool out of a organized toolbox. Which is fine if that's 
> the only job involved. Programming, or as I see it, is not about picking 
> tools out of a box, but combining them.

Right. A good language will have an obvious tool for each part of the
combination, so you don't spend time worrying about picking the right
tools - the right choices are obvious. A bad language will have more
than one tool for many parts of the combination, so you wind up
wasting time on which of n interchangable tools is the right one
instead of actually solving the problem at hand.

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