Mike Meyer wrote:
> John Bokma <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
