Slashdot Log In
Bitter Java
from the tea-is-smoother-but-harder-to-program dept.
| 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.
All I want to know is.. (Score:2, Funny)
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.
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.
Re:Development Processes be damned.. (Score:4, Funny)
For some functional languages, it seems you can use any design pattern you want - as long as it's recursion.
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:Design patterns and Lisp (Score:4, Informative)
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);
}
finally {
myfile.close();
}
and
(with-open-file (myfile filename)
)
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.
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.
Sun invented patterns? (Score:3, Funny)
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)
"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.
This book is right on the money (Score:1, Informative)
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.
My Gripes about Java &tm; (Score:5, Funny)
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.
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
Mm.... Bitter java... (Score:2)
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.
mmmmm... Money.. (Score:2, Insightful)
Here's a book title... (Score:2, Funny)
Examples, please! (Score:2, Interesting)
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)
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.
Amazon.com? (Score:1)
distributed programming != OO (Score:1)
have to do with distributed programming. OO doesn't make distributed programming any easier or harder. They are separate issues. If it
didn't work it's because they didn't solve the
right problem.
anti-antipatterns (Score:4, Interesting)
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.
Antipatterns (Score:5, Informative)
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
This is a great book idea for beginners (Score:1)
Antipatterns? (Score:2)
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.
I hope more people read this... (Score:2)
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.
Dunno about this... (Score:1)
In other words - programming is hard! (Score:2, Interesting)
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:
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."
Nothing more to see here. Move along. (Score:2)
Quoth the reviewer:
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>
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)
A book on real world programming (Score:1)
OO toolkits & templates (Score:2)
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.
Over engineered... (Score:1)
Take for example writing serial driver. The functional specs are finite and limited by the hardware. Building a business application is influenced by what sales, marketing, management, QA, programmers and customers think is important. Don't mod me up or down, since this is freakin common sense.
there was an island between Sumatra and Bali... (Score:4, Funny)
Danny (who plays gamelan [danny.oz.au] and is interested in Indonesia [dannyreviews.com]).
Thinking in Java (Score:5, Interesting)
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".
Good things are hard to do (Score:2)
- JFK
Anti-patterns in 1998 (Score:5, Informative)
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:-
Sample chapters (Score:4, Informative)
Inheritance is overrated (Score:1)
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.
Antipatterns are well-accepted... and useful. (Score:2)
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].
Teaching it Every Week (Score:2)
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)
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).
Comp Sci degree == bad code (Score:1)
This trend is that they create structure for no reason at all. My belief is that, every time I split functionality into a new class, the application has to benefit from this split in some concrete way. If it doesn't then the code just ends up slow and difficult to maintain.
I had a guy working for me that had a cs degree and a couple years of software development experience. A bright guy, I gave him a small project to complete.
Eventually I had to maintain his code and what I found, chilled me to the bone. He had about 5 pages of code split up into 15 classes!
As you might imagine, it is pretty difficult to maintain something with more structure than code. I just gave up and rewrote the thing.
So what did all his attemts at ood create? What was the point of thinking like Bootch on this one? Not every project is "The Great Software System", most of the time its simple little hacks that run for a year and then need some attention.
Maybe ood == unmaintainable?
old school (Score:1)
I've seen others touching on my approach to software development.
OOP is interesting, a good IDE is impressive if it's pulled off, write once
and deploy everywhere is a noble goal. But... nothing beats pure clean
C written using vi and a CLI make. The stuff runs fast without surprises,
the editing process is almost subconscious and if the coder is good,
maintaining the code is economical and bugs are nearly nonexistent.
Same thing goes for debugging, there's nothing like printfs to get to the
heart of a problem. The real secret of programming is to have the ability
to "be the computer", to load and run the code in your head.
It's an old school attitude, but I think all that other stuff is a crutch.
Sure I'll use those extra layers of cruft, sometimes options are limited
or the platform or client demands it. But the overhead both at runtime and
during development outweigh the benefits. -- K&R are dead, long live K&R.
Bill Romanowski
www.tqworld.com
Sounds like DB normalization?? (Score:2, Interesting)
My Book Title (Score:2)
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.
www.antipatterns.com (Score:1)
Buy PDF Online... (Score:1)
We should all applaud a small publisher like Manning for doing this.
It's always nice to be validated.... (Score:1)
The Newest, Greatest [db system|programming language| methodolgy] is the Silver Bullet(tm).
Management, and students, and academics: THERE IS NO SILVER BULLET. Deal with it!
I took a course in OOPs and GUI, back in '94. (I know, sounds like someone dropping an egg.) What I decided was that OOD looked interesting, but the closer you got to actually *coding*, the *fuzzier* it looked. Folks, we get one instruction executed at a time (even if we're multiprocessor, we're doing multiples of the same instruction). When you get down to it, you need to be able to deal with ->sequential instructions-.
I see a lot of younger folks who *didn't* have the serious intro I had - assembler, o/s, etc...and the result is that they have no *clue* what's going on inside the physical machine.
In fact, what I finally decided about OOP is that it is doing nothing other than:
a) trying to enforce all the structured coding and good code practices
that they were teaching for 20
years by *compiler*, and
b) the compilers, and their libraries, became so huge, because they tried to create every function ever needed for every program that will ever be written.
*sigh*
Management, however, almost never wants to pay for quality, they want to find a formula for it.
mark, who'se good, and experienced,
and still looking for a job
during this "recovery"
150 secs vs. 5 secs: I Know The Story (Score:1)
The results? It took 2 1/2 minutes on average to get the authorization code from the credit card service. The stripped down (1:1) code only took 5 seconds. Yes--150 seconds for an object oriented vendor independent abstracted version versus 5 seconds for a flat direct to their API version. This was on a test RedHat 7.2 Linux machine with 768megs of RAM and dual 533's with no users. I tried a different machine, RedHat 6.2, 640megs, dual 533's, no users, same results.
I played around with memory allocation for Resin, Apache, etc. No improvements.
Finally some sense on Java (Score:1)
My department has quietly deprecated Java in favour of simpler building blocks (C for big real-time applications, Perl and VB for small apps). Our projects are always on-time and on-budget as a result. In comparison, hard-core OOP languages like C++ and Java have resulted in disasters ($$$$$).
I'm not against them in principal, but the problem with Java (and to a lesser extent C++) is that OOP requires a fair bit of expertise to master. The issues are subtle and deep. These projects I would not something I would give to anyone under 5-10 years of programming experience which unfortunately seems to be the profile of your average Big-5 IT consultant.
Java is still platform-sensitive and vulnerable to run-time errors. Its sole strength is database connectivity. You can implement some OOP concepts in C but structuring your program well. This usually gets you the results you want. OO Perl is very nice, but not for novices.
A final comment - when I see a well made web site it seems like the scripts often end in .pl or .php. I'm starting to see good ones in .asp. Most often, the really pathetic ones end in .jsp. The results speak for themselves.
Another Review .... (Score:2)
"This book discusses some design patterns and their issues and solutions for Java programming. The author uses VisualAge for Java, Websphere and DB2 as his tools, but the principles can be applied to any Java project. The codes are developed with JDK 1.2.2. Some, but not all, of them have been compiled, but not tested, in JDK 1.3.1. The author uses the term "antipattern" for a flaw in design. In addition, he attempts to have a unique descriptive term for each antipattern. If you jump from one chapter to another without specific order, you might be puzzled by all the new terms. Fortunately, the book has a good index on the keywords and the pages they are described."
URL: Bitter Java Review [compunotes.com]
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:Well hell yeah! (Score:2)
Not to be rude, but if you're so "bitter" about Java why don't you design something better? I agree that Sun overmarkets Java's cross-platform capabilities, but for the most part it DOES work. I don't know of anything else (commercial-quality, that is) that works across as many hardware platforms, especially for server-side apps, which is the area where Java has really done well. Most of the examples in the book seem to revolve around J2EE and Servlets.
Yes, applets suck for the most part. Oh well...big loss there. Then again, most crappy applets I've seen tend to be the ones where someone implements a menu-bar or some retarded visual gimmick.
So Java has it's problems, but there's no more reason to be bitter about Java than any other software platform.
Re:Well hell yeah! (Score:1)
Mind you, this is all related to server-side processing. Bringing in Swing/AWT and browsers just makes a mess of things.
Re:A T*roll.... (Score:1)
As long as the language they choose is statically typed. I haven't seen too many dynamically typed languages sucessfully ported to DuhtNet.
Re:A T*roll.... (Score:1)
Uhh...how again does C# allow you to use any languae on the CLR? You just specified the language.
And even then, that's not true. The CLR (pronounced VIRTUAL MACHINE for all you Java folks) allows only C#, Visual Basic.NET and M$ flavors of C++ to be complied down to a common intermediate language (pronounced BYTECODE for the the Java guys). They even had to badly hack VB and rip off Java to do it. Sure, you could write a compiler to turn Java or COBOL or Fortran or god knows what else in the common language, but frankly, I doubt many will bother. It's only fast because M$ has the ability to tailor the entire OS to the
I know, a bit off topic, but I can't stand pointless shilling for
Re:A T*roll.... (Score:2)
Pascal [qut.edu.au]
Scheme [gnu.org]
Python [jython.org]
Re:Well hell yeah! (Score:1)
Re:Well hell yeah! (Score:2)
Other than this, I have not heard of Java code not being portable across platforms. I'd love to hear some examples of what you are talking about.
Re:Well hell yeah! (Score:1)
As for the Applets, I agree you might "piss off all the visitors to your web pages". However that is because they are slow to load, not unstable. I don't think Applets are inherently more unstable than any other code. Besides Applets are a few classes and interfaces in a language who's API has thousands. Java != Applets. If Java gets replaced by something better great, but for now, it's a great tool.
.NET not quite the solution you imagine (Score:2)
Only languages that closely resemble the structure of the CLI framework will have slick performance. The less it fits CLI profile, the slower it will be because the less that can be emulated "natively" by CLI and must be custom simulated.
I don't really know what is so bad about native EXE's making OS API calls anyhow for server-based apps? If the memory is properly managed by the OS or processor, one app should not clobber another no matter what anyhow.
It just seems like a machine language on top of machine language. I don't get it. Swapping machine brands without recompiling is not that common a need anyhow. Use an interpreter if you need that. Python and Perl have been doing that for years.
I don't get it. These run-time-engine thingies seem like a fad. Anybody wish to fill us in?
Re:finally (Score:2)
I see a business opportunity in this: the "Frustrated" series, similar to the Dummy series.
"Java For the Frustrated"
"MFC For the Frustrated"
"Dealing with Frustration for the Frustrated"
The cover would feature a cartoon of a frustrated geek pulling his/her hair out, and peices of hair at the bottom.
Re:Well hell yeah! (Score:2)
Not necessarily. You still have to handle them properly in order to get decent results.
Also, the way Java does it tends to bloat up the code IMO, making it hard to find the business logic that actually does the real work. IOW, harder to read. It makes the exceptions more prominate than the real meat.
BTW, many Delphi fans think that OOPascal is superior to Java. I won't get into the middle of that fight here.