Python or PHP?

[Mike Meyer]

John Bokma <john at castleamber.com> writes:

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

Yes, but *I* didn't say like, because I wanted to point out that you
had purposely uglified it.

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

If you want to program in a normal language, I recommend
COBOL. Natural languages have a different purpose than programming
languages, which are designed to communicate algorithms clearly and
concisely. In that domain, it's just 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"

Let's get the facts straight here. I may have skipped over it the
first time, but I didn't call you argumentative then. It wasn't until
you argumentative until after you deleted it that I said you were
argumentative.

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

No, let's not. It's a perfect example of why having multiple ways to
do things is a bad idea.

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

No, I talked about a tuple to point out that doing it right made
something a machine could parse properly, with no thought at all.

>> 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 already gave the right one. The one with the optional parens put
back in.

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

You still haven't argued that I'm wrong about Perl. You're arguing
about whether or not a behavior is bad, not the behavior.

Trying to argue that I'm wrong because I'm wrong about Perl's behavior
being bad would be a lot more effective if you pointed out where the
descriptions of bad behavior were incorrect.

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

That's an implementation feature, not a language feature. That's an
implementation feature, not a language feature. I might also note that
you're wrong about alloc/free, in that you don't get real time
guaranteed memory allocation/deallocation with it, either.

Care to try again?

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

I'd say you've never done anything but trivial

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

Righ - you once again avoid the real issue.

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

If you had enough experience with jvm's, you'd know that Sun's wasn't
the only one out ther.

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

Switching jvm's doesn't mean you switch away from Java. It means you
switch the implementation of the jvm that Java is running on. "Run
anywhere" has nothing to do with this.

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

Your knowledge of free/alloc is wrong. They don't guarantee real time
behavior. Nor do they guarantee memory allocations.

I'm beginning to think your programming experience is limited.

>>> 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 didn't bother refuting the point that you've created a subset of
Perl which never uses "foreach".

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

That's enough time to become proficient in a language. Which isn't
required if all you want to do is decide if it's well-designed.

>> 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 didn't say a word about bad tools.

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

Because they do different things with them. while and if are nearly
identical tools - they both have a keyword, a boolean and a block of
code. But they do different things.

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