Kurt Starsinic wrote:
>
> I wasn't talking about external standards bodies per se, I was talking
> about languages that are perceived as well-defined, where the implementation(s)
> match(es) the thorough, authoritative, and slow-moving documentation. Perl
> is not that (and I am not complaining).
>
> > What are some legitimate reasons why this might be seen as essential?
>
> Well-considered, justified, realistic intentions to:
>
> Develop a large code base over time;
>
> Hire people with substantial expertise in the language, and have
> that expertise compliment the skills of current employees;
>
> Develop formal coding guidelines;
>
> Support a large, diverse, customer/platform base.
>
So, to paraphrase:
* There are some languages (not Perl) that are "well-defined", presumably
meaning that they change very slowly.
[I would challenge the implication that Perl doesn't have thorough documentation,
but I don't think that's what you meant.]
* "Well-defined" [WD] languages are better choices than "less-well-defined"
languages if you want to:
* develop large complex applications
* build internal expertise
* establish formal internal engineering processes
* "support a large, diverse, customer/platform base"
These conditions exist within many corporate IT organizations. And it's these
organizations that are choosing Java, C++, etc. for their projects, rather than Perl.
I still don't quite see the clear link between the requirements you listed and
the language. Why do you think it is that Perl is not considered satisfactory
for these purposes?
-Jason
