Yeah this thread is going to fill the server's disc in no time at all.

Thank god, I thought I was alone in this world thinking that design patterns were overrated. Some of them are useful -if- you ADAPT and APPLY them, not literally use them. That way at least you still thought about it. Things go wrong when you stop thinking about it.

I consider design patterns to be very evil. They teach people to think in terms of solutions instead of the problem. So it's like being given a bunch of round pegs of different sizes and a hammer. Find one that seems to fit then beat on it with the hammer until it works.

They teach people to think in terms of solutions instead of the problem.

No, it's about framing the problem in common terms, often to the detriment of targeting a larger solution. It's when the solution gets lost because of all the design frippery around individual problems that patterns become "evil". I don't know about you, but I've never used a Singleton program or played a Flyweight game.

Sorry, but all these "X Is Evil" rants are tired, trite and intellectually lazy.

I honestly do avoid trying to work all day long. The less I have to think the better. In some ways "design patterns" mean I don't have to think much, because I simply see a problem that fits a general solution and apply the general solution to it and there we are, done. I can work like that all day long without thinking about what I'm doing. As soon as I come across a genuinely new problem I'm up shit creek and spend days or weeks agonising over how to solve it.

Really, that's what design patterns are for. They're like a Library for generalized problems. And they give us a point of reference which we can use to discuss certain things. Of course using one when you don't understand it is a problem.

However, you can take several of the design patterns and use them to describe a method by which a problem could be solved and a person can, with minimal research, go out and decipher what you meant.

Patterns seem to be an attempt to help distill years of experience and brain-pattern-recognition into something easy to explain to someone else. Eg. a newbie at college. And there's the problem - if you aren't intrinsically living, breathing, eating code day in day out all your life the subtlety and nuances of the problems you are trying to solve mean inexperienced people are only seeing half the picture and probably battering square design pattern problems into those round problem holes. I see it a lot in here when people are asking about, er, for example entity systems. Total failure of most people asking about them to understand what they are for and when or why to use them. And other questions concerning threads, and arrays of arrays and so on.

Exactly. Except experienced people fall into the same trap. Ah! That's the visitor pattern...then run off spending days writing code that should have taken minutes to write. Not thinking about design and the problem is (I'm sorry) evil.

The component based pattern is (for most people) stupid. Attempting to fake prototype based in class based in a PITA, ugly and a ton of work even if you're using a library.

Forget design patterns. Data-structures and algorithms. If you need a specific "code snippet" that does X...do a web search if you don't know how. Maybe that code snippet is a so-called design pattern or maybe it isn't.

Quote

Sorry, but all these "X Is Evil" rants are tired, trite and intellectually lazy.

As a developer I constantly try to be more efficient. Thus, I learn from other people, hopefully even, after so many years.To me, software development in general is still archaic and highly inefficient. Everything takes much too much time. Think of all the ideas you can't realize because the freaking coding takes forever and even longer.So, patterns are just another source of knowledge you can benefit from, nothing more and nothing less.

goto, unstructured (n): A high level programming language flow control feature that's primary purpose is to allow fanboys from different programming camps to have an argument where all points are citing papers which neither have read.

goto, unstructured (n): A high level programming language flow control feature that's primary purpose is to allow fanboys from different programming camps to have an argument where all points are citing papers which neither have read.

I'd guess that 85% of my CS related rants are actually the same one, over and over (ad nauseam) and can be described as reactionary to people taking the following notions:

Doing "A" in situation "B" is a good idea.Doing "A" in situation "B" is a bad idea.

and extrapolation "B" to always.

design patterns, unstructured gotos and test units (among many many others) all fall into the above.

Quote

brain-pattern-recognition

I should have mentioned that the brain both very good and very bad at pattern recognition. We see patterns that don't exist and we mistake patterns that are only superficially similar.

I don't care if a language supports unstructured gotos or not as they are only (in my experience) useful in very narrow cases (notably state machine like processing). The "real" problem here is that people have been convinced that structured gotos (such as labelled break, etc) are bad. That's pure madness. (EDIT: Of course ALL flow control structures are structured gotos)

I'd guess that 85% of my CS related rants are actually the same one, over and over (ad nauseam) and can be described as reactionary to people taking the following notions:

Doing "A" in situation "B" is a good idea.Doing "A" in situation "B" is a bad idea.

and extrapolation "B" to always.

I guess ranting on something is not very popular amongs community of humans

Nothing's black or white if the initial statement of your rant falls in one or the other then there's always someone to tell you that you may have underestimated some situations. It's especialy true when it hurts someone's personnal preferences by telling something is negative.

Adam Martin (T-machine, blahblahblahh of these parts) once told me how they structure authority at his consultancy: he who codes it is right. That is, you can argue till you're blue in the face but whoever got it working has moved on and is making money doing something else.

NOTE: My rants (unless I'm poking a bear) can all be backed up by technical merit and many years of experience. If I'm making a subjective statement I'll almost always point it out. And they are always intended to be helpful and to make people think rather than parrot.

Luckily in computer science a fair amount of things actually are black & white. What's tricky is that today's black & white might have flipped vs. X number of years ago. As an example: gotos. The original problem was that all mainstream languages were unstructured and unstructured gotos was the only flow-control mechanism. That situation has been effectively dead for about 40 years and is moot. This is basically the rant of "Gotos considered harmful". Dead issue, move on. The remaining problem was that "unstructured gotos" caused havok to compilers. They complicated the notion of a basic block and prevented a fair number of optimizations. This issue is also dead with the introduction SSA (and other modern representations, in SSA a PHI node kills the problem.) So also dead for 20-30 years. But all of this is about unstructured gotos. There has never ever been an issue with structured gotos. And yet there are a large number of people that avoid them because someone (without a clue) told them they were bad. Actually the opposite is true. Avoiding a structured goto will almost always require the introduction of otherwise pointless variables which increase the pressure on the register allocator. It certainly increases the size and complexity of the code. Now if in a given situation the programmer in question decides that a version without unstructured gotos look cleaner than with...fine, there's nothing wrong with making stylistic choices. The thing to keep in mind is that if you think that structured gotos are "bad", then you can't use any flow control mechanism. They are all structured gotos (for, while, if blocks, etc.).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org