Python or PHP?

[John Bokma]

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.

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

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

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

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

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.

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.

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

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

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

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

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

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

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.

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.

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

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

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

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

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

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

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

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

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

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

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