Some lines are too good to pass up. I have spent paragraphs trying to explain the sea change toward simplicity in Java. I should have taken the "grade 9" approach:
I *heart* POJOs.
Recently, I've thought about a common theme between art and computer science: the "reaction against complexity".
This phrase seems to come up a lot in art, whether it is music, architecture, or visual art. Almost all of the schools (e.g. the Impressionists) seem to come about in reaction to something. Often, it is complexity.
The Bubble
I wonder if anything sets out to be complicated. It often seems like there is an idea that is embraced, then added to, reused, refactored, and eventually pushed into an ever-expanding range of uses. Then, there is a lightning bolt that jars everyone into the realization that, "hey, we are in an era of complexity right now -- how did that happen?".
Here's some examples from art... (These may be grossly over-simplified!)
Grunge
An easy, contemporary example is hard rock/metal in the late 1980s (in North America and Europe). Throughout the decade, the style had grown from its bluesy roots in Led Zeppelin to having shrill, operatic vocals, and guitar solos with amazing technical virtuosity. Bombastic looks and videos ruled the day.
Then along came a band out of Seattle, and nothing was the same. Seemingly overnight.
Cool Jazz
In the 1940's, a primary form of American jazz was bebop. Bebop was known for its fast tempos and sophisticated ideas for melody, harmony, and rhythm. Miles Davis, in his first stint as band leader, took things in a new direction with a landmark recording called "Birth of the Cool". To quote this website, "The cool jazz style has been described as a reaction against... [the excess] of bebop and is generally more relaxed". There's that phrase again.
Modern Architecture
Modern architecture is a style that began in the early 20th century. It's characterized by simple geometric lines and a distinct lack of ornamentation. Ultimately, it led the way to the skyscraper. To quote one of the founders, Ludwig Mies van der Rohe: "Less is more". (Sound familiar in the geek world?)
To paraphrase Wikipedia, some historians feel that the Modern school is a "reaction against" the excesses of the movement known as Art Nouveau (an example is here).
Convention over configuration
This is not news but we geeks seem to be emerging from an orgy of XML (aka The Bubble), where it has been used for everything. Most of this use is predicated by configuration: Struts 1.x, EJB 2, and the list goes on.
Of course, the lightning bolt has been Ruby on Rails. Most readers will know that the bumper sticker for the RoR camp is "convention over configuration": just do the natural thing with a minimal, simple set of files, and the framework will take care of the rest. Why over-specify everything all the time?
Similarly, annotations have simplified EJB 3 and JAX-WS. XML is invaluable, no doubt, but perhaps the days of excess are over? I have heard several speakers talk about the "old days of XML hell" with "legacy" frameworks (which are only a few years old).
Perhaps this is Struts 1.x?
Perhaps the historians will talk about a new age of frameworks "as a reaction against complexity"....
The Upshot
Whether it's in your own project or in the Java scene, keep an eye out for complexity and note the reactions to it. It's fun to guess what the "next bubble" will be. Based on patterns in art, my guess is that annotations themselves will be the Next Bubble. They fix a problem, are being embraced, then added to, reused -- wait, haven't we heard this before?
In this post, Weiqi Gao quietly mentions that the St Louis Java User's Group had a talk by Mark Volkmann, 10 years ago this month, on Java: What's All the Excitement About?
It's a quick, fun read to go back in time with the slides. I don't think we need another "10 year retrospective", but here are some random thoughts.
A dear friend is a neuropsychologist. She has a zillion interesting brain factoids but one relevant one is the allure of the "inconsistent reward".
My paraphrased essence is that we are drawn to situations where there is the possibility of a reward. It has to be Goldilocks: never being rewarded is daunting; being rewarded too easily is boring. This phenomenon explains computer games, gambling, ...
And unit-testing, IMO. I have said before that unit-testing is fun: "like getting a row of limes on the Turing Slot Machine. It is an electrochemical buzz, broadcasting to our dopamine receptors." Personally, I find a palpable tension while the tests are running, just before the outcome.
A thought for a Friday: Maybe the Java IDE's should represent JUnit results as the spinners on a mini slot-machine? "Big money, no whammies...."
I recently attended a StL Java SIG meeting: a presentation on JRuby by Mark Volkmann.
As a Groovy fan, I have been a bit concerned about the press on JRuby lately: it's well known that Sun hired 2 major guys (Nutter and Enebo) for JRuby support, and had big plans to hit JRuby V 1.0 at Java One (they hit V 0.9.9 -- is Wayne Gretzky on the design committee?)
With all this hoopla, I wondered: what's up with Groovy? After all, 2 years ago when I was into Jython, Groovy had all the mindshare, with its own JSR etc. I can't keep up...
Some comments at the Java SIG expanded my view, though... To borrow an analogy from the American political parties, I've realized that the JVM is a "big tent" which can acommodate a lot of players and viewpoints. There's room for all kinds of tools and languages. I recently heard on Java Posse that there are dozens -- hundreds! -- of languages that run on the JVM. Someone pointed out that Groovy is doing just fine on its own: it has left the nest and doesn't need Mama Sun anymore.
A final thought: in the Microsoft world, a big initiative for one language does not necessarily spell bad news for the others.
Bloch recommended ... that final is the new private. Mark all fields final by default (blank final is OK) and only remove final if you an demonstrate a need too. This encourages safety and immutability.-- Elliot Rusty Harold on Joshua Bloch's Java One presentation (it isn't clear who coined the phrase)
I've been reading Brian Goetz' Java Concurrency in Practice. It has some mind-expanding thoughts on how subtle it can be to have threading problems in Java (or any language).
The book, and Amdahl's Law, has inspired me to codify a warning to junior developers (apprentices, in the parlance of Code to Joy), and as a reminder to the senior devs (composers).
Preface
A program is said to be thread-effective if it is:
I've blogged on this idea in the past, but didn't have a term for the thought.
Define JVM Tunneling to be the phenomenon where certain languages, by running on the JVM, encounter ultra-low resistance as a proposed addition to a project or organization. The most successful JVM tunnelers are languages that compile to bytecodes and whose installations require the addition of a single jar to the classpath.
Primary examples are Groovy and JRuby.
To be a virtuoso code composer in Java (or any language), one needs to understand concurrency and the memory model of the platform.
Many of us, myself included, should study and learn as much as we can about these subjects: they truly separate the masters from the apprentices.
The best resource going these days for Java is the book Java Concurrency in Practice. Get it. Just get it. After all, at your next interview, some of your competitors will have read it.
Here's a blog on a study group for the book.
re: title. What's with the lemmings you ask? Many, many moons ago in grad school, I played a wonderful computer game called Lemmings. The gist was that there were many lemmings who would flow from one place to another. They weren't very bright. The game-play was for you to control gates, ramps, and other control structures to guide the little buggers to safety, and to prevent them from causing chaos.
Here's an interesting post on new-age build tools like Rake and Gant.
A moderately new thought (for me) on build tools:
Things that we use _all the time_ tend to resist change. For example, in natural language, the verbs “to be” and “to have” are notoriously weird because they aren’t made “regular”, as is the tendency with less-used verbs. We don't think about "to have" or "to be": we just use them. All the time.
Similarly, build tools have amazing resilience. The industry suffered with ‘make’ for decades. The fact that Ant saved us from ‘make’ is enough for it to go into the Hall of Fame.
I'm in no hurry to see Ant go away. I am intrigued though by Gant.
