|Perl: the Markov chain saw|
Perl's scope is getting better, but still very prime, and hacked (this is one thing I really hate about Perl, Perl has too much hacked pacthes and concepts, it almost become a daily routine in Perl, why don't they think in a systematic way??? largely because Perl is building on a poorly defined foundation!)
Some examples please. Perl is pretty consistant in it's structure in my opinion, certainly not radicallly inconsistant compared to other languages. The lack of a defined foundation can be considered an advantage. Perl shamelessly steals interesting things from other languages. Perl6 is carrying on this tradition. I far prefer useful functionality to theoretical purity.
Perl's OO is hacked, which hurts modulization that is a main contributor to maintainability in all modern languages.
This is arguable. It lacks useful things like direct support for private methods/attributes. However, these can be implemented using other language features. It's rarely an issue in real world code in my experience.
You can make arguments about Java's OO too (lack of generic classes, lack of multiple implementation inheritance, non-OO base types, etc.).
Again, these are arguable points (well, except for generic classes - not having those was insane and will be fixed in the next version :-) There are good reasons for non-OO base types and interfaces - but there are also disadvantages.
perl is not a stable language, it is still RADICALLY (don't read this sentence without this word) evolving, and many times, that is done by hacking. There is a delimer for Perl, because the original design of this language is flawed, you have to either radically modify it, or to keep it familiar but with lots of
Completely disagree. Perl has been remarkably stable. I've still got perl4 scripts running unchanged in perl 5.8. It has certainly evolved, but it's kept compatability to a remarkable degree.
Java has gone through a lot of changes too since it was first released and is still having major features added (witness the proposed addition of generic classes to the next version.) I've had people working on projects where they have had to completely gut elements due to changes in the "standard" libraries :-)
Again, I beg to differ ;-)
Its language independent. I've seen a lot of terrible perl code. I have also seen a lot of terrible C, C++, Java, insert-language-of-choice code. I've seen great perl code. I've also seen great C++, C, even assembler. Bad programmers write bad code. Period.
Now, you can make an argument that it is easier to write bad code in perl than it is in some other languages. Personally I'm undecided on that issue. However, in my opinion, even if this is true it is part of the price you pay in having a flexible language that enables a good programmer to produce good code in a timely manner.
This is why many people can and do use perl for serious commercial projects.
I've not chosen to use perl for fun (well, not just for fun :-). Fun doesn't pay my rent.
I've used it because it's a useful language. I've used it because people pay me to use it. Whether that be because they have existing perl code that is doing its job very well, or because it is easier (aka cheaper) to develop a solution in perl than any other language. I've used it because some CPAN modules cut development time to almost nothing compared to Java/C++/whatever (try an API with multiple-database support as good as DBI in another language).
I don't think perl is a silver bullet. I don't use it for everything. I don't recommend it for everything. I've even regretted using it on occasion. The same applies to every other language. There is no silver bullet.
You use the right tool for the right job. Perl can be that tool a great deal of the time.