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
I would love it if someone would replace Java with something that worked. I'd even accept something from Microsoft.
Kickstart
There is something about OOP that I have learned makes people want to over-apply it. The result is frequently bad, as project development times stretch out to infinity. I know of a number of OOP programming projects that got canceled because of implementation issues (speed of development, speed of use, etc.), and that is rare now-a-days in older programming languages.
I want to read this book. I have a feeling it may be instructive in avoiding this moral hazard of OOP.
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.
You're still stuck in the Java = Applet mode.
A lot of non-technical people are stuck in this mindset. If you start approaching and talking to technical folks, you'll learn the real Java story.
For now, I suggest learning the "Macro" function whatever version of Microsoft Office you're misusing.
Please stop posting to /.
Anyone who tells you that a tool/language/methodology will make programming easy is a liar/fuckwit. Doing difficult things is hard. There comes a point where a system is so difficult that it makes very little difference whether you program it in VB or assembler. It's still going to be hard.
I though perl was a girl's language but look how hard it is to fix the page widening bug.
"Under the iron bridge, we fist" - The Smiths, Still Ill
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.
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 seem to recall being urged to avoid Amazon at all costs not so long ago due to their patent of 'one click' purchasing? Is this still on? Just in case here is an alternative link.
It's not clear what "nicely wrapped" objects
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.
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;
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!--
I'm a beginning programmer and it is a great idea to have a book showing the wrong way to do something for someone like me. It is near impossible for a beginner to go grab an Orielly guide and start learning from scratch. Also, most beginner's guides are full of directions and facts, but have no real-world examples. Usually, you get a 3 line example and that's it! Something like this should help beginner's to understand by showing what's wrong in a real programming example.
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.
The best antipattern to java: .net is better - it allow people to use whatever language they want on the same CLI...
DO NOT USE JAVA!
It's ugly and slow.
Even C# with
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.
I still find I really prefer the taste of FORTRAN :-) OK, I admit it, I've dated myself by saying that, but who cares? :-)
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.
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.
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.
The word on the street is that Java is dog slow unless you optimize, it is slow because of class loading, and the way you optimize is that you use object creation sparingly in your inner loops, even if it makes your code look ugly.
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."
>>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.
Yeah and it's in libcomplex.a. Real life experience calculating some quantum mechanical wave functions that are heavy on the complex --- re-code critical sections in c avoiding c++ complex and you can buy yourself 1.5 orders of magnitude in execution speed. Moral of story: temporary objects bad.
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>
Te overuse of OOP stems from the shift in the american education system from the late 1980's on. In the good 'ol days, programmers for the application world could learn how to do things as a tradesman, but now everyone has to go to college. The result is that people graduate with CS degrees that have no idea how to do things that are not for academic exercices, and some people just don't know how to do anything. So they make giant OO classes that have worthless getter and setter methods for fields that do not need to be accessed, and other worthless crap that they teach you nowadays.
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.
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.
While you poke fun, I adapt.
Finally, someone looks at OOP in a real world light. So often in books/classroom they push these ideas into your head so much that you forget about the real world constraints of using them. This book appears to bring those to life. This looks like a must read for any CS student looking to get another viewpoint on OOP.
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.
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.
Speed
Size
Cost
You may choose only two.
Danny (who plays gamelan and is interested in Indonesia).
I have written over 900 book reviews
Tate's approach is looks a bit different
Nice to know someone bothers to proof-read this stuff before posting it on slashdot.
I am very skilled at HTML programming, one of the most challenging languages out there!
HTML is not a programming language. Ever try to implement a double-linked list in HTML?
nuff said!
While it's true that there are an infinity of bad ways of doing things, Anti-patterns is about the most common way of doing things badly (Patterns are about the optimal way of doing things). In particular, it focuses on things people do wrong (commonly) that seem like good ideas -- typically an solution to the design problem is also offered.
If anything, Anitpatterns are more useful than patterns.
I am not a number! I am a man! And don't you
How did this troll get modded up? Why don't you mod up the Recipe Troll while you're at it (browse at -1 for details).
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
Functional programming is completely non intuitive, is bad at being able to represent
real worl problems in that the code bloats to as horrendous sphagetti mess (yeah , I'm sure
those collage lab examples were great , but it isn't that neat in the real world) and most
functional languages run at the speed of recently kneecapped tortoise. Declarative languages such
as Prolog were touted decades ago as the saviour
of us all, how many places do you find them now?
The only survivor is SQL and that gets bit tacked on it to make it procedural and hence usable
outside its natural enviroment of a database.
Functional languages are another seemed-like-a-good-idea-at-the-time dead end IMO.
"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
No personal offense intended, but I'm always a little worried by people that think that they don't have anything more to learn.
You're probably right in that, if you're a professional programmer, you should probably know most of the stuff in this book.
But also, I'd be very surprised if there weren't several new ideas as well. Just because you're making money programming doesn't mean that you know everything. People tend to get into habits and don't look around for better ways.
If you consider a language like OCaml, I think you are presented with the best of both worlds. It is a language that is functional "in spirit" in that you can have such things as anonymous functions, partial function application, etc., yet it also keeps the ability to utilize state when necessary. I believe "when necessary" is the key phrase -- it is certainly a GOOD idea to minimize state in your programs. Try writing a language interpreter in a non-functional language. Good luck.
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.
I fully agree with you. 80% of my classmates couldn't write decent code if their life depended on it.
There are some sample chapters available on the book's website
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.
I really like ADA, not ADA95 with objects either. Good old ADA83 , MMMMMMMM, yummy.
Oh, we're all so sorry to offend you're delicate semantic sensibilities.
Would you be happier with "common design mistakes to avoid and why they are flawed"?
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
You probably had a DRI driver in the old kernel config that you did not select in 2.4.15. Also the Nvidia drivers from www.nvidia.com must be installed on a per kernel basis.
I would argue the single most overused aspect of OOP is inheritence. I think it is well used if intelligently used in API sets such as Java, but the code that results from 5-deep levels of inheritance can be practically unreadable. Functions can be defined in any of five different levels, plus !OOPS! it happened to be overrided at level #3, changing its behavior. It seems that designing an heirarchical inheritance structure that accomodates all future uses of the objects is next to impossible on the first run, and probably on the second (look how much java has played with its structures). In java, I'm a one-trick pony with interfaces. I define interfaces for behavior, and leave inheritance to the dogs and java API developers. Helps out a lot with simple extensibility of systems. Class.forName() - manna from heaven! But maybe that's just me.
Hey, I'm just your average shit and piss factory.
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.
Believe me, reading extra books like this will only slow you down as a beginner. There is a reason that the programs you learn with are three line buggers -- so that you don't get confused.
Example: I was teaching my wife a little about C++, and she asks what the int main (int argc char **argv) is. Instead of telling her that it is all used to interact with the command line, I try to explain that **argv is a two dimensional array of characters. BAD IDEA! Why should she have to know that to program "Hello World!"? All she needs to know at that point is how to best use those data structures to get at the command line arguments.
In the same way, all beginning OOP programmers need to know is how objects work, and what inheritance, encapsulation, etc. is. Books like this might ruin you before you start!
So I take it that in this passage you are just trying to make it absolutely clear that programming is a man's job. ;)
-- Point? None! Cob.
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.
Anyone wanting to taste more. Bruce Tate put this article up on IBM developerWorks:
A taste of "Bitter Java"
Which brings us to the question: what is the origin of 'java' in the meaning 'coffee'? Maybe Java's reputation as a coffee producer has something to do with this...
Oh, BTW, if I wanted to talk about a great multiplatform object-oriented language, it would be Python. Apart from the lack of hype and big-business support, it's no worse than Java.
--
If you moderate this, then your children will be next.
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
This is why there is a glut of programmers on the market. Everybody and their brother thinks they are going to become programmers because "They Know Computers".
Exaclty what do your HTML programs do.
Exactly what do you know "about computers".
You are an HTML editor, not a programmer. It is a markup language that simply dictates visual layout. You might be a javascript, vbscript, or whatever script programmer,a nd embed that in your HTML, but you aren't an HTML programmer.
So the porblem is you have all these morons that think they are HTML programmers, that are great salesmen, and charismatic individuals, that sell themselves to a IS department, and keep their jobs, while real programmers, that tend to be less charismatic, sit in the unemployment lines (Not that programmers are inherently un-charismatic, just that the ones that are run the risk of losing their jobs to charismatic morons).
It's just that English is deficient. There's no genderless pronoun that suits. And don't even try to pass that "one" crap off. Nothing makes a sentence stop dead in its tracks faster than that.
Other languages don't have this problem. Spanish, for instance, has su. As a bonus, it also doesn't have the "free" ambiguity.
What a beautiful expression of the Lisp way, and the critical role of macros.
Those interested in patterns and Lisp should read Peter Norvig's essay on patterns in dynamic languages, notably Lisp. Norvig was a senior scientist at Sun, is now head of reseach at Google, and knows what he's talking about. Non-Lispers will find his thoughts a revelation, I suspect.
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.
"That kind of flexibility, which allows the programmer to mold the language to fit the needs of the task, is really what makes Lisp great to work with."
It's not quite the same, but it's worth making an effort to write in a gender-neutral fashion. IMO, "one" is just fine, but some people are not used to using it and hearing it, so it sounds awkward.
If you don't agree that gender-neutral language is a worthwhile pursuit, maybe you will after reading Douglas Hofstadter's hilarious essay on the topic.
Become a FSF associate member before the low #s are used
Homer: Say, where's this car made anyway?
Salesman: The country no longer exists.
It doesn't mean much now, it's built for the future.
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.
Bad habits can be carried along in one's career. You are never too old or experienced to learn and hone your basics. Don't assume that because you are aware of something that everyone else is. The biggest mistake is to become arrogant and assume that you are too experienced to have any flaws.
I think you are missing the point of what a "pattern" is. It's nothing more than good practice to solve a particular problem. If, given a particular problem, there are two or more ways of solving it, then there's a good chance that one or other is better in a given situation. Patterns are just ways of describing what forces may lead you to use one or the other.
The phrase That kind of flexibility suggests that there is often more than one way of doing things in Lisp. How do you decide which one to pick? When is it a good idea to use macros etc?
Just because most of the patterns in the book "Design Patterns" may not apply to your language, don't think that the principle doesn't.
I've not used Lisp, but I've applied patterns in everything from x-86 assembler to unix shell scripts to SQL. The patterns vary per language (knowing when it is best to use an inner join in SQL is not much use in x-86), but each language quite clearly has its own "design patterns".
I would not want to work with any developer who seriously believes that patterns don't apply to his/her language of choice.
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
"his" is gender-neutral in this context.
Much like in spanish, where a plural containing at least one male uses the masculine form.
Let me start by saying that I like lisp, so I'm not intentionally out to lisp-bash... but...
Having worked with C for many years, and having worked with perl for a few now, I have to say that I really miss typed-variables. Nothing catches a mistake faster than a type mismatch, and almost nothing is harder to track down than a bug where the compiler/interpreter happily turned a string into a number for you.
Consider: print "ha" if 2 > "ha";
Yeah, the compiler knows how to convert "ha" into the numnber 0, but should it? Not always, and I claim not without my explicit type-casting. If I put an (int) type there, then I think I know what I'm doing, otherwise I'd rather it error.
My only other complaint with modern programming techniques, is this simple observation:
I can build a lighthouse out of legos in 15 minutes.. it will look kinda lego-ish, but it would function as a lighthouse (provided I have a light to mount in it).
To do the same thing in clay would take several hours (probably days for me!), and yes.. it would look much better, but when you're a little ways away, and it's dark... they'll look the same.
I like lisp for the simplicity of its syntax, and in any language, I'd like to have untyped variables AVAILABLE for use... but sometimes I know I always want a 16-bit integer, and if something else gets in there, it's a bug -- then I want the language to catch it as early as possible so I don't have to sit and stare at it in the debugger trying to figure out why -11726 is the current number of records!
(as a C++ programmer)
(lies "people's fear of Lisp" in the convoluted-seeming structures
("were taught" they in computer science classes)
)
)
C__Programmer::IsSeeminglyBizarre(LispCodingStyle) ;
--- Jason Olshefsky
Karma: Poser (mostly affected by adding this line long after everyone else did)
Chris Beckenbach
Somebody has to say it. I'm a LISP junkie, indoctrinated at MIT in the late 1970's. I write LISP and Scheme systems for fun. Even when I write C code, about half the time I start off by implementing a mini-LISP. Its great for memory management and debugging.
However, I'm also an object junkie. CLOS is a joke. It's about as object-oriented as Ada, which isn't much. Not only is Paul Graham right that you can do it, this is what you should do if you want a real O-O system rather than something that basically just uses the word "object" in the documentation.
I have run accross a disturbing trend in young coders. The only way I can explain it is that they are being taught strange ideas in university.
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?
It was much funnier the first time I read it.
Reading this thread (but not the book), this is one of the first times
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
This review sounds exactly like database normalization- one does not end up with twenty tables each with two columns and expect wonderful performance- sometimes that repeated data that might (in a fully normalized database) speed performance by a significant amount. Joins in the database world cost cycles- I think the same thing holds in the OO world- don't normalize to the nth degree.
I 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.
Even better are "strict" type-inferencing languages. (O'Caml for example)
The type is determined by its use and enforced. I wish C/C++ had similar facilities.
I have to say that I really miss typed-variables. Nothing catches a mistake faster than a type mismatch
...). Lispers treat declarations as "hints to the compiler to make things fast" rather than strict contracts. If you want to enter into such contracts, you can...
I don't miss typed variables at all. You can OPTIONALLY declare the types of variables using (declare
Or you can eschew functions and use methods exclusively. CLOS methods are really "multimethods" -- they dispatch on the types of as many of their arguments as you care to supply types for. Using methods instantly reveals when you've supplied an argument of the wrong type (since no applicable method will exist).
Thank you for pointing that out. Why do people take the time to overanalyze english grammar without taking a similar amount of time to learn how the language works? The sentence would've meant the same thing if the author had used "her" instead - the only rule when writing in a gender-neutral situation is to maintain the same pronoun when referring to the same subject. Given the smiley, I don't think that normiep was serious - but you just know that someone else was.
:)
Sigh. Stupid political correctness crap.
No kidding, come on people, this is 2002. His/her who gives a rats ass, that is not what this topic is about.
We are not debating whether or not men can program LISP better than women. That's a different subject completely.
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.
If you recall Superman comics the Bizarro Superman was the anti-character to Superman. Bizzaro Superman was from Bizzaro World.
So if you ask me I would say the the correct term should be "Bizzaro Patterns".
Anyhow, Java is overated. Anything that refers to "Enterprise" this or that is an obvious marketing hack, similar to all those Microsoft ads that have about 50 exclamation points in them ("Enhance Your Carreer! Web Services are for what's happening now!).
It will someday be revealed that Java was just a wildly successful plot to sell Books.
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.
That's an interesting example...Now that C has changed into C++, I find I can no longer understand the code analogies that people write. I always feel the need to check the .h files to see how things are defined.
More lisp-like, I think, would be
(let ((*student* (new-cs-major))
(*Lisp-curriculum* 'outdated))
(causes-irrational-fear? 'Lisp))
--> T
If you're interested in antipatterns, check out (of course) http://www.antipatterns.com/.
I just got a catalog the other day that has cobol AND fortran for .net CLI, created by third-party developers, not to mention a bunch of other modeling snap-ins.
You have to destroy objects to change their state, for example when an employee changes to a manager, etc.
What a perfect setup, thank you. I couldn't have asked for a better example of poor OO design.
The correct way to model this is to realize that there is no such class as Employee or Manager. The correct class is Person. Employee is the role that a Person plays in a relationship with the Company class. You don't need to destroy the Person instance when someone gets promoted.
This shows that the true problem is not with OO, but with poorly applied OO concepts. As with any tool, it is possible to use OO incorrectly.
It happens that I've written an entire article on this topic here: The Myth of the Employee Class.
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
actually, in spanish the male gender is ALSO the neutral. You would say 'la musica' for a female musician, 'el musico' for a male musician, and 'los musicos' for a set of musicians which may be male or female (you'd reserve 'las musicas' for a set of female musicians)
It's there. Saw it. 30 years ago. Volcano or something.
.
In short, you do not understand how to use templates effectively.
"Power" in a computer langauge is doing a lot with a little. ASM is versatile, it is not by any stretch of "powerful". By Bill, I know I'm right, having spent 10 years of my life doing assembly (and thinking it was good).
.
Everyone involved in the C++ vs. X debates should read this book. It shows quite clearly everything that is good and evil about C++. The fact that there aren't ANY compilers which can actually run all the examples in that book is pretty telling in itself.
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
Whether or not they have anything to do with "patterns" is not relevant; you are complaining about the word "antipattern", not their usefulness. Highlighting common design problems is useful in any framework, no matter what you call it.
You're not a grizzled veteran, you're an egomaniacal asshole. There's a difference.
how much more obvious need it be made?????
How about:
That kind of flexibility, which allows programmers to mold the language to fit their needs (and their tasks' needs), is really what makes Lisp great to work with.
Oh look, English can handle it.
Well said...the more I use Java, the more I miss C++ and templates. Casting Objects starts reminding me of casting void* back in the day when I was doing C. Doing StringBuffer.append ten times in a row because it's faster than concatenating String objects seems clunky. What's up with String.equals() anyway? Why can't I just use the stupid "=" operator? Ugh. It just feels like a big hack.
I think C++ is like a sharp knife - it's a great tool when you know how to use it, but you have to be careful. A lot of people use it, cut themselves, and go back to Java. Plus, the language has been around long enough to get a set of toolkits and libraries that's arguably richer than Java's.
did they forget to hand you your sense of humor?
As I said, the << is atomically safe. If you insist on using multiple << operators and want your text to remain contiguous, you'll need to do this:
{
stream_locker guard(cout, stream_locker::lock_defer);
if (cout.test_safe_flag())
{
guard.lock();
}
std::cout << "foo" << "bar" << std::endl;
}
We should all applaud a small publisher like Manning for doing this.
Most of Lispers are coding with commercial implementations, while there are very few of great Lisp applications based on free/OSS implementations. Emacs is the best of them, but it is dying. TeXmacs is upcoming, but will it succeed So, there are lots of Lisp dialects, but it is even worse - most of (good) imlementations are commercial.
Today we are living in the time of XML. But most of popular XML applications are written on Java, Python and even Perl - but not on Lisp. Why? Theoretically Lisp is the best candidate for XML processing/transformation, why not to use it? I'll tell you why - because there is no such thing as Lisp - instead, there are too many of Lisp dialects. Thus, for most of programmers it is uncertain, which Lisp to use. And that's why programmers prefer to use Java, C, Python or Perl.
Now see what you are saying about Lisp patterns. It is less important which pattern to use when you don't know which dialect to use. Give Lisp to masses and you will be surprised how many patterns people will use with Lisp. Academical thinking dislike patterns, practical thinking cannot live without patterns.
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
Sounds like stuff I've been saying for *years*.
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"
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
Sheesh - I didn't say the idea couldn't possibly be expressed. Do you really dispute that it would be better to have genderless pronoun? A carpenter is only as good as his tools, after all... oh wait, I mean a carpenter is only as good as the tools owned by said carpenter. There - that's much better.
I went through a similar object oriented problem. I created a credit card validation and approval system that in theory would only require a customized backend to integrate with any mechant account.
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.
(* 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.
I do use it a lot. Enough to tell you that "FileInputStream myfile" needs to be declared outside of the try block. As written above, myfile's scope is limited to the try block, so it is not valid within the finally block.
(* 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.
If you've ever used functions in Excel you're three quarters of the way to being a Lisp guru. The other bit mostly involves getting used to a slower runtime than Excel.
If you think saying "he" is sexist, it's you who are deficient.
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 !
Using OO for everything might well be overkill. Have a look at
Teaching Programming as an engeneering discipline. Here is a statement showing some of their goals:
The current trend in computer science education is to restrict the student to one or two models. The most extreme case is where a single rather complex model and language, namely object-oriented programming in Java, is used as a general-purpose approach with which all problems should be solved. This trend is driven by market forces and has no scientific basis. One goal of the book is to be a counterweight to this trend. In addition to giving the student a deep insight, this has immediate practical benefits. Many problems that are hard to solve in Java become simple when viewed in the proper computation model. For example, both concurrent programming and user interface design are difficult in Java. The book shows how these two areas can be much simplified.
Good, read, even if you don't accept it's standpoint.
I suppose it would depend on ones definition of 'better', though.
I want my Cowboyneal
Keep it simple AND stupid?
Hey, design patterns are just generally applicable ways of designing things (like software) that usually (through prior experiences) produce good designs that are robust, flexible, or whatever is wanted.
Everything that has to do with designing and is (relatively) commonly used and works is a design pattern.
Procedures are a pattern, just like OO. But when your implementation environment directly supports that pattern, then it becomes just a mundane tool.
Many GoF patterns are for C++ and Smalltalk, because those were the languages that the GoF had experience in. The patterns were meant to produce better designs for those languages. Because the implementation isn't supported by the language, a specific pattern must be enforced on the programmer.
Lisp doesn't need most of the GoF patterns due to its superior features, but that doesn't mean the patterns aren't there - they're just easier to implement. But if you don't use them, then your design won't be any better just due to your selection of language. And using a language or an environment that provides these basic patterns for you allows you to concentrate on even higher level patterns.
Or have you seen anyone implementing class inheritance using assembly? I haven't. It's a bit easier when the language handles stuff like named variables, scopes, functions and type checking, just to name a few very commonly used design and implementation patterns that help implementing an OO system.
--
Tarmo
Yep, this example is an example of an implementation pattern - a good way of doing a specific task, in this case, reading a file and making sure it's closed.
This has nothing to do with design patterns, although the point is valid - some languages will make implementing a specific implementation or design pattern easier than others.
Btw, as to your Java example, Java has the GarbageCollector design pattern built-in. This means that you can just open the file and do what you want, then forget about it, since the file is closed automatically when the file object becomes unreferenced = when the myFile variable drops out of scope = you exit the current function.
In this case a design pattern helped make a specific implementation pattern ridiculously easy to implement.
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.
I like antipatterns because they capture the simplicity of patterns in a new context: literary descriptions of common traps that do damage.
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.
Lisp doesn't need design patterns because most of the classic design pattersn are trivial to do in Lisp. In other words, Lisp programmers use design patterns without having to read the design pattern literature, because the ideas are already built into the language features.
When programming in weaker languages like Java or C++, you need to make more of a conscious efforts to use high-level design. My view of the design pattern movement (whose founders seem to have a background in Smalltalk) is that they are trying to find ways to use high-level features in languages which support them only weakly. This is a good thing, but it is mostly irrelevant for Lisp programmers.
(* 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.
(* 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.
"Carpenters are only as good as their tools". You said "English is deficient. There is no genderless pronoun which suits."
English is NOT deficient. "Them" is a genderless pronoun. It can be used to express these ideas in a genderless way. Your mistake is trying to narrow it down to the individual and then finding that there is no suitable genderless singular pronoun. However, you are talking about a group of people or an indvidual drawn from a larger group, where the individual could be male or female. For example, a carpenter can be male or female. The group of all carpenters is neither male nor female, so can be referred to as "them". If you make your statements in the plural, you don't need to worry if the individual is male or female. The gender-inclusiveness of "them" takes care of it for you.
English is not deficient. There is a genderless pronoun which suits. QED. Sheesh.
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
Technically, la musico is correct. Same for any previously male-dominated profession, such as la presidente. The noun stays the same, but with la instead of el.
However, this is a bit "snooty" among the common folk, and so in casual speech la musica tends to be used.
I have written a complete PDF viewer in Java 1.4 with a very customized Swing user interface. The development was all done under Windows 2000.
I just installed it under Red Hat 7.3 the other day, and every feature worked the same as it did on Windows. All the graphics were drawn the properly, font rendering was correct. File IO, parsing, search logic, internet connections, custom Swing components, etc. all worked.
I know that's how it's supposed to work, but I was still blown away that it all ran the very first time.
"Scientists prove we were never here."
-- Devo