On Tue, Aug 14, 2001 at 09:50:40PM -0700, Jason W. May wrote:
> So, to paraphrase:
>
> * There are some languages (not Perl) that are "well-defined", presumably
> meaning that they change very slowly.
Not necessarily. Languages often change more slowly as they become
more clearly defined, but well-defined != stagnant.
> [I would challenge the implication that Perl doesn't have thorough
> documentation, but I don't think that's what you meant.]
Yes and no. Perl's documentation is long on tutorials, examples, and
overviews. It's short on technical guiding principals (`TIMTOWTDI'
notwithstanding). There's redundancy, inaccuracy, bloat, holes in coverage,
and mediocre cross-indexing. There are good reasons for this, and I love
Perl; but, C and Java, e.g., suffer from _different_ deficiencies.
I can study the BNF grammar of C in K&R, and I can read about sequence
points in the ANSI C++ spec; yet, there's no formal grammar or VM definition
for Perl. Can you imagine developing an independent implementation of Perl,
and saying that it's `to spec' with a straight face?
> * "Well-defined" [WD] languages are better choices than "less-well-defined"
> languages if you want to:
s/are/can be/;
> * 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?
It's evolving very quickly, and an exhaustive, frozen, formal core
language definition was never a priority. But all that will change when
Perl 7 ships. ;^)
- Kurt
