Python or PHP?

[John Bokma]

Mike Meyer wrote:

> John Bokma <john at castleamber.com> writes:

>> You already showed code like:
> 
> Actually, I never showed you this code.

hence *like*, and yes you did, in a footnote.

> In this case, the good rewrite invokes the well-known logical operator
> "not":
> 
> if not condition then
>    something

unless condition then
    	something

Weird, we use constructions like that in normal language all the time, 
and when we program it's suddenly bloat?

>>>> it makes the code more readable.
>>> Then why do most Perl programmers consider unless "! a good idea"?
>> Reread the last part of the last sentence you quoted above.
> 
> I can't - in being argumentative, you neglected to include it.

*sigh* in your obsession to call me argumentative, your skipped over it:
"it makes the code more readable"

>> wasn't creating some silly list. The etc was a giveaway.
> 
> Um, I suggest you brust up on your English skills.
                    ^^^^^

> What you created was a list. Not in Python or Perl, but in English.

I doubt if any Perl programmer in the given context would have any 
problem with it, but lets drop it.

> Oh, I understood it.

Sure, is that why you talked about a tuple? But, lets drop it.

> And so far, I've only said *two* things were wrong with Perl. One is
> that it provides more than one way to do things - which point you've
> made for me by arguing about how you did/didn't choose the right one
> in an example.

If you think I gave a wrong example, give the right one. The only reason 
for an argument was your lack of knowledge about split and map, which 
only tells something about you, not Perl.

> I also said that it's failure to flag assigning the
> output of map/grep (there's that multiple choices thing again)

There is that lack of understanding again: map and grep are two 
different things. I can't help if you consider map/grep a *choice*

> to a
> scalar when you wanted a list was bad. You haven't argued that I was
> wrong about Perl in either case.

*sigh* if you want a list, you assign it to something that can handle a 
list. If you assing a list to a scalar, you get the count. So if you 
want to select items out of a list on a criteria, you use grep in a list 
context, if you want to count the items, guess...

>> Amazing, how can you debug if you know next to nothing of it?
> 
> So either your assessment of my skills is *way* off, or I'm an
> *amazing* programmer.

If you consider map/grep a multiple choice, what do you think? 
(rethorical question).

>> It's also a restriction. Why do you think in Java one can call the gc
>> explicitly?
> 
> If it's a restriction, there must be something it restricts you from
> doing. Care to tell me exactly what garbage collection keeps you from
> doing?

real time guaranteed memory allocation/deallocation (which might be 
fixed by now in Java)

>> In my case it saves time the other way around, I consider correct
>> usage trivial, but the typing all the time...
> 
> I guess you haven't had to chase many bugs related to missing free's

In my own code? I can't remember. In code written by other people: in 
the cases they forget to free memory they did so many other things wrong 
that I sincerly hope they have found other work by now.

> skilled programmers, and makes wrong choices painful. TMTOWTDI makes
> wrong choices - or ugly code - easy.

Especially if one keeps mixing up map and grep :-D

> Which is one of the reasons that
> multiple nearly identical constructs is a bad design.

Worse is when self proclaimed perl programmers call map and grep 
identical constructs...

> So the jvm implementations you're familiar with have really bad
> garbage collectors.

I have no idea if this has changed recently. The last thing I read about 
it is that there are 4 kinds of garbage collection one can select in 
Sun's implementation.

> A good programmer won't immediately abandon either
> Java or garbage collection. They'd check out other implementations of
> the jvm to see if one of those has a better garbage collector.

Uhm, people often pick Java because of write once, run everywhere. So 
that is not always, or even rarely an option.

> another. There are probably others as well. You can't simply tag one
> as "better" without knowing what the problem domain is.

I didn't say better, what I meant: there are situations real time 
free/alloc is prefered, unless my knowledge of gc in general is 
outdated.

>> I haven't been using *foreach* for quite some time, I use *for* all
>> the time. Which is just because I am lazy.
> 
> You make my case for me. You write in a subset of Perl that excludes
> "foreach". Is that the "absolute beginner" or the "beginner" subet?
> Or maybe it's a subset that doesn't depend on the skill level of the
> programmer.

"The foreach keyword is just a synonym for the for keyword, so you can 
 just use foreach and for interchangeably, whichever you think is more 
 readable in a given situation" (Programming Perl, 3rd edition, p118)

>> You used Perl 3!?? LOL! For what? To write poetry? I mean, if you
>> used version 3, and you still make extremely basic mistakes...
> 
> No, I wrote systems adminstration utilities in Perl 3. I wrote web
> application in Perl 4. I just maintain Perl 5. Your "basic mistakes"
> was forgetting the warts on strip. BFD.

The BFD was calling map / grep a *choice*. I am not sure about for and 
foreach, it could be that you call for $item ( @list ) a foreach loop, 
which I hope. Otherwise, if you really thought there where two 
*different* loop ops (as you wrote) then there is another BFD to add.

>>> 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?
>> Neither, and think about that for some time.
> 
> So you write all your code yourself,

Ok, let me rephrase that: think about that for a long time.

>> So you got stuck with Perl 3 somehow?
> 
> I got stuck with the latest version of Perl that was available. It was
> a major improvement over shell scripts. That's not saying a lot, even
> today - and shell scripting has improved since then.

Perl 1.0?

>>> 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.
>> But to me, you don't sound qualified to make that statement, your
>> Perl skills are, well, rusty.
> 
> Ok, ask in both groups. See how many people you find that maintain
> both who feel that each is better. I'm positive you'll find the
> majority who do both find Python programs more maintainable.

I just did (asking). And hope to be able to answer your question in a 
year or so. Oh, and I want to add to your latter sentence: code written 
by programmers who didn't learn Perl in 3 hours by downloading and 
editing CGI scripts.

>>> A good programmer will compare the toolset to others he's familiar
>>> with,
>> which only can be done when he/she knows both (almost) equally well.
> 
> Nope. A quick survey of a toolset is all that's needed to make a first
> approximation as to it's quality - to someone who's familiar with
> enough toolsets, anyway.

Weird: I am going study Python for at least one year. Unless you call 
that a quick survey :-D.

> A good understanding of toolset design allows you to point out flaws
> in a toolset without becoming intimately familiar with it. For
> instance, mutliple nearly identical ways to express the same construct
> is always a flaw in a toolset. Which has been the point I've been
> making the whole time.

So a hammer is a bad tool, since one can use a scewdriver...

I always wondered why an artist, like for example a painter, has so many 
nearly identical tools...

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