Skip to main content

Cleaning things up

1 reply [Last post]
pdoubleya
Offline
Joined: 2004-02-09
Points: 0

This is more a philosophical posting...looking more for philosophical input on how the language should change (or not) than specific language suggestions.

As I'm reading these posts, one point that comes across is that people would like additions to the language itself to make Java code less verbose, and to reduce visual clutter.

I have read in a number of forums how Java (the language) is too verbose, that is, the language syntax forces one to write long statements that, in a large program, feel like visual clutter. This argument sometimes comes from users of other languages that can express the same intention with fewer commands (or less typing).

Tiger improves the language, potentially reducing visual clutter, with all of the major enhancements: for-each loops, autoboxing, generics...so that is good.

The trick is, Java has a pretty consistent philosophy of "what you see is what you get". Imports, for example, can either be explicit, or can include everything in a package with the single package.* matcher. We could have a more complex regex matching for package imports (or use cool things like Ants ** matcher for recursive imports), but arguably the effect would not be obvious for programmers coming to our programs after the fact. Same for the lack of a pre-processor routine, and macros, in compilation. It makes the intent more clear by prohibiting a feature that has proven to _hide_ intent (or the end effect) in other languages.

Some of the principles that seem to guide the development of the language

non-ambiguity: language constructs have a single, clearly obvious meaning (so no op. overloading)

clear intent: the intent of the programmer is made clear because they can't easily be ambiguous (in the language, APIs are different)

clear effect: the end result of a statement or set of statements is more clear because there the parts of the statement, and the composition, are kept simple by the language

I believe the trick is how we can continue to hone the Java language without sacrificing these principles.

To state this as a question: how can we change the language to reduce verbosity and visual clutter without sacrificing the principles of non-ambiguity, clarity of intent, and clarity of effect?

Patrick

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cowwoc
Offline
Joined: 2003-08-24
Points: 0

In a nutshell: improve the usability of the core API.

I see some classes written using the JavaBeans convention -- getProperty(), setProperty() -- and others that utterly ignore it (even though they clearly could have used it). I see a Enumeration, Iterator, Vector, ArrayList, String, StringBuffer, StringBuilder.

My point is simple (I've filed a RFE to this extent a few months back): Sun must formally propose a way by which to fix the API usability over time. What I personally find desirable is removing the visibility (if not the existance) of "old ways of doing things" and making sure there is at most one (newest way) to do any one thing. There are currently 10 different ways to load images and only 2 of those use the "new approach". We don't need 10 bloody methods! :) The API should only list the newer ones and hide the rest. Less visual clutter.

I honestly don't see a good reason for listing method that have been deprecated since JDK 1.0... If anyone is adding such calls in *new* code, they should be shot. If they are using old code, let them look up the *old* Javadocs.

Gili