Slashdot Mirror
White Camel Award Nominations
Idmat writes "Nominate the Perl community's unsung heroes for the first White Camel
awards. Three awards--for outstanding contributions to Perl Advocacy,
Perl User Groups, and the Perl Community--will be awarded at O'Reilly's
Perl Conference 3.0 on August 24, 1999. Nominate the folks who have
made these important non-technical contributions to Perl at
perl.com All nominations must be in by August 2.
The White Camel awards are sponsored by Perl Mongers, O'Reilly &
Associates, and sourceXchange.
See the press release for more info " Anyone want to share
their ideas?
Hear, hear, Abigail's Perl prowess is well known throughout the USENET community. :)
A small example of her handiwork, if I may:
sub A::TIESCALAR{bless\my$x=>A};package B;@q=qw/Hacker Another
Perl Just/;use overload'""'=>sub{pop @q};sub A::FETCH{bless\my
$y=>B}; tie my $shoe => 'A';print "$shoe $shoe $shoe $shoe\n";
To be fair, you should actually compare the technologies -- and not in your Prisoner Of Bill little box, either. Feel free to post, and we'll be happy to show you how underwhelming PHP is compared with dynamic Perl solutions.
Those of you who haven't seen Writing Apache Modules in C and Perl", by Dr. Dr. [he has too many degrees :-] Lincoln Stein and Doug MacEachern, really should check it out.
Now, what can Perl do that Python cannot do? I don't know what you're looking for here. There's a remarkably long list of things you can't do in python than you can do in Perl. Some of these are severe. Others are not.
- With python, the object is the way, the truth, and the light. Let no man cometh unto his data save through the object. In perl, OO is an option, not a requirement.
- With python, you cannot pass in chunks of anonymous code and access variables in that code chunk in the correct scope. That's because Python has no understanding of proper closures. Perl does.
- With python, you cannot generate C code to compile into an a.out.
- With python, the pattern matching is not tightly integrated into the language. It is merely loosely bolted on, which introduces inefficiencies and quoting clumsinesses.
- With python, class methods and object methods are treated dissimilarly. This is unclean.
- With python, you cannot access your overridden superclass's method in a portably symbolic fashion -- there's no SUPER or super().
- With python, you cannot implement a class in whatever way makes sense to you. You must use its system. That means, for example, that you cannot use a closure as an object. No big surprise, I suppose. Python never did figure out closures.
- With python, you cannot correctly garbage collect lost circular references when the interpreter thread shuts down. This makes it completely unsuitable for use in embedded applications. It fails to follow proper finalizer semantics for things it forgets about!
- With python, you cannot tie arbitrary semantics to variables and handles through the tie machanism to trigger implicit object calls.
- With python, you cannot set watch points on variables.
- With python, you cannot catch compile-time errors using function prototypes.
- With python, you cannot determine your calling context, nor behave differently dependent upon the same.
- With python, writing an eval string is a pain in the royal butt due to the insane whitespace problem.
- With python, you have significantly less control of compile-time versus run-time issues. Yes, this matters.
- With python, you have no equivalent to CPAN or the CPAN.pm module to support a system for automatatic registration, distribution, replications, and installation of 3rd-party modules.
- With python, you cannot write poetry, because of the white space issue -- again.
- With python, you have no equivalent to Apache's mod_perl.
There are doubtless many others. These are just off the top of my head. You should visit the Perl OO links I gave in a different followup so you actually know what you're talking about next time.In fact, a Perl function can dynamically determine at run time:
- the number of arguments passed to it
- the precise or abstract types of each of those arguments
- whether its return value is expected to be zero (void context), one (scalar context), or multiple values (list context).
This is virtually impossible in any other programming language. It's completely laughable in C, and even Python is lacking the cojones to do it. I don't know what you're smoking kid, but you definitely need to lay off. Your trollisms are leaking through. Let's see now:Here's another for you:
} } Yes, that was a complete program. Enjoy.You failed with the closure example because you were forced to create a whole new class just to pass a bit of code in, for God's sake. Do you really have no understanding of what lexical scoping is about, or did you just want to avoid admitting that Python is fundamentally incapable of coping with treating functions as first class citizens? That was the ugliest, least readable, most cumbersome hack I can imagine. What if you had 100 different callbacks, each of which did different things and which played with different lexically scoped variables from different scopes? Don't you see how your solution is an crufty hack, and no real solution at all? You failed.
As for the second example, I was showing you that Python is incapable of doing correct allocation on demand. Instead, you were forced to do all the dirty work the way you do it in some low-level language. Memory management is too important a task to leave up to the programmer, and too tedious a one as well. Once again, you try to present this design flaw as a feature. I'm sorry, but you're wrong.
And I don't see why you allocate hashes (`dictionaries') with braces and dereference them with brackets. The queer thing is that this:
If you're counting braces in C, Java, troff, awk, C++, Perl, Javascript or any of the rest, you're doing something fundamentally wrong. That's the computer's job. Perhaps you should try a more sophisticated editor than ed. :-) Really, balanced braces and alignment of code are the job of your editor to help you with.
When it came time for the object design, he rejected much of the C++ model. That's probably just as well, since C++ has so many oddities not found in any other language with object support. Python's model seemed sufficiently clean and appealing that, as with so many other tools and languages where Larry "cherry-picked" the coolest property from eclectic sources, he took most of the object stuff from Python.
For example, the object's self reference (the "this" pointer) coming in as the initial argument in a method call rather than as a formally defined variable comes right from Python.
Of course, we weren't really content to stop there. One difference from Python is that the class itself can serve as something of a meta-object. This has some rather nifty ramifications to this. If you're filling out a check-list of features, you'll find that Perl OO programming supports classes and objects, single and multiple inheritance, instance methods and class methods, access to overridden methods (a virtual SUPER class), constructors and destructors, operator overloading, proxy methods via autoloading, delegation, a rooted hierarchy for all objects (class UNIVERSAL), and two different levels of garbage collection.
Before you diss it too much, you should know what Perl OO is actually about. If you're looking for more information or examples on Perl OO, here are some suggestions:
I don't mean to pretend that Perl's OO doesn't have its host of issues. The biggest one is that unless you're careful in your design, one class needs to get unnaturally chummy with its parent class to avoid accidentally overriding or interfering with not just functional members (methods) but also data members (attributes).
But as Larry has said: `Concentrate on Perl's strengths, not its weaknesses.'