When I was in school, I used to get in trouble in math tests for writing the answers to problems without showing at all how I worked it out. Sometimes I couldn't really explain it myself either, because it was obvious. You can see the answer in your head! It's just that it's in a totally different way to how we were taught.
Of course, where this differs from the childhood stories of supergeniuses (which I'm most definately not) is that in skipping over the workings I'd tend to make mistakes about a third of the time and get it wrong, and without workings that meant some really ugly math scores from time to time.
I still do the same thing today. I jump to conclusions way ahead of an explanation, based on introductory and sketchy data, and yet I see things correctly... some of time. After years of being embarrased by mistakes sprinkled with the odd stunning success, I've gradually come to think of it as more of well developed hunch muscle. I treat the hunches like the CIA treat intelligence from shady allies that have hurt you in the past. Trust, But Verify. Go with the hunch, but find as many smart and aggressive people as you can to attack you and tear your idea apart. #perl is invaluable in this regard :)
In software development, I've had some big hunches. Some concepts and designs I genuinely think might be able to change the Perl community, the IT industry, or the country. Anything that emerges from #perl with a "show me the code" makes this list. While I may not find time to do them all myself any more, I'm fully committed to making them happen any way I can.
They may just be hunches, but in secret (till now) I like to think of them as my Plans for World Domination. Until today there were six. Some of you may recognise a few. Some probably sound like gibberish.
#1 A Perl/CPAN WebApp Codegen Quine
#2 It IS possible to write a Perl parser
#3 Lazy Ammortized-O(1) Infinitely-Scalable Web Image Delivery
#4 IPC-Over-IRC Behaviour-Based Spam/Virus Prevention
#5 CPAN for JavaScript
#6 (To be announced soon)
I hinted at #6 in my last post, but I'll leave it to the new benevolant dictor for the project to announce. It's his baby now.
And with #5 there turned out to be three or four people in the Perl community all converging on the JSAN idea at the same time so it probably doesn't count. David Wheeler made it possible with Test.More, and Casey West executed incredibly quickly. Hurray for JSAN!
But now a new plan has snuck up on me unawares. While slowly talking to people about it to garner interest, someone I respect has grabbed me this morning and said "We need do this, and it needs to happen RIGHT NOW!". So it's launching now, and the press releases are going out shortly on the following idea.
With the now-ready-for-prime-time OpenOffice.org 2.0 release due next month, the next major problem preventing migration to OpenOffice.org is: How do Microsoft Office users read OpenDocument files we create and send to them?
And so, World Domination Plan #7
Microsoft can't or won't add OpenDocument support to Office. So we add it for them, for free.
I'm calling it OpenOpenOffice :)
Using Perl, and a bit C#/.NET, we can relatively easily add support for the three main OpenDocument/OpenOffice.org formats (Writer, Calc, Impress) to Microsoft Office. And do it completely legally, despite them not liking it. And with some effort, we may well be releasing 1.0 in a month.
How? As I've mentioned before, sometimes it's just a case of looking at things a little bit backwards, then the rest is obvious. It goes like this.
1) OpenOffice.org can convert files from Microsoft Office to OpenDocument, and from OpenDocument to Microsoft Office.
2) The OpenOffice.org team are going to keep making these filters better and better, with no effort needed by us.
3) What if we just flipped the import/export filters around and made Microsoft Office use them backwards.
4) Actually integrating that code, or requiring an Office user to install OpenOffice.org would suck. Let's not do that.
5) We need a swiss army chainsaw to plug them together remotely. Perl!
6) C# can talk to Microsoft Office. Perl can talk to OpenOffice.org. C# has SOAP client libs. Perl has well tested standalone and Apache SOAP server CPAN modules.
7) Whip up a SOAP server that talks to OpenOffice.org via generated macros. Release to CPAN.
8) Whip up a Microsoft Office SOAP-client import filter. Wrap it up as a .msi installer. Release $somewhere.
If Microsoft won't do the right thing and add support for a document format they voted for in committee, we'll just have to do it for them. And if we are very lucky, OpenOpenOffice will be doing a better job of their import/export than Microsoft does once they finally get their import/export ready. :)
At the very least, it will be an incredibly fun thing to get out there.
Microsoft Office, Powered By Perl.
What an interesting ring that has to it...
Wanna help? :)
