With a single paragraph on his blog, James Gosling just ended the Java closures debate.
Now, let’s move forward and git er done. I hope we never find a word that completes this sentence:
“Erasure is to Generics, as ________ is to Closures.”
TV has come a long way in the last ten years…
…I’m hoping my ancient TVs hold on for one or two more years.
For my 8 hour trip to Kalamazoo last week, I printed some Google white papers for some “light reading”. One of these was MapReduce: Simplified Data Processing on Large Clusters, which was recently updated. I read the original version last year and wanted to catch up. From the paper:
Programmers find the system easy to use: more than ten thousand distinct MapReduce programs have been implemented internally at Google over the past four years, and an average of one hundred thousand MapReduce jobs are executed on Google’s clusters every day, processing a total of more than twenty petabytes of data per day.
Meh. 20 petabytes? You should see the JAR files in *my* app, I tell ya…
Seriously, I did not read that article and think…”hmm…that’s kind of like a database.” I cannot imagine anyone thinking that. Nor is MapReduce an index. You can use it to *create* an index, for example. But still…MapReduce does not compete with a database in any way. It is entirely different, for an entirely different kind of problem. Yet, we have the DeWitt/Stonebraker article, described next.
The punchline is that upon my triumphant return to O’Fallon, MO, I discover everyone’s blogging about MapReduce. OK, that’s just a weird coincidence. I think this unbelievably inaccurate article written by David J. DeWitt and Michael Stonebraker (everybody’s saying they are database experts…) sparked a lot of the debate. It’s generally not cool to link to really awful material, but this one is worth it for the sheer entertainment factor. I recommend you read in this order:
The most telling part of all this is the fact that the original authors do not participate in the comments, at all. They are being ripped to pieces — FOR GOOD REASON — and they say nothing.
David J. DeWitt and Michael Stonebraker should retract their highly inaccurate article.
What do COBOL programmers think when they get on The Internets and read that Java is the New COBOL?
Damn…take a close look at those death rays…
You know what Not Invented Here (NIH) means, Google it if you need help. I’m here to talk about one case where we may need more innovation: Swing’s JTable component.
I really like JTable. JTable is a remarkably powerful GUI component, accommodating a huge spectrum of applications. Its design provides clear separation between the table, scroll pane, table header, cell renderers, cell editors, and the table model. The component is usable out of the box, and its modular design facilitates a great deal of customization. For instance, here is a screen shot from the RichJTable project:
You can find many other JTable extensions:
That’s just a quick search…there are many more out there.
All of these customizations — spreadsheets, tree tables, etc — extend JTable. The variety of custom components demonstrate just how flexible the original JTable design is. Is this a problem?
From page 164 of The Invisible Future: The Seamless Integration Of Technology Into Everyday Life:
In design, there is a trade-off between weak general and strong specific systems. Tools, like people, seem to be either a jack-of-all-trades, or specialized. Inherently “super-appliances” fall into the jack-of-all-trades weak-general category.
This weak general vs. strong specific trade-off plays a role in the design of all tools, including chisels, screwdrivers, bicycles and supercomputers. For reasons that we shall see, strong general systems have never been an option. One has always had to make a choice.
You can read Bill Buxton’s complete essay here. The point is, a Swiss Army Knife has a lot of tools, but they are all relatively weak. A dedicated spoon works a lot better than the weak spoon found on a Swiss Army Knife.
JTable is really good, but at its heart it is a weak-general tool. Writing a general-purpose table component is really hard, and the Swing team did a damn fine job with JTable. Thus, everybody else down the food chain (that I’m aware of) simply extends JTable.
JTable is good enough for 95% (?) of the use cases out there, but it is not as good as a dedicated spreadsheet. This is the problem. Grid components in dedicated spreadsheet applications are designed with one purpose in life: to display and edit spreadsheets. As such, they are strong-specific GUI components. In a dedicated spreadsheet, the GUI is crisp and responsive, focus traversal works, mouse clicks work, and data commits at the right time.
Many people have tried — including myself — to extend and coerce JTable into a spreadsheet component. But Swing JTable is subject to engineering tradeoffs like every other piece of software, and it can only be pushed so far. You can make JTable look and behave a lot like a good spreadsheet, but I doubt we will ever achieve perfection.
Consider IntelliJ IDEA, a product renowned for keyboard navigation. Unfortunately, keyboard navigation sucks whenever they use an editable JTable, such as in the Change Signature dialog:
Perhaps I need to embed a little video here to demonstrate the problems…basically, keyboard and mouse navigation just feel incredibly broken and wrong. JTable does the best that it can, but it is not a dedicated data entry component. JTable’s primary function is tabular data display, tabular data entry is a secondary feature for this general purpose GUI component.
I submit to you this idea:
Someone should write a dedicated Swing data entry grid component from the ground up, without extending JTable.
Random thoughts…
Anybody writing a data entry grid from scratch would certainly be accused of NIH. I can hear it now…”You are writing what??? You should just extend JTable! 95% of the functionality is already there!”
I believe that starting with a general-purpose component might make that final 5% impossible.
I hope I make it clear that this article is not a criticism of JTable at all. Pretending that a single GUI component can be perfect at *every* task is foolish and naive. Yet…I cannot say I have ever heard of someone writing a Java data entry grid — of Excel caliber — from scratch. Every single grid component I have seen extends JTable.
For most purposes, extending JTable is the right choice. But surely there are cases where a strong-specific, dedicated data entry grid component is more appropriate.
The DirecTV HDPC-20 is generating lots of buzz. In a nutshell, this product will let you record DirecTV to a Vista PC, which you can then (perhaps?) stream to any TV in the house via Media Center Extenders like the XBox 360. This image comes from the back of the device, revealing several patent numbers:
I thought it’d be fun to track these down via Google Patent Search.
None of this is surprising. Although DRM-free music seems attainable, video is an entirely different battle. Most of the patents describe techniques to prevent analog copies, such as recording to VHS. Patent 6381747 is a lot more interesting, however. This one lets service providers like DirecTV “activate, control and reconfigure the copy protection process”.
You should be very skeptical before buying into this system.
This could be a really kick ass product, but it could also be a nightmare if you spend thousands of dollars on computer equipment and extender devices, only to discover your favorite shows are blocked.
Four more years! Four more years!
What do I care? It’s not like my vote counts by the time my turn arrives. Now for some real fun. Part one of a multi-part hidden message…”Java Concurrency in Practice”.
