Python or PHP?

[Mike Meyer]

John Bokma <john at castleamber.com> writes:

> Mike Meyer wrote:
>
>> John Bokma <john at castleamber.com> writes:
> [ unless ]
>> Yeah - unless is a bad idea.
> LOL, because you don't like it?

Oh, come on. You say something, I agree with it, so you remove your
original comment so you can argue with me? You're just being
argumentative. Surely you can do better than that. But I'll humor you.

> You already showed code like:

Actually, I never showed you this code. You went out of your way to
make it uglier than it was.

> if condition then
>    nothing
> else
>    something
> unless IMNSHO improves readability.

Anyone can create bogus use cases to show how some random construct
can improve readability. If you show the construct to a *good*
programmer and they come up with a rewrite that doesn't need the
construct, then the construct is a bad idea.

In this case, the good rewrite invokes the well-known logical operator
"not":

if not condition then
   something

>>> 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"?
> Reread the last part of the last sentence you quoted above.

I can't - in being argumentative, you neglected to include it.

>>> *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.
> *sigh*, you asked several *stand alone* problems, from the context of 
> your question especially *you* should have been able to grasp that I 
> 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. It turned out to be
a silly list because a syntactic element of the items in the list was
identical to a syntactic element in the list, with nothing to set it
off.

>>> 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.
>
> You claimed to have some experience with perl, so I was *hoping* that 
> you at least were able to understand sort, split, and grep are perl 
> keywords. I mean, as a joke, I even almost translated your examples 
> literaly e.g.

Oh, I understood it. It just took more work than it would have if
you'd done it the other way. Ok, so you were making a joke. I'll get
around to laughing at it eventually.

>> Choosing the other
>> option would have grouped the arguments, and made things clear.
> I doubt it, you are just looking everywhere for a point, there is none. 
> Your Perl skills are doubtfull to say the least. And yet you think you 
> can say how badly it is designed, and so many things are wrong with it.

If you look, you'll find the example where I chose the right
option. That will put your doubts at rest.

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. I also said that it's failure to flag assigning the
output of map/grep (there's that multiple choices thing again) to a
scalar when you wanted a list was bad. You haven't argued that I was
wrong about Perl in either case.

> To me you appear like a parrot, just repeating what you read somewhere, 
> or heard somewhere.

Nah, I seldom listen to what other people have to say about Perl - at
least since I stopped developing in it. I did read "The seven deadly
sins" page, but have mostly forgotten that.

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

>> You may be overwhelmed by any language. I'm not.
> Sure, LOL. You are so overwhelmed with Perl that you even lack the basic 
> skills, but yet nag about it a lot.

At this point, I'm *underwhelmed* with Perl. And let's see - less than
one conversation a year for the past nine years. Yeah, that's nagging
about it a lot. I'd say both your assessments were equally accurate.

>>> In a pure language such things are in the library.
>> So, where's the ARM assemblly library that includes dictionaries?
> I don't have access to a small one I wrote ages ago. But I am sure there 
> are enough people who can provide you with one, or otherwise, as a 
> skilled programmer, you would be able to write one in a day or less.

In other words, I have to write in a dialect of the language. As I'm
sure you're aware by now, that's a sign of bad language design. No
thanks.

>> You keep harping on restrictions. Garbage collection isn't a
>> restriction. It's a feature.
> 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?

>>> 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.
> 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
(though those have gotten easier to find with modern free/alloc tools)
or a reference through a free'd pointer. I can type free(mem) an awful
lot of times in the time it takes to read through the stack trace from
the first crash related to one of those bugs.

>> 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?
> Who are "the programmers" to you? And what is a bad choice?

The programmers in this case are the people who write code in the
language under discussion. A bad choice is the one that skilled coders
don't make. TOOWTDI makes the right choice obvious to even the least
skilled programmers, and makes wrong choices painful. TMTOWTDI makes
wrong choices - or ugly code - easy. Which is one of the reasons that
multiple nearly identical constructs is a bad design.

>> That's as silly as a language having garbage collection
>> and alloc/free. Good programmers won't use the latter.
> Good programmers in your opinion. A really good programmer would use 
> alloc/free, if garbage collection works as it does with Java, in those 
> cases it's better.

So the jvm implementations you're familiar with have really bad
garbage collectors. 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. Failing
that, they'd check out other languages to see if one of them might
have a garbage collector that will perform adequately to the problem
at hand - assuming such is politically feasible. After that, they'd
begin to consider alternatives to garbage collection. Explicit
alloc/free is one possibility. A stack-based allocation scheme is
another. There are probably others as well. You can't simply tag one
as "better" without knowing what the problem domain is.

>>> 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.
> I have no idea. Which modules do you miss in Perl that come with Python?

I already pointed out some modules that come with Python that Perl (as
installed by my system packaging system) doesn't come with.  A quick
check shows that it still doesn't come with mail-handling modules -
parsing mailboxes, parsing mail messages, and sending mail via smtp. I
tend to use those on a regular basis. I'm sure I can find them in CPAN
if I really need them, though.

>>>> 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
> So instead of the ability to install a Perl module with just a few lines 
> of typing, one has to eh... what? Use google? Ask around?

Personally, I check PyPI, and a few other sites. Google helps at
times. If all else fails, I ask on c.l.python.

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

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

>>>>>> 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?
> Neither, and think about that for some time.

So you write all your code yourself, and don't avail yourself of Perls
best feature - CPAN?

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

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

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

>> 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.
> without a good understanding of the other toolset, yup.

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.

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