I’d be willing to help you understand software abstraction and all the topics at hand that I am deliberately avoiding; choose your medium. I recently ran a Scala training course for Red Hat/JBoss and I’m running the same course again after Christmas. It was called a ‘Scala training course’, but really I was teaching advanced concepts with a language that supports some of them (we also touched on Haskell98).

You’re not in the area I assume but I strongly implore you to seek further and definitely keep your trap yappin’

Your post sort of changes tack, starting with a promise to explain what using more refined languages will be like, but ending with the fairly ‘duh - obvious’ conclusion that the need to dance to some idiot boss’s fiddle is very bad for your codebase. That’s the real conclusion of your post, I think - if you get the sense that doing X is the cleaner way, try and fight for it, and don’t listen to any book, guru, or bosses premonitions. You might be wrong, but making the mistake is the only way to really learn.

Unfortunately, this puts your last comment in a bit of a bind, as it seems to be telling me to shut my yap and just follow the sheeple - blame languages that lack elegance as the only thing standing between me and the promised land of programming. Thing is, I use many languages, and not one of them magically makes my code jump over the moon, or magically eliminates all bugs. A man can dream, perhaps.

Maybe I need that lecture on category theory. I could maybe compare it to the many tutorials on haskell type classes for kicks.

In the meantime, please take my word for it, it’s like that

Therefore, I’d say your metaphor is fundamentally flawed; java’s problems lie in its ‘half-assed’ness. It has a static, explicit type system, but then the notion of whether or not any variable/attribute/parameter can hold null is completely dynamic. It chooses the ‘enumerate all common use cases’ vs the ‘create meta programming directives like operator overloading and let library builders sort it out’ paradigm, which has a few redeeming features to some, but then doesn’t do it right, because new and obvious use cases (such as BigInteger and BigDecimal needing operator support) aren’t added in a timely fashion.

It has closures, but they carry 4+ lines of cruft just to write them (anonymous inner classes - function pointers that close over lexical scope. That’s close enough to ‘closure’ in my book, but you need to wrap all non-final variables, you have to jump through some hoops to escape from the closure using e.g. a return or break or continue, and, of course, you need to write both the class/interface name and the method name). Discussion to do something about the cruft finally shows up for java7, but then half the proposals act as if anonymous inner classes don’t exist and write a new type system instead.

Just point such people to Scala. It doesn’t just run on the JVM, like python or ruby - it actually takes some pains to produce class files that look and feel like a java-generated class file from the perspective of a java developer. They have getters and setters and sensical hashCode and equals implementations and such - most of that invisible for scala code, as it should be. You can therefore use scala on a few files in a java-based project and the people you work with (or yourself if you go back to java for some of the files) don’t really notice.

Java isn’t the only language base that has to deal with lots of conflicting similar implementations of the same concept. Python has a bunch of rails-wannabees, all very very similar and yet all different (TurboGears and Django are virtually the same thing, for example). I imagine its a common problem for any language with such an enormous userbase. Again, though, java doesn’t really carry it to its logical conclusion; there is no CPAN-like database for java. There’s the maven repository but there are plenty of writings to find online about the many things Maven does very very wrong.

Fortunately to java programmers, and the JVM (which, in my book, is made up mostly of win), recent pressures in programming language world seem to have kickstarted improvements to java into gear. Most of the above issues are now being addressed, though whether it’ll help will remain to be seen.

Metaphors are an important vehicle for accepting each side of the coin, because metaphors aren’t too prescriptive. In written language, we tolerate more complexity, as it requires more time in reading and writing to accomplish the same analysis and design using speech communication. The subtle nuance suggested in The Parable of the Infinite Jar of Objects is that although you may be forced to express everything as an object in one way or another, having too many objects impedes communication. The water shed moment comes after the embarrassment, and the opportunity presents itself to illustrate through metaphor how to accomplish agility: pare down the model.

The first thing that can be taught about analysis is that models are not right or wrong; models are more or less useful. How far do you go in modeling? As far as is useful. There’s always more than one way to model a problem. There’s also no necessary way to begin visualizing a model. Modeling is an iterative process, and it doesn’t need to start at the best place. With any reasonable starting place, the model will converge on a similarly useful model.

What is the difference between Euclid’s Euclidean geometry and Hilbert’s Euclidean geometry? They both modeled the same problem, but with different perspectives. Euclid and Hilbert were looking at the same picture, but starting from different angles and distances.

Sometimes, the modeling path chosen will not end up in a robust model. Invalid solutions are not necessarily completely discarded. Although we should heed “plan to throw one away; you will, anyhow”, then it is useful to pull back and ask if some of our initial assumptions are invalid. By teasing away the assumptions that don’t apply to the particular problem, the model becomes more robust.

A good example of design patterns capturing higher truths is the Sorting Pattern: implementing a sorting algorithm using a divide-and-conquer approach. All shuffling algorithms can be decomposed into Split and Join semantics. The number of shuffles it takes to sort a list depends upon the splitting decision. Selection Sort splits a list into two elements: the first element, and the rest of the list. Merge Sort splits a list into two halves. Quick Sort varies in how it splits a list, but makes a best effort to split a list evenly. The ingenuity behind C.A.R. Hoare’s design of Quick Sort is that all of the complexity is in the Split: there is no Join code. The Split/Join model is a very robust model that separates the model into two models for improved decision-making. We can see the advantage of the robustness of this model in Introspection Sort (IntroSort) used in the SGI implementation of the C++ Standard Library: IntroSort combines Quick Sort, Heap Sort and Insertion Sort.