Here is something provocative I found, provoked by chromatic, at http://use.perl.org/~chromatic/journal/32416, who had been provoked by a #perl6 comment about slow parrot development.
DeMorganized, 'Quick, cheap, good: pick two' becomes, 'Late, over-budget, no good: pick one.'
Or, 'We don't need no stinking deadlines.'
The other point of view is, 'Release early, release often.'
'Quick, cheap, good: pick two,' can be paraphrased as, 'Slow and steady wins the race.'
The opposite point of view is, 'By fits and starts, as the hog pisseth,' which I found in a dictionary of Japanese proverbs, where it is given as the English equivalent of 'Usagi no fun,' literally, rabbit droppings.
I couldn't remember the name of Module::CoreList, the module that tells you in which version modules in core made it into the core. I thought it was CoreVersion, but searching for core and coreversion and version on cpan didn't turn it up.
[Actually going back, now I find it's between 300-400 of the 1456 modules CPAN search returns for 'core'. But that's too far at the back. I didn't find it, anyway. I was turned off by Lingua::Stem, README.hpux, Chemistry::Atom in the list before it. All good modules, probably, but not at this moment.]
Googling on 'perl how tell what version core module dual life cpan made' also didn't turn it up.
I hope this message will make it easier for me when I'm looking for it next time. Easier because either Google finds it, or I remember I posted here about it.
I asked on freenode's #perl and someone gave me the answer straight away. Buubot there also answers questions of the form 'core:Module::CoreList'
You can use Module::CoreList this way to find when it made its own way into the core.
perl -MModule::CoreList -e "print Module::CoreList->first_release('Module::CoreList')"
Why do I want to know? I want to know how much I may require a user to install by using certain modules.
But perhaps there is a more extensive way to answer such questions.
Larry Wall joked in the 10th state of the onion address at http://www.perl.com/pub/a/2006/09/21/onion.html:
"In the Scientific American that just came out, there's an article on chess experts, written by an expert, on what makes experts so expert. This expert claims that you can become an expert in just about anything if you study it persistently for ten years or so. So, since this is my tenth State of the Onion, maybe I'm about to become an expert in giving strange talks. One can only hope (not)."
The August 2006 Scientific American article is at:
Leaving aside whether Larry Wall is an expert in giving talks or not, I think the message of the article is not that message. Rather, it is that if there is anything we learn after 10 years' studying experts, it is that experts know more than we know.
Here's the ancient Chinese philosopher, ChuangZi's reaction to the address, which was about raising children and programming languages and balancing competing tensions and irreconcilable desires. ChuangZi was puzzled. He asked, Is this a programmer talking about his family? Or a family man talking about programming?
A Larry Wall story: Larry Wall leaves the podium, in an altered state of consciousness, asking, "Was I a man dreaming I was a butterfly? Or am I now a butterfly dreaming I am a man?"
I'm really excited by osfameron's Perl::Tags with vim, because it creates tags as you go. Tags are great for clicking your way round your code. However vim's tags are created statically.
Perl::Tags creates them dynamically as you jump from one module to another. The problem before it was, You never knew where you were going to go, and it was impossible to create tags for all the things you might be interested in beforehand. So you ended up never using tags outside your own code.
But with Perl::Tags, you don't have this restriction. It helps me moving back and forth between my garden of relatively well-understood code and the jungle of code outside my garden which I need to subdue.
You can also write regex to create tags not just for subs, vars and packages, but for anything you can parse. ctags could do this, eg tagging Spiffy fields
ctags "--regex-perl=/^\s*field '?(\w+)(';| =>
But it's nicer to be able to do it as part of a perl module.
The TAKAHASHI METHOD seems to be to talk as fast as you can and to rub it in for those who can't understand you by showing slides with only KEYWORDS from the talk as large as you can project them. You can read my lips if you can read LARGE FONTS, so to speak.
That's a JOKE for second language speakers, who know the importance of having slides for a a talk. In fact the Takahashi method, as well as being a humorous method, seems well suited for LIGHTNING TALKS, where the speaker has come to brain dump but the audience has the brain capacity to absorb more by looking at a poster.
Takahashi http://rubycolor.org/takahashi/takahashi/img0.html sees the characteristics as:
a. VISIBLE to the people at the back. Better than for someone to tell you, 'Your presentation was great but only the people at the front could see,' is to hear, 'Your presentation was ordinary, but everyone understood it!' I guess that one doesn't translate so well.
b. For the presenter, keywords are POINTERS to appropriate content, helping them determine what their point is at each point in the talk when writing it or delivering it.
c. Because there are many slides, one for each couple of sentences perhaps, it makes it EASY-TO-DELIVER by requiring the presenter to decide what to say in a lot of detail before delivering the talk. This makes it good for people who suffer from stage fright.
d. Because there is little information on the screen it helps the listeners CONCENTRATE on what is being said, rather than on trying to read the slides.
Reading the slides, rather than listening to the presenter, can be the first step in not hearing, or not understanding, something.
I may have MISCHARACTERIZED what is on the screen by saying just keywords appear. Takahashi seems to include whole noun phrases in his slides. HEADLINE-type sentences is how a Wikipedia entry characterized them, I think.
Masayoshi Takahashi seems to be another perl humorist.
Actually, judging from his presentation at YAPC::Asia::2006
he is a ruby humorist, rather than a perl one.
In the slides, he says Ruby, like perl is TIMTOWTDI, but rather than leaving the choices up to the programmer, it encourages one option rather than the other, eg the optional semicolon at the end of lines naturally starts to seem noisy and you are 'forced/encouraged' to omit it.
On the one hand, you write the way you like, but on the other hand, you are also 'brainwashed' to like the way you can write.
So perl is for the superhacker who loves options, but ruby is for the ordinary, lazy (but not lazy enough) programmer and it changes the way they think.
So Ruby is a dangerous language, he concludes. You come to think I am so cool, and this feeling of power is without basis. So he says, don't use it yourself, recommend it to everyone else.
I guess it is tongue-in-cheek. The Japanese audience laughed a lot.
Steve McConnell in Chapter 5 of Code Complete (http://cc2e.com) says:
Coupling describes how tightly a class or routine is related to other classes or routines. The goal is to create classes and routines with small, direct, visible, and flexible relations to other classes and routines, which is known as loose coupling.
Loose coupling is also a term in management (http://jmm.aaa.net.au/articles/8677.htm):
Weick made the practical connection that schools simply did not behave like industrial or commercial enterprises. He acknowledges the writings of Glassman (1973) and March and Olsen (1975). From this area of study arose the concept that there were critical differences between what came to be called HSOs (Human Service Organisations) and profit-centred businesses. One of these differences was that the main business of HSOs, whether hospitals or schools, happened between professionals (doctors, nurses, teachers) and clients (patients or students). This primary business was supported by a backbone of administrative and resource services. Another description of this sort of organisation was presented by Kouzes and Mico (1979) under the heading Domain Theory. The key discovery that these writers (and Weick) both made, was that Administration was not the main source of expertise and decision making, disseminated through a hierarchy of management and workers. Rather, administration and the professionals tended to
have different roles, independent authority, low levels of standardisation and even different agendas.
Loose coupling was the name for the operational links within such a structure. The theory of loose coupling not only explains how HSOs operate with such links, but attempts to explain why they are able to function with what at first glance many seem an inefficient and ineffective structure. Weick asks "what does hold and educational organisation together?" (1976, p4).
Can the effect that version source control has on the relation between development and a project, freeing the coder from the consequences of test failure, also be regarded as a form of loose coupling?
The first question I asked Audrey at OSDC.tw was was the new name of pugs Bugs. She said that Larry's Bugs Manifesto http://blog.livedoor.jp/dankogai/mov/lamdaorz.mov was an April Fool's Joke.
What a disappointment!
Before going any further, here is some material on Taiwanese bugs. I tried looking round for an Internet Taiwan bugarium, but couldn't find one. Here's he National Taiwan University Department of Entomology's collection of Chinese paintings of bugs. http://www.entomol.ntu.edu.tw/index-c.htm
I find the Bugs Manifesto moving. I'm not too sure why. It's probably the delivery and the fact I can't understand what Larry is saying.
In actual fact, he's probably just taking off Josh McAdams' Southern accent in the perl podcasts http://www.perlcast.com/ And the text appears to be a pastiche of Audrey's manifesto at http://pugscode.org/talks/oscon05/movies.html
But I prefer an alternative scenario.
Picture Larry, as a teenager, listening to the bugs one summer night after a tiring, but rewarding, afternoon playing the violin with the youth orchestra, and the night music reminding him of the music he had been playing a couple of hours before.
Stirred to listen to some more classical music, he turns on the radio and searches around for the local classical music station, but at the expected frequency, instead there is a country music station with a powerful transmitter, welling up from the South on the night air. The mood is spoiled and he thinks: 'Where'd those hillbillies come from? Get them out of here!'
More than 20 years later, in Japan, the fact bugs rhymes with pugs allows him to have some fun with that memory and the work of Josh McAdams and Audrey.
Audrey played the manifesto at her perl6 tutorial at OSDC.tw. Again, I was moved. But I'm glad I had first heard it before seeing Larry delivering it. (Apparently I don't have the right compression program.) The visuals of Larry delivering the manifesto overpower the message of the manifesto.
Here is this guy jumping up and down and twitching. I too recognized Scientology's lord master Xenu. http://perlmonks.org/?node_id=540655
Hey! If Larry can make fun of the South, Josh McAdams, country music, perlcast, Audrey, Taiwan, pugs AND bugs, we can make fun of him too.
I asked Audrey at OSDC.tw if perl had dialects. I didn't think it did. I regarded it as monolithic, not about to fork.
On the other hand, not knowing much about python, and seeing all the double-barreled python names, like Jython, and PyPy and so on, I thought other languages did have dialects.
Audrey said of course it has dialects, giving me Ingy's modules as an example. I had thought only Perl/Tk would qualify as a dialect.
Of course there is the issue of what is a language and what is a dialect.
Interestingly, Chinese people apparently regard the differences between
Cantonese and Mandarin and Taiwanese as differences of dialect, while Western
linguists call them different languages because they are mutually
But then there is a saying that a language is a dialect with an army and a navy.
Here's a translation, from a Ruby list, of Matz's slides to his YAPC::Asia talk on why Ruby will not use Unicode, Ruby on Perls.
(That title brings to mind, Cinderella on Ice.)
Linkname: [rhg-discussion] [ANN] Ruby Hacking Guide - New chapters
(and a bonus)
From the end, Unicode is practical, but not a panacea. Character Set Independence, on the other hand, is not an impossibility.