"... Exposing implementation details in an API is a flaw, not a
I'm only partially convinced with you here as too many API references would
look like noise. I do, however, get a warm a fuzzy feeling that the
technology is used widely when I see lots of 'powered by' logos or websites
that are dedicated to telling you how many companies use a given technology.
Here's a post by Bjørn Hansen <http://askask.com/
> regarding a Powered by
Perl logo: http://www.askbjoernhansen.com/2005/03/11/powered.html,
exists but I have no metrics as to whether it is in wide use or not.
Anybody know where the metrics are located?
"It is however not a testament that Perl encourages people to
build well-designed web applications..."
Yes, but then what is? Let's think creatively here. Let's assume that
putting /perl/ in your URL is not the greatest way to promote Perl. Give me
three other suggestions that I could give to a team that is relying heavily
on Perl and would like to help other companies that are 'on the fence' with
regard to using it.
"Why would 90% of those companies download Perl for evaluation, and then
not use it?"
Here, of course, I have to question the integrity of the data. If I get a
number, let's say the number 60, and this number represents the number of
people who downloaded an online tool that does a wide variety of things, can
I reliably report that 60 people are 'users'? No. User A may have
downloaded the tool three times. User B may have downloaded the tool to
test it and see what it does. User C may have some automated script that
downloads the tool every 30 days. Ultimately the download statistics are
murky and more information is needed.
The thing to keep in mind here is the audience. You are an IT manager. Are
download statistics going to be compelling to you? I think they offer
supporting information, but in themselves are not that informative for the
reasons I've mentioned.
"Why are system administration tasks (installation scripts?) inferior to
online support systems?"
For quite a few reasons that I can think of -- a) security is typically much
more of a concern for a system that is intended to be run by strangers;
scripts are typically run in-house by privileged users only b)
administration scripts are run and developed by a few people whereas many
more eyes/hands/minds touch web utilities c) the list goes on. I think the
most compelling reason is COST. The system administration script is
considered by IT management to be free whereas the online support system
involves inherent costs of maintenance, development, deployment, etc.
"Any organization of significant size uses all of Perl, Python,
Ruby, Java and lots of other things."
I work with very large organizations and I know precisely what they tell me
when I start talking about three of the languages you mentioned (Perl,
Python, and Ruby) -- no, no, and no. Java is the only one that is accepted
and I suspect it is not because it is the best but rather that Sun and other
companies that heavily use Java have done a very good job of advocating for
it. I would like to see Perl do the same thing.
"It is nice to have stories about extra-ordinary uses of languages (e.g.
how a Tcl script remote-controls the Mars Rover)..."
I'm for whatever works. If we study the opinions of developers and find that
they are impressed by Perl being used in the next generation of deep space
exploration tools then promote that. If that doesn't work, it is time to
think of something else. Like anything, the opinions, tastes, and thought
processes of people shift over time. The goal of advocacy is to map those
opinions such that your message will become associated with things people
like and avoid things that cause rejection. (This problem is compounded
with computer languages because we actually have to deliver the goods...but
that is for another discussion.) If I blindfolded you and handed you three
pieces of cheese your individual tastes -- cultural, sociological, etc. --
would kick in to tell me which type you liked and which made you want to
throw up. Advocacy (like marketing) should take this into consideration when
formulating its core message. So, before saying that /perl/ in the URL has
no effect, we should run a study to determine whether it has an effect on
developers and IT managers.
"OK, so what do you want to have happen?"
Before I can answer that I need to know how Perl advocacy is currently being
done. I'm big on studying a problem and using actual data to drive results.
I know there is a problem with Perl advocacy because I spent about an hour
reading almost all of the posted responses to a recent Slashdot article
about a Rakudo Star release. I would say the responses were mostly (> 90%)
So, how is Perl advocacy done? Is there an actual advocacy organization
with yearly goals, some people who officially head up the organization,
etc.? What are the 2010 goals? 2011? Is there a central Perl portal for
'all things advocacy' which contains the current meeting minutes of this
"https://www.socialtext.net/perl5/index.cgi?companies_using_perl ... but
I don't think there is a real added value in such list."
Thank you for this post. There is an excellent book I recommend that
everyone who is even remotely interested in Perl advocacy read -- The
Tipping Point by Malcolm Gladwell (http://www.amazon.com/Tipping-Point-Little-Things-Difference/dp/0316346624).
In the book there is this story about another guy who rode around
immediately prior the British invasion on April 18, 1775 but rousted very
few colonists to action. Paul Revere took a different route to bring people
to arms against the British and history tells us he was incredibly
successful. Gladwell analyzes the differences between their routes and
methods and finds no significant difference. However, when you study WHO
these men were we start to understand why Revere's ride was a success and
the other fellow's fell flat. The difference was in the men themselves.
Revere was well known and popular. His character beamed and people trusted
him. The other fellow did not possess these qualities, so people were less
inclined to leave their homes and risk death.
The URL you posted is a bit like the other fellow's ride -- it is on an
obscure site, not centrally supported (as far as I can tell), and the
message is therefore not as effective as it could be.
On Fri, Aug 13, 2010 at 1:05 PM, Jan Dubois wrote:
Joel Limardo wrote:
I disagree that your example discounts my point -- downloading Perl is
not the same thing as building your online support system with it and
not only leaving the .pl extension on your pages but leaving /perl/ in
the URI. The latter publicly says, 'hey, by the way...we use Perl and
we rely on it for something that we consider to be fairly important'
versus the fore which could mean virtually anything (evaluation,
installation scripts, etc.).
Sorry, but I disagree with your additional points as well:
1) Leaving "/perl/" and ".pl" in the URL does *not* mean: "Hey, we are
using Perl to do this and are proud of it." It rather means that
they didn't bother to think about providing meaningful URLs for
their application. Exposing implementation details in an API is
a flaw, not a feature.
Of course this may be all completely justifiable, given that the
system may be just a quick hack by their support group. It is
however not a testament that Perl encourages people to build
well-designed web applications.
2) Why would 90% of those companies download Perl for evaluation,
and then not use it? Do you expect it to routinely fail in
evaluation as being unfit for actual use?
3) Why are system administration tasks (installation scripts?)
inferior to online support systems?
I think the difference here is significant. Is it enough that people
and companies are using Perl and not talking about it, or should they
be clear that they use it and rely upon it? Isn't it in the
interests of Perl advocacy to present evidence that Perl is not just
used but that it is relied upon and can handle more system
Any organization of significant size uses all of Perl, Python, Ruby,
Java and lots of other things. It is nice to have stories about
extra-ordinary uses of languages (e.g. how a Tcl script remote-controls
the Mars Rover), but a list of companies that use any particular
mainstream technology for their bread-and-butter work isn't that
compelling IMO. Especially if we don't have any additional insight
into the scope of the application, and the challenges that had
to be overcome.
So background stories of big applications written (mostly) in Perl
would make good advocacy. Crawling the web for URLs that match
m,/perl/, or m/\.pl$/ not so much.