Technologies to Watch: A Look at Four That May Challenge Java’s Development Dominance
Subject:   Oh, and the original intent.
Date:   2005-11-03 13:16:53
From:   evoke
Response to: Oh, and the original intent.

Pardon ?

For a terse textbook example this seems relevant, of course. For a 450000 line project with 900+ classes, I've just searched for main() methods and found only 7 instances, 6 of which are for various quite familiar cmdline batch utilites and 1 of which is for a rich client entry point. Which isn't very convincing to me that typing this in is exactly killing the project...

If the likely counterargument is that, ok, but surely typing in 'public class' goo is bothersome...I don't actually think I've actually typed that phrase in 2+ years.

And I'm not being facetious, it's merely because in production-level projects it rapidly becomes best practice to clone proper header block with copyright disclaimers and cvs dollar-tag blocks, and javadoc tags and a class defintion already set up, etc. In my particular case I've even gone the minor laziness farther of binding that static text chunk to a function key in my editor to eliminate the cut-n-paste bother. Tap-a-key simple. But even without the key binding, not exactly overly bothersome.

I do admit, being adept with Lisp and Python and yet coding Java for the corporate master, that there are cases where Java's language limits lead to inconveniences and pattern insertions that I grrr against, such as, say, lacking a covariant return type. However the mere goo of typing a 'main' or 'class' definition, or accessors, isn't compelling in itself, as we have trivial key bindings and Eclipse and IntelliJ one-button clicks and so forth for that stuff.

If you want to convince me that Ruby can rock steady with increased productivity, I'd contend you ought to avoid omissions of complexity and persuade versus examples of SlickEdit tricked out with macros and key bindings, or an experienced dual-use Eclipse / IntelliJ developer.

Closure and code blocks and covariants and so forth are where Ruby and Lisp and dynamically typed languages start to slay. Goo is not precisely fluffy, but isn't, I would assert, a compelling debate point, particular toward the middle and higher range projects where you assert Ruby needs to go, where all manner of assorted copyright and cvs tag and etcetera goo are already being neatly aggregated, dealt, and dispensed with.