It appears to my clouded lens that Perl's lack of strong typing and contract enforcement has allowed it to be as backwards-compatible as it is (arguably moreso than Java), although it seems you hold Java to a double standard since there are quite a few modules out there that require, for whatever reasons, versions of Perl more recent than Perl 1.0 (if it ever existed) - CPAN, great as it is, doesn't solve the difficulty of adding new language features and having new libraries dependent on those new language features be backwards compatible. Are you going to make all your programs Perl 4 compliant? How about Perl 3?

One of the things that's seemed to be an everpresent problem in CS is that designing for the future is hard. You just can't foresee all the problems that might crop up. YouArentGonnaNeedIt and YouAreGonnaNeedIt are always ridin up and down that seesaw of long-term planning, and I think it's unreasonable to expect to that language specifications shouldn't also evolve with the programmers using those specifications. It'd be great for them to get it right the first time, but how often does that happen? Why do notions like refactoring have books written about them?

I'd argue that writing programs in a 'foolproof' way is hard to do in Perl, just as it is in Java or any other language. However, the addition of type safety is sometimes a GoodThing, since it mitigates the risk of client code (code using any given API) screwing up by having arbitrary functions executing arbitrary things. I want to idiot-proof my code, not because I think other people are idiots, but because I know I _am_ an idiot, and I'll screw things up every chance I can get.

Don't get me wrong, I really like perl a lot (and am still learning!), I was raised on Scheme and C/C++, but I also respect Java's place in the PL hierarchy (although they should have at least handled recursive tail calls properly... that's a different story though ;). It's just that having non-static typing means that you can't make as strong a guarantee of what you can or can't do with a symbolic name. It means that my subroutine can return an integer half the time, or another subroutine as a first class value the other half of the time. It means that if in my program, if I accidentally re-assign my $shared variable somewhere (even with lexical scoping), $shared might be a hash reference instead of an array reference. Of course, I can add a check at runtime using ref(), but sometimes it's nicer to have that check made for me at compile-time so I don't have to wait and write a unit test to realize that I'm bungling something. Perl is great for flexibility, brevity, expressiveness-in-shortest-number-of-lines, and, in general, becoming a very 'natural' and idiomatic language to speak in, but but it also provides a lot of ways for me or the person coding to my framework to screw up by localizing the wrong symbolic name at the wrong time or whatever.
To me, one of the biggest strengths of Java is its ability to enforce contract-based programming. You can ensure that implementors and client-developers follow the contract that you lay down to some stronger degree than most other languages... for instance, (example shamelessly lifted from the way JUnit does things, basically an example of the Template Method from the GoF):

public abstract class Goo implements Gooable {
   protected abstract void doSomethingThatRequiresSetup();

   public void doSomething() {
      setUp();
      doSomethingThatRequiresSetup();
      tearDown();
   }


   public void setUp() {
      ... initialize network connections and blah blah blah
   }

   public void tearDown() {
      ... close network connections and any open files
   }
}
[download]

Granted, this contract is still a little weak, since we have no guarantees as to what doSomethingThatRequiresSetup() does, but we can guarantee that the initialization and finalization steps occur, if J. Random Implementor does decide to extend the Goo class and implement the doSomethingThatRequiresSetup() method. Of course, it is still possible to screw this guarantee up by spuriously subclassing the Goo class and overriding the behavior of doSomething(), or directly invoking doSomethingThatRequiresSetup(). As always, one should always favor composition and delegation to inheritance, but that's just part of the lingo. It's like getting slapped here for not use strict; or to turn warnings off or to not untaint user input that's going to be inserted into invocations of system() or exec() (or even sending user input to system or exec commands for that matter).

Besides, no language holds a candle up to Scheme ;). Where else can you smash your brains out with the power of hygienic macros and call/cc? Not until continuations become first class values in Perl 6 at least :).

wow, that's a lotta blathering. apologies for the rambling - flames/corrections/thinly-veiled insults are welcome!

Allen

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.