Bitter Java 427
| Bitter Java: The lessons taught by server-side Java Antipatterns | |
| author | Bruce A. Tate (with help from Braden R. Flowers) |
| pages | |
| publisher | Manning |
| rating | 8 |
| reviewer | Peter Wayner |
| ISBN | 1-930110-43-X |
| summary | A collection of bad habits to avoid for server developers using Java. |
Writing and reading technical books is both a pleasure and a chore. Programming computers can be great fun, but doing the job well requires almost impossible amounts of discipline, attention to detail, and pure drive. The machines churn through billions of operations per second and a mistake in just one can send everything tumbling out of control. Most authors tend to gloss over the difficulty by tossing in a spoonful of Mary Poppins because it does little good to grouse. It's just so simple and straight-forward to toss in optimistic words like "simple" and "straight-forward."
Tate's approach is looks a bit different. He wants to follow in the tradition of Frederick Brook's Mythical Man Month and talk about software development with an honest voice. Microsoft executives, Objective C devotees, and assembler lovers will be disappointed because the title is a bit misleading. He's not really bitter about Java in the way that Princess Diana was bitter about the British Royalty, he's just had a few bad experiences and he wants to help us learn from them.
In fact, he's not even writing about Java in the general sense. The book concentrates on the problems that often arise with most popular and complicated applications for the technology like servlets and enterprise Java beans. If you're building a web site based on Java, then you might want to read through this book.
The structure itself is devoted to uncovering antipatterns , a term Tate uses because it plays off the way that Sun offered Java patterns to help programmers use the new tools efficiently. Most of the chapters show the wrong way to build something and then show how to correct it.
Chapter 8, for instance, demonstrates a bulletin board that seems to be well-designed on the surface. The parts of the data structure are broken up into suitable objects and every object comes with a collection of methods that act as gatekeepers for the data inside the object. It all looks elegant, but it performs badly especially on large installations when the objects live on different servers. Suddenly, all of the extra well-meaning object-oriented engineering starts jamming the flow. Wrapping every object with so much glue code is like hiring more workers to speed up a bureaucracy. Tate shows how to aggregate the calls and speed things up dramatically by cutting through the misapplied object-oriented concepts.
If you step back a bit and think about the book from a distance, the right title starts to look like "Bitter Object-Oriented Programming". Most of the problems in the book emerge when seemingly good uses of OOP turn out to be terribly slow when implemented. While all of the problems are practical hurdles awaiting Java programmers, they must have cousins in the world of C++ and the other OOP languages. Splitting things up into many objects is plenty of fun at the beginning, but when the messages start flowing, the code becomes a swamp.
After a few chapters it becomes clear that object-oriented programming is starting to reach practical limits. The theory may be elegant, but programmers can only make it work if they use guidebooks like Tate's. The object-oriented toolkits are too easy to use dangerously. So what is the solution?
This kind of guidebook filled with antipatterns may be the best we can do for now. Tate himself says that the book is filled with "merc talk", the kind of chatter about hair raising experiences he says that mercenaries trade when they're sitting around the fire. This is an apt description. If you're a hired codeslinger creating J2EE applications or servlets, then this is a good book for your shelf.
Peter Wayner's latest two books are Translucent Databases , an exploration of how to create ultra-secure databases, and Disappearing Cryptography: Information Hiding, Steganography and Watermarking , a book about mathematical parlour tricks, sleights-of-hand, and subversive things you can do with bits. You can purchase Bitter Java at bn.com, and you can join Peter in reviewing books by submitting reviews after reading the book review guidelines.
Development Processes be damned.. (Score:5, Insightful)
Development prowess and productivity is determined by how well your code works, not how many widgets you can crank out and connect together in "internet time". It's knowing how things work, and if they'll work together well or not. It's knowing when it's better to write the damn thing yourself, instead of spending 2-3x more time and resources gluing off the shelf components together..
I'm heading off to buy the book, if not just for the reason to support the author courageous enough to go against the grain and give this topic a voice.
Some patterns to live by... (Score:3, Insightful)
"Keep it simple, stupid." - anonymous
"Limit temporary object creation." - any smart Java programmer
Java does a pretty good job of providing much more functionality for a little more overhead. There are areas in the Java libs which seem over-engineered and slower and bigger than they should be (Swing!). Don't throw out the baby with the bath water, though...Java is good and the crufty parts will evolve into something better.
Re:All I want to know is.. (Score:3, Insightful)
OOP can be oops! (Score:1, Insightful)
I want to read this book. I have a feeling it may be instructive in avoiding this moral hazard of OOP.
So many books on java... (Score:5, Insightful)
For example, "We clinched the deal because we promised to use the J2EE/EJB framework" -- as opposed to, "Our product is good, and the guys liked our technical expertise and design." This is a "sort of" true story!
S
mmmmm... Money.. (Score:2, Insightful)
You are clever. (Score:0, Insightful)
Anyone who tells you that a tool/language/methodology will make programming easy is a liar/fuckwit. Doing difficult things is hard. There comes a point where a system is so difficult that it makes very little difference whether you program it in VB or assembler. It's still going to be hard.
I though perl was a girl's language but look how hard it is to fix the page widening bug.
The solution (Score:3, Insightful)
Of course, there is no magic bullet to make software suck less, but I would strongly encourage all developers to at least look at what FP offers.
Cross platform (Score:3, Insightful)
Making "Write Once, Run Anywhere" a Java mantra was a huge mistake. It should have been more like "Write once, tweak a little, maybe it'll run... But it's easier than porting C code!" A more modest claim would have been much better.
Re:This book is right on the money (Score:3, Insightful)
Oh, then he's an idiot. ;-)
His final chapter is scathing (words like "worst" and "language" and "ever" all pop up) but is entirely factual.
Sounds like flamebait...er...'opinions' to me. Not facts.
The fact is Java is good for nothing but web applets and only then if you don't care about uptimes.
Nice assertion...now back it up with some facts. You might want to start by explaining how all those application servers out there do so much useful work running Java. Then go download Eclipse (www.eclipse.org) or JBuilder and then explain how such great IDEs could possibly be written in Java. There are also plenty of great Java-based websites out there, StockCharts.com [stockcharts.com] being one example.
Fact is, Java is very good these days. Like anything, it has it's warts...but the good far outweighs the bad. Being able to target Windows, Linux and MacOS with a single code base is sweet.
There may be issues with specific Java libraries and frameworks. Don't confuse those with the language or runtime, which are both fairly clean.
Blame Colleges (Score:1, Insightful)
I say down with CS because daddy said it was a good idea.
The world needs less CS graduates and more people that are compitent in the field.
If you don't like this because it describes you, good I hate you.
Over-Design (Score:2, Insightful)
Re:Development Processes be damned.. (Score:2, Insightful)
Uhh yeah. Now let's see how easy it is to maintain and upgrade your amazing functional language code over the next 10 years. Man, people who hate OO languages are funny. They just don't like OO cause they can't figure out how to program OO.
Re:Development Processes be damned.. (Score:3, Insightful)
and i thought design patterns were just typical ways other people code stuff so you can 1, learn more quickly, and 2, not have to re-think through all that. are you saing that every lisp program you come across has a completely different design? (i'm not familiar with that language).
Re:My Gripes about Java &tm; (Score:3, Insightful)
I was about to point out that C has GOTO when I realized that C programmers who use 'goto' in C code more than 3 times in a 2 month span invariably seem to wind up homeless and discombobulated. So, it's probably for the best that you didn't point this out
Re:Design patterns and Lisp (Score:5, Insightful)
One is the pervasive nature of intrinsic typing. Variables are not typed, values are. Object-oriented methods, of course, explicitly mention classes, but non-OO code does not need to explicitly type variables, except to improve performance. The flexibility of many built-in Lisp operators helps deal with multiple types transparently. For instance, length of array, length of a string, and length of a list all use the same function: LENGTH.
Another source of flexibility is Lisp macros, which can use the full power of the Lisp programming language to rearrange and process Lisp macro calls into Lisp code. If there is some design pattern that Lisp does not natively support, you can use Lisp macros to create a Lisp "dialect" that cleanly expresses the design.
Paul Graham [paulgraham.com], in his books, demonstrates, for instance, that if Lisp did not already have CLOS to express object-oriented concepts, that in about a hundred lines of pretty clean Lisp macrology, you can add single-dispatch methods to the language, and it looks just like "real" Lisp, and mixes with the base language transparently.
It took Stroustrup a large effort (cfront) to add objects and methods to C, and it requires explicitly invoking a compiler program to do the translation, with name-mangling and everything else. In Lisp, you would write Lisp macros to do the same thing, and you would still be working in true Lisp. You can also add macros on macros: cfront is basically a monolith, but Lisp macros can work together; you can continuously "build up" from the language foundation, and the various layers can be overlapped.
Any time you find yourself repeating a pattern, it suggests a Lisp macro. If you have an example of the pattern already written, it is pretty much cut-and-paste to create the general macro from the specific pattern instance.
That kind of flexibility, which allows the programmer to mold the language to fit his (and his tasks) needs, is really what makes Lisp great to work with.
It's something like the difference between working with Legos and clay. If you're missing a Lego part to serve a particular function, you're pretty much stuck, unless you want to injection-mold your own custom blocks. Therefore, Lego models tend to use "design patterns" where the standard blocks or parts fit together a certain way that solves a certain class of problems. Lego models, although they can be amazing achievements, all tend to look like Lego models.
With clay, however, the medium is fluid. You can mold it to just about any shape you want. Sculptures usually look like their subject, not like clay.
Re:OO and functional (Score:5, Insightful)
Lisp has a full-blown object system called CLOS (Common Lisp Object System), which frankly blows C++'s object system out of the water, in terms of flexibility, power, and syntactic cleanliness, just for starters. Lisp programmers aren't scared of OO. It's C++ programmers who are scared of Lisp, although why anyone would be less scared of C++ is a mystery to me.
OO doesn't magically mean "easy to maintain." It may mean "easy to find drones who think they learned the language from a book in 21 days, so they put in on their resume" which I think was your real point.
To address the original issue, functional designs tend to be much more "factored" than procedural designs, because things are designed to use functional abstraction rather than interactions between different bits of code and variables. This tends to make them much more robust and maintainable.
how about (Score:3, Insightful)
...bitter about people who keep buying into marketspeak?
...bitter about people who keep developing the same old language, but put some makeup on it so for it to seem different?
...bitter about methodologies, because they're set in stone?
...bitter about requirements, because they're set in water?
...bitter about business because you're just a "resource" to them?
...bitter about business programming because it's dull, insignificant, and someone should have already figured out a way to generate all this stupid code since it's been repeated some many times over?
Heh, whatever, I need to sleep.
Real programming (Score:5, Insightful)
The hardest thing to get across to a Java/C++/VB zealot is that assembly is the most powerful language available. There is no computing algorithm, or programming paradigm that can't be expressed in assembly. I routinely write classes in assembly, and use runtime polymorphism - in fact, correct multiple inheritance is more easily implemented in asm than C++! (fewer lines, no assinine casting...) However, this doesn't mean that assembly language is the cure all for every programming problem. Some problems lend themselves to assembly (like device drivers, OS code), others to C++ (games, applications), and others to Java (web programs). What's hard is convincing people that if they understood the underlying computer science, they could write the code in the language which best suited the particular application, rather than being stuck writing in Java, or whatever HLL is popular at the time.
Incidentally, I like assembly because of the freedom and power it provides. But I still write in Java or C++ when the needs of the project dictate. Real computer science transcends the language used, as languages come and go. Soon, Java will be outdated, and those who only learned to program in Java will find their knowledge useless.
What matters is not whether you know langauge X, but rather that you know the fundamental algorithms of computer science and can translate them into any language. If you can break down a task into algorithms, then you can pick the language best suited for those algorithms, and translate the algorithms into code in a trivial amount of time, regardless of which language you use. What too many people miss is the fact that if you can't break a problem down into its fundamental algorithms, or translate those algorithms into an arbitrary language, your days as a programmer will be few, irrespective of how well you know a particular language.
Just an observation... (Score:2, Insightful)
"So what", you may say, "just deal with it."
Well, the problem is not "just dealing" with it - the problem is if classes do not make my life easier, write code faster, write code that fails predictably, then they are in fact failures.
Part of my history with software is I like to write software that you look at and go "oh, I could have written that". Which is far more difficult than writing code that is hard to understand. "Intuitive programming" is what someone once called it (I forget the brilliant soul who came up with the phrase). C++, much like Java, does not fall into that category.
Sooooo, it was with much trepedation that I plunged into Objective C. At first, I hated the syntax (and the NeXT/Apple classes). Then, quickly and surprisingly, I learned how rich and powerful it was. Best it really DID make programming easier and fun again.
But I am back at C++ (ugh). It is again like cutting off both arms and legs and being expected to whip Jet Li's ass. Yah, right!
OO has been touted as the best thing since sliced bread, yet I have found that for the most part it is like having bread where all the slices are tagged as "virtual" - the REAL slicing still has to be done by yours truly. And to be honest, the tools are still effing primitive. I can't believe that we STILL debug EXACTLY the same effing way we did 20+ years ago (okay, source code debugging makes it easier still, but not significantly).
Finally, for those who expect Microsoft to save the day, 'bout time to give up on those losers. By the time they get something out and it is being used a LOT, they dump it for the NEXT GREAT THING (and folks see pink slips).
Re:Development Processes be damned.. (Score:4, Insightful)
This process is obviously not super-productive. However, this individual simply does not have enough *real-world* experience. After getting lectured/fired a few times for not "putting out," he'll tune his skills to be able to make better decisions on how to apply his OO know-how.
Finally, it is my opinion that this type of programmer is overall better than simply a guy who knows how well his code works. I know a lot of hacker-types who know their code down to ++ inside the assignment wrapped in their if statement. What they produce works, however:
* Try to maintain it. Let me bring my lawn chair and a bag a popcorn and I'll watch.
* Try to add anything to it. This time I think I'll just have a tall glass of pink-lemonade.
* etc.
One the otherhand, if I was given the code written by the OO goon, I'd be more likely to understand it, and trim the fat.
Re:Development Processes be damned.. (Score:1, Insightful)
Building zillions of objects seems kind of dumb. Just like fully normalized databases seem kind of dumb. I think people hear a good idea, or theory, or whatever and just get carried away with it, like the kid who thinks, "I like salt" and then pours the whole carton of Morton's into your pea soup.
Re:The solution (Score:3, Insightful)
Object oriented is good when things are easily modeled by objects. When it's easy to think of them as physical models.
Functional programming is good when something is well described by goal states.
Procedural programming is good when the algorithm is the thing.
The remaining set of approaches are involved in making quick choices between options based on relative desireability. In a person one might describe this as "having a feel for the problem", but that is often confused with the modeling approach. This is more related to a ranking procedure or an emotional approach. At the moment, the best way that I know of getting this is via a neural net, but that's clearly not a desireable programming strategy. A hash table is an example of this approach in use (if not in design). But the actual methodology would need to stretch far beyond hash tables.
For a larger system, one would want to pick one of these approaches as a basis, and interface it with two of the other approaches. These in combination would be able to synthesize an attack on the fourth method problems. Then each problem would need to be solved using the api's relavant to the particular mode that handles that kind of problem best.
Re:Design patterns and Lisp (Score:2, Insightful)
I think there seem to be fewer patterns in Lisp, because Lisp needs them less.
I'm sorry, but I have to reply - a lot of people are making statements like this and it only shows that they misunderstand what a design pattern is.
A proper design pattern applies to all languages equally - because it's about design not about coding.
Saying that Lisp doesn't need design patterns is like saying BMWs don't need drivers.
A design pattern is something like "isolate all the hardware dependent stuff in one portion of the application" or "use a special class as a filter for translating object oriented data into SQL statements". Your examples are anything but "design patterns".