[Tutor] Are you allowed to shoot camels? [kinda OT]

[Max Noel]

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 tutor at ruby-lang.org. 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?"