Python or PHP?

[John Bokma]

Mike Meyer wrote:

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

[ unless ]

> Yeah - unless is a bad idea.

LOL, because you don't like it? You already showed code like:

if condition then
   nothing
else
   something

unless IMNSHO improves readability.

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

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

>>> 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.
> 
> And what if you do something with it other than assign it to a
> variable?

Depends on what you are going to do with it. If you give it to something 
that turns the context into scalar, you get the number of items, but 
either that is what you want, or you make a mistake.

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

sort a list                           sort @alist

split a string on white space         split ' ', $astring

pull select list elements based       grep criteria, @list
on some criteria of some kind

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

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

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

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

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

> already pointed out the LISP study on garbage collection. Bounds
> checking doesn't prevent mistakes, it just makes them easier to find
> by causing an error report at the point the bug occured, instead of at
> some point in the future.

So it prevents a mistake from poping up in production code. That's 
enough for me.

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

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

>> 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.
> 
> No, unfortunately I still have to maintain Perl code.

Then I seriously would recommend you to take a few days to read, and re-
read Learning Perl. Not as a joke, but to save yourself a lot of time. 
Make notes the second pass.

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

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

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

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

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

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

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

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

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

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

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

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