Modifying Java WIthout Modifying Java

This is as much a reminder to myself as it is an update for you.  While working with Awesome Sauce Java, it became clear that it does at least two things:

1. It works just like Java, because it exposes Java as Java.
2. It can be modified to work just like Java, but it can be changed:
   1. To become functional, by e. g. returning values from method calls that currently return void.
   2. To support concurrency, by eliminating side-effects.
   3. To clean and edit method names, to shorten them and/or make them more representative of what they do.

The list of ways Awesome Sauce Java can change Java is considerably longer, but I first wanted to highlight these three important ways in which it's possible to modify Java.  Modifying Java isn't something to be taken lightly, but providing the same functionality with more consistent names, that are possibly shorter, may help the language become more usable and improve programmer productivity.

How Awesome Sauce Java Can Evolve Java

Because of the way Awesome Sauce Java is written, it's possible to alter the language according to the ways listed above, and even more ways, too.  But rather than simply telling consumers of a programming language to accept changes to the language and learn to alter their mental processes in order to write code by "the one true way", Awesome Sauce Java seeks to offer choice.  Why?  Because learning takes time and most (non-software) systems we work with allow us to coexist with them even as our knowledge grows.  Programming is subtly, yet radically inflexible.

Changing Java interfaces isn't something to take lightly.  Yet, there are areas of the language that are obviously written in ways to make working with them slow and tedious.  Take TableColumnModel, for example.  The methods throughout the class include the name Column or ColumnModel within them, even though they're being called with a TableColumnModel instance and/or the argument defines the action:

• addColumn(TableColumn aColumn)
• addColumnModelListener(TableColumnModelListener x)

By virtue of polymorphic methods being processed to match argument types, the two methods listed could conceivably be defined as:

• add(TableColumn aColumn)
• add(TableColumnModelListener x)

It's possible the second method might need "Listener" in the signature, but simplifying the naming scheme for methods in this manner may make Java more readable while improving programmer productivity by reducing typing load.  And reading load.  And editing load.  And documentation load.  And all kinds of other loads that add up to inverting the desired approach to working with Pareto: doing more work in progressively less time.

I didn't start out to edit Java.  But what Awesome Sauce Java presents is an opportunity for both sets of TableColumn methods to co-exist within the language.  What that means is that programmers can use the language as-is and based on their current knowledge of Java, as in the first set of TableColumn methods.

But Awesome Sauce Java will also allow Java programmers to leverage streamlined forms that offer the same functionality, essentially editing out the kruft of Java to make the language more consistent.

If that sounds like a good feature of a programming language, I hope you'll consider contributing to Awesome Sauce Java crowd funding on Indiegogo.

Have a great day!