White Camel Award Nominations

Re:COBOL of the 90's by Anonymous Coward · 1999-07-06 19:12 · Score: 1

Just like COBOL before it, Perl is a disaster because it allows idiots to program. Who the hell do these people think they are?
We didn't spend tens of thousands of dollars going to university for years just so some punk idiot can take our jobs away by writing in Perl.
Leave programming for the professionals, and get these secretaries back to their word processors.
The reason there's so much terrible Perl code is because there are so many morons programming in it.
Throw it out, and you get rid of the morons. C++ is a good replacement, because that way the idiots know they can't code. Perl tricks them, and then we all pay the penalty.

Re:COBOL of the 90's by Ranger+Rick · 1999-07-06 20:43 · Score: 1

> Throw it out, and you get rid of the morons. C++
> is a good replacement, because that way the
> idiots know they can't code. Perl tricks them,
> and then we all pay the penalty.

Oooh, yeah! Why don't we get rid of cars, too? Oh, and computers in general! That'll get rid of all the idiots... :)

Really, I see no reason why I should do things the hard way just to prove myself. Perl can be impossible to read -- *IF* the person writing it doesn't know how. It can also be very clear and easy to follow.

The advantage to Perl is it's flexibility, but the same thing that allows you to do more good allows you to do more evil. :)

Perl doesn't kill programs, people do.

--

WWJD? JWRTFM!!!

What are you people smoking? Re:Hear, Hear! by gavinhall · 1999-07-06 16:07 · Score: 1

Posted by Volkadav:

I use perl fairly often, and while it can be written in a _highly_ obfuscatory manner, it is just as possible to write very clear code (c.f. English.pm to take care of the $@ phenomenon). IMHO C is a thousand times worse, and I don't see (no pun intended) anyone calling it a sinking aquatic transportation method. :^) Don't get me wrong, the times I've encountered Python I've liked it, and intend to try it more. Language debates are a little pointless in the final analysis for most of us who don't have advanced CS or Linuguistics degrees anyway... ("And just how many EBNF syntax definitions have _you_ written today, schmarty pants?! >:)")

Re:What are you people smoking? Re:Hear, Hear! by Zagadka · 1999-07-07 00:51 · Score: 1

The fact that Perl requires goofy symbols before variables depending on their type pretty well precludes the possibility of writing readable Perl code. That reminds me of that old Perl joke. "I just wrote this Perl script that does all sorts of cool stuff in only 8 characters! Actully, I could've written it in only 6, but this is more readable."

I have yet to see readable Perl code. Today, on those rare occasions when I have to write Perl, I often write it in Python first, and then convert it to Perl. The Perl code looks like the Python code would after being sent over a very noisy serial line with no error correction...

Yes, Python isn't as popular as Perl, but popularity is for Lemmings. I'll take technical superiority any day. Python gets the job done easier than Perl, and if/when bugs need to be fixed or features need to be added, I don't need to pull may hair out trying to understand an unreadable script.
Re:What are you people smoking? Re:Hear, Hear! by Zagadka · 1999-07-07 05:29 · Score: 1

That was an interesting rant. Too bad it was, for the most part, irrelevant.

As for the relevant parts:

You can readily tell at a glance what "part of speech" the identifier is functioning as. The $ for "this" versus the @ for "these" is a useful distinction that allows Perl programmers faster

Huh? Faster what?

These symbols permit static type-checking and logic errors in the compiler that would not otherwise be possible in so dynamic a language without severe reworking from the ground-up.

Is there a way to pass around an object that may be an array, or a string, or an associative array?

It is easy to perform string interpolation, as in "these $count cats".

It's also correspondingly difficult to determine what will happen to the contents of a quoted string.

Symbolic notation is often more convenient to work with than verbosely spelt out words that do the same thing.

True. I've said that myself many times. But what about using symbols when none should really be required? What about when the symbols actually inhibit certain things? I want to be able to pass around arrays and strings using the same variable. How does one do that in Perl?

...of which there are remarkably fewer new ones than in any other of the systems mentioned earlier in this article.

The true mark of the desperate: the need to compare apples and oranges. Cobol has far fewer "keywords" than virtually any natural language, I guess COBOL isn't so verbose after all...
Re:What are you people smoking? Re:Hear, Hear! by Tom+Christiansen · 1999-07-07 06:16 · Score: 2
You can readily tell at a glance what "part of speech" the identifier is functioning as. The $ for "this" versus the @ for "these" is a useful distinction that allows Perl programmers faster
Huh? Faster what?
Faster understanding of who's frobbing whom, and how.
Is there a way to pass around an object that may be an array, or a string, or an associative array?
Of course. Use a reference. Or an object. This is a win for homogeneity, but a loss at compile-time type-checking. Some of us like that kind of thing. I guess you don't.
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.

It is easy to perform string interpolation, as in "these $count cats".
It's also correspondingly difficult to determine what will happen to the contents of a quoted string.
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:
Perl: print "these $count cats"
Perl: printf "these %d cats", $count
C: printf("these %d cats", count)
Python: print "these %d cats" % count

Re:COBOL of the 90's by sql*kitten · 1999-07-06 19:38 · Score: 1

Perl is the C or maybe the Lisp of the 90's.

Actually, Perl is more like the Rexx of the '90s. Python, if we're drawing analogies not in language model but sociologically is barely even the PL/1 of the 90's.

IBM et al. fully intend to make Java the COBOL of the 00's - literally a common business oriented language. If the industry makes it the Ada of the 00's too, then so much the better (but I do very much like Ada). And I hope they succeed. COBOL itself is obsolete (even Microsfocus Object COBOL) and C++ ins't suitable for large scale projects (for many reasons, many of which are detailed in the Java white papers).

Personally, I prefer to use PL/SQL, and that's going to be the de facto business language for a good long time yet. With that and Java, I don't expect to be obsolete for the next couple of decades.

Re:COBOL of the 90's by mill · 1999-07-06 19:07 · Score: 1

I rather "count" curly braces than whitespaces, but since I let GNU Emacs take care of the "counting" for me it doesn't matter to me.

IMHO Python is close to impossible to read when on paper because of its use of indentation.

/mill

Re:Hear, Hear! by AMK · 1999-07-06 19:51 · Score: 1

Umm... Hackish OO features are a strange brickbat to throw at Perl, because Perl5's OO-features were strongly influenced by Python's, except the syntax has been Perlized (reasonably enough).

And I wish PCRE was as optimized as Perl's regex code, or that the regex code was available as a standalone library; unfortunately that seems very difficult to do, and unlikely to happen.

Re:COBOL of the 90's by AMK · 1999-07-06 20:10 · Score: 1

The trend is toward greater diversity in languages, not less -- and I don't mean languages designed for academic purposes, but languages that are actually being used. Look at the last few years: Python, Perl, and Tcl all have growing communities; Java, of course, is still to be reckoned with; in the Web-specific space we have PHP, Frontier, the various Apache modules for different languages, and there are dark horses like Guile, Dylan, or REBOL that may or may not become important. I can't think of a language that I would consider to be "dying" ("holding steady" is a different question). I know people who are turning away Python-related consulting jobs because they already have more than enough work.

When Java was first introduced, there was much excited chatter about it killing off other languages; I think Sun is still half-heartedly arguing that. Yet interpreted languages have adapted to Java quite nicely, thank you -- consider Jacl and, of course, JPython. So get used to the diversity -- it doesn't look like it'll be going away, particularly since component architectures like COM and CORBA grant a lot more flexibility in choosing a language.

Re:Python loses by AMK · 1999-07-07 07:01 · Score: 1

I'll cheerfully agree with most of Tom C.'s points on garbage collection, scoping, and the absence of super(). To correct some minor factual misstatements:

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.

Hmm? You can quite happily store your data in interwoven dictionaries, lists, and tuples if you like, and never write a single class. If you want to talk about classes being a requirement, talk about Java.

With python, you cannot generate C code to compile into an a.out.

There's a Python-to-C translator, though it seems very experimental and I'm not familiar with its status; the author claims it will handle almost all Python code, but you know what those programmers are like. Of course, you can compile Python to Java bytecodes quite nicely using JPython.

With python, the pattern matching is not tightly integrated into the language. It is merely loosely bolted on, which introduces inefficiencies and quoting clumsinesses.

True, but it also means you can leave it out if pattern matching isn't of interest to your application domain. People who want to run massive numeric simulations, build virtual environments, or run a large online role-playing game may not care about processing text. (Coincidences are funny things; while checking the third link, I went to reference.com and was startled when my search pulled up Python code on my screen -- someone forgot to make a CGI script executable, I suppose. reference.com is an application that does care about text searching, I would imagine.)

The greatest problems with regexes in Python 1.5 are:

Parts of re.py are still written in Python, not C, and are therefore slow. Fixing that is on my list for 1.6.
PCRE doesn't do a lot of optimizations and analyses. Mostly this is because the compiler doesn't build a parse tree and traverse it, but instead tries to construct a string of bytecodes in a single pass.
Unicode regexes are an open issue at this point. I've been casting longing glances at the regex engine in Mozilla, which does build a nice parse tree and supports Unicode, and hope to work on splitting it out into a separate library.

With python, you cannot determine your calling context, nor behave differently dependent upon the same.

Python doesn't have the idea of scalar/array/etc context, so I don't see the relevance.

With python, writing an eval string is a pain in the royal butt due to the insane whitespace problem.

If you're generating multiple blocks of code, then generating curly brackets and indentation are isomorphic problems; replace { with \n + indentation-level spaces, and replace '}' with newlines.

With python, you have no equivalent to Apache's mod_perl.

PyApache (don't ask me why it's not called mod_python). Zope is more interesting still.

Re:how 'bout asking why? by pudge · 1999-07-06 20:14 · Score: 1

# sourceXchange is that HP program to link up
# developers with software projects. what easier
# way to find good developers than to ask the OSS
# community?

Um, the awards are for NON-technical contributions. Maybe some really good developers will be nominated, of course, but I wouldn't think a good place to look for developers is nominees for a non-technical award.

Re:how 'bout asking why? by pudge · 1999-07-06 23:36 · Score: 1

# Does that mean we can't nominate Tom Christiansen # for his years of advocacy work just because he's
# also a technical contributor?

No. It just means that awardees will be awarded for non-technical contributions.

I nominate Rob by Red+Storm · 1999-07-06 17:53 · Score: 1

Hey what about nominating Rob, for his most amazing use of Perl to create this most amazing of sites?! Plus He makes the source available to those at large for their pearl learning.

--
---- Fight to protect your right to keep and arm bears! ummmm... ya I think that's right....

Re:COBOL of the 90's by MeerCat · 1999-07-06 17:26 · Score: 1

Hmmm, yeah, right.
So Rob and the boys are Cobol nerds eh ?

VB is the Cobol of the 90's.
Perl is the C or maybe the Lisp of the 90's. Python looks like it may end up being the Eiffel of the 90's.

--
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best

Re:We snub perl? by washort · 1999-07-06 20:49 · Score: 1

> You find that perl is often snubbed by all CS courses, for traditional imperative programming languages
> (and ofcorse the almost useless functional and declarative languages)..

*giggle* Have you ever done any programming in a functional language such as, say, Haskell? I find it to be a very elegant expression of certain algorithms. Of course it's not best for everything, but nothing is. Perl is best for text processing, and in my opinion second best for everything else (that's one of the reasons i really like Perl). Also, would you inflict Perl on someone as a first language? However, I'd agree that Perl would be a far better choice than the languages used in my last CS class (COBOL and C++). :)

Perl is a kluge, but it's the only kluge you'll ever need.

Re:Perl sucks / php3 rules by washort · 1999-07-06 20:55 · Score: 1

And what else can PHP do? Perl is a complete language, which I use almost every day for application prototyping and general scripting. Can PHP do SMTP? IRC? IPC? XML? You're being rather narrow.

Re:abigail by washort · 1999-07-06 20:24 · Score: 2

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";

Re:COBOL of the 90's by Zagadka · 1999-07-06 23:29 · Score: 1

Huh? So how do you read C code that's printed on paper? Do you count the braces, or pay attention to the indentation? I doubt it's the former, and the latter is the same as Python.

I've used both Perl and Python quite a bit. I have to say that Python code tends to be somewhat easier to write, and significantly easier to read.

I at first thought Python's "indentation == block structure" was pretty gross, but it actually makes sense. People pay attention to indentation, so it only makes sense that the computer should too.

But really, anyone who bases their conviction that Perl is better than Python because they think Python's indentation thing is "yucky" obviously hasn't taken a real look at Python, and deserves to be ignored.

I used to use Perl. Then I went and learned Python despite my reservations about it's indentation scheme. Since then, I've converted to Python. Anything Perl is good at, Python is better at. It's easier to write, and easier to read. Even before I learned Python, I found it to be easier to read than Perl. I normally don't "convert" to a language. I know more languages than I have fingers, and quite a few of them I use on a regular basis.

The only "advantage" Perl has is that it's installed on more systems than Python. That's the only reason I use Perl at all actually. When I have to write a script that will run on a machine that has Perl but not Python installed. That is (thankfully) becoming more rare.

My point is that while having C vs Java arguments (for example) are futile -- each languange has its valid uses -- Perl is essentially holding us hostage. There's no reason to use Perl, because Python is strictly better. No reason that is, except for the large installed base of Perl. I won't even mention the obvious parallel to Windows and Linux. D'oh! Looks like I just did.

Someone asked for some Python sample code. I was going to post some, but /. seems to have a bug where even stuff posted as "HTML Formatted" undergoes "entity translation". Of course, that doesn't have anything to do with the Perl code in /. being hard to maintain... right?

Re:COBOL of the 90's by Zagadka · 1999-07-07 01:20 · Score: 1

That's what I'd like to know: what can you do in Perl that you can't do in Python? My guess is nothing. As for what you can do in Python that you can't do in Perl: Python code is actually maintainable. Perl code generally isn't. And Perl makes it hard as hell to make code that even comes close to readable.

What is it that turns Linux users into crusaders against Windows?

A Challenge for Tom by Zagadka · 1999-07-07 05:48 · Score: 1

Several of the points on your list are wrong. Several others are irrelevant. What disturbs me the most is that you had to stoop to personal insults. I won't go into what that implies.

How about this: find your most readable piece of Perl code that you think can't be easily reimplemented in Python. Post it here. Nothing silly like executing chunks of Perl code allowed. It's just as hard for Perl to execute chunks of Python code.

Remember: it has to be readable code.

Re:A Challenge for Tom by Zagadka · 1999-07-08 04:56 · Score: 1

I love the way you define as "irrelevant" the things that you just can't do.

Sorry, I just don't feel the need to write poetry in a scripting language all that often.
Where's your the C code that I can generate and you can't?

I can't parse that question. Please rephrase.
How about the way you can lose objects in Python and never call their finalizers when the program exists?

I agree that the reference counting mechanism in Python is screwy. People are working to correct that. In the meantime, it's never actually been an issue in any script I've ever seen. How about the way Perl uses dynamic scoping? That's fundamentally broken too. Are there any plans to fix it?
Anyway, below are Python conversions of the code you posted.
import sys import signal def timeout( period, closure ):
signal.alarm(period) closure() # no need to comment, since this is obviously a function call signal.alarm(0)
class LineReader:

def __init__(self):
self.line = ''

def readLine(self):

self.line = sys.stdin.readline()

myLineReader = LineReader()

timeout( 30, myLineReader.readLine );

# now check line for proper contents
print myLineReader.line
Re:A Challenge for Tom by Zagadka · 1999-07-08 09:59 · Score: 1

What if you had 100 different callbacks, each of which did different things and which played with different lexically scoped variables from different scopes?

Then I'd kill myself for creating such a poorly designed system. But the "timeout" function I created above can also accept normal functions. As mentioned earlier, I did have a version that didn't use a separate class.
I notice you completely ignored my other points. I'll assume that means you couldn't think of any way to refute them.
I also find it amusing that you said you were going to give me the last word, but apparently couldn't resist the urge to post the above.
As for the second example, I was showing you that Python is incapable of doing correct allocation on demand.

That depends on what you consider to be correct. I could just as easily say that it shows Perl is incapable of doing correct runtime bounds-checking. You seem to think that "however Perl does it is the right way". As I mentioned earlier, there are advantages and disadvantages to each approach. Oh, that's right, Perl is "the way, the truth, and the light". Perl's way of doing things has to be better.
Explain to me exacty what the [] operator is doing when I say '$a[2][5][3] = 9' and a is completely uninitialized. An expression tree for the left side of that assignment would be nice. I'd like to know the type and value of each node in that tree.
Incidently, I don't like Python's "two namespace" thing, nor do I care for the fact that it uses reference counting, and hence has problems cleaning up cycles. I've also got a love/hate relationship with the whole indentation versus braces thing. I think that, for a language the uses braces for blocks, Perl at least does the right thing in requiring blocks for things like if's, loops, etc (rather that just a statement like in C, C++, Java, etc.)
I also think the "%" operator in Python is pretty goofy. Writing a sprintf-like function in Python would be easy. With keyword arguments it would be even better than the real sprintf.
Python's "lambda" is also severely underpowered. (lambda only works with an expression, which means no side effects unless you call another (named) function/method, which sort of defeats to purpose of lambda in many situations)
I do think that Perl's "provide a million ways to do one thing" is a weakness though. Most Perl programmers know only a small fraction of those techniques. Even if I were to learn, or perhaps especially if I were to learn Perl inside and out, it would be a problem when others came to maintain my code. And while you have me partially convinced that some of the symbols Perl uses may be of marginal use occasionally, I still think it's gone way overboard.
In all, Python's got some problems. From a practical point of view though, maintenance is the biggest problem with software, and Perl code has severe maintenance problems. So despite Python's minor weaknesses, it's still many times better than Perl for projects in the real world where more than one developer is involved.
Re:A Challenge for Tom by Tom+Christiansen · 1999-07-07 06:42 · Score: 2

I love the way you define as "irrelevant" the things that you just can't do. Where's your the C code that I can generate and you can't? How about the way you can lose objects in Python and never call their finalizers when the program exists? That's fundamentally broken.
How about this: find your most readable piece of Perl code that you think can't be easily reimplemented in Python. Post it here. Nothing silly like executing chunks of Perl code allowed. It's just as hard for Perl to execute chunks of Python code.
Go to town:
sub timeout {
my($period,$closure) = @_; alarm($period); $closure->(); # indirect function call alarm(0);
}
my $line = '';
timeout(30, sub { $line = readline(*STDIN) });
# now check $line for proper contents
print $line;

You can't do it. You don't have proper scoping. You can't get the proper $line variable set. So instead you'll have to invent some god-awful overly obfuscated object-oriented abomination because you didn't get the language primitives right.
Here's another for you:
for ($i = 0; 10 > $i; $i++) {
for ($j = 0; 10 > $j; $j++) { for ($k = 0; 10 > $k; $k++) { $a[$i][$j][$k] = $j + $k * 2 ** $i;
}
} } Yes, that was a complete program. Enjoy.
Re:A Challenge for Tom by Tom+Christiansen · 1999-07-08 06:58 · Score: 2

Congratulations -- you failed twice, as I knew you would.
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.
Re:A Challenge for Tom by Tom+Christiansen · 1999-07-08 11:21 · Score: 2

But the "timeout" function I created above can also accept normal functions. As mentioned earlier, I did have a version that didn't use a separate class.
"Normal functions" aren't good enough. When I pass in sub { $line = readline(*STDIN) } that's a closure. It find the version of $line which is currently in scope. You know, a lambda that actually works right, because it has correct scope? Python can't do that, because its idea of scope is not rich enough. Lisp, Scheme, and Perl can all do it. There is no end of gross workarounds for not having closures, but such they remain. You cannot compare simple wrapping a bit of sub{} around something to all that OO bull. It's just not the same. At all. I'm disappointed that you seem to pretend that it is.
I notice you completely ignored my other points. I'll assume that means you couldn't think of any way to refute them.
Bah. I don't have infinite time. You can't bait me into playing that game. And I despise the web as a conversation forum. Get thee to a newsgroup so I can use a real newsreader and a real editor, damn it. I'm tired of cutting and pasting from vi into lynx or netscrape. And I hate writing in HTML, but if I don't, it looks like shit.
I also find it amusing that you said you were going to give me the last word,
I said if you planned on simply being a flamer.
That depends on what you consider to be correct. I could just as easily say that it shows Perl is incapable of doing correct runtime bounds-checking. You seem to think that "however Perl does it is the right way".
It's all part of the "do-what-I-mean" philosophy; or, if you would, the automatic memory management philosophy. If I want to assign to a variable and there's something already there, I expect what was used to be there to get recycled properly. If I want to assign to a variable and there's nothing there yet, I expect the system to allocate space for me. In Python, I can't do the simple equivalent to:
my @list; $list[$place] = some_value();
This goes against the principle of least surprise. Why do I have to presize arrays (`lists')? I don't have to do so with strings! That's part of the beauty of implicit memory management. It drives me nuts. Why can I do this:
a = {} a["fred"] = "barney"
but I can't do this
a = [] a[23] = "barney"
It just doesn't make sense. It's a pain in the butt.
And I don't see why you allocate hashes (`dictionaries') with braces and dereference them with brackets. The queer thing is that this:
a = {} a["fred"] = "barney" a[23] = "barney"

Comment removed by account_deleted · 1999-07-07 08:56 · Score: 1

Comment removed based on user account deletion

Comment removed by account_deleted · 1999-07-07 08:58 · Score: 1

Comment removed based on user account deletion

these kinds of awards are good for OSS by semis · 1999-07-06 14:19 · Score: 1

The OSS community should have more of these kinds of awards, aiming for public recognition of various folks helping OSS in both technical and non-technical areas.

Certainly this would help to futher motivate advocates and developers alike.

Re:People still use Perl????? by Ratface · 1999-07-06 18:10 · Score: 1

There's plenty of people out there still using Perl. In the US, where leased line prices are comparitively cheap, the majority of companies who want to take their web presence seriously will have their own server. In the UK (and much of Europe) it costs an arm and a leg to host a server, so small-medium businesses and even the occasional large company host their sites with ISP's.

Unfortunately, many ISP's don't provide much more than the usual cgi access for functionality, so a lot of people are writing some very interesting and often quite complex systems in Perl.

Of course, this isn't an ideal state of affairs and I for one would much rather be using PHP style solutions, but often the choice just isn't there.

--

A little planning goes a long way...

A Swiss Army Knife by coaxial · 1999-07-06 23:06 · Score: 1

I'm sorry, but Perl is by far one of the best (if not the best) utility languages it out there. Granted I wouldn't want to make a ray tracer with it, but still you can't beat it for all the miscellaneous tasks that come up during the day.
Most of the posts I've seen deriding Perl, can be summed up as, "Ehh Perl! _____ is much better for CGI and WWW!" Now I'm not here to debate that, but I can't stand by and let people pigeon hole it as simply a "web" language. It's a general text manipulation language. Yes you can do CGI with it, but it can also do so much more. I've used it as a code generator, and for numerous build scripts.

Perl is somthing that should be every hacker's toolbox. It just makes life so much easier. Sure you can probably do all the stuff I use Perl for with something else (shell scripts come to mind), but why would you? Perl may not be the perfect too for the job, but it certainly gets the job done.

Re:We snob perl? by coaxial · 1999-07-07 00:45 · Score: 1

I don't know about snubbed. Every professor I had sung the praises of Perl. The reason why Perl isn't used, and the reason it is so powerful, is because it abstracts out so much detail. You don't need to know anything about memory management, the garbage collector takes care of it. Want a hash table? Just type, "%htable"!

I occasionally interview people at work. I met a 4.8 GPA master's student who didn't know the first thing about advanced data structures. Why? He was taught using Perl!

Python!? by 0xdeadbeef · 1999-07-06 19:57 · Score: 1

I_wish_I_could_use_python_but_my_space_bar_is_brok en!

Re:Tom Christiansen by I+R+A+Aggie · 1999-07-06 21:05 · Score: 1

I nominate Tom Christiansen as a perl overly sung unhero. Please join me in recognising his uselessness to our community.

Ok, how many pages of perl documentation have you written?

James

Re:Perl sucks / php3 rules by Tom+Christiansen · 1999-07-06 20:43 · Score: 2

For dynamic generated html, that's it.

Without providing substantiating evidence, I'm afraid that your blithe remark comes off as either disingenuous or underinformed. You can hardly tell Slashdot.org or Deja.com that they aren't getting a tremendous productivity, performance, portability, programmability, and maintanability win through using Apache + mod_perl + Perl for their dynamic HTML generation.

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.

Re:Python loses by Tom+Christiansen · 1999-07-07 04:04 · Score: 2

That's what I'd like to know: what can you do in Perl that you can't do in Python? My guess is nothing.

You're not just wrong -- you're massively and pathetically wrong. A tiny list is enclosed below.

As for what you can do in Python that you can't do in Perl: Python code is actually maintainable. Perl code generally isn't. And Perl makes it hard as hell to make code that even comes close to readable.

The more times you repeat that lie, the less reasonable you sound. Please see my other response for why you have no idea what you're talking about. If you write bad perl code, it's your own fault for being imcompetent.

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.

Re:COBOL of the 90's by Tom+Christiansen · 1999-07-06 19:09 · Score: 3

What? Spend more time writing code then trying to count the curly braces?

You would prefer perhaps mental telepathy?

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.

Re:Hear, Hear! by Tom+Christiansen · 1999-07-06 20:30 · Score: 3

Hackish OO features are a strange brickbat to throw at Perl, because Perl5's OO-features were strongly influenced by Python's

Very much so. Larry Wall had been using C++ for a few years before he added object support to Perl. He did so at least partially so he could interface with C++ using a simpler language.

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:

The perltootc manpage, for managing class (and sometimes instance data) in Perl.
The perltoot manpage, a tutorial for OO in Perl
The perlobj manpage, a rather dry but essential page.
The overload manpage, to see how operator overloading works with Perl objects.
The Perl Cookbook (yes, my name is on the cover) has a chapter on objects. You can download the source through the Examples link there (either normal gzip or else Wintel zip format).
A new book (that yes, I tech-edited, but no, which I don't get royalties on) is coming out by Damian Conway, called simply enough Object Oriented Perl. Damian is our Melville. :-) We've accepted three of this prolific fellow's papers in the refereed track at the next Perl Conference. One of them is even a technical paper that's written completely in a certain kind of poetry.

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

We snob perl? by rent · 1999-07-06 20:40 · Score: 1

Perl, being a great language, doesn't get much recognition from the academic community.
How many times do you see perl mentioned in a programming language text book??

You find that perl is often snubbed by all CS courses, for traditional imperative programming languages (and ofcorse the almost useless functional and declarative languages)..

My guess to why this is occurring is that perl brakes away from the traditional programming language design rules (or current trends) so much that it is viewed as inferior. While every traditional imperative language can have a 'record' data type, Perl can have none... Pointers in Perl are all but gone.. and all variables are global, unless explicitly declared.. - and those are just one of the many examples to why this language is viewed as a step back. However, these features are what make the language better, and I could go on about the many superior features that perl has that are not found in any of the major languages..

I nominate the person who's quest would be to re-write the text books, and put at least a page on the most Practical language on Earth, Perl!

Re:how 'bout asking why? by brian+d+foy · 1999-07-07 10:25 · Score: 1

The White Camel Awards are sponsored by Perl Mongers. Nobody but Perl Mongers gets to see the nomination information. Perl Mongers will select the award recipients.

The idea is to recognize persons who have made significant, non-technical contributions to the Perl community. I like giving stuff away, and that's why I created these awards and organized the necessary people to raise funds and so on. That's it.

If sourceXchange wanted to find developers, this would be a really stupid and expensive way to go about it. The people being nominated aren't exactly unknowns, after all. :)

Re:abigail by Abigail · 1999-07-06 23:14 · Score: 1

I'm famous now!

--- Abigail

Slashdot Mirror

White Camel Award Nominations

41 of 76 comments (clear)