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
