I should have really hoped that the copious examples would have sufficed. Did you read them all? The Churchyard site has oodles of them. Did you go to google and try looking up "singular they"? There are plenty of links there.
If you can bring yourself to say "yourself", and I certainly can, yet still use a plural verb with "you", then it requires no stretch of the imagination to do the same thing with "they" and all its forms. Mind you: "themself" was in use long before we discontinued the opposition of "thyself" versus "yourselves" and started "yourself" versus "yourselves".
You shouldn't say, "We already have a meaning for `they'." You lead one to believe that the plural sense is the only meaning. It isn't. Not only isn't it the only meaning now, it never has been. "They" has always taken the role of a pronoun for an unknown antecedent. In modern speech, we see other interesting things happening with it, where even when the gender is known, but the exact identity is not, "they" is sometimes employed.
You can't just "invent" a new word for so important a job as a personal pronoun--not if you expect it to take hold. This is far too important a job. You can always invent new words for new things (although it's best if there's some parental etymon to lend meaning), and you can often invent new words for old things. But we already have an old word for an old thing: one that everyone intuitively uses and recognizes, irrespective of whether they happen to notice the practice or just go on blindly communicating using the language of their ancestors and their peers. (As in fact, I just did in the previous sentence. Did you have a fatal heart attack? No? Good. If you did, well, that's a real shame, but I'll just assume you aren't reading this.:-)
You'll never overcome the inertia of a word in adequate production in a critical role. I'd like to see you change around "we" just because it suits your fancy, too.
It doesn't matter if you argue from an artificial, presciptivist point of view, because the evidence of continual and widespread use since well before Modern English even existed up though our current day illustrates that this is a meaning that has always existed. You can't just invent grammars and impose them on language. The real people know how it works, and don't need to try to fathom Latin rules applied to a non-Latin tongue in order to understand this.
BTW, you forgot to hit "post anonymously" this time.:-)
What's up with compiling perl is that there is a perlcc tool in the current release, one which is much improved in 5.005_63 over previous releases. The initial work was done by Malcolm Beattie, quite some time ago, with substantial recent work done by Vishal Bhatia and Tom Hughes, and perhaps Nick Ing-Simmons if memory serves. This includes modes for simple C output, more optimized C output (who says `optimal' is an absolute superlative?:-), and `Perl byte code' output.
But this isn't want you want to look at for the CGI performance issue. You'll get an order of magnitude (10-40x) by using Apache's mod_perl to pre-load the pre-compiled programs directly into your httpd daemons. The amount of support for Apache in Perl is phenomenal. In the Apache directory alone on CPAN, we have all these:
Of course, eventually even this breaks down. I don't think you want to handle 100,000 hits per second this way. For that kind of situation, you need to look into much more sophisticated systems of redundant daemons, sometimes with highly clever dispatch mechanisms way down low, such as with TCP splicing. See the latest Usenix `USITS' symposium proceedings for things in this realm.
curious... I understand why it is a great example of a successful free software project, but why is it a successful demonstration of open source? It seems that larry wall and people (of his choice) have done all of the development. The only thing I can think of is that it has been ported to so many platforms.
That's like saying that all the development work for Linux was done by Linus Torvalds and people of his choice. "Choice" isn't the operative term. About the only person Larry ordains is the release manager, but even that is completely a volunteer thing. If you check the change logs, you'll see that there are hundreds of different names in there. Larry didn't "choose" to have those people help out by contributing code. They chose themselves, just as with any other open source project. Most of the people who do most of the work are the ones you've never heard of. You can't lavish enough praise on Gurusamy Sarathy, Matthias Neeracher, Nick Ing-Simmons, Tim Bunce, Ilya Zakharevich, Graham Barr, Andy Dougherty, Dan Sugalski, Jarkko Hietaniemi, Malcolm Beattie, Chip Salzenberg, Paul Marquess, and Andreas König (just to name a few of the names that pop into my head; please forgive me for omissions; see the change logs) to really thank them for their herculean efforts. It's the volunteers that have made Perl what it is today. They gave freely of themselves. They didn't get "chosen".
Sure, there are places Larry keeps a tight control over--just try wedging a few more lines of C code in the inner interpreter loop, for example. But by and large, the Bazaar around the edges is a richly diverse free-for-all where all kinds of people do all kinds of things.
I think you are acting intentionally dense and I find it irritating.
I'll consider the dense part, but not the intentionally part.
The problem is precisely that Perl's deliberate obfuscation of the distinction between numbers and strings makes it harder to do polymorphic overloading
I haven't seen evidence of that.
because strings and numbers/aren't/ the same thing and the coercions that Perl automatically invokes are not always the ones you want to use.
That's what you say. In my worldview, you're wrong. If I have a string of bytes with values in the 48-59 range (that is, digits). I can elect to perform operations on them that don't make sense for values outside that range. So what? There are many other sets of ranges with their own operations that make sense uniquely within those ranges.
Think about the Unix sort(1) program. Notice how it does not attempt to infer the type of its input stream. That's because it's a generic program. If you want to interpret your data as numeric data, than you are free to use sort -n. It's like that with Perl. *You* are in charge.
For example, suppose you need to serialize values to send it to some other application, and that this serialization format is not plain text, and has different conventions for strings and numbers.
Ah, and just whose fault is this? I say that the fault lies with that other program for expecting so much rigamarole. Didn't we learn that ioctl(2) was bad, and simple text-based interfaces to controlling devices were infinitely better than binary crud?
If you expect to treat your data like a string of digits, feel free. If you don't know what you want to treat it as, then I suggest you make that decision yourself. If you can't figure out how to do regex tests, there are manpages to help you.
I'm not being intentionally dense. I honestly cannot see your problem! In my world, you see, that `problem' simply does not occur.
I feel like you keep complaining about problems that occur in a two-dimensional world to someone who lives in a three-dimensional world rather askew from your own 2D plane, intersecting in only a few places.
I don't run crying to the makers of Unix to have them `fix' their filesystem so that a file has a "I'm full of numbers" property in its inode just so that the sort program can know whether to assume a -n flag or not.
So, too, with Perl. It makes these things easier by not distinguishing them. You've simply defined easier to be "hard". Perhaps you shouldn't be doing that.
Redhat is not here to promote causes. They are not a charity. They're a business, one pulicly incorporated. As such, this business exists to serve its stockholders first. In fact, if they don't, they're quite apt to get sued. Ever heard of fiduciary responsibility? That doesn't mean that one cannot try hard to live by one's principles, but the crucial principle here really is the bottom line.
Then again, I suspect that what Macchiavelli said of States can be equally applied to Corporations. They are not "moral" or "principled" in the sense that a man can be.
type of construct. It is synonymous with all that is bad about perl syntax. Saving a few characters does not in anyway make it a more powerful language. It just caters to people who are too lazy to write readable code. THIS is the problem with perl.
Excusing your abuse of the word "synonymous", I really must disagree with your use of the word "few". Those "few" characters you just saved are in fact all of this:
if (@ARGV == 0) { unshift(@ARGV, '-'); } while (defined($ARGV = shift(@ARGV))) { if (!open(ARGV, $ARGV)) { warn "Can't open $ARGV: $!\n"; next; } while (defined($_ = <ARGV>)) { #... } }
You see, while (<>) {} is a standard way of writing a rather complicated but extremely frequent pattern found in virtually all filter programs. Let's call it the `filter pattern', shall we? Now, do you really want to make people write that whole thing out every single time they care to employ the filter pattern? What will that save? Is it somehow clearer to write in low-level than in high-level code? Not necessarily. It depends upon the level of abstraction at which you focus. Is it perhaps less error-prone? By no means! It's more prone to error, not less so. That's because because replacing one line of code with a dozen (or what have you) increases the risk of error that many times as well. It also distracts the reader and the writer from the problem at hand. And it causes synchronization issues if you care to update that bit of code in one place. Wouldn't you like to have it updated in all places instead, all at once, so you don't have to remember to change it in all places? I know I would. And yes, this has actually occurred for that bit of code. Thank goodness we had a pat idiot for a standard pattern.
Of course, there's an even briefer version of that pattern: the -n or -p command-line option, as seen in filter programs such as this one:
#!/usr/bin/perl -p # # code2html - convert code to html for posting to slashdot # # tchrist@perl.com # Sunday, December 19th, 1999
BEGIN { print "<TT>\n" }# AND THE SPIRIT OF awk...
# first kill all the tabs 1 while s/\t+/ " " x (length($&) * 8 - length($`) % 8)/e;
# then the four standard naughty bits s/&/&/g;# must remember to do this one first! s/</</g;# this is the most important one s/>/>/g;# don't close too early s/"/"/g;# only in embedded tags, i guess
# make lines break where they should s/^\s*$/<P>/ || s/$/<BR>/;
# make sure spaces aren't squishticated so we # can do indentation and properly align comments s/( {2,})/' ' x length($1)/ge;
END { print "</TT>\n" }#...SHALL BE WITH US ALWAYS
Life is too short, and too prone to error, to write all that out in longhand each and every time I care to employ that pattern.
To make the mechanism fully general and programmer-extensible requires type-safety. Perl doesn't have that, and I count it a flaw.
Hard to say what you mean by type safety. Compile-type range checking? I was never particularly found of Pascal's declarations of a 12-element array of integers being fundamentally differently typed than a 13-element array of the same. Nor did I much care for its allowing you to create a type that guarantees, for example, that an integer (such as a year) be greater than 0 and less than 2000 (oops:-).
And yes, I'm aware of programming-by-contract, with language-support of pre- and post-conditions. This is, however, a run-time issue, unless you've solved the halting problem.:-) Meanwhile, I just use asserts.
Perhaps you mean static type analysis. Perl has some of that, or, rather, can. For example, it will automatic inline certain kind of functions that it deems safe, much like a good C compiler, and unlike languages like Python. Another example is that there are situations where you can make perl raise a compile type explosion if you access a mistyped data attribute name in an object field, a type of functionality present in C++ but absent in Python. However, this is the exception not the rule, for Perl is really not much into static analysis.
But if you content yourself with dynamic typing, Perl's actually quite good with this. All objects are strictly typed. You can't coerce them as you can in C++. If you call a method from class Y on an object of class X, and class X is not derived from class Y, then you'll raise a run-time explosion.
What you and so many others constantly harp on is that Perl allows a "string" and a "number" to be used interchangeably as need arises. And I tell you truthfully: I do not understand you! I'm quite serious. Then again, this might be evidence that Sapir-Whorf was right after all.:-)
Strangely, those who complain of this flexibility never seem to decry with equally strident voices the ability to interchange floats and ints, or single-character items with multi-character strings; and seldom do they complain of a variable's use as a boolean.
What they're missing is how convenient it is for input and output that strings and number go back and forth. I don't relish having to call something like readinteger or readchar or readstring, nor having to call something like writeinteger or writechar or writestring. I was burnt too often as a young child by coredumps and consternation from scanf(3), sprintf(3), and their brethren ever to go back to that misery. (Maybe someday I'll tell you about the atrocity of rpmfind(1) some day.)
Please, let me just write$n = <FH> (or, if you prefer, $n = readline(*FH) ), and be done with the matter. I've got better things to worry about.
#!/usr/bin/perl -p # # code2html - convert code to html for posting to slashdot # # tchrist@perl.com # Sunday, December 19th, 1999
BEGIN { print "<TT>\n" }# AND THE SPIRIT OF awk...
# first kill all the tabs 1 while s/\t+/ " " x (length($&) * 8 - length($`) % 8)/e;
# then the four standard naughty bits s/&/&/g;# must remember to do this one first! s/</</g;# this is the most important one s/>/>/g;# don't close too early s/"/"/g;# only in embedded tags, i guess
# make lines break where they should s/^\s*$/<P>/ || s/$/<BR>/;
# make sure spaces aren't squishticated so we # can do indentation and properly align comments s/( {2,})/' ' x length($1)/ge;
END { print "</TT>\n" }#...SHALL BE WITH US ALWAYS
That makes your code look like this:
#!/usr/bin/perl
use Mozilla::LDAP::Conn;
die "No connection\n" unless ($conn = Mozilla::LDAP::Conn->new('my_server));
The main problem boils down to this: the Perl program print x; compiles and runs without an error message. The equivalent program in Python, Java, C, or C++ produces a compiler error. I have a hunch that a lot of programmers have torn out a lot of their hair while debugging Perl programs because of this.
It does?
% perl -we 'print x' Unquoted string "x" may clash with future reserved word at -e line 1. Name "main::x" used only once: possible typo at -e line 1. Filehandle main::x never opened at -e line 1.
I should hardly call that "without error", albeit you might rightly point out that those are merely warnings. Very well. Let's add some more pain, and then do a compile-only check.
% cat noncomp
use 5.005_63; use warnings FATAL => 'all'; print x;
% perl -c noncomp Unquoted string "x" may clash with future reserved word at noncomp line 3.
[Exit 255]
As you see, it wouldn't even compile. Anything else you'd like? Perl lets you choose your own level of pain. It's perfectly reasonable that a programming project should have a coding standard with a high pain level, just as it is perfectly reasonable that a quick four-liner not be required to suffer the same.
Very well, Jordan. I'll answer those particular points. I trust you will be content with my doing this rather than laboriously addressing your own points, since they seemed to be mostly about my not having answered each and every issue that the original poster had raised.
I really do wish, however, that someone else would please write some lengthy and detailed perl apologia sometimes. Truly I do.
Perl code is a mess of obscure control characters which can change the meaning of the code significantly. More to the point, Perl will generally try to "guess" what you want to do even if you don't quite express it correctly (Tom Christiansen's words, not mine). This may initially sound like a good idea, but it makes finding bugs a nightmare.
The first point is with respect to small changes in punctuation (not "control characters") making a large difference in semantics. This is, of course, completely true, and I saw no reason to dispute it. However, it is likewise also true in nearly every language that comes to mind, whether programming or natural.
Consider the tremendous difference in choosing single or double quotes in a C string. Notice how quote choice makes a big difference in shell programming as well, and even more importantly, how this is not the same difference as C manifested! Notice how in C the presence or absence of an asterisk or an ampersand completely changes what happens, just as in Perl the presence of absence of a dollar sign or backslash (to choose corresponding construct) can have tremendous impact. Notice, too, how in C a spurious semicolon can completely change your world.
while (i++ < j); b[i] = a[i];
And of course, positioning of that ++ matters a lot, too.
I could cite plenty of examples in English, too, such as:
I dedicate this book to my parents, Mother Theresa and God.
I dedicate this book to my parents, Mother Theresa, and God.
The place where Perl is particularly heavy on symbolic notation is in regular expressions. Modulo Icon, I don't know of any language or system currently in use that affords so much power. Regular expressions (ok, I know they're not truly regular by the proper language-theory definition) are an extremely compact but user-friendly interface to various sorts of FAs. Yes, of course interchanging, omitting, or deleting one single character completely changes the meaning, because each symbol carries a large amount of semantic content. This is equally true of any other language that uses regular expressions, whether it be from libc or in any other programming language. Consider how differently a circumflex can be interpreted in a call to regcomp(3) depending on whether it is the first thing in the string or not, as well as whether it's the first thing after the opening square bracket of a character class. It's subtle. You do have to be careful. Such is the nature of the beast. Then again, I haven't seen a Calculus book that eschewed symbolic notation, either, and I'm not certainly I'd care to.
Let's consider the "do what I mean" effect. If you'd like another quote of mine on this matter which is also somewhat mixed in its connotation, then consider: " `Do what I mean' is really just `do what Larry means', and if you and Larry don't mean the same thing, then you may be in trouble.":-)
I guess the bottom line here is Perl's context-dependent behaviours. I have mixed feelings about this whole issue, and could probably work up a fairly substantial jeremiad in either direction. I'm talking about the fact that things like these two:
@files = `ls`; $files = `ls`;
The first, being in "list context" by merit of being on the RHS of an array assignment, actually ends up being
@files = split(/(?<=\n)/, `ls`);
It seems pretty obvious that it's more fun to write it without that ugly split. A reasonable alternate approach would be the creation of two separately named functions to do this job. But that's not what happened.
Of course, it's not as though C were free of issues of context dependence. Consider how the comma operator acts in "list context", such as when you construct an actual or formal parameter list to a function or when you create an aggregate data initialization, compared with the normal, "scalar context" comma operator. Or consider how sometimes c[] and *c are equivalent (parameter declarations), and how sometimes they are not (extern declarations). And for a real fun time, just try to explain to a neophyte why argv[0][0] is doing run-time pointer arithmetic (assuming the conventional declaration), but that data[i][j] would not be given a declaration like char data[MAX_X][MAX_Y] to create a proper two-dimensional array.
C has plenty of other "do what I mean" issues. For example:
Letting multiplication bind more tightly than addition -- a secret, implicit rule
Permitting but not requiring a trailing comma on aggregate data declarations
Allowing int to be omitted in declarations involving extern, static, auto, unsigned, and volatile.
Defaulting functions to have a return type of int.
Assuming that for(;;) should mean while(1).
Sign extension on some architectures.
Freely coercing integral types
I imagine there are more of those, too, that I could come up with if I had. In fact, I'm quite sure that I could list a bunch of "do what I mean" issues for Python if necessary. Certainly the significance of whitespace and indentation is one glaring case. Another is the default nature of many libraries to raise an exception upon error, rather than returning an error status, even when that exception is, as K&P put it in Java's case, far from exceptional.
So I didn't address these issues because I felt that they were largely true, but not particularly relevant. All symbolic encoding systems are subject to semantic shifts due to small changes in symbols. And many of them attempt to "do what you mean". Does Perl share these properties? Of course it does.
Finally, Jordan, you've stated that you feel that Perl lacks attributes of a programming language that lends itself to high maintainability. I don't know whether this is fair or not, because I do not know what your metric is. If you're looking for me to play the devil's advocate, I could point out things like
minimal static analysis
extremely late binding
libertine autoextension of memory
free, dynamic conversion between intrinsic types
default mode is for fast-and-loose programming, not careful architecture with elaborate pre-declarations
However, our advocate's adversary would be quick to illustrate how easily these can be construed to be not bugs but features given the appropriate target environment. In this respect, you've probably hit the nail on the head when you mentioned trade-offs.
But you haven't enumerated your criteria, so it's hard to judge what you're thinking.
Wrong. `themself' isn't a word. Sorry, Tom, but as a writer, you should know better.
Curiously enough, that didn't seem to stop your from understanding me, now did it?:-)
In any event, it most certainly is, which means this is another annoying case of paradiorthosis.:-(
See the entry for "themself" in the 3rd Edition of Fowler. Make sure you also read both Steven Pinker and this collection by Henry Churchyard, which is replete with endless examples of singular they and its declensions from the 1300s to the present day.
And as for the "themself" versus "themselves" thing, we use "yourself" when the antecedent is singular. For example: "You're going by yourself, aren't you, Johnny?" Notice there's no "yourselves" there. English has always done this, so "themself" over "themselves" works just as well now as it did back in 1570 when Caxton wrote, "Each of them should make themself ready."
Now, wouldn't it be nice to get back to talking about Larry's article instead of make false corrections?:-(
Gee, your python code didn't compile. Gotta love a language where whitespace bugs out the compiler so badly.:-(
The equivalent to your python code in Perl is as simple as the following:
for (@array_of_things) { print; }
# look -- indentation is irrelevant! for (@array_of_things) { print; }
# so is that trailing semicolon for (@array_of_things) { print }
#:-) suppose i, good be can postfix print for @array_of_things;
# this one is a tad different print "@array_of_things\n";
# this one could be best, depending on formatting print @array_of_things;
# and then there's this one print join("\n", @array_of_things, '');
# Or this: { local($\, $,) = ("\n", "\n"); print for @array_of_things; }
But thanks for the compliment on clean code. I realize it wasn't mine you were complimenting, but Perl thanks you.:-)
I believe that it's easy to write beautiful code in Perl if you want to. I'm very sad that people don't want to. Here's one old example where I've made a stab at using indentation to make nice code. I could probably put a bit more work in it. I've many more recent examples as well, if you care. I believe seeing good examples of well-formatted code is critical for a beginner. We tried to do that in the Perl Cookbook, but there's always room for more.
You have just said that only skilled Perl coders can maintain your Perl code - hardly a ringing endorsement of Perl, or your coding ability.
It is unthinkable to expect someone not skilled in language X to maintain code written in language X -- for all values of X. The hiring manager who made that fatal decision should themself be sacked.
"We are just using an entirely new way to represent the date that isn't more human readable, or more machine friendly, that just happens to look exactly like the standard 2 digit year format until the year 2000 occurs, at which point it still works exactly as planned."
You aren't going to want to hear this, but listen carefully: you did not RTFM.
It's clearly documented. Always has been. You were just guessing how localtime(3) behaved instead of looking it up and reading the precise behaviour. A library API is a contract. If you sign up to using that library without reading the fine print, then you cannot complain when that fine print bites you in the ass. Stop guessing, and read!
You are incorrect in your assumption that this is somehow peculiar to Perl. Whether it's peculiar in general is another question entirely.:-) I wrote about this in a letter to Dan Gillmor. Essentially, you need to understand a struct tm. Apparently the situation is even worse in Java Script, where it appears that different implementations behave differently.
If you're on the cutting edge of Perl technology, please pay special attention to the new -DPERL_Y2KWARN configuration option. It produces an effect like this:
% perl -we 'printf "Year is 19%d\n", (localtime)[5]' Possible Y2K bug: %d format string following '19' at -e line 1. Year is 19100
Interesting, eh? Another option is to use the D'oh::Year module by Michael Schwern. The author wrote about it here in Dej a News. Anyway, here's the README.Y2K file from the 5.005__63 release of Perl:
The following information about Perl and the year 2000 is a modified version of the information that can be found in the Frequently Asked Question (FAQ) documents.
Does Perl have a year 2000 problem? Is Perl Y2K compliant?
Short answer: No, Perl does not have a year 2000 problem. Yes, Perl is Y2K compliant (whatever that means). The programmers you've hired to use it, however, probably are not. If you want perl to complain when your programmers create programs with certain types of possible year 2000 problems, a build option allows you to turn on warnings.
Long answer: The question belies a true understanding of the issue. Perl is just as Y2K compliant as your pencil --no more, and no less. Can you use your pencil to write a non-Y2K-compliant memo? Of course you can. Is that the pencil's fault? Of course it isn't.
The date and time functions supplied with perl (gmtime and localtime) supply adequate information to determine the year well beyond 2000 (2038 is when trouble strikes for 32-bit machines). The year returned by these functions when used in an array context is the year minus 1900. For years between 1910 and 1999 this happens to be a 2-digit decimal number. To avoid the year 2000 problem simply do not treat the year as a 2-digit number. It isn't. When gmtime() and localtime() are used in scalar context they return a timestamp string that contains a fully- expanded year. For example, $timestamp = gmtime(1005613200) sets $timestamp to "Tue Nov 13 01:00:00 2001". There's no year 2000 problem here.
That doesn't mean that Perl can't be used to create non- Y2K compliant programs. It can. But so can your pencil. It's the fault of the user, not the language. At the risk of inflaming the NRA: ``Perl doesn't break Y2K, people do.'' See http://language.perl.com/news/y2k.html for a longer exposition.
If you want perl to warn you when it sees a program which catenates a number with the string "19" -- a common indication of a year 2000 problem -- build perl using the Configure option "-Accflags=-DPERL_Y2KWARN". (See the file INSTALL for more information about building perl.)
We've known about this in C for about twenty years or so. So, let's not pretend you haven't been notified, ok?
By the way, it kind of looks silly when you get all sanctimonious about people who rip on Perl, and then give us an ALL CAPS yell about "Visual Basic Weenies!" (at the same time, demonstrating a mean touch with the HTML bold tag). What is this, a schoolyard bullying chain -- the C jocks beat on the Perl geeks who beat on the VB handicapped kids?
I think to this one I shall respond in code:
@lengs = qw(C C++ Java Pascal Perl Basic FORTRAN COBOL);
for $coder (@lengs) { for $proggie (@lengs) { next if $coder eq $proggie; print "Don't hire $coder hackers to maintain $proggie code!\n"; } }
print "\n";
for (@lengs) { print "Hire $_ hackers to maintain $_ code.\n"; }
There. Now the blame is more equally distributed, and the advice hopefully more clear.
You should. Learning is good. There are many nice things about Python.
I like its philosophy. For the record, one the strengths Guido claims for Python is that it works excellently in 100k LOC programs: you prototype in Python, then profile, then replace the slow parts (which will be 5% of the code) with C. Python is friendly to that kind of approach.
You can approach this from more than one angle. On one hand, that's the same thing that the tcl people always say, which--at least in old days before John put so much work into new tcl--pretty much required that you always wrote parts of your program in C. That's not necessarily everyone's panacea. It also means you lock yourself into keeping the main language a bit slower.
On the other hand, it always provides an escape into turbo power. And a far, far nicer escape, I hold, than writing something like:
If you're going to use Python, just realize that it's not going to be all that fast. The program (a mere ten-liner) I use to format for slashdot code blocks like the one above runs 10x faster than the less-functional Python equivalent offered up by one of its anonymous zealots. Of course, it's easy to see that this sort of problem is precisely the kind of thing that Perl is very, very good at. The best artisans and architects use a variety of tools for a variety of tasks. The most reasonable of the language advocates understand that there is no single truth. I've seen tcl and python and java people (by which I mean strong advocates and frequent users) all use perl for areas in which it excels, such as the one I just used it for above.
Kindly explain your premise. Please document which flexibility is wrong, and why. Expound upon precisely which areas you would prefer inflexibility in. Demonstrate why your desired lack of expressivity would help you.
Perl has a finite syntax, one that's infinitely easier (no, that's not hyperbole; it's true) than any natural language. The excuse that there are thinks you will not have time to learn in a ten-minute perusal of the language is no excuse whatsoever.
You'll have to work much harder than you have to justify your position.
Perl sucks. I will admit that if you know Perl well, then yes, you can write powerful programs quickly within particular domains (notibly cgi scripting), some might even enjoy this. However, if you have ever tried to maintain a perl program, particularly someone else's, then believe me, the fun drains right out of the experience. Perl code is a mess of obscure control characters which can change the meaning of the code significantly.
Anything that says "X sucks" stands a good change of being downscored, and probably deserves it, too. Please endeavour to express whatever sentiments lie behind that outburst using substantiating reasoning rather than emotive expletives.
Perl is not a rebellion against `good design'. In many senses, it is an expression of the same, where good design means something organic and adaptive, something tuned more to the wait people think than to the way computers operate. It is a kind of design which has proven itself time and again over the last several thousand -- if not in fact, billion -- years.
As for the common refrain, "I can't maintain other people's code!", this is just another bit of popular Perl FUD. Eschew such nonsense. The underlying inability may reflect on you. It may reflect on them. But it does not reflect on Perl.
What you hate is when the code to be maintained was written by an unskilled laborer, someone who doesn't understand the tenets of software design. It would be hell maintaining that code no matter what language it was written in. Another scenario for hating life is when the original coder was competent, but the person doing the maintenance is completely clueless. Here my plea:
STOP HIRING VISUAL BASIC WEENIES TO MAINTAIN PERL CODE!.
You don't hire them for maintenance of C++ libraries, so stop hiring script kiddies (I mean nonprogrammers who can only cut and paste others' scripts) to maintain Perl. This is your fault for hiring the wrong people for the job.
I've had the pleasurable experience of maintaining a great deal of Perl code that was designed and implemented by competent, professional programmers. You cannot compare the work of the Legos kiddie with that of the professional architect. It's insulting to all three parties.
One last bit: don't denigrate the accidental programmers who've had Perl thrust upon them, or who have turned to it from a starting point of zero knowledge. They're doing the best that they can, given the circumstances, and should be encouraged, not squelched. Most programming is performed folks not trained in formal software engineering. You should compliment them for how much they were able to accomplish, not diss them for not knowing the precepts and subtleties of good design. Perl succeeds because it is available not just for professionals, but for casual programmers as well.
Really? That mean that that single, ten-dollar share you bought is now worth something up in the petabuck range! That's just awesome. Time to buy out Bill Gates.
Isn't he the one who says that Linux is a piece of shit? Sounds like a great Slashdot role model to me!
Ken *invented* most of what you know as Unix and C. (It's fun to watch him and Dennis both disavow ownership and point at each other.:-) Without Ken, we wouldn't have Unix, and we probably wouldn't have C. And we most certainly wouldn't have Linux. If Ken said this, then I'm completely certain that he could have backed it up. But I don't recall having read anything by him that referred to Linux so scatologically. Please don't spread gossip and rumor, allowing idle speculation to blossom into bitter invective against a man hte likes of whose genius you seldom meet in one lifetime. Always get the exact quote and context.
Computer: In a sense, Linux is following in this tradition. Any thoughts on this phenomenon?
Thompson: I view Linux as something that's not Microsoft-a backlash against Microsoft, no more and no less. I don't think it will be very successful in the long run. I've looked at the source and there are pieces that are good and pieces that are not. A whole bunch of random people have contributed to this source, and the quality varies drastically.
My experience and some of my friends' experience is that Linux is quite unreliable. Microsoft is really unreliable but Linux is worse. In a non-PC environment, it just won't hold up. If you're using it on a single box, that's one thing. But if you want to use Linux in firewalls, gateways, embedded systems, and so on, it has a long way to go.
Delving deeper, we have this article by Eric Raymond in Linux Today, in which he clarifies what Ken said, as follows:
The best news, I guess, is that Ken says he didn't intend to write off Linux itself as simply an anti-Microsoft backlash; what he was trying to say was that he believes the recent popularity of Linux in the press is an anything-but-Microsoft phenomenon. He adds ``i very much appreciate the chance to look at available code when i am faced with the task of interfacing to some nightmare piece of hardware'' and that ``i think the open software movement (and linux in particular) is laudable.''
Ken further adds ``i dont see eye-to-eye with microsoft's business practices.'' His original language was rather stronger and more entertaining, but he asked me not to quote that in order to avoid giving Lucent's lawyers heart failure.
The bad news is that Ken still thinks Linux is flaky. I offered to have VA Linux Labs ship him a machine so he could see what a properly tuned modern Linux looks like, but he said he couldn't accept. He adds ``i do believe that in a race, it is naive to think linux has a hope of making a dent against microsoft starting from way behind with a fraction of the resources and amateur labor. (i feel the same about unix.)''
I cited all the case studies and trend curves and statistics you'd expect me to. He didn't respond directly to those, but I hope I at least gave him some things to think about.
Ken did finish by saying ``i must say the linux community is a lot nicer than the unix community. a negative comment on unix would warrent death threats. with linux, it is like stirring up a nest of butterflies.'' (Hm. Butterfly T-shirts, anyone?)
The really bad news, of course, is that Ken was wrong about the volatile and irrational reaction by the members of the Linux community against those who cast aspersions on the current state of apotheosis of Linux--or of the FSF, for that matter. This kind of thing most certainly does happen, as all here can doubtless attest. So much for the good old days.
Of course, doing anything but following the Slashdot sheep in bowing and scraping before the revered RMS has clobbered my karma, as I knew it would...
Jay, you Ignorant Slut (TM:-), nobody disrespects the gHoly Inquisitiogn!:-)
It's possible to have a couple hundred points of karma and still state your mind about you know who. I've got an existence proof.:-)
But you have to be careful not to make quick jabs, or persistent attacks--attractive though this may be. You have to use lots of words and sound reasoning. You have to avoid ad hominem attacks and address the ideas not the people. And you have to appear less religious and more accepting than the disloyal opposition. If you can make your side's position out to be more inclusive, more helpful to more people, this can make a difference.
Sure, I don't always do that; I'm sure there are a score of counterexamples. And you don't always fail to do it. But if you're hooked on karma, you have to be careful how you say what you say. At some level, this is probably true everywhere, but particularly challenging in fleeting forums like this one.
I can't just "ignore" ads. They take over my entire attention span. The blinking, jumping, moving, and popping-up atrocities are completely distracting. I do not have the gift of being able to ignore things screaming in my ear or flashing in my eye. Perhaps you do. That's nice.
Slashdot Mirror
If you can bring yourself to say "yourself", and I certainly can, yet still use a plural verb with "you", then it requires no stretch of the imagination to do the same thing with "they" and all its forms. Mind you: "themself" was in use long before we discontinued the opposition of "thyself" versus "yourselves" and started "yourself" versus "yourselves".
You shouldn't say, "We already have a meaning for `they'." You lead one to believe that the plural sense is the only meaning. It isn't. Not only isn't it the only meaning now, it never has been. "They" has always taken the role of a pronoun for an unknown antecedent. In modern speech, we see other interesting things happening with it, where even when the gender is known, but the exact identity is not, "they" is sometimes employed.
You can't just "invent" a new word for so important a job as a personal pronoun--not if you expect it to take hold. This is far too important a job. You can always invent new words for new things (although it's best if there's some parental etymon to lend meaning), and you can often invent new words for old things. But we already have an old word for an old thing: one that everyone intuitively uses and recognizes, irrespective of whether they happen to notice the practice or just go on blindly communicating using the language of their ancestors and their peers. (As in fact, I just did in the previous sentence. Did you have a fatal heart attack? No? Good. If you did, well, that's a real shame, but I'll just assume you aren't reading this. :-)
You'll never overcome the inertia of a word in adequate production in a critical role. I'd like to see you change around "we" just because it suits your fancy, too.
It doesn't matter if you argue from an artificial, presciptivist point of view, because the evidence of continual and widespread use since well before Modern English even existed up though our current day illustrates that this is a meaning that has always existed. You can't just invent grammars and impose them on language. The real people know how it works, and don't need to try to fathom Latin rules applied to a non-Latin tongue in order to understand this.
BTW, you forgot to hit "post anonymously" this time. :-)
But this isn't want you want to look at for the CGI performance issue. You'll get an order of magnitude (10-40x) by using Apache's mod_perl to pre-load the pre-compiled programs directly into your httpd daemons. The amount of support for Apache in Perl is phenomenal. In the Apache directory alone on CPAN, we have all these:
There's also a great book from O'Reilly called Writing Apache Modules in Perl and C . It's got an Eagle on the cover.Of course, eventually even this breaks down. I don't think you want to handle 100,000 hits per second this way. For that kind of situation, you need to look into much more sophisticated systems of redundant daemons, sometimes with highly clever dispatch mechanisms way down low, such as with TCP splicing. See the latest Usenix `USITS' symposium proceedings for things in this realm.
Sure, there are places Larry keeps a tight control over--just try wedging a few more lines of C code in the inner interpreter loop, for example. But by and large, the Bazaar around the edges is a richly diverse free-for-all where all kinds of people do all kinds of things.
Think about the Unix sort(1) program. Notice how it does not attempt to infer the type of its input stream. That's because it's a generic program. If you want to interpret your data as numeric data, than you are free to use sort -n. It's like that with Perl. *You* are in charge.
Ah, and just whose fault is this? I say that the fault lies with that other program for expecting so much rigamarole. Didn't we learn that ioctl(2) was bad, and simple text-based interfaces to controlling devices were infinitely better than binary crud?If you expect to treat your data like a string of digits, feel free. If you don't know what you want to treat it as, then I suggest you make that decision yourself. If you can't figure out how to do regex tests, there are manpages to help you.
I'm not being intentionally dense. I honestly cannot see your problem! In my world, you see, that `problem' simply does not occur.
I feel like you keep complaining about problems that occur in a two-dimensional world to someone who lives in a three-dimensional world rather askew from your own 2D plane, intersecting in only a few places.
I don't run crying to the makers of Unix to have them `fix' their filesystem so that a file has a "I'm full of numbers" property in its inode just so that the sort program can know whether to assume a -n flag or not.
So, too, with Perl. It makes these things easier by not distinguishing them. You've simply defined easier to be "hard". Perhaps you shouldn't be doing that.
Then again, I suspect that what Macchiavelli said of States can be equally applied to Corporations. They are not "moral" or "principled" in the sense that a man can be.
Of course, there's an even briefer version of that pattern: the -n or -p command-line option, as seen in filter programs such as this one:
Life is too short, and too prone to error, to write all that out in longhand each and every time I care to employ that pattern.And yes, I'm aware of programming-by-contract, with language-support of pre- and post-conditions. This is, however, a run-time issue, unless you've solved the halting problem. :-) Meanwhile, I just use asserts.
Perhaps you mean static type analysis. Perl has some of that, or, rather, can. For example, it will automatic inline certain kind of functions that it deems safe, much like a good C compiler, and unlike languages like Python. Another example is that there are situations where you can make perl raise a compile type explosion if you access a mistyped data attribute name in an object field, a type of functionality present in C++ but absent in Python. However, this is the exception not the rule, for Perl is really not much into static analysis.
But if you content yourself with dynamic typing, Perl's actually quite good with this. All objects are strictly typed. You can't coerce them as you can in C++. If you call a method from class Y on an object of class X, and class X is not derived from class Y, then you'll raise a run-time explosion.
What you and so many others constantly harp on is that Perl allows a "string" and a "number" to be used interchangeably as need arises. And I tell you truthfully: I do not understand you! I'm quite serious. Then again, this might be evidence that Sapir-Whorf was right after all. :-)
Strangely, those who complain of this flexibility never seem to decry with equally strident voices the ability to interchange floats and ints, or single-character items with multi-character strings; and seldom do they complain of a variable's use as a boolean.
What they're missing is how convenient it is for input and output that strings and number go back and forth. I don't relish having to call something like readinteger or readchar or readstring, nor having to call something like writeinteger or writechar or writestring. I was burnt too often as a young child by coredumps and consternation from scanf(3), sprintf(3), and their brethren ever to go back to that misery. (Maybe someday I'll tell you about the atrocity of rpmfind(1) some day.)
Please, let me just write$n = <FH> (or, if you prefer, $n = readline(*FH) ), and be done with the matter. I've got better things to worry about.
I really do wish, however, that someone else would please write some lengthy and detailed perl apologia sometimes. Truly I do.
The first point is with respect to small changes in punctuation (not "control characters") making a large difference in semantics. This is, of course, completely true, and I saw no reason to dispute it. However, it is likewise also true in nearly every language that comes to mind, whether programming or natural.Consider the tremendous difference in choosing single or double quotes in a C string. Notice how quote choice makes a big difference in shell programming as well, and even more importantly, how this is not the same difference as C manifested! Notice how in C the presence or absence of an asterisk or an ampersand completely changes what happens, just as in Perl the presence of absence of a dollar sign or backslash (to choose corresponding construct) can have tremendous impact. Notice, too, how in C a spurious semicolon can completely change your world.
And of course, positioning of that ++ matters a lot, too.I could cite plenty of examples in English, too, such as:
- I dedicate this book to my parents, Mother Theresa and God.
- I dedicate this book to my parents, Mother Theresa, and God.
The place where Perl is particularly heavy on symbolic notation is in regular expressions. Modulo Icon, I don't know of any language or system currently in use that affords so much power. Regular expressions (ok, I know they're not truly regular by the proper language-theory definition) are an extremely compact but user-friendly interface to various sorts of FAs. Yes, of course interchanging, omitting, or deleting one single character completely changes the meaning, because each symbol carries a large amount of semantic content. This is equally true of any other language that uses regular expressions, whether it be from libc or in any other programming language. Consider how differently a circumflex can be interpreted in a call to regcomp(3) depending on whether it is the first thing in the string or not, as well as whether it's the first thing after the opening square bracket of a character class. It's subtle. You do have to be careful. Such is the nature of the beast. Then again, I haven't seen a Calculus book that eschewed symbolic notation, either, and I'm not certainly I'd care to.Let's consider the "do what I mean" effect. If you'd like another quote of mine on this matter which is also somewhat mixed in its connotation, then consider: " `Do what I mean' is really just `do what Larry means', and if you and Larry don't mean the same thing, then you may be in trouble." :-)
I guess the bottom line here is Perl's context-dependent behaviours. I have mixed feelings about this whole issue, and could probably work up a fairly substantial jeremiad in either direction. I'm talking about the fact that things like these two:
The first, being in "list context" by merit of being on the RHS of an array assignment, actually ends up being It seems pretty obvious that it's more fun to write it without that ugly split. A reasonable alternate approach would be the creation of two separately named functions to do this job. But that's not what happened.Of course, it's not as though C were free of issues of context dependence. Consider how the comma operator acts in "list context", such as when you construct an actual or formal parameter list to a function or when you create an aggregate data initialization, compared with the normal, "scalar context" comma operator. Or consider how sometimes c[] and *c are equivalent (parameter declarations), and how sometimes they are not (extern declarations). And for a real fun time, just try to explain to a neophyte why argv[0][0] is doing run-time pointer arithmetic (assuming the conventional declaration), but that data[i][j] would not be given a declaration like char data[MAX_X][MAX_Y] to create a proper two-dimensional array.
C has plenty of other "do what I mean" issues. For example:
- Letting multiplication bind more tightly than addition -- a secret, implicit rule
- Permitting but not requiring a trailing comma on aggregate data declarations
- Allowing int to be omitted in declarations involving extern, static, auto, unsigned, and volatile.
- Defaulting functions to have a return type of int.
- Assuming that for(;;) should mean while(1).
- Sign extension on some architectures.
- Freely coercing integral types
I imagine there are more of those, too, that I could come up with if I had. In fact, I'm quite sure that I could list a bunch of "do what I mean" issues for Python if necessary. Certainly the significance of whitespace and indentation is one glaring case. Another is the default nature of many libraries to raise an exception upon error, rather than returning an error status, even when that exception is, as K&P put it in Java's case, far from exceptional.So I didn't address these issues because I felt that they were largely true, but not particularly relevant. All symbolic encoding systems are subject to semantic shifts due to small changes in symbols. And many of them attempt to "do what you mean". Does Perl share these properties? Of course it does.
Finally, Jordan, you've stated that you feel that Perl lacks attributes of a programming language that lends itself to high maintainability. I don't know whether this is fair or not, because I do not know what your metric is. If you're looking for me to play the devil's advocate, I could point out things like
- minimal static analysis
- extremely late binding
- libertine autoextension of memory
- free, dynamic conversion between intrinsic types
- default mode is for fast-and-loose programming, not careful architecture with elaborate pre-declarations
However, our advocate's adversary would be quick to illustrate how easily these can be construed to be not bugs but features given the appropriate target environment. In this respect, you've probably hit the nail on the head when you mentioned trade-offs.But you haven't enumerated your criteria, so it's hard to judge what you're thinking.
In any event, it most certainly is, which means this is another annoying case of paradiorthosis. :-(
See the entry for "themself" in the 3rd Edition of Fowler. Make sure you also read both Steven Pinker and this collection by Henry Churchyard, which is replete with endless examples of singular they and its declensions from the 1300s to the present day.
And as for the "themself" versus "themselves" thing, we use "yourself" when the antecedent is singular. For example: "You're going by yourself, aren't you, Johnny?" Notice there's no "yourselves" there. English has always done this, so "themself" over "themselves" works just as well now as it did back in 1570 when Caxton wrote, "Each of them should make themself ready."
Now, wouldn't it be nice to get back to talking about Larry's article instead of make false corrections? :-(
The equivalent to your python code in Perl is as simple as the following:
But thanks for the compliment on clean code. I realize it wasn't mine you were complimenting, but Perl thanks you.I believe that it's easy to write beautiful code in Perl if you want to. I'm very sad that people don't want to. Here's one old example where I've made a stab at using indentation to make nice code. I could probably put a bit more work in it. I've many more recent examples as well, if you care. I believe seeing good examples of well-formatted code is critical for a beginner. We tried to do that in the Perl Cookbook, but there's always room for more.
It's clearly documented. Always has been. You were just guessing how localtime(3) behaved instead of looking it up and reading the precise behaviour. A library API is a contract. If you sign up to using that library without reading the fine print, then you cannot complain when that fine print bites you in the ass. Stop guessing, and read!
You are incorrect in your assumption that this is somehow peculiar to Perl. Whether it's peculiar in general is another question entirely. :-) I wrote about this in a letter to Dan Gillmor. Essentially, you need to understand a struct tm. Apparently the situation is even worse in Java Script, where it appears that different implementations behave differently.
If you're on the cutting edge of Perl technology, please pay special attention to the new -DPERL_Y2KWARN configuration option. It produces an effect like this:
Interesting, eh? Another option is to use the D'oh::Year module by Michael Schwern. The author wrote about it here in Dej a News. Anyway, here's the README.Y2K file from the 5.005__63 release of Perl: We've known about this in C for about twenty years or so. So, let's not pretend you haven't been notified, ok?On the other hand, it always provides an escape into turbo power. And a far, far nicer escape, I hold, than writing something like:
If you're going to use Python, just realize that it's not going to be all that fast. The program (a mere ten-liner) I use to format for slashdot code blocks like the one above runs 10x faster than the less-functional Python equivalent offered up by one of its anonymous zealots. Of course, it's easy to see that this sort of problem is precisely the kind of thing that Perl is very, very good at. The best artisans and architects use a variety of tools for a variety of tasks. The most reasonable of the language advocates understand that there is no single truth. I've seen tcl and python and java people (by which I mean strong advocates and frequent users) all use perl for areas in which it excels, such as the one I just used it for above.Ian, please keep your frothing python bigotry to yourself. It has no place here.
Perl has a finite syntax, one that's infinitely easier (no, that's not hyperbole; it's true) than any natural language. The excuse that there are thinks you will not have time to learn in a ten-minute perusal of the language is no excuse whatsoever.
You'll have to work much harder than you have to justify your position.
Perl is not a rebellion against `good design'. In many senses, it is an expression of the same, where good design means something organic and adaptive, something tuned more to the wait people think than to the way computers operate. It is a kind of design which has proven itself time and again over the last several thousand -- if not in fact, billion -- years.
As for the common refrain, "I can't maintain other people's code!", this is just another bit of popular Perl FUD. Eschew such nonsense. The underlying inability may reflect on you. It may reflect on them. But it does not reflect on Perl.
What you hate is when the code to be maintained was written by an unskilled laborer, someone who doesn't understand the tenets of software design. It would be hell maintaining that code no matter what language it was written in. Another scenario for hating life is when the original coder was competent, but the person doing the maintenance is completely clueless. Here my plea:
You don't hire them for maintenance of C++ libraries, so stop hiring script kiddies (I mean nonprogrammers who can only cut and paste others' scripts) to maintain Perl. This is your fault for hiring the wrong people for the job.
I've had the pleasurable experience of maintaining a great deal of Perl code that was designed and implemented by competent, professional programmers. You cannot compare the work of the Legos kiddie with that of the professional architect. It's insulting to all three parties.
One last bit: don't denigrate the accidental programmers who've had Perl thrust upon them, or who have turned to it from a starting point of zero knowledge. They're doing the best that they can, given the circumstances, and should be encouraged, not squelched. Most programming is performed folks not trained in formal software engineering. You should compliment them for how much they were able to accomplish, not diss them for not knowing the precepts and subtleties of good design. Perl succeeds because it is available not just for professionals, but for casual programmers as well.
You might try satire. It seems to work better for me. I've got about seven more of those waiting for the right moment. :-)
[...time passes...]
Alright, here you go. Read this, which I got from IEEE Computer Magazine:
Delving deeper, we have this article by Eric Raymond in Linux Today, in which he clarifies what Ken said, as follows: The really bad news, of course, is that Ken was wrong about the volatile and irrational reaction by the members of the Linux community against those who cast aspersions on the current state of apotheosis of Linux--or of the FSF, for that matter. This kind of thing most certainly does happen, as all here can doubtless attest. So much for the good old days.It's possible to have a couple hundred points of karma and still state your mind about you know who. I've got an existence proof. :-)
But you have to be careful not to make quick jabs, or persistent attacks--attractive though this may be. You have to use lots of words and sound reasoning. You have to avoid ad hominem attacks and address the ideas not the people. And you have to appear less religious and more accepting than the disloyal opposition. If you can make your side's position out to be more inclusive, more helpful to more people, this can make a difference.
Sure, I don't always do that; I'm sure there are a score of counterexamples. And you don't always fail to do it. But if you're hooked on karma, you have to be careful how you say what you say. At some level, this is probably true everywhere, but particularly challenging in fleeting forums like this one.
I can't just "ignore" ads. They take over my entire attention span. The blinking, jumping, moving, and popping-up atrocities are completely distracting. I do not have the gift of being able to ignore things screaming in my ear or flashing in my eye. Perhaps you do. That's nice.
Make that fajitas and quesadillas, of course.