Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

Bitter Java 427

Posted by timothy from the tea-is-smoother-but-harder-to-program dept.
Peter Wayner writes: "There are 1693 books for sale at Amazon.com with the word "java" in the title and almost all of them are earnest, chipper books that promise real programmers, dummies , and nuts that learning Java is easy. Bruce Tate's, Bitter Java , is not one these books." Read on to see if you'd like to experience Bruce Tate's bitterness first hand.
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.
This discussion has been archived. No new comments can be posted.

Bitter Java More

Bitter Java

Comments Filter:
  • How many of those results are for coffee or the island?
    • Well, that's a really intelligent question - very entertaining as well. In a post that actually relates to the book, I think that Tate does a nice job in this book of really showing proper object oriented programming. So often OOP gets used as such a buzzword that if you, as a programmer, don't embrace and beat it into the ground, you're somehow seen as substandard or writing poor code. There are tools for every job. That's why people need to get a better grasp on OOP and understand when it should and shouldn't be used. One thing that this review did not mention is Tate's crisp writing style. He writes with a slightly conversational tone but one that won't become annoying by the 50th page or so. This is a very good book and I suggest you pick it up if you believe that OOP is the cure for all of society's ills.
    • A search for "java + coffee" returned 4 results (one of them misleading because it's a java programming book edited by a guy named Coffee). A search "java + island" returned 15 results.

      What does this mean?

      • Islands in the South Pacific are more popular than caffeinated beverages (unlikely)
      • Not that many coffee drinkers refer to coffee as "java" (more likely)
      • If users want to quote search statistics from Amazon for books on a particular topic, then Amazon needs a better search engine [google.com] (bingo)

  • Development Processes be damned.. (Score:5, Insightful)

    by TechnoVooDooDaddy ( 470187 ) on Thursday May 16, 2002 @10:23AM (#3529593) Homepage
    After years of listening to manager preach about "repeatable processes" and "the replaceable engineer" it's about time someone focused on skillsets. Appropriate and judicious use of OO concepts, design patterns does not a cookie cutter make.. Component design kludged up with so much glue that software engineers these days are nothing more than component assemblers.

    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.

    • Re:Development Processes be damned.. (Score:3, Interesting)

      by Anonymous Coward
      design patterns does not a cookie cutter make..

      The only programmers using design patterns are C++ and Java programmers. Do you know why? Because the "patterns" are meant to overcome language hurdles that dont occur in lisp and strictly functional languages.

      How many language designers besides Stroustrop constantly defend their language on usenet by appealing to C's popularity? He's a brilliant guy, but that argument is a crock.

      • I agree that Lisp &c are great languages and C++ is a crock, but you're wrong that the only programmers using DPs are C++ and Java programmers. They're simply the only ones who have a commonly known shared vocabulary for talking about their language's needed design patterns.

        As you can see from the discussion of the Visitor pattern, design patterns are native to languages; Lisp removes the need for the Visitor pattern with CLOS's multiple dispatch. However, by doing that Lisp doesn't reduce the total number of design patterns available to it; instead, it makes higher-level design patterns easier to express.

        So in a sense some of the DPs you see in the book are meant to cover language weaknesses -- but before you get to proud about not having _those_ weaknesses, remember Godel's principle: you also have weaknesses. C++ is not a weaker language simply because it needs the Visitor design pattern; it's weaker for many other reasons, involving complexity and impetuous design (or lack of design).

        Consider before you assume that DPs are signs of weakness: Smalltalk also uses DPs, and Smalltalk is _far_ from being a weak language.

        -Billy

      • Re:Development Processes be damned.. (Score:2, Insightful)

        by Anonymous Coward
        The only programmers using design patterns are C++ and Java programmers. Do you know why? Because the "patterns" are meant to overcome language hurdles that dont occur in lisp and strictly functional languages.

        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:OO and functional (Score:5, Insightful)

          by jaoswald ( 63789 ) on Thursday May 16, 2002 @11:44AM (#3530142) Homepage
          OO and functional are not opposing concepts. Also, you may have missed the subtle point, but Lisp is not a strictly functional language, although it is obviously function-oriented.

          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.
      • Patterns are language-agnostic. They are just concepts. They don't "overcome" anything in and of themselves. Perhaps your lovely functional language is just particularly suited to a particular pattern - that doesn't mean it isn't there.
      • that's an interesting twist on design patterns... to "overcome language hurdles that dont occur in lisp and strictly functional languages."

        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:Design patterns and Lisp (Score:5, Insightful)

          by jaoswald ( 63789 ) on Thursday May 16, 2002 @11:36AM (#3530085) Homepage
          It's not that every Lisp program has a different design, any more than every machine has the same design; however, in Lisp, there tend to be fewer obstacles to expressing a particular program design in the language. There are a wide range of reasons for that.

          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.
          • It's something like the difference between working with Legos and clay. ... 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.

            However, it's also worth remembering that while silver flutes tend to look the same, so do clay flutes. They don't need to, but then neither do silver flutes. They tend to. And it's the silver flutes that have, e.g., keys, and a multi-octave range.

            Also, though small sculptures can be made from clay, large ones require stone (or, I grant you, cement or metal). And moulded sculputers tend to look like sculpted sculputes. But not like welded sculptures.

            The nature of the medium always both liberates and constrains. Squeak cannot be made stable enough for business applications, without making it quite difficult for even the original programmer to fix things. Python is slow. C is fast, but rigid. C++ is ... I'm not sure where to put it. It seems (to me) like an inferior cousin to Ada95, so I'm not a good person to talk about it's virtues.

            Patterns in the use of dynamic languages are significantly different than those of static languages. But they still exist. Just don't expect the same ones to be important. (Or they may be so basic that they are built into the language, and thus tend to escape notice.)

            • Yes but whatever the differences between languages are the choice of language depends upon what program you want to write.

            • Re:Design patterns and Lisp (Score:4, Informative)

              by alispguru ( 72689 ) <bob,bane&me,com> on Thursday May 16, 2002 @03:09PM (#3532054) Journal
              I think there seem to be fewer patterns in Lisp, because Lisp needs them less. Lispers tend to dismiss patterns because of presentations like this one [norvig.com] by Peter Norvig, in which he shows that roughly two-thirds of the patterns in the Gang of Four book deal with techniques that are unnecessary in Common Lisp.

              Lisp does have patterns, but Lisp hackers tend to implement them as macros, automating their application rather than forcing everyone to know and re-enter them to use them. That's the difference between:

              // Please forgive any Java errors here
              // I don't use this pattern enough to get it right
              // without a compiler to check it...
              try {
              FileInputStream myfile = new FileInputStream(filename);
              // Mess with file...
              }
              finally {
              myfile.close();
              }
              and

              (with-open-file (myfile filename)
              ;; Mess with file...
              )
              They do the same thing - guarantee that myfile gets closed no matter what - but the Lisp way requires less typing and is less prone to errors.

          • I just fininished reading Modern C++ Design [awprofessional.com] by Andrei Alexandrescu, which explains all sorts of cool hacks you can do with templates in C++. Or to put it in more sober language, how to implement reusable design patterns using C++'s templates and compile-time polymorphism.

            It's a great read and really demonstrates just how powerful C++'s templating system is. It shows how to do just what you say - create a general macro from a specific pattern instance - for example making reusable templates to efficiently implement multiple dispatch and the Visitor pattern. And C++'s template specialization happens at compile time, which with a good optimizing compiler gives you performance as good as handwritten code. I haven't used Common Lisp so I can't compare C++ templates to CL macros - but you shouldn't underestimate C++'s macro-ing and code reuse abilities. The syntax is horrible, but there do exist people who don't like Lisp syntax either...

            The fact that early C++ implementations were using the cfront preprocessor doesn't really say much about the language - just that it had an unwieldy first implementation. All current C++ compilers really do handle the language natively (g++ for one). You can find all sorts of reasons for saying C++ is unpleasant and ugly, but cfront is not one of them. OTOH, if you were saying that Lisp is more powerful than C because it is much easier to add objects to Lisp than to add them to C: well of course, everyone knew that already.

            • Lisp macros are also compile-time. And, because the transformations they perform end up producing "ordinary" Lisp code, all Lisp compilers get them correct. Also, since the macro language is the same as the base language, it is well-defined. In fact, a substantial portion of a Lisp compiler is likely to be written using Lisp macros.

              C++ templates share much of the power of Lisp macros, but they are somewhat more restricted in what they can do and express. They play an essential role in writing generic algorithms, which is a great thing. But once you've decided to write your C++ code using templates, you're committed to doing things in the template style. Lisp macros are completely transparent, in the sense that macro code and Lisp code look the same, and fit together.

              I concede that the STL folks and Blitz++ folks have done amazing things with the template system. But C++ compilers still have issues with getting the STL to work consistently.

              I think the way I would summarize it is that writing Lisp macros is continually improving the language, without narrowing the scope of your options. C++ templates feel to me like building a tower. Sure, each floor is higher than the one before, but soon, the only way to build is up. If you don't like the choices you made building the ground floor, you have to abandon the work built on top, as well.
        • are you saing that every lisp program you come across has a completely different design?

          For lisp, probably not. Most lisp is peppered with imperative things, even the language itself supports sequenced stateful execution without requiring you to explicitly pass states around. For a functional language like haskell, definitely. It's hard to wrap one's brain around a client/server design being implemented as something like (in pseudocode):

          function client(serverdata)
          return server(clientdata)
          function server(clientdata)
          return client(serverdata)

          And where clientdata and serverdata are infinitely large. Neat pattern when you finally get it tho...
          • Oof. Got the design completely wrong. Typos, I swear .... yeah. Anyway, http://www.haskell.org/tutorial/patterns.html, which is actually talking about lazy pattern binding, but still introduces the design as two functions that are infinitely recursive, generating two infinitely long lists ... yes, lazy evaluation is weird.
      • The only programmers using design patterns are C++ and Java programmers.

        The book was originally written with SmallTalk in mind. Maybe you should stick to just saying "object-oriented" (I suppose 99% of which are C++ and Java programmers, though VB is finally truly object oriented, so it applies to them too)

        Do you know why? Because the "patterns" are meant to overcome language hurdles that dont occur in lisp and strictly functional languages.

        Give me just one example so I can begin to take you seriously. There are just different hurdles. First off, let's be clear, lisp is not by any means a "strictly" functional language. Strictly functional means no side effects. At all. Which is fine if you want to wrap everything up into typeful states and pass them around with syntactic sugar ala monads, but guess what, you just implemented a pattern. One that has a bit more mathematical category theory behind it, but it's still a pattern, imposing a structure on your overall design that may or may not fit your needs.

    • Re:Development Processes be damned.. (Score:4, Insightful)

      by Enonu ( 129798 ) on Thursday May 16, 2002 @12:23PM (#3530443)
      You do have a point in that you describing a new breed of OO programmer who likes to over-design the entire process. She'll create an interface for every class, *intend* to use design pattern X before the project starts, and then finally make sure that everything is abstracted so far, that you have to go down 4 levels of class hierarchy before everything implemented.

      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.

  • Sun invented patterns? (Score:3, Funny)

    by joib ( 70841 ) on Thursday May 16, 2002 @10:23AM (#3529599)

    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.
    And Al Gore invented the internet. Or was that Bill G again?

  • Some patterns to live by... (Score:3, Insightful)

    by Glock27 ( 446276 ) on Thursday May 16, 2002 @10:24AM (#3529603)
    "Make it as simple as possible, but no simpler." - Einstein

    "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.

  • My Gripes about Java &tm; (Score:5, Funny)

    by Anonymous Coward on Thursday May 16, 2002 @10:27AM (#3529626)
    Hello fellow coders,

    I'm a first year programming student at a local community college school and I've just finished my Visual Basic classes. This term I'll be moving onto Java. However I've noticed some issues with Java that I'd like to discuss with the rest of the programming community. Please do not think of me as being technically ignorant. In addition to VB, I am very skilled at HTML programming, one of the most challenging languages out there!

    Java is based on a concept known as Object Oriented Programming. In this style of programming (also known as OOPS in the coding community) a programmer builds "objects" or "glasses" out of his code, and then manipulates these "glasses". Since I'm assuming that you, dear reader, are as skilled at programming as I am, I'll skip further explanation of these "glasses".

    Please allow me to make a brief aside here and discuss the origins Java for a moment. My research shows that this language is one of the oldest languages in existance, pre-dating even assembly! It was created in the early 70s when AT&T began looking for a new language to write BSD, its Unix Operation System (later on, other companies would "borrow" the BSD source code to build both Solaris and Linux!)

    Back to the topic on hand, I feel that Java - despite its flaws - has been a very valuable tool to the world of computers. Unfortunately its starting to show its age, and I feel that it should be retired as C++, Python and Perl seem to have been. Recently I've become aquainted with another language that's quite recently been developed. Its one that promises to greatly simplify programming. This new language is called COBOL.

    Although syntactically borrowing a great deal from its predecessor Ruby, C greatly simplifies things (thus its name, which hints at its simpler nature by striping off the klunky double-pluses.) Its biggest strength is that it abandons an OOPS-style of programming. No more awkward "objects" or "glasses". Instead C uses what are called structs. Vaguely similiar to a Java "glass", a struct does away with anachonisms like inheiritance, namespaces and the whole private/public/protected/friend access issues of its variables and routines. By freeing the programmer from the requirement to juggle all these issues, the coder can focus on implementing his algorithm and rapidly developing his application.

    While C lacks the speed and robustness of Java, I think these are petty issues. Given the speed of modern computers, the relative sluggishness of C shouldn't be an issue. Robustness and stability will occur as C becomes more pervasive amongst the programming community and it becomes more fine-tuned. Eventually C should have stablity rivalling that of Java.

    I'm hoping to see C adopted as the de facto standard of programming. Based on what I've learned of this language, the future seems very bright indeed for C! Eventually, many years from now, perhaps we'll even see an operating system coded in this langauage.

    Thank you for your time. Your feedback is greatly appreciated.
    • Note: C is a subset of COBOL. C++ is merely a faster version of C.

  • So many books on java... (Score:5, Insightful)

    by sisukapalli1 ( 471175 ) on Thursday May 16, 2002 @10:28AM (#3529627)
    It is sometimes very scary when things are so, ahem, much marketed. In many places, there seems to be more emphasis on the tools and techniques used than what the product is supposed to do.

    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
  • That's how I like it. Nice and bitter. And strong.

    Certainly problems arising from OOP are not specific to java. It's quite possible in C++ (and presumably other OOP languages) to write a class with an interface that would make Stroustrup proud but that runs like me before my morning coffee. One of the issues I've had with OOP is the extreme care needed in design, disproportionate to the benefits. Still, it does have benefits, so I use it.

    Now while the reviewer relates the issues in the book to other languages, does the author? It sounds like it might be a good book for a non-java programmer, but it isn't clear that it is.

    • I've got the book. Just bought it last week; it's very good.

      It is pretty Java-specific (there's a chapter devoted to JSP, for example), but in the memory leak chapter ("Bitter Memories"), he covers the C++ memory model, as a comparison to the Java one.

      If you are capable of understanding the meta-pattern, then "Bitter Java" is useful for non-Java developers. The JSP examples could certainly apply to any HTML scripting language (the horror of seeing bad ASP programmers converted into even worse JSP programmers is something that should be outlawed).

      BTW, there is an associated web site: www.bitterjava.com.

      -jon

  • mmmmm... Money.. (Score:2, Insightful)

    by tomblackwell ( 6196 )
    Way to pack those Amazon affiliate links into that submission...
  • "Practical OO Programming In Binary"

  • Examples, please! (Score:2, Interesting)

    by Shimmer ( 3036 )
    Before we get out the brickbats, can someone please post an example of the horrors of OO technique that are referred to here.

    As someone who has used OO successfully for 10+ years, I'll have a hard time accepting these OO "antipatterns" without concrete examples.

    -- Brian

  • The solution (Score:3, Insightful)

    by Larne ( 9283 ) on Thursday May 16, 2002 @10:31AM (#3529648)
    After a few chapters it becomes clear that object-oriented programming is starting to reach practical limits. [...] So what is the solution?
    Some people have been saying for years that the solution is functional programing [chalmers.se]. In some functional languages, wierd run-time errors become type errors caught at compile time, the absence of state makes programs much easier to reason about, and so on.

    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.

    • Re:The solution (Score:2, Informative)

      by BrokenHalo ( 565198 )
      So what is the solution?

      Go back to assembly! :-)

    • Re:The solution (Score:3, Insightful)

      by HiThere ( 15173 )
      It's not that simple. There is a class of problems for which the functional approach is good. There is another class for which object oriented is good. There is a class for which procedural is good. And there is another class, for which I don't know a good methodology.

      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.

  • anti-antipatterns (Score:4, Interesting)

    by graveyhead ( 210996 ) <fletch@@@fletchtronics...net> on Thursday May 16, 2002 @10:36AM (#3529677)
    If design patterns are used correctly, they accomplish one of 2 things, but rarely both:

    they speed up the development of a system
    or

    they speed up the execution of a system

    This is, of course, one of the fundamental trade-offs that us computer programmers make all the time. The important part is choosing a pattern that is appropriate for the system. For example, the flyweight pattern is used to limit/reuse objects in a system. It is appropriate to use this pattern when top execution speed is necessary, but the price is the complexity of implementation.

    The facade pattern, OTOH, is designed to make life simpler for programmers, potentially at the cost of execution speed.

    It sounds to me like this guy has trouble picking the appropriate patterns from the start.

    • If design patterns are used correctly, they accomplish one of 2 things, but rarely both: * they speed up the development of a system or * they speed up the execution of a system

      I don't really agree with this. In most systems I work on they do both- in different places. In one place speed isn't important (e.g. UI), in another it is (e.g. database lookups that are called from a zillion places).

      It sounds to me like this guy has trouble picking the appropriate patterns from the start

      No engineer always knows what pattern to use; for one thing the known requirements often change as you work towards delivery, and the patterns that best address these requirements often change with them.

      I mean sure, a good pattern is along the lines of 'avoid having requirements that change', but that pattern is often inapplicable.

  • Antipatterns (Score:5, Informative)

    by Frums ( 112820 ) on Thursday May 16, 2002 @10:37AM (#3529687) Homepage Journal
    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.

    Actually, "antipattern" is an accepted term in the pattern commnunity for describing a bad process or design that on the surface looks like a good idea. If a Pattern is a good practice distilled from the experiences of many good develoeprs, then an antipattern is a "gotcha" thathas been distilled from experience common to many good developers. This book describes it, but th ename really has nothing to do with Sun's practice of describing things in terms of patterns.

    -Frums

    • Actually, "antipattern" is an accepted term in the pattern commnunity for describing a bad process or design that on the surface looks like a good idea. If a Pattern is a good practice distilled from the experiences of many good develoeprs, then an antipattern is a "gotcha" thathas been distilled from experience common to many good developers. This book describes it, but
      the name really has nothing to do with Sun's practice of describing things in terms of patterns.

      That's right. The AntiPattern is a well established idea, even marked by the publication of an AntiPatterns book [wiley.com] just a few years after the publication of Design Patterns [awprofessional.com] by the gang of four.
  • Antipatterns is probably the dumbest word ever. It's supposedly showing how you do something the wrong way. Well, there are a gadzillion ways to do something the wrong way! Do we really want to focus on those?

    Anyways, the book shows a bad way, then corrects it. Much like any "optimizing" books of the 1980's. It seems that the book with a little effort could provide patterns instead, mainly by focusing on the solutions instead of the problems.

    M.

  • ...in addition to all those "Learn Java in 21 Amazing Days" books.

    Java is often pitched as being a breeze to learn. And it is relatively easy since things like memory management is taken care of for you and the libraries tidily abstract a lot of details for you.

    But I've seen a lot of budding Java programmers program away with little awareness for what's going on in terms of efficiency and good system design, and this book seems to address these qualities well. Just because Java's slightly easier to program doesn't mean that programmers can be clueless.

  • So, if you write a system that runs across multiple servers you can end up with a poorly performing system if you don't know how to separate functionality out properly. From the Unix Hater's Handbook:

    If C gives you enough rope to hang yourself, then C++ gives you enough rope to bind and gag your neighborhood, rig the sails on a small ship, and still have enough rope to hang yourself from the yardarm.

    I would say that Java shortens the rope but then lets you hook it up to a power winch. Modern toolkits and languages are really powerful. Being able to write a distributed application so easily that YOU DIDN'T NOTICE HOW DAMN MANY CROSS SERVER CALLS YOU WERE MAKING is pretty amazing. On the last large project I did we used Java and I noted that Java made locking so easy that we swept right past the easy locking problems (like, did you remember to release the lock) and straight into the really nasty ones. I think that going beyond "Learn Java in 21 Days" into how to break your functionality out properly is a wonderful topic for a book but the gratuitous swipe a Java doesn't seem useful. Just remember, "Power tools for power fools."

  • Call me jaded, but do we really need another book explaining that it's possible to poorly design an OOP solution, or that not every problem can be solved with some implementation of an OOP tool - be it Java, C++, C# or B_Flat?

    Quoth the reviewer:

    If you're a hired codeslinger creating J2EE applications or servlets, then this is a good book for your shelf.
    If you're a hired codeslinger creating J2EE applications, shouldn't you already know how to create a scalable application and whether or not Java beans/servlets is correct tool or methodology for the problem at hand? It seems that this book should be recommeded more for Java newbies (which is fine) than Java veterans.

    <DISCLAIMER>I am not a Java programmer, but I am a grizzled veteran</DISCLAIMER>

  • Over-Design (Score:2, Insightful)

    by supercytro ( 527265 )
    One the problems with OOP is that systems tend to be over-designed and overly-abstracted out. Whilst the result may be elegant, what generally results is a convulated solution which requires a lot of work to utilise practically and efficiently. However, this in no way means OOP is 'flawed'; merely that experience and intelligent design is required instead of applying OOP as a magic bullet or as some systems are applied, a magic rocket.
  • The object-oriented toolkits are too easy to use dangerously. So what is the solution?

    At least in the world of C++ you do have the STL - hard to use, but hard to use dangerously. I think that templates are a somewhat undervalued addition to OOP - they allow for an extra level of abstraction(?) without the penalty of slower code.

    • Actually, STL (and to a large extent, templates themselves) represent a fundamentally different programming *paradigm* than OOP. It's called generic programming, and has quite a number of uses. And yes, I do agree that they make a good addition to OOP, but in reality they represent the inclusion of a whole other programming paradigm to C++. Personally, I think it's way cool and useful, albeit a bit complicated to use.

      • Templates and all are way cool and I often find myself wishing Java had them, but what is the performance hit to using them?

        • Uhm, compiler dependant?


          Seriously, you *may* pay a penalty for the compilers lack of intelligence when dealing with templates, but that is more than made up for by the fact that the STL code itself is *damn* good and efficient. My point is that you could probably hand-code better performing stuff yourself (I like to think that I can, anyway :-), but it would likely either take a long time or miss one crucial feature in most OO languages - strict type rule enforcement. Using the STL you get proven implementations AND type safety thanks to the template system (and the compiler, mind you) doing the tedious bits. Kind of like a tiny part of the huge library in Java, but with type safety C++-style.


          Occasionally, I roll my own templates - not too often, but it happens. Great modelling feature for something that is practically the same except for the type involved.

  • there was an island between Sumatra and Bali... (Score:4, Funny)

    by danny ( 2658 ) on Thursday May 16, 2002 @10:51AM (#3529791) Homepage
    The island that used to exist between Sumatra and Bali seems to have been wiped off the Net... At least, I went through the top 200 results of a Google search for "Java" a while back without finding any pages about it and, while some of the 1294 books at Amazon must surely be about the island, none of them make it into the first 200 results.

    Danny (who plays gamelan [danny.oz.au] and is interested in Indonesia [dannyreviews.com]).

  • Thinking in Java (Score:5, Interesting)

    by garoush ( 111257 ) on Thursday May 16, 2002 @11:03AM (#3529859) Homepage
    The best Java book that I have seen so far is "Thinking in Java" by Bruce Eckel. Here is why.

    While Mr. Eckel's book does covers the syntax of the language (java in this case) et. al, it also cover the meaning of the language and most of all, it covers how to think in the language (hence: the title).

    Almost any developer can pickup a language and become knowledgeable with it by working on one or two projects. However, being *proficient* at your domain, and understanding coding-principles of the language for your domain, and understanding the business of being a programmer is much more difficult goal to achieve -- only time, experience, and dedication will ever get you there. It is this quality that I look for first, the knowledge of a language comes third.

    Here is a link that I point people at to high-light my point: Chicken Soup for Your Modeling Soul [sdmagazine.com] -- I specially like item 21: "A fool with a tool is still a fool".
    • Another really superb book is Effective Java, written by Josh Bloch, who is responsible for the Java Collections API.

      It's definitely not a book for beginners; it's more of a style guide for API design in Java. It fills a gap between the very abstract world of patterns and the low-level syntax of the language. For example, it gives a several-page exposition of the contract of equals(), which was eye-opening even to this fairly experienced Java programmer.

      And ... it's superbly written. Bloch's prose is crisp, clear, and gets right to the point. It is, in fact, my favorite book devoted to a single language since K&R.
  • "We do this thing and the other not because they are easy but because they are hard."

    - JFK

  • Anti-patterns in 1998 (Score:5, Informative)

    by fingal ( 49160 ) on Thursday May 16, 2002 @11:24AM (#3530010) Homepage

    If folk are interested in the concept of modelling the "wrong" way to do things then I would also recommend reading Anti Patterns - Refactoring Software, Architectures and Projects in Crisis by William H Brown, Raphael C Malveau, Hays W "Skip" McCormick III & Thoma J Mowbray (ISBN 0-471-19713-0).

    This takes a slightly higher level look at the whole management of coding projects (although a lot of the patterns that are desribed are equally applicable to the low-level coding structure) and looks at common fallacies that are used by many teams as the "correct" way to do things. A knowledge of common mis-conceptions that have been proven not to work in the past (except in certain clearly defined "special cases") is invaluable in being able to spot the nascent structures before the get set in stone and the cost of re-factoring the structures becomes higher than the cost of living with them.

    Finally if people really want to get into this field I would also recommend Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Profects by Edward Yourdon which, if nothing else, serves as very reassuring purely from the fact that you know that many many other people have to deal with similar situations when project management goes really bad.

    Finally as food for thought for those posters who stated above that patterns (and specifically design patterns) are not useful, I'll take the liberty of quoting the preface to Anti Patterns:-

    AntiPatterns are fun to read and discuss with firends. But get serious! This book is about the truth of software technology and development. In it, we define what's really hapening in technology and on software projects, and what you can do about it. AntiPatterns identify those bad design concepts, technical approaches, and development practices that lead to poor-quality software and project failure. This book also explains how projects identified and avoided these problems to improve their designs and practices for software success.

    Can you handle the truth? The truth is surprisingly hard to comunicate, and often regarded as politically incorrect and undiplomatic. The truth does not make everybody happy. In order to make this exposition of our industry palatable, we resort to comedy wherever feasible; and it has been said that comedy is the most serious tragedy. The truth is that the state of software engineering today is a tragedy: Five out of six coprporate development projects are considered unsuccessful. [Johnson 95]. Most software systems that are delivered fall far short of the desired features and virtually every system is a stovepipe, unable to accommodate changing business needs.

    In trying to explain this universal lack of software success, we came to the conclusion that there are many more AntiPatterns in practice than design patterns. In Internet time, technology is changing so fast that the design patterns of yesterday are quickly becoming the AntiPatterns of today....

  • Sample chapters (Score:4, Informative)

    by jacoplane ( 78110 ) on Thursday May 16, 2002 @11:35AM (#3530078) Homepage Journal
    There are some sample chapters available on the book's website [manning.com]

  • how about (Score:3, Insightful)

    by david_g ( 24196 ) on Thursday May 16, 2002 @11:45AM (#3530148)
    ...bitter about people who decide that one language is all they need to learn and leave the rest of us having to know mediocre programming languages because that's the only way you get a job?

    ...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.
  • The idea of "Antipatterns" is widely accepted; thinking in those terms is really quite useful. A nice briefing describing antipatterns is at http://www.antipatterns.com/briefing [antipatterns.com]. They define antipatterns as ``negative solutions that present more problems than they address.'' In other words, an antipattern is a solution that's worse than the problem. One of their analogies is a map with a minefield marked in it.... sometimes knowing where not to go is as important as knowing where to go.

    More information (and some fun examples) can be found by starting at http://www.antipatterns.com/dev_cat.htm [antipatterns.com], where they list many specific antipatterns for development, management, and architecture. These pages aren't easy to find, which is too bad because they're a nice summary of specific antipatterns.

    One example of an antipattern is vendor lock-in [antipatterns.com]. Their description of why vendor lock-in is an antipattern is both amusing and sobering, thankfully, nothing like that would ever happen in the real world :-) [sunbelt-software.com]. A full description of an anti-pattern needs to also describe a remedy/alternative; their recommendation for vendor lock-in (aka ``Pottersville'') is an isolation layer. It'd be easy to argue that open source software/free software (OSS/FS) [dwheeler.com] is an alternative solution, since OSS/FS also frees customers from absolute control by a single vendor and there's quantitative evidence for why, in many cases, you should use it [dwheeler.com].

  • I teach Sun's core Java curriculum, and I know very, very, very (too) well that it's not easy to learn, it's harder still to implement well, and it's next to impossible to grasp completely in a single week. I tell my students to practice, and to read Bruce Eckel [bruceeckel.com]'s Thinking in Java [tatteredcover.com]. After I get through this book, I may end up recommending it as well.

    I don't get Idiot's Guide or For Dummies. Why would anyone buy a book that insults their intelligence right on the cover? Unless people are really that stupid.

  • Thanks for the kind words. (Score:5, Interesting)

    by BitterJava ( 579801 ) on Thursday May 16, 2002 @12:00PM (#3530233)
    I'm truly not worthy. You have elegantly and accurately captured the spirit of Bitter Java. I spent a whole lot of time as a Java architect and consultant, and noticed a whole lot of repeated mistakes. Bitter Java is about capturing those mistakes and wrapping them up, so that others can avoid them. I've got a weakness for kayaking, and that comes through (a little too strongly?) in the book. One of my favorite pictures is of a friend leaning against a sign after driving all night, and yawning. We snapped the shot, and then pointed out the words on the sign: "Seven people have drowned here." Of course, after wetting his pants, Eric was about to get in his kayak and run the falls. That's a perfect antipattern. Literary form; concise; points out a negative behavior (playing under the falls), and the decidedly negative consequence. That's Bitter Java. Of course, you've also got to point out how to avoid the negative consequence, and thus the emphasis on refactoring in Bitter Java. I definitely cannot claim credit for creating antipatterns. (Thanks to the reviewer who compared me to Al Gore...priceless.) In fact, one of the authors of the best-selling Antipatterns book, Skip McCormick III, wrote a glowing forward for Bitter Java. Thanks, Skip.

  • Real programming (Score:5, Insightful)

    by gillbates ( 106458 ) on Thursday May 16, 2002 @12:00PM (#3530239) Homepage Journal
    The problem with the "Learn To Program in (insert language here)" books is that they don't teach people how to program, but just how to write code in a given language.

    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.

    • Preach on! (Score:2)

      by DG ( 989 )
      Lemme hear an "Amen!"

      And I'll go even farther than you, and state:

      "Properly written code is largely language independant - so the language you choose to program in does not affect system effectiveness"

      Or dumbed down:

      "If it works, and it was well-written, then it doesn't matter what language it was written in"

      The trick is that you-as-programmer have to assume that you are writing code that someone else will maintain, that this maintainer will be unfamilliar with the language, and that this code runs the system that pays your salary.

      You have to optimise your code for LEGIBILITY, so that when the downstream maintainer starts changing it, you give him the highest possible chance of understanding what is actually going on, making the change correctly, and not screwing up your paycheque.

      It's really not that hard to do, once you get into the swing of it, and very very rarely does it compromise the ultimate system performance. There usually is no downside.

      If you learn to do this, then you can let people work in their language of choice, which pays HUGE dividends in productivity and coder happiness.

      I wrote a huge user-management tool in my personal language of choice - perl. Perl maps well into the way I think (you might say I think in perl) Immediately after I wrote it, I moved to a new position in the company, and this massive codebase was dropped on three people who had zero experience with the language. But because the code was optimised for legibility, they picked up on it right away, and were able to greatly extend the functionality of the code with almost no delay and no loss of original functionality.

      Forcing coders to work in a particular language - or badmouthing a language because it isn't fashionable (like one moron of a consultant recently chose to do at a meeting I was at) is a sure sign of Not Getting It.

      DG
  • One thing that I noted when I first dealt with the problem of C++ (yeah, the language is a problem, we all know that) - is that everyone was writing these "wonderful" classes and yet, I found that not a SINGLE ONE made writing code that much easier. Oh, it changed the paradigm, but it didn't change the amount of work that had to be done. Far from it: it actually INCREASED work because we had to learn each and every class (which, in that perverse way that programmers are, seldom had much in common).

    "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).
  • This review sounds exactly like database normalization- one does not end up with twenty tables each with two columns and expect wonderful performance- sometimes that repeated data that might (in a fully normalized database) speed performance by a significant amount. Joins in the database world cost cycles- I think the same thing holds in the OO world- don't normalize to the nth degree.
  • I've always wanted to write a book called "Teach Yourself C Programming in 21 months, if you're lucky, and forget about C++".

    The syntax of a language? Easy to master in a short period of time. Usage in expressing ideas? Months. Years. It's amazing what people think they can get away with shortcutting.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close