On Feb 3, 2005, at 00:42, Liam Clarke wrote:

I don't find it that bad. Ruby does it as well, and it's perfectly
readable. It's more or less equivalent as if condition: and
if(condition): both being valid in Python.

Yeah, but you'd never call a function foo like this-

 x = foo

in Python. It's just good to be able to say that a function always has
<some rule here>.
That improves readability (imao).

Yes. That, and the fact that you can use function pointers very easily that way. For example,
x = foo
x()
will call foo. Which is cool.


I do prefer the Python style as well. Just like variable naming conventions should tell you something about their nature, function calls should have something that explicitly gives them away as such.

MyClass
MY_CONSTANT
myVariable
myFunctionCall()

@mod = (1,2,3)
$mod = 3
$mod[0] = 1

Is inconsistent. Or at least, the logic behind this is not immediately
apparent to me. I'm always open to illumination on these things
however.

Yeah. As with most things in Perl, there is no way to guess it. This is actually what I hate the most about that language, and what makes it write-only.


if ( not $d eq "a" && not $d eq "c") = False for $d = "b"
if ($d ne "a" && $d ne "c") = True

This probably has to do with operator precedence. It's been lifted
from C, so chances are that && has a higher precedence than eq. Use
parentheses.

Ah... Ironic, I got misled by TMTOWTDI. I figured that if not x=="a"
and not x == "c" evaled as True in Python, and "if (not $d eq "a")"
evaled as True in Perl, that
if ( not $d eq "a" && not $d eq "c") would also eval as true.
Of course, what's even weirder to me is that
if ($d ne "a" && $d ne "c") does eval as True, as far as I can see,

'$d ne "a"' is the same as d != "a" in Python, which is the same as
'if not d == "a"', which, logically, would mean that $d ne "a" is the
same as 'if(not $d eq "a") in which case both tests should handle the
addition of an AND the same.

Again, no, because IIRC (it's been a while since I last used Perl) eq and ne are the Perl operators with the lowest precedence. In effect, your last statement is evaluated as if((not $d) eq "a").
Use == and !=, they work on strings as well. Or (and?) use parens.
Also, don't forget that Perl, like Python, uses lazy evaluation.


Once again, illumination is welcomed, as I have a finally that some
subtlety of Boolean logic is eluding me, and a 'x != a' test is
different to 'if not x == a' in a small but significant way.

Max - the foo > std.txt thing explains it, but what about @dude =
<FILE>, where do the brackets originate from?

I have no idea. Somehow I think it makes sense. It's one of the few things that I think make sense in Perl. Couldn't tell you why I think so, though :p


This is another issue I'm having with Perl as opposed to Python - Perl
is very much written by *nix users for *nix users, it's implementation
of *nix conventions shows, including the
`` things. Whereas (correct me if I'm wrong), but Python was written
by *nix users for everyone. Python seems very non-OS-denominational in
it's current incarnation, it may have been very *nix orientated prior.

Not really. The thing is, Python in itself does very little. You have to import modules whenever you want to do something that involves the system (aside from file operations). That's an advantage IMO, since the default modules are quite good and allow for some nice cross-platform capabilities.
However, if the redirection operators and pipes are what make you think that way, you should know that MS-DOS (and WinNT's DOS shell) does handle pipes and redirection. Perhaps not as powerfully as *NIX, but it does.


(however, I would appreciate it if the Python standard distribution came with a "real" XML parser, 'cause DOM and SAX just plain suck -- by the way, thanks guys, I tried dom4j on my Java project and it changed my life)

So here comes me, the guy who installed Linux once, failed to see the
big deal and uninstalled it. Up until 3 months ago, my comp was used
for gaming, pure and simple, me being a certified Day of Defeat freak,
and so Windows has always best served my purpose.

Now, I want to programme, so I have to learn Unix conventions to use a
crossplatform language!  It's like asking *nix users to sign a
Microsoft EULA!! (Well, not as bad, but still as anathemic.)

Well, in Perl's defense, Windows does implement a fairly large part of the POSIX standard.
And believe me. I'm a UNIX user (Mac OS X is my primary OS, but I also use Windows and Linux on a fairly regular basis). Perl doesn't make any more sense to me than when I was still a Windows-only guy.


How's Ruby? I bookmarked the homepage, but never got around to looking at it.

Very, very nice. Cleanest object-orientedness I ever saw in a language (not that I have that much experience -- people like Alan would probably be better judges than me on this).
I find it more elegant than Python, however I end up using Python anyway because Ruby has a huge flaw: it's Japanese (AFAIK it's also the only "Made in Japan" programming language, apart from stuff like ASM 68K), and so is a large part of its community. As such, English language documentation is flaky at best.
And as far as I know there is no [EMAIL PROTECTED] Which, as you will probably agree, sucks.


Oh, and I will say this - Perl > Java (and that's an inequality test,
not a redirection of output)

I'll have to disagree with you there, unless vi/emacs is the only IDE you have access to (did I ever tell you about Eclipse?), and perhaps even then.
From what I remember, if you're programming in an object-oriented style (which I now tend do by default unless there is a painfully obvious and optimal solution in procedural style), Perl is the ugliest thing ever created since Visual Basic. Last time I checked, its OOness was frighteningly ugly. Java was built as an OO language from the ground up, if you except the presence of the basic C types. As such, it is very clean, although it clearly lacks the elegance of Python (then again, what to say of Perl?).
Java code always makes sense when you read it (and in the worst-case, when you have access to the API documentation, which is available as long as you have Internet access). Sure, it requires a lot of typing (in both meanings of the word), but it's rarely -- if ever -- ambiguous.


Also, Java has the added advantage of being very easy to learn: I learned it in 1 week 4 months ago (doesn't beat Python's record, though: I was doing useful stuff with it within 24 hours of learning about its existence), and now feel confident enough with it to do just about anything. Of course, my C/C++ programming experience probably helped me a lot with this.
In my opinion, Java has only 2 big flaws:
1) The Java Virtual Machine is a horrible resource hog. Sure, your program runs quite fast, but unless you've got multiple CPUs the responsiveness of your machine goes *down* (especially noticeable on machines with slow CPUs such as the G4 867 with which I'm typing this right now).
2) Sun didn't ever encourage anyone to write [insert language here]�compilers that compiled to JVM bytecode. The JVM was supposed to run Java code and nothing else. That's stupid. Microsoft got it right with .NET; Sun should have thought of it at least 5 years ago.



-- Max
maxnoel_fr at yahoo dot fr -- ICQ #85274019
"Look at you hacker... A pathetic creature of meat and bone, panting and sweating as you run through my corridors... How can you challenge a perfect, immortal machine?"


_______________________________________________
Tutor maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/tutor

Reply via email to