Python or PHP?

[Mike Meyer]

John Bokma <john at castleamber.com> writes:

> Mike Meyer wrote:
>
>> John Bokma <postmaster at castleamber.com> writes:
>>> Mike Meyer wrote:
>
> [ snip ]
>
>>> 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.
>
> Funny, quite a lot of Perl programmers consider using unless instead of 
> if ! a good idea. And if a programmer is not able to grasp the meaning 
> of unless if he sees it the first time, he should be able to look it up. 
> And if a programmer says that it burdens his mental processes, or slows 
> him down, I hope I never have to work with him/her and/or maintain 
> his/her code.

Yeah - unless is a bad idea. If that were the only such problem in
Perl, it wouldn't be a problem. Unfortnately, it's a symptom of the
design philosphy of the language.

>>>> 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.
> I must have missed it, since I didn't see it.

Um - you commented on it.

>>> 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.
> I doubt that features have been added to Perl just because. Even ones 
> that look like it, unless for example, have an excellent use, it makes 
> the code more readable.

Then why do most Perl programmers consider unless "! a good idea"? No,
things were added to Perl so there would be more than one way to do
them - which is even *worse* than adding them without a good reason.

>>>> 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.
>
> *sigh* you gave a list of problems, I replied by putting all answers on 
> one line, with () around them, and commas between them. I was not 
> constructing a tuple, or a list in Perl 

Right. You were constructing something for humans to read - and
managed to construct something that was a PITA to read. If you'd made
the oher choice, it wouldn't have been a PITA to read.

>> Actually, it's not clear the grep was right either. The return value
>> of grep (and map) isn't always the right thing.
> If you want to have a list of results and you assign it to a scalar, you 
> are doing the wrong thing.

And what if you do something with it other than assign it to a
variable?

You're right - the assignment is doing something wrong. A good
language would catch things at that point and let the programmer know
about it, so you get notified of the bug at the location of the
bug. Python doesn't do this any better, though.

> But the bottom line is: I gave you answers to all, except one, of your 
> problems, you think my set of answers is a kind of Perl list, you 
> thought the grep was plainly wrong, and I guess you are not comfortable 
> with split.

I thought your answer was a kind of list, but the syntax you chose
made it completely unclear where each item ended, because you
overloaded the "," character to seperate arguments to functions in the
list as well as to separate items in the list. Choosing the other
option would have grouped the arguments, and made things clear. And
yes, I consider the Perl split atrocious.

> And this gives me the feeling that you either haven't been using Perl 
> for over 4 years, or was never got beyond the absolute beginner level. 
> In the latter case I can imagine that you are overwhelmed by Perl. As 
> would one by any language.

I'll admit it's been a while since I did anything other than
debugging. I haven't had much call to do the things that Perl is
really good at (simple re-heavy scripts), so I haven't done much
development in it.

You may be overwhelmed by any language. I'm not. The only one that
ever overwhelmed me was Common LISP. It looks like Perl 6 would, if I
ever bothered to learn it - because it's going to be bigger than
Common LISP.


>>>>> 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.
> It fragments it in a way every programming community is fragmented: 
> absoluut beginner, beginner, junior, senior, guru. 

It also fragments along subsets of the language, which is the bad thing.

>>> ARM assembly, told you ;-)
>> 
>> That's not a coverage. Unless ARM assembly includes garbage
>> collection, dictionaries and similar things.
>
> In a pure language such things are in the library.

So, where's the ARM assemblly library that includes dictionaries?

>>> 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.
> LOL, but they will make other mistakes. Otherwise, I am really curious, 
> can you show a publication that shows that the number of bugs / 
> application is much smaller when a garbage collection language is used, 
> and one that does bounds checking?

Of course they'll make other mistakes. No programmer is perfect.  I
already pointed out the LISP study on garbage collection. Bounds
checking doesn't prevent mistakes, it just makes them easier to find
by causing an error report at the point the bug occured, instead of at
some point in the future.

>>> 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?
> Depends of course, but rephrase: we take 10 programs of C, 10 of Java, 
> each which are equal (except in the number of bugs). You think Java has 
> less?

If they have the same functionality, then yes, I think the java will
have fewer bugs, because it will have fewer lines of code.

>> 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.
> But are there now less bugs compared to a few years ago? Are, say, Java 
> programs in general more bug free? 

No, because programs do more things than they did a few years ago.

>>> 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.
> Nope, I got the impression from you that Python restricts programmers, 
> so they make less mistakes. They can't make mistakes of "whole classes", 
> but that doesn't mean they are suddenly good programmers.

Python doesn't restrict programmers. Python is one of the *least*
restrictive languages I know. It eliminates certain classes of bugs by
providing well-designed facilities in lieue of older facilities, but
that's not a restriction. And that's not a unique to Python,
either. Most modern languages share those facilities.

> If I considered garbage collection bad, I would say so. But like airbags 
> doesn't improve the driving skills of someone, so doesn't all kind of 
> restrictions turn bad programmers suddenly in good programmers.

You keep harping on restrictions. Garbage collection isn't a
restriction. It's a feature. It replaces the explicit alloc/free found
in older languages. Since good language design calls for one way to do
things, you lose the older, more bug-prone facility. After all, it now
contributes nothing to the language. No restriction at all.

As I said before, I hate restrictions. Restrictions hamper
programmers.

> Moreover, good programmers rarely need to be restricted. But I don't see 
> garbage collection as an anti-memory-leak restriction (which it can't be 
> in all cases) but as a time saver.

I think garbage collection is a time saver as well. It saves me time
hunting bugs caused by incorrect usage of the facilities it
replaced. It may save a little time in not having to write explicit
deallocation instructions, but that's trivial.

>>> 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.
> But is that because there are separate communities, or because there are 
> different skill levels? Moreover, I hope that "have to maintain" was 
> "had to maintain (some time ago)", because your Perl skills are more 
> than lacking.

No, unfortunately I still have to maintain Perl code.

Ok, so it's only the skill level of the programmers that's the cause
of the changes. So why does the language offer bad choices to the
programmers? That's as silly as a language having garbage collection
and alloc/free. Good programmers won't use the latter. Bad ones will,
just because it's there.

>>> 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?
> Which Perl? ActiveState Perl does indeed come with HTML, and XML 
> parsers, SMTP, etc, clients. Web server(s), I have no idea, haven't 
> needed a Perl webserver, I doubt it comes with AS Perl.

Sure, anyone can bundle whatever they want up as a distribution, but
that doesn't mean those things are part of the base library. The
original contention which caused your reaction was that Python came
with a larger base library than Perl does. It seems that this claim is
still true even if you use the ActiveState distribution of Perl.

>> That's odd - all the
>> packages I see seem to want to install those things from CPAN.
> Is there such a centralized place for libraries for Python?

Unfortunately, no. PyPI is the one linked to from the web site. It
doesn't have CPAN's auto-install capabilities

>>> I use either for or while. 
>> You never use the Perl foreach loop? That doesn't sound like a skilled
>> Perl programmer to me.
> I already stated you have little Perl experience. Now I have to change 
> that to *extremely* little Perl experience.
> So it seems I am right: the overwhelming effect of "many ways" is mainly 
> seen by absolute beginners, who are able to make up many ways, even if 
> there is just one or two :-D.

Are you afraid to answer the question? Do you or do you not use the
"foreach" loop in perl? Until you do, I can't know why my asking that
question makes you call my perl experience into question.

Is it because only an idiot would never use the foreach loop? I
agree. Which is why I find your claim not to use it ludicruous.

Is it because only an idiot would use the foreach loop? If so, please
back that up by telling me what's wrong with the foreach loop.

>>> 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.
> Perl 4? Even Perl 5 is almost 11 years old. Which version of Perl 5 are 
> you talking about?

Yup - I was using Perl back when it was at version 3. The currently
installed Perl is 5.8.5.

>>>> Right - Perl makes writing ugly,
>>> Nope, the programmer does that.
>> No, the programme writes the ugly code. Perl makes it easy.
> So, and who is to blame? Would you trust a programmer who can only write 
> code in a certain way because he is restricted by the langauge to do so? 

Which would you trust more - a programmer who had to unlearn all his
bad habits, or one who never had the chance to develop them?

> And do you really think his/her code would be better compared to a 
> skilled programmer?

No, I don't think it would be better. I don't think it would be as
good. I never claimed any of those things - I claimed that code
written in a TOOWTDI language is more maintainable than code written
in a TMTOWTDI 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?
> Programming, in a skilled way. There is no ultimate superior tool. Why 
> do you think I am learning Python? Because I found the holy grail? Or 
> that I just want another way to do things?

Of course there's no holy grail, just as there's no silver
bullet. However, languages can be compared as to their suitability for
an application domain, and I try to chose the superior language for
each application domain. At one point, I did a lot of work in
application domains for which Perl was a good choice. That simply
isn't true any more.

>>> 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.
> No. If this was crossposted in a Perl group, by now quite a lot of 
> people would have pointed you out, probably in a less nice way, that 
> your Perl skills are of a person who hasn't even gone beyond the first 
> few chapters of "Learning Perl". 

Oh, bullshit. I admit my perl skills are rusty - that comes from
having found a language that is superior to it across a large
collection of problem domains. I never read "Learning Perl". It didnt'
exist when I learned Perl.

Even if it is true, the point still stands - Perl programs are less
maintainable than Python programs. I maintain that the difference in
philosphy on the number of ways to do things is a cause for that.

>>> 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.
>
> And a bad programmer will go at great length explaining how bad the 
> tools are, because he has to learn them :-D

A good programmer will compare the toolset to others he's familiar
with, and choose the toolset that is best for the jobs he does. An
evangelical programmer will then spend a lot of effort explaining why
one toolset is better than another.

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