Python or PHP?

[John Bokma]

Mike Meyer wrote:

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

your footnote:
"
*) I still remember seeing FORTRAN programmers writing ALGOL-W
conditionals as:

             if not condition then
             else
                begin
                code
                end
"

mine purposely uglified version:

"
if condition then
   nothing
else
   something
"

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

I, and I am sure I am not alone, consider unless not just bloat. To me 
it serves a purpose: "communicate algorithms clearly" :-)

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

Ok, again:

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

( sort @alist, split ' ', $astring, grep criteria, @list, etc )
"

I skip over your "grep is wrong, should be map", and "split is also 
wrong":

The most funniest reply I ever read:

"
You also chose the wrong way to do things globally, by leaving off the
optional parens on the function invocations. That makes the list a
PITA to parse, in that you have to know the number of arguments to
each function in order to parse the list you provided.

Consider the python version:

         (alist.sort(), astring.split(), [x for x in alist if criteria
(x)])
"

I mean, that last part is extremely weird, I mean, in your original 
question you use ; to separate each question: how does Python parse 
that? Really Mike, give it up: you gave a few problems, I answered a 
few, everyone could have seen that I separated each solution with a 
comma, (almost each keyword is a dead giveaway since they match the word 
in your original question). And you are suddenly saying that the way I 
decided to write my answer says something about Perl? How much rope do 
you need?

Moreover, in your reply you clearly showed that you mixed up map and 
grep. Those are quite fundemental building blocks in perl, it's like 
mixing up an array with a hash. 

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

So you have been assimilated by the borg then? And do you think one 
can't write a parser that is able to correctly parse my reply? I give 
you a hint:

if a comma is followed by a keyword (bareword), it's a new statement. 
etc is a no-op statement. Or should my answer be pure Perl? Is your 
group of problems pure python? Perl?

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

If you can't distinguish map from grep, have problems with split (and 
maybe even white space), and have parsing problems (e.g. see a Perl list 
where there is none), it's going to be a bit hard, don't you think?

>> real time guaranteed memory allocation/deallocation (which might be 
>> fixed by now in Java)
> 
> That's an implementation feature, not a language feature.

*sigh*

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

That depends on the platform, of course.

[ memory allocation and freeing bugs ]
> I'd say you've never done anything but trivial

For someone who claims to maintain perl code but mixes up grep and map, 
and seems to have a hard time at understanding Perl in general, this is 
quite a bold statement, to say the least.

> Righ - you once again avoid the real issue.

The real issue seems to be your *lack* of Perl skills.

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

If your English reading skills where sufficient enough, you would have 
been able to understand from my use of the word implementation that I am 
aware of this. You want me to spell it out in Perl? Oh, no wait... >:->

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

Maybe do some research into which jvm's are available for which 
platforms, and also the problems some people have run into because "Run 
anywhere" is not that easy even if there is a jvm "anywhere". But again, 
maybe this all has recently changed.

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

Weird, I have worked on enough platforms where both are the case, if you 
know what you are doing. Maybe that's the difference ;-)

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

Coming from a Perl "maintainer" that mixes up map and grep, that's quite 
a bold statement. Even if you are right (which you are not), I doubt you 
are qualified to make such a statement.

[ for is a synonym for foreach ]
> You didn't bother refuting the point that you've created a subset of
> Perl which never uses "foreach".

And you think that someone who *did* bother to learn Perl has a problem 
with reading my for's? Is slowed down? Has to stop, think, read up the 
documentation, is confused, etc?

I recommend to buy Learning Perl. I am sure that a skilled programmer, 
as you claim to be, can finish reading it in 3 hours. Re-read it again, 
and make some notes.

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

Let's just say that I define "proficient in a language" different.

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

Ok, flawed.

>> I always wondered why an artist, like for example a painter, has so
>> many nearly identical tools...
> 
> Because they do different things with them.

Yup.

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