Slashdot Mirror

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

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

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

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

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

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

TC is re-implementing the classic Unix command set in pure Perl. See http://language.perl.com/ppt/

The film?s very existence totally exposes the insanity of Hollywood?s ratings system

South Park goes out in a blaze of glory, not only because it?s funny and bizarre, but because it?s out at precisely the right moment

Cache-Control: private
Pragma: no-cache
Server: Apache/1.3.6 (Unix) mod_perl/1.20
Content-Type: text/html
Client-Date: Thu, 01 Jul 1999 18:05:40 GMT
Client-Peer: 206.170.14.75:80
Title: Slashdot:South Park The Movie

Is this the price of acquisition, or are the article filters not checking for valid characters? If the current codeset were available, I'd send in more bug fixes. Will we ever see it, or has it gone the way of all fleeceware in the acquisition, locked away from prying eyes?

What's next? No more "clean" interface, maybe? Mandatory pop-up adverts with sound-clips? ActiveX controls and client-side Visual Basic with epileptic spinners?

Alas. What a sad day!

The film?s very existence totally exposes the insanity of Hollywood?s ratings system

South Park goes out in a blaze of glory, not only because it?s funny and bizarre, but because it?s out at precisely the right moment

Cache-Control: private
Pragma: no-cache
Server: Apache/1.3.6 (Unix) mod_perl/1.20
Content-Type: text/html
Client-Date: Thu, 01 Jul 1999 18:05:40 GMT
Client-Peer: 206.170.14.75:80
Title: Slashdot:South Park The Movie

Is this the price of acquisition, or are the article filters not checking for valid characters? If the current codeset were available, I'd send in more bug fixes. Will we ever see it, or has it gone the way of all fleeceware in the acquisition, locked away from prying eyes?

What's next? No more "clean" interface, maybe? Mandatory pop-up adverts with sound-clips? ActiveX controls and client-side Visual Basic with epileptic spinners?

Alas. What a sad day!

Welcome to the CPAN multiplexer. Whenever you ask for a path from this site that begins http://www.perl.com/CPAN/ you will automatically get a site close to you. Since you're reading this now, you must have called it without a slash, which gives you the chance to pick which site you prefer. Please select your nearest CPAN site. Preferences are now sticky! That means that whoever you pick will persist via cookies. This choice will remain in effect until you return to this page and select a different mirror, even if that server becomes nonfunctional.

Welcome to the CPAN multiplexer. Whenever you ask for a path from this site that begins http://www.perl.com/CPAN/ you will automatically get a site close to you. Since you're reading this now, you must have called it without a slash, which gives you the chance to pick which site you prefer. Please select your nearest CPAN site. Preferences are now sticky! That means that whoever you pick will persist via cookies. This choice will remain in effect until you return to this page and select a different mirror, even if that server becomes nonfunctional.

You watch TV, don't you? Aren't you plastered w/ ads every so few minutes?

You shouldn't assume that everyone buys into the spamvert mentality. Not everyone is a prisoner of the American consumerist claptrap you're talking about, whether because of their geography or because they prefer something other than a lie-down-and-vege-out plug-in drug.

In short, we do not all live in a Brave New World of pervasive mind-control through spamverts, and those of us who have willfully absented ourselves from that particular horror shall not be dragged kicking and screaming into it. We'll kick the face of the spamverts. Mark my words.

``Contempt, rather than celebration, is the proper response to advertising and the system that makes it possible.'' --Neil Postman

No, you use the more modern chomp() which removes EOL's from lines as defined by the $/ variable.

I imagine that $/ defaults to CRLF on Windoze.

Not everyone agrees what a line in a text file is, because one person's textual character set is another's binary gibberish. Even when all parties involved are using ASCII instead of EBCDIC, Rad50, or Unicode, discrepancies arise. There is no such thing as a newline character. It is purely virtual, a figment of the operating system, standard libraries, device drivers, and Perl.

Under Unix or Plan9, a "\n" represents the physical sequence "\cJ", a linefeed. However, on a terminal that's not in raw mode, an key generates an incoming "\cM" (a carriage return), which turns into "\cJ", while an outgoing "\cJ" magically turns into "\cM\cJ". This strangeness doesn't happen with normal files, just terminal devices, and is handled strictly by the device driver.

On a Mac, a "\n" is usually represented by "\cM"; just to make life interesting, a "\r" represents a "\cJ". You will note that this is exactly the opposite of the way that Unix, Plan9, VMS, CP/M, or nearly anyone else does it. This means that Mac programmers writing files for other systems, or talking over a network, have to be careful. If you just send out "\n", you'll deliver a "\cM" and no "\cJ" will ever be seen. Most network services prefer to receive and send "\cM\cJ" as a line terminator, but most are also content to receive merely a "\cJ". The old adage ``be liberal in what you accept, and conservative in what you send'' is still true today.

Under VMS, DOS, or derivatives thereof, a "\n" represents "\cJ", in a similar fashion to Unix and Plan9. From the perspective of a tty, Unix and DOS behave identically: a user who hits ENTER generates a "\cM", but this arrives at the program as a "\n", which is "\cJ". And a "\n" (that's a "\cJ", remember) sent to a terminal shows up as a "\cM\cJ".

But these strange conversions happen to Windows files as well. A ``text file'' in DOS actually contains two characters at the end of every line, "\cM\cJ". And the last block in the file has a "\cZ" in it to indicate where the text stops. When you write a line like "bad news\n" on those systems, the file ends up containing "bad news\cM\cJ", just as if it were a terminal.

When you read a line on such systems, it's even stranger. The file itself contains "bad news\cM\cJ", a ten-byte string. When you read it in, your program gets nothing but "bad news\n", where that "\n" is the virtual newline character, that is, a linefeed ("\cJ"). That means to get rid of it, a single chop or chomp will do it. But your poor program has been tricked into thinking it's only read nine bytes from the file. If you were to read ten such lines, you would appear to have read 90 just bytes into the file, but in fact would be at position 100. That's why the tell function must always be used to figure out where you are. You can't infer your position just by counting what you've read.

This legacy of the old CP/M file system, in which their equivalent of an inode stored only block counts and not file sizes, has been a source of frustration and despair to programmers for decades now. And there's no end in sight. Because DOS is compatible with CP/M file formats, Windows with DOS, and NT with Windows, the transgressions of the fathers have truly been visited unto the children of the fourth generation.

Some of this may be confusing. Here's a handy reference to the ASCII CR and LF characters. You can print it out and stick it in your wallet.

LF == \012 == \x0A == \cJ == ASCII 10
CR == \015 == \x0D == \cM == ASCII 13

| Unix | DOS | Mac |
---------------------------
\n | LF | LF | CR |
\r | CR | CR | LF |
\n * | LF | CRLF | CR |
\r * | CR | CR | LF |
---------------------------
* text-mode STDIO

The Unix column assumes that you are not accessing a serial line (like a tty) in canonical mode. If you are, then CR on input becomes "\n", and "\n" on output becomes CRLF.

These are just the most common definitions of \n and \r in Perl. There may well be others.

--tom

try going to 90% of webpages that have hard-coded font sizes in them.

--tom

The more UNIX-originated tools on NT the better.

The advent of freely available, plug-and-play substitutes for our standard Unix tools has been a great relief to victims of Big Bad Bill. These include the vi (vim, actually, but that's fine), Perl, the entire UWIN environment, the Cygwin suite, and of course, Perl Power Tools, which also work on non-{Microsoft,Unix} systems.

Some folks feel that we shouldn't port our tools to the evil one lest it thereby become easier to exist under his yoke, and thus perhaps decrease the chance of someone upgrading to Unix. But hold on there. Imagine that you're living in a fertile oasis of plenty, and on a dayhike, come across your friend toiling for his business in the searing desert that surrounds you. He is parched and crying out for aid. You invite him back to your oasis to refresh him, but he says that his job is there in the infernal sands. What do you do? Do you just walk away and abandon him? Of course not! You give him a sip or seven of that cool water you've brought with you from your safe haven.

So too should it be with our tools.

--tom

Some of you know what the Perl slogan on Windows is, and you can say it with me: ``It's a good thing there's more than one way to do it, because most of them don't work.''

I'm curious how it will avoid the insanely inefficient process start-up penalties one incurs under Microsoft, as well as how the non-shared data pages will be fast without being copy-on-write. The multiple-interpreters-in-one-process work will also help everyone.

I'd say to reserve one's fears until there's something to fear. ActiveState can't after all be all bad: they even list the Perl Power Tools on their pages to help people sentenced to tool-deprived systems. :-)

--tom

As for the definition of `interpreted', I will say that I would define Perl, along with the Bourne, C and Korn shells, and TCL as interpreted scripting languages, as opposed to Ada, C, C++ and Java, which I would define as compiled programming languages.

Nostagically relevant, consider pi, pix, px, and pc on old BSD systems for a Pascal environment. I can present you with Pascal source, and ask what it is. You cannot tell me. It could be run under a pure interpreter, a bytecode compiler-and-interpreter, or further translated into some machine's assembly language. All are still interpreted.

As an aside - don't Microsoft claim that NT is POSIX compliant? If it is, then why do they have to make custom changes to things like Java and Perl?

--tom

ianal, but the gist of it is that you can modify and redistribute perl as you wish, in accordance with some fairly lenient conditions (which do *not* oblige you to redistribute the source, although you get out of some other clauses if you do).

beware the trap of thinking that everything's gpl'd.

however, this can't really be as bad as it first looks. if microsoft go ahead and 'embrace' perl, what's the worst market it's going to affect? NT web servers? do we care?

This isn't necessarily an altogether Bad Thing (tm). It means that Microsoft must feel they are losing out by not supporting Perl fully. Unfortunately, the nature of the Perl source licence means that Microsoft don't have to publish the source for their implementation.

And before people start spouting off about how Microsoft shouldn't be allowed to embrace Perl like this, don't forget that the whole idea of Open software is that anyone can use it, and one of the reasons that Perl uses the Artistic licence, as opposed to the GPL is to allow companies to use Perl in commercial software. It's not something I personally agree with, but the creators of Perl decided to do it that way, and it was their choice.

I also foresee dire predictions that Microsoft will turn Perl into a proprietary technology, like they did with Java. However, so what if they do? Perl isn't like Java - for the most part, it's a server-side scripting language, not a half-compiled binary which is meant to run on the client.

The main thing is, don't panic. This will probably turn out to be good for Perl in the long run.

The Dodger

Lucky is a monadic parser. Monads are a very powerful way to resolve the contradictions between functional and object oriented programming philosophies. A monadic parser has all the elegance, flexibility, and raw power of a functional parser without the grammer constrains normaly imposd on a functional parser.

of a proposition, fact, function, etc., or the predicate contained therein, when the predicate is non-relational and applies to only one subject term. [emphasis mine --tchrist]

--tom

Man pages are too-kitchen sink for the clueful-newbie.

... manpages aren't required in SysV (they're a BSD-ism) ...

Unfortunately, technically speaking, only catpages not manpages are required. Perhaps that's what you meant. But even catpages are better than nothing.

...even GNU disses manpages ...

It's bad enough when you summon up a manpage only to be infuriatingly chidden by the FSF that `This documentation is no longer being maintained and may be inaccurate or incomplete.' Worse still is the situation with programs like diff or gnomecal, which are completely bereft of any manpage whatsoever. The FSF should be ashamed of themselves! This is one of the root causes of the notorious Daemon Linux project.

This lackadaisical attitude toward complete, on-line documentation is hardly confined to the FSF, although I hold them ultimately responsible for one area: Linux distributors. The Linux rebundlers inherit the problem from the FSF, and do nothing about it. Take SuSE for example. In virtually all other aspects a robust and coherent Linux distribution, SuSE confesses in their printed book that accompanies their CD that not all commands and functions have documentation. What a punt! They're just being irresponsible.

I suppose that one could in desperation invent some sort of rarefied alibi for the FSF's negligence here. They are, after all, more dedicated to principle than they are to mundane matters of quotidian utility. But for those who repackage and sell Linux distributions, no excuse can exist. These businesses are selling what they purport to be an integrated system, yet then have the audacity to confess that it is not. If the FSF won't fix this, then the resellers must. But the FSF really is the right place to fix it, because that way the fix helps everyone, rather than just one reseller trying to create a market advantage for themselves.

But this already depressing situation gets worse, far worse, before it gets better. You see, as programmers try to create something flashy enough to attract non-programmers, something critical has been lost. I'm thinking of those programs whose GUIs are the Way, the Truth, and the Light, whereby no man cometh unto the documentation for a given program save through its lauded GUI. If the information is not found under an About button or a Help button, it simply isn't available. Even if it were to be found there, how would you know it? Once you figure out each program's new set of hieroglyphics, these miserable shinyhappy icons and their cascading shinyhappy menus just aren't greppable. How do you in a non-manual fashion search through these myriad menus? How do you print them out? How do you create an index?

This situation in completely unacceptable.

Having recently tried out the whole Eterm, Enlightenment, and Gnome set-up, as duly impressed as I was with Eterm's manpage, I was severely underwhelmed by the attention toward detailed -- strike that, make it any -- documentation manifest in the other two. Miguel has assured me that what I had looked at was a mistake, that the released snuck out without the libraries' docs included. But I want more than only the programming libraries having manpages. If it's a command or a file format, it needs to be documented! Otherwise we're back to the mushroom school of systems management (keep us in the dark and feed us shit). Every little gnomic panel application and associated happycon needs a manpage, one that apropos and whatis can access, as well. Don't make me click with a mouse to find help and directions. I didn't spend thirty years mastering the keyboard and learning to read and write lengthy treatises merely to be reduced to a one-bit input device and a two-line output device.

Having to randomly hunt through manpages, HOWTOs, info pages, various programs' home pages out on the Web, per-program help pages, and stringsing the infernal binaries is shear madness As Henry Spencer observed, `Those who do not understand Unix are condemned to reinvent it, poorly.' Unified Unix manpages solved the insane situation in which you had shelves upon shelves of printed documentation that came with an IBM mainframe; these docs weren't online, so were unnavigable. Apparently we are doomed to repeat that unhappy history.

While it's true that I write all my books in troff, along with the traditional helpmates of eqn, pic, and tbl, please don't assume by this that I am particularly enamoured of that system. I'm certainly not. What I do expect in proper online documentation is the properties that manpages provide:

• All documentation must be contained and accessible from within the same on-line system.
• Available for independent on-line viewing, apart from the application.
• Format easy to read and write by humans, parse and generate by programs.
• Conveniently structured.
• Printable as a high-quality book using a typesetter.
• Searchable and indexable using standard tools.

--tom

Man pages are too-kitchen sink for the clueful-newbie.

... manpages aren't required in SysV (they're a BSD-ism) ...

Unfortunately, technically speaking, only catpages not manpages are required. Perhaps that's what you meant. But even catpages are better than nothing.

...even GNU disses manpages ...

It's bad enough when you summon up a manpage only to be infuriatingly chidden by the FSF that `This documentation is no longer being maintained and may be inaccurate or incomplete.' Worse still is the situation with programs like diff or gnomecal, which are completely bereft of any manpage whatsoever. The FSF should be ashamed of themselves! This is one of the root causes of the notorious Daemon Linux project.

This lackadaisical attitude toward complete, on-line documentation is hardly confined to the FSF, although I hold them ultimately responsible for one area: Linux distributors. The Linux rebundlers inherit the problem from the FSF, and do nothing about it. Take SuSE for example. In virtually all other aspects a robust and coherent Linux distribution, SuSE confesses in their printed book that accompanies their CD that not all commands and functions have documentation. What a punt! They're just being irresponsible.

I suppose that one could in desperation invent some sort of rarefied alibi for the FSF's negligence here. They are, after all, more dedicated to principle than they are to mundane matters of quotidian utility. But for those who repackage and sell Linux distributions, no excuse can exist. These businesses are selling what they purport to be an integrated system, yet then have the audacity to confess that it is not. If the FSF won't fix this, then the resellers must. But the FSF really is the right place to fix it, because that way the fix helps everyone, rather than just one reseller trying to create a market advantage for themselves.

But this already depressing situation gets worse, far worse, before it gets better. You see, as programmers try to create something flashy enough to attract non-programmers, something critical has been lost. I'm thinking of those programs whose GUIs are the Way, the Truth, and the Light, whereby no man cometh unto the documentation for a given program save through its lauded GUI. If the information is not found under an About button or a Help button, it simply isn't available. Even if it were to be found there, how would you know it? Once you figure out each program's new set of hieroglyphics, these miserable shinyhappy icons and their cascading shinyhappy menus just aren't greppable. How do you in a non-manual fashion search through these myriad menus? How do you print them out? How do you create an index?

This situation in completely unacceptable.

Having recently tried out the whole Eterm, Enlightenment, and Gnome set-up, as duly impressed as I was with Eterm's manpage, I was severely underwhelmed by the attention toward detailed -- strike that, make it any -- documentation manifest in the other two. Miguel has assured me that what I had looked at was a mistake, that the released snuck out without the libraries' docs included. But I want more than only the programming libraries having manpages. If it's a command or a file format, it needs to be documented! Otherwise we're back to the mushroom school of systems management (keep us in the dark and feed us shit). Every little gnomic panel application and associated happycon needs a manpage, one that apropos and whatis can access, as well. Don't make me click with a mouse to find help and directions. I didn't spend thirty years mastering the keyboard and learning to read and write lengthy treatises merely to be reduced to a one-bit input device and a two-line output device.

Having to randomly hunt through manpages, HOWTOs, info pages, various programs' home pages out on the Web, per-program help pages, and stringsing the infernal binaries is shear madness As Henry Spencer observed, `Those who do not understand Unix are condemned to reinvent it, poorly.' Unified Unix manpages solved the insane situation in which you had shelves upon shelves of printed documentation that came with an IBM mainframe; these docs weren't online, so were unnavigable. Apparently we are doomed to repeat that unhappy history.

While it's true that I write all my books in troff, along with the traditional helpmates of eqn, pic, and tbl, please don't assume by this that I am particularly enamoured of that system. I'm certainly not. What I do expect in proper online documentation is the properties that manpages provide:

• All documentation must be contained and accessible from within the same on-line system.
• Available for independent on-line viewing, apart from the application.
• Format easy to read and write by humans, parse and generate by programs.
• Conveniently structured.
• Printable as a high-quality book using a typesetter.
• Searchable and indexable using standard tools.

--tom

Doubtless that's because you're a Prisoner of Bill. For the rest of us, it's garbeldy gook, because it's not legal HTML. If you fetch the raw page, and get a nice octal dump, you'll see what I mean.

My point was simply that I felt that when Slashdot points us at a site that requires a special setup to view (for example: you must register; or you must have a valid referring page; or you need Flash installed; or you must have tithed Lord Bill) that this merits special notification of this unpleasantry.

I assure you that I certainly did "check my facts" before posting. Did you?

--tom

Perhaps in much the same way as /. warns about registration required when pointing at the New York Times, it might also be useful if you would include a warning when Microsoft is required for proper viewing of a page you link to.

• No one person, or culture, is right or moral all the time. We should value our ideas and our culture, but we shouldn't assume that they are the source of all virtue or knowledge, and that other people or cultures have nothing to contribute.
  
• Because nobody is right all the time, we need to seek out information from people we disagree with, or who have different perspectives, in order to become educated. This doesn't mean that every perspective is equally useful, only that there's no single perspective which contains all the information in the world.*
  
• Because no culture is right all the time, it follows that our culture is sometimes not right. Some of the rules, generalizations, and assumptions which we are taught aren't true -- or at least aren't entirely true. We need to find out which ones aren't true, and quit teaching them to each other.
  
• An "original" idea isn't entirely original. It depends on a lot of cultural context, and on a lot of precursor ideas. (There would be no Perl without C, sh, awk, and so forth.) Hence while the nominal author of a work has indeed made something new, s/he hasn't made it ex nihilo. To paraphrase Newton, every great author or creator stands on the shoulders of giants -- and him/herself tends to have a few others on his/her shoulders as well.
  

There's a page on the perl site that has a link that describes something called MS-HTML. Apparently, this is an intentional plot by Uncle Billie. Check it out.

I have my own gripes about the pricing for the ORA conference, but I don't know there is much that can be done. This year it is in Monterey, which will be even more expensive, I think. But realize that the ORA conference is not for hackers, it is for businesses. The market the Perl Conference is aimed at, it seems, is used to paying that kind of fee for a conference. And hey, it helps pay for www.perl.com, so it can't be all bad. :)

It's not all that hypothetical.... If you're willing to brave an alpha version, have a look at Perlmacs. I expect to have a new version out RSN. It's getting stable enough to call beta.