 |
|
 |
 |
|
|
 
Bruce Tate's BlogThe Illusion of the WallPosted by batate on June 28, 2004 at 07:21 PM | Comments (2)So I’m at JavaOne, and listening to the keynote. To summarize, Java is everywhere. We (Sun) really understand how to make money with it. And yes, we’re going to build an IDE for consumers, and people will love it and use it and it will attract 10 billion developers. Mobile is where it’s at. And somehow, we’re going to milk billions of dollars out of that knowledge. And after listening to this, I’m thinking I’ve heard it before. Maybe it’s last year’s keynote. I like it, want it, need it…but am skeptical. And so my mind wanders to the mountains. I was on the Piedra River in Colorado. My long-time kayaking partner Mike Oehrtman and I had met a couple of locals to guide us through a river that we assumed would be fun enough to get us in trouble, but not too fun for our own good. We watched them put in and shred the river. They played every little hole and toyed around with monster waterfalls. They made it look easy. But through humorously tragic miscommunication, I found myself on a section of the river that was over my head, both literally and metaphorically. I was not where I thought I was, and my skills could not cope with the power or steepness of the river. After rounding the corner, I meandered into a violent eight-foot twisting drop. It hammered me. I flipped, tried to roll, panicked, bailed, swam. In fact, I swam over waterfalls and under downed trees through frigid waters for nearly a mile, in an incident that should have killed me. After scraping myself out of the river and getting myself and my gear collected, I had barely put my paddle in the water when I screwed up yet again. Wet paddle. Hear roar. Make mistake. Flip. Blow roll. Blow another roll. Panic. Curse underwater. Choke. Bail out. Swim. All in all, I swam four times that day. I felt like Bill Murray in Ground Hog Day. (He lived the same bad day over and over.) Most of the time, I couldn’t tell what mistake that I made to get myself into trouble in the first place. I’d found a river too big for me to run. I’d hit the wall. Some Java developers that I know feel a little like that right now. They’ve hit the wall. It’s ground-hog day all over again. Get excited. Learn a monolithic API. Start to build it. Make design mistakes. Dig hole. Make mess. Curse. Work overtime. Scratch and claw. Find silver bullet. Lather, rinse, and repeat. While it was great at one time, this object technology doesn’t seem so easy any more. Enter Ground Hog Day on a grander scale. Those of you who are old enough to remember have seen this before. A long time ago, when we thought we’d taken procedural programming as far as it would go, we hit that unrunnable rapid. People wrote books like the Mythical Man Month and Death March. So we innovated. Object oriented technology was born. We started playing with it in the 1970s, with Small Talk. A few joined the band wagon, and used the technology to good effect. They are like the guides that led Mike and I to the dangerous river. And they had fun, and were incredibly productive. And like Mike and I, other lesser equipped paddlers in the industry followed enthusiastically, but they were in over their head. And they crashed and burned. They heard the roar (inheritance? CORBA? #define?) And they flipped, tried to recover, and swam. Some wailed, “This is truly a river that is too mighty for the layman to run. Let us build a sign, and a wall, to keep the public safely out. Let there be no more good people drown here.” But it turns out that the river unrunnable after all. In fact, while we were sucking that cold water through our nose, and scratching our way to the shore, we were learning. Our universities taught. Gurus published. We read. And some smart vendors paid attention, and introduced simpler technologies, like objects with training wheels. COM gave us components without inheritance. The defense industry gave us Ada, or encapsulation without a full-blown object model. C++ gave us the additional object oriented semantics, but left the procedural stuff in tact, so the effect was like a C plus plus, minus minus. At the time, it looked like we’d hit the wall. These “solutions” often looked like they were doing more harm than good. But we were learning, and absorbing. The collective psyche of the masses was moving, so when we were ready for objects, they not only met modest success, they exploded on the scene with Java. The world was ready for more, and Sun got the product and the timing right. The rest is history. And that, finally, brings me to the point. We’re in a similar place today. The early guides are putting in on the roaring river, and their kayaks have AOP (Aspect Oriented Programming) all over them. And a few of us are going to foolishly follow them down the river, and maybe even get killed. We’ll hear that AOP really isn’t a seventeen-foot rubber raft that is immune to capsize. But what happens next? Can that particular river be run? I, for one, think so. You can see the early stages of the first backlash. In fact, if you try to turn everything into an aspect, you’ll crash. Certain aspects are hard to understand. We need to understand implications of performance, and learn to test performance. Some of it seems too much like black magic. And some are saying that maybe AOP is the wrong model. But a few people are bringing AOP ideas into the main stream. They are giving you AOP with training wheels (pontoons?). JBoss has publicized the idea of interception in an EJB container. Perhaps a better example is the Spring framework, where you can consume AOP services. So, you’re starting to see people talk about the important concepts in AOP, like transparency, and independent services, and generalization of an important problem, and cross-cutting concerns. In fact, in my book (Better, Faster, Lighter Java), I don’t talk much about AOP, because I don’t think that most of us are ready. Instead, I talk about basic principles that we can borrow from AOP, and apply today. And I think I’ve struck a chord that’s ringing true. Today, my book was #3 on the list of JavaOne best sellers. If you think about it, those ideas are all around us. Spring is a way to consume aspects in Java. JDO is a persistence aspect. JBoss, Pico, Keel, JSF, and many others let you use IOC in meaningful ways. True, these frameworks will not, in and of themselves, introduce the full power of AOP. But don’t view this as the end. While it may seem like we’ve hit that unrunnable rapid, we’re moving forward. We’re learning. And that’s where I think we are today. We’re learning, and we’re getting ready to conquer that rapid that’s seen experts, but has to date been unrunnable by ordinary Joes, like me. And that’s what I’m looking for at JavaOne. I want little steps toward the next paradigm. I want chicken instead of elephant. Simplicity. Transparency. Interception. Attachable services. Inversion of control. Testability. I’ll find it in pockets—at JetBrains with IDEA; Kodo-Spring integration at the SolarMetric booth (where I present on Wednesday at 2); in the experiences of the expert guides; in BOF (Birds-of a-Feather) sessions; in the bars. But for the most part, I don’t think it’s going to happen at the keynotes, or in the big booths. This year, the action’s with the little guy. So fast-forward to 2002. After another mistake in judgment, I found myself on a flooded creek, once again, far more difficult than any I’d ever encountered. That day, one expert kayaker died, and two were rescued by helicopter. I shouldn’t have been out there. But I had learned enough, on the Piedra and other places. I coped, and survived, and even thrived. I can’t say that I’ll ever jump on that creek in flood. I may not even try my luck on the Piedra again: I’m getting a little old for that stuff. But on that day, the knowledge meant survival. Today, for Java, it means the same thing. Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
