Slashdot Mirror
Bitter 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.
How many of those results are for coffee or the island?
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.
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?
"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.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
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.
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.
The enemies of Democracy are
Way to pack those Amazon affiliate links into that submission...
"Practical OO Programming In Binary"
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 most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
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.
Advertising cross-platform code as being one of the major benefits of java was a mistake by Sun. They should have realized that a language written for a generic VM is cross-platform only if the implementations of that VM and the system interfaces it uses on each platform are 100% compatible. That's a challenge even if all the implementations are written by Sun! Considering that they are not, and that some of those implementations were written by people with a somewhat vested interest in ensuring that cross-platform operation never comes to pass, it should have been obvious that it would never come off without a hitch.
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.
The enemies of Democracy are
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.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
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.
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
I can see it now:
Chapter 1
The joys of 0
Chapter 2
The joys of 1
Chapter 3
0 meets 1
--It's Pimptastic!--
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.
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:
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."
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>
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.
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.
Danny (who plays gamelan and is interested in Indonesia).
I have written over 900 book reviews
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
Remember Amalek.
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 -- I specially like item 21: "A fool with a tool is still a fool".
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
No, the over-engineering of code with too many layers and overly complicated object heirarchies are much more likely to be the culprit.
Roger Session (COM and DCOM: Microsoft's Vision for Distributed Objects, Wiley, 1998) (OK, this is from the pre-C# days when MS was going to have you do your GUI in VB, your business logic in the MS Java dialect-du-jour) goes on about "object pools", about how you don't create a new taxi cab everytime you need a ride from the airport.
Yes, that is a good example where the Factory pattern along with object recycling is useful.
I always wondered, what is so expensive about object creation anyway, and in C++ with "auto" objects, it is just about free. Java object loading, however, is expensive because unlike C++, they do not use a static VTABLE but have to check character string names against what is in the object. Java object loading is what makes you sit there twiddling your thumbs when an good sized Java app fires up.
You are confusing 'class loading' with 'object creation'. Class loading typically happens once for many object creation events.
Auto objects in C++ come off the stack, whereas Java objects are always allocated from the heap. However, current Java implementations are very fast at object creation, and you never blow stack with Java objects. ;-)
So, to optimize a Java app, one has to leave clean, textbook OO behind and resort to tricks like OO's that "lazy load" classes as they are needed instead of at application start time, like the use of "object pools" to create object instances once and keep reusing them.
Um, that is 'textbook OO'. BTW, 'lazy loading' was around long before Java...it's been used for years in the VB community.
The word on the street is that Java is dog slow unless you optimize,
The word on the street is wrong, then. Modern Java is quite fast on typical 'first blush' code.
it is slow because of class loading,
Class loading mainly effects application startup time. It is a fallacy to confuse 'startup time' with 'execution time'. Many of my apps stay up for days at a time...startup time just isn't an issue.
and the way you optimize is that you use object creation sparingly in your inner loops, even if it makes your code look ugly.
Interestingly, this is also a good way to optimize C++. ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
"We do this thing and the other not because they are easy but because they are hard."
- JFK
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:-
The only Good System is a Sound System
Patterns are about balancing and rearranging opposing forces in a design to achieve some wanted effect. All patterns have consequences. These usually must be dealt with by other patterns. And thus you have a pattern language. In this setting anti-patterns makes absolutely no sense at all.
M.
There are some sample chapters available on the book's website
Hmmm...
Pascal
Scheme
Python
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, 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.
Another really superb book is Effective Java, written by Josh Bloch, who is responsible for the Java Collections API.
... 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.
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
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.
...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 tone of the review was "Gee whiz, even if you use Java, you can still get it wrong!" That sort of book is very well suited for new programmers. Showing them the wrong way to do something is often as valuable as showing them the right way. But recommending it for "hired codeslingers" seems a bit, well, inappropriate.
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.
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.
The society for a thought-free internet welcomes you.
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).
IANAL, but I've seen actors play them on TV
I have written a lot of Java code. Only once did my code not work on other platforms. I was writing some charting software on an NT box. This requires getting a graphics context from the OS and using that to render the images. This works fine on NT, however, if you run it on a headless Unix box (no X server) it won't work because there is no way to get the context. So the code was not cross platform. However this is fixed in version 1.4. And you could include the PJA toolkit jar to fix it as well.
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.
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.
Take a look at Python. It doesn't have a large commercial backer, but it is commercial-quality. NASA uses it, Disney uses it, more shops than you probably imagine. Oh, and python simply rocks.
Glock27 (in addition to a catchy sig) has it right. Java is quite fast. It can be made faster by diligent design practice. Sloppy design can result in wasteful object creation/garbage collection and some of the built in class libraries have bad habits (a few i/o streams come to mind) in this regard also.
Having said that, my company is doing immersive 3D networked technology (which can include FPS games) in Java (with some OpenGL or DX) and we're capable of getting really respectable frame rates even with very busy systems. Part of it is because we allocate once where possible and recycle, rather than continually create and destroy objects. And we avoid some of the utility classes. And we THINK while designing to minimize things like thread counts, class counts, etc. to give quick loading of the app and good performance even on crappy hardware.
Good Java code is as fast as good C++. Good C might be a bit faster, but most C is mediocre and Java can compete with that. Slow Java code is a result of poorly educated programmers and designers doing unwise things (most of which are utterly avoidable).
-- Mal: "Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious."
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.
... 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.
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
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.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Yes but whatever the differences between languages are the choice of language depends upon what program you want to write.
Video Game cheats, hints a
Yes, that is similar to what PJA does, but running a virtual frame buffer is a waste of resources if you are not going to use it often.
Nevertheless, the code does not run on multipul platforms (until 1.4 at least)
AWT with the browser-supplied VM was a very bad idea, but I suppose it was necessary to get Java off the ground. Using Swing with the Java plug-in works quite well multi-platform. If you can get your users to install the plug-in (it's easy for Windows users, but others have to be motivated) it's a great thin-client platform.
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.
Neither Prolog nor SQL are functional languages, so using those as examples is rather silly. I'd like to know where you'd see SQL outside of databases, seems it would be rather a bad language for anything else (though I don't know much about SQL99, maybe the standards committee had delusions of grandeur).
There are a number of functional languages with quite respectable performance in good implementations, e.g. O'Caml, Standard ML (MLTon, smlnj), Scheme (bigloo, stalin for certain applications), and (though less functionally oriented) Common Lisp (CMUCL/SBCL, ACL),. They may not be quite as good as good C/C++ compilers, but they're not that far behind, either.
I suspect you and I have different definitions of OO. The problem is that damn near everyone has a slightly different definition of OO. Go read this article by Johathan Rees, then come back and tell us what you mean by a "real OO system", and why you can't do it properly in CLOS.
To a Lisp hacker, XML is S-expressions in drag.
Other languages don't have this problem. Spanish, for instance, has su. As a bonus, it also doesn't have the "free" ambiguity.
Spanish has its own inherent sexism. For instance, a musician is "el musico" (inherently masculine). The word for music is "la musica" (inherently feminine). So what do you call a female musician in Spanish? "El musico mujer" ("the (inherently-masculine) musician woman").
I think it's a problem common to all romance languages. English has the benefit of not insisting that inanimate objects must have figurative penises or vaginas.
I don't make the rules. I just make fun of them.
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
Want to learn about race cars? Read my Book
I just fininished reading Modern C++ Design 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.
-- Ed Avis ed@membled.com
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 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.
// Mess with file...
;; Mess with file...
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.
To a Lisp hacker, XML is S-expressions in drag.
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.
Tweet, tweet.
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.
In my sociology class, I wrote a paper on the effectiveness of a computer science degree. My observations were pretty obvious: academic experience is almost useless in writing good programs in the absense of practical experience.
Something that is commonly overlooked though, is that academic experience has a significant benefit when combined with practical experience. Having one, but not the other, has a whole host of problems.
It's not meaningless to have a comp sci degree, but having a comp sci degree does not, in any way, make one a programmer.
int func(int a);
func((b += 3, b));
How about:
:-) Those working for smaller companies may wish to order:
Volume 1: The OO and the Imperative Approach
Volume 2: Data Structures and Algorithms
Volume 3: Learn C in 24hrs
Volume 3a: Initialising Pointers and Stress Management
Volume 3b: gdb
Volume 4: Learn Java in 24hrs
Volume 5: Bitter Java
Volume 6: Software Engineering inc Source and Project Management
Volume 7: Mythical Man Month
Volume 8: How to Write a CV
Preferably in that order.
Volume 9: The DIY DBA
Phillip.
Property for sale in Nice, France
Yeah I posted before I thought about Python. It definitely does rock. Back in college we used it as a scripting language for a VR system, binding python objects to 3D models, etc. The fact that we could dynamically override stuff like model.LeftArm.turn was really cool.
But, although it's a great language I don't see it being used in enterprise scale solutions the way J2EE is. I could be wrong, and would like to be proved wrong. It could just be a marketing thing, since J2EE is such a buzzword now.
Although the template solutions in that book were pretty clever, they generally pointed to deficiencies in the language itself. For example, look at how difficult the command pattern is to implement in C++! In better languages, it is simply a lambda expression.
In addition, a lot of the stuff in that book is pretty useless for what programmers do day-in and day-out, and the compile-time benefits are only really benefits if you have extremely time-critical code.
The stuff is good for computer languages theory, but for practice, C++ is way too complex for day-to-day efficient work.
Engineering and the Ultimate
I think there seem to be fewer patterns in Lisp, because Lisp needs them less.
I'm sorry, but I have to reply - a lot of people are making statements like this and it only shows that they misunderstand what a design pattern is.
A proper design pattern applies to all languages equally - because it's about design not about coding.
Saying that Lisp doesn't need design patterns is like saying BMWs don't need drivers.
A design pattern is something like "isolate all the hardware dependent stuff in one portion of the application" or "use a special class as a filter for translating object oriented data into SQL statements". Your examples are anything but "design patterns".
Clear, Dark Skies
(* 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. *)
The problem is that there is no objective way to measure that paradigm/language B is better than A.
Computer Science is sorely lacking in the metrics and objective comparison department.
It is more intellectually honest (and safer) to say, "Paradigm X fits closer to the way I think and work", rather than "X is better than Y".
Note that strong-typed languages tend to be more verbose than dynamic ones, however, fans of them say that the compiler protection is worth it.
It is sort of like the fighter plane design issue of deciding whether keep the plane light and nimble to outmeanouver the enemy, or heavily armored so that it can take more hits without failing.
There are complex strategic tradeoffs in paradigm and language design such that it is hard to say that one is clearly better. It often depends on the skillset and personality of the pilot.
Table-ized A.I.
(* OOP can be wonderful if you use it with caution: it's not the best paradigm that solves all problems in every single case you may stumble on. It's just another way to make things work better. If used correctly (IMHO), it's very useful. *)
I keep hearing this from the more mild OOP fans, but there is almost zilch agreement on when and where to use OOP or another approach. (Alleged) expert A will say use OOP on project X, but procedural/relational on Y, but expert B will say the opposite.
Somebody needs to find "paradigm patterns" for when to use what. Otherwise, we will just have flamewars all day.
OOP criticism:
http://geocities.com/tablizer/oopbad.htm
(Warning: it is now easy to slashdot geocities because they ran out of VC and are getting stingy like a real business.)
Table-ized A.I.
(* 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. *)
There is another set of messages descussing this very same issue around here somewhere.
"Normalization" seems to involve two different (probably orthogonal) things. One is to remove duplication, and the other is to "group related" things into separate chunks/tables/objects.
Duplication removal is hard to argue against, except maybe where the duplication may be temporary.
The "grouping" issue is the more controversial one. It is better IMO to have "virtual chunks" rather than physical, or "hide-wired" chunks if possible; because the chunking needs may change or need to be different per section or algorithm.
IOW, Einstein had it right: It is all relative.
Table-ized A.I.
funny, in English the male gender is ALSO the neutral. Except you're wrong about la musica.
Some people like their coffee black, no sugar.
They enjoy the aroma.
Others hate such type of coffee, and can't understand why anyone will want to drink bitter coffee.
One can be bitter about ANYTHING, just that, when you are bitter about one thing, think of the other qualities of that thing.
Besides bitterness, the thing may have a good aroma, or it looks good, or it is useful in chasing away pests, and so on, and so forth
Muchas Gracias, Señor Edward Snowden !
i can tell you that python, and more specifically, zope, do scale just as well, if not better, to the enterprise. python allows you to extend via C/C++ relatively easily, and that provides a very easy path to scalability.
:)
as an example, i just deployed a site that will has at least 20k unique users per day. granted, that isn't true internet-scale, but i guarentee you that it will scale farther, faster, and easier than anything that comes outta Sun(tm).
whether or not python/zope are used in other enterprise solutions or not is a different question entirely, of course, but i did want to offer some evidence to the idea that there are alternatives to the java marketing machine.
btw, i'm glad you like python.
I'm sure neither NASA nor Disney would consider using Python for everything.
True, true. But the guy from NASA I met at the last Python conference (IPC10) told me NASA uses python for all their testing. To me, that speaks volumes.
Competent programmers know that different tools are useful for different purposes.
Again, right on the money. But the OP was asking for something that works as well *cough* as J2EEEEE (tm) for web stuff.
Yes on options two and three, but I wouldn't rely on option #1 if I were you. Consider the following:
//filesToMung is a String[] array
for (int i = 0; i < filesToMung.length; i++)
processFile(new FileInputStream(filesToMung[i]);
A new FileInputStream is created every time around the loop, passed to processFile(), and then becomes unreferenced. The compiler cannot immediately reclaim the stream (processFile might spin a thread to hold onto it), so it has to let the GC do it. If the GC is a reference counter, like vanilla Python's GC, this loop will work reliably. If it's anything more reliable or modern (mark-sweep, stop-and-copy, generation scavenging), this will fail randomly if filesToMung gets big enough, as unclosed, uncollected streams pile up between GC sweeps.
There is a difference between finalizatiion and storage reclamation, and it's a real bad idea to mix the two.
To a Lisp hacker, XML is S-expressions in drag.
Thank you. I originally wrote the code with myfile above the try block, but thought that the Java designers might have made it convenient for a catch/finally clause to get at local variables in the try block. They already made a "convenient" decision that the scope of exception object bindings goes beyond the catch statement:
try {
}
catch (Exception e) {
}
...
try {
}
catch (Exception e) {
}
The compiler will spit at the second catch - the first declaration of Exception e is still in scope. Bleah!
To a Lisp hacker, XML is S-expressions in drag.
I believe we are actually in agreement. What I thought I was saying was that most of the stuff promoted as "patterns" is actually canonical ways of getting around limitations in Java/C++.
For example, the Visitor pattern is the canonical way of dealing with the belief/requirement in most OO langauges that writing a method that can dispatch on a published type somehow violates that type's encapsulation. In CLOS, you just write another generic function, which ends up being more efficient than the Visitor pattern (one dispatch versus two per visitation).
The claim in the presentation I referenced is that two-thirds of the patterns presented in the original Gang of Four book have this nature. They don't apply to all languages equally, because they're unnecessary in CLOS. Patterns would be more interesting to Lisp people (and more intellectually interesting in general) if they weren't primarily used to help people get things done despite using Java/C++.
To a Lisp hacker, XML is S-expressions in drag.
(* and all I can say about it is that my team works better with OOP. *)
Care to give an explicit example?
There is more training material about making decent OOP than making decent procedural/relational.
Also, a lot of the complaints about procedural tend to be language-specific limitations anyhow.
(* There's no need for flamewars: be open minded, test both ways and pick the one you liked better. Nobody will find a magic way of choosing one for you. *)
I would rarely pick OO. OOP makes it too hard for me to manage attributes because it tends to mix attributes up with algorithms, which are less compact and concise than attributes. IOW, OO drags both down to the level of algorithm grokability, which is a lot lower than attribute tables, at least for my eyes and head.
I will believe that OOP is better when I see side-by-side code comparisons of OO kicking p/r's butt. Until then, the cliche animal, shape, stack, and device driver examples don't apply to real world projects that I see.
Table-ized A.I.
(* I assume you're joking? People don't turn into dogs. *)
Perhaps you have not met my neighbor's ex-wife.
Her poly reeeaaaaly morphed.
Table-ized A.I.
(* The correct way to model this is to realize that there is no such class as Employee or Manager. The correct class is Person. *)
I would challenge this. "Employee" is usually a sufficient entity for biz apps.
If you use Person, you might be tempted to put vendors or customers under it. However, vendors and customers can be *companies* and not necessarily persons.
It often works to have a Contact class or entity, and to reference it as needed. Some OO fans want to put the Contact info in some "root" class, such as "BusinessParty". But, vendors and clients can end up having multiple contacts per company, such as a Billing_contact, Sales_contact, etc. HAS-A Contact is more flexible than IS-A contact in this regard. Your design will change less if you later go to 1-to-many Contacts.
To model biz, you need a big graph(s), not a big tree(s), for the most part. Unfortunately, OO offers little or nothing that natively makes managing graphs and sets easier, that I see. OOP is optimized for trees and nested relatioships. Outside of these, it is not very contributory.
BTW, "roles" can be modeled very nicely in non-OO ways.
Table-ized A.I.
(* Even C# with .net is better - it allow people to use whatever language they want on the same CLI... *)
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?
Table-ized A.I.
The problem is that people read one or two "Learn X in 21 Days" books, and then try to force all their future designs to resemble the toy animal and shape examples.
There is rarely a disclaimer such as:
"Warning: Objects in Mirror Example Are Deceptively Simpler Than Real World Objects"
Table-ized A.I.
(* It's good to see a book which devles into the frustrating part of languages. Whether you like it or not, all languages have parts which can be a pain to use. It's good to see a book that acknowledges this. *)
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.
Table-ized A.I.
(* Again, right on the money. But the OP was asking for something that works as well *cough* as J2EEEEE (tm) for web stuff. *)
.NET (after version 1.0).
Depending on how you measure/define "better", candidates include Perl, Python, PHP, and perhaps even
Could you be more specific about what is "web stuff"?
Table-ized A.I.
(* Only once did my code not work on other platforms. I was writing some charting software on an NT box. This requires getting a graphics context from the OS and using that to render the images. *)
This sounds like a contradiction. If you want it cross-platform, then why does the OS's "graphics context" matter? Isn't it the client's graphics context that matters?
If you are using standard GIF, PNG, JPEG etc, even that shouldn't matter. Rendering vectors, for example, is not even a "graphics" operation really. I envision it like a pipe:
vector_list --> renderer --> output_file
Table-ized A.I.
(* Force-ing you to handle Exceptions will help you write more error proof code. *)
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.
Table-ized A.I.
What *is* a good use of inheritance for biz app modeling? I have never found any.
Table-ized A.I.
Could you be more specific about what is "web stuff"?
Sure. Web stuff is using a web server to serve a GUI to a client or to act as an RPC end-point (e.g., XMLRPC over HTTP, SOAP over HTTP, or roll-yer-own over HTTP).
Zope excels at the GUI by truly separating presentation from logic. Check out Zope Page Templates, which use an attribute markup language to embed presentation control in XHTML tags. Simply mind-blowing. Also, Zope is the only web server I've run across (I'm sure there are others...) that realizes the promise of reuse thru Object-Orientation. The quintessential example is style sheets. Under IIS/CFM/J2Whatever, you typically have to include a style sheet in every document that should use it. Under Zope, you instantiate it once, include it once, and sub objects inherit it automatically. Even better, that behavior can be overridden by careful instantiation of other objects in the hierarchy.
As to the RPC, again Zope is stellar. It does XMLRPC out of the box, and I hear SOAP support is coming soon (I seem to recall a package that makes this possible today, but I'm too lazy to surf over there and find the link for you). I mentioned a Zope app I recently deployed earlier in this thread, and with that app, we act as both RPC client and server. Using Zope/Python made the RPC stuff almost trivial, and our Marketing people were simply floored by how much we implemented in so little time.
Does that answer your question? Please let me know if I can answer anything further about Python or Zope. I've been programming almost 15 years, and I know 13 languages last count. Python is the only one about which I've ever felt passion.
You can get Zope here.
(* Zope excels at the GUI by truly separating presentation from logic *)
From what I have read, it is pretty good at content management, but so so at complex web forms. A reviewer for Info Week a year ago said that "it is haunted by too much OO zealotry" [paraphrase].
(* Also, Zope is the only web server I've run across (I'm sure there are others...) that realizes the promise of reuse thru Object-Orientation. The quintessential example is style sheets. Under IIS/CFM/J2Whatever, you typically have to include a style sheet in every document that should use it. Under Zope, you instantiate it once, include it once, and sub objects inherit it automatically. *)
You don't need OO for that. You could have some template, a table record per page for example. Somewhere you specify what the default is for the app, and *unless* you give a specific style sheet name, it uses that default (blank = default).
OO taking credit for defaults is kind of Al Gorish.
However, the tricker part is in granularity management. With methods, inheritance is all or nothing. You can't override 1/3 of a method without duplication or refactoring.
(* and our Marketing people were simply floored by how much we implemented in so little time. *)
Give me my favorite tools, and I am Kobe Bryant of the byte floor also.
Table-ized A.I.
(* An Employee class might be "sufficient" for some apps, but that doesn't make it correct. It breaks quite easily, as described by the poster at the top of this thread. *)
Which "break" are you talking about? I didn't see any breakage in my approach.
(* We typically model Person and Company as subclasses of BusinessEntity. You seem to think this is a "big tree", but it's actually quite small. *)
Yes, but I see no purpose in this. A customer is a customer. They might start out as a small single-person business and then grow to a company. My approach would only require flipping an attribute somewhere, and not *converting* from one class to another. IOW, more "change-friendly". The reald is not a tree, and modeling that using trees will tend to be fragile. End of story.
The company may even not bother tracking whether a customer is an individual or a company as long as they pay their bills. You are hard-dividing simply out of OO doctrine, and not a real biz need.
(* Contact is a role of the BusinessEntity class, not a class itself. If you model it like this you have HAS-A Contact, not IS-A Contact. As you state, this more flexible. But you're helping my side of the argument here, not challenging it. *)
"Contact" is a "role"??? I am not getting this.
(* It handles graphs and sets just fine. Can you post an example of something in this areana that it doesn't do well? *)
It does not handle multi-aspect orthogonal divisions well. See:
http://geocities.com/tablizer/subtypes.htm
and
http://geocities.com/tablizer/aspects.htm
(Yahoo is undergoing maintenance right now, so you may have to wait until Sunday to read 'em.)
At the very most, OOP is not superior. It is simply an overhyped alternative.
Table-ized A.I.
To clarify, and to hopefully cut off this hydra's head of an argument/troll, when I (and most Lisp programmers) say "Lisp" I mean "ANSI Common Lisp" as in the first object-oriented programming language to have an ANSI standard associated with it.
The multiplicity of Lisp dialects was a problem that went away in the mid-1980's, whether you realized it or not.
The only possible source of confusion I can imagine that would make this an honest post, rather than a troll, is Scheme. So the choice is "Common Lisp" or "Scheme." Which to me are as different as C++ and Java.
You don't need OO for that. You could have some template, a table record per page for example. Somewhere you specify what the default is for the app, and *unless* you give a specific style sheet name, it uses that default (blank = default).
Of course you don't need OO for that; everything we've talked about is Turing-complete.
OO taking credit for defaults is kind of Al Gorish.
As much as I appreciate any swipe at the former Veep, I think you're missing the point. Sure, I know you can code a function to do the correct style sheet lookup, but the difference is in the effort. Instead of trying to maintain a single massive, monolithic function that is essentially a big case statement, using OO and acquisition in Zope moves the burden from the developer to the system. The code becomes smaller and more logical, not larger and more difficult to comprehend.
The style sheet example was just that: an example. There are plenty ways that the OO nature of Zope saves time. I won't bore you with them because you really don't seem interested.
However, the tricker part is in granularity management. With methods, inheritance is all or nothing. You can't override 1/3 of a method without duplication or refactoring.
True, inheritance is not the be-all end-all technique of reusing code, hence the shift in emphasis in the OO community away from inheritance and towards composition. And with Python, you also have the option of using meta-classes (the risk, of course, is that your brain may explode).
Opening paragraph:
"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
(* Employee breaks as a class because it doesn't handle other relevant roles that a person might play (e.g. stockholder, customer, account owner). *)
:-) I sometimes do business as an individual, and sometimes as a company.
Why not? Anything can point to (reference) anything in the relational model.
(* No, a customer might also be an employee, a stockholder, a vendor, an astronaut, a mother, a policeman, a manager, etc. If you can't grasp this, you're missing a fundamental OO concept. *)
We probably need a looooong talk together.
(* Are you trying to say that a person turns into a company!? I hope not. *)
YES, I am.
(* But Person and Company have completely different attributes. *)
In most practical cases, a company is trying to model information about customers. They may not *know* whether that customer is an individual or a company. I am the owner of a company, BTW, and I have no employees (and almost no sales either
What specific *relavant* attributes would be different?
Table-ized A.I.
(* Of course you don't need OO for that; everything we've talked about is Turing-complete. *)
Yes, but you have not proven OO *better*.
(* Instead of trying to maintain a single massive, monolithic function that is essentially a big case statement *)
You did not read very carefully. I said NOTHING about using a "big case statement". You are comparing decent OO (if there is such a thing) to bad procedural/relational.
Why do so many OO fans love to use that word "monolithic" but none can cleary define it nor provide a realistic example of it (except in bad p/r)?
(* The code becomes smaller and more logical, not larger and more difficult to comprehend. *)
Bullsh*t! I don't beleive you! I suspect you were just poor at procedural/relational programming, so anything looks good in comparison.
(* I won't bore you with them because you really don't seem interested. *)
Show me something specific, and I will match or beat it!
(* hence the shift in emphasis in the OO community away from inheritance and towards composition. *)
Which OO does no better than procedural/relational. OO is optimized for trees and nested relationships. Outside of that, it offers nothing that helps over other paradigms.
Table-ized A.I.