>>> "... Exposing implementation details in an API is a flaw, not a feature."
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, which 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%) negative. 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 organization? >>> "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 <j...@activestate.com> 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 > > administration tasks? > > 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. > > Cheers, > -Jan > >
