Generalized Rant Thread

Miscellaneous Topics
#1

From Roquen’s Dictionary of Computer Science:

design pattern (n): A set of boiler-plate code templates which fall into one or more of the following categories:

  • Massive ugly (and usually overcomplicated) hack to work around a missing feature in the target language.
  • Massive ugly hack that unifies two or more simple constructs into a single framework.
  • Massive ugly hack that no one with an ounce of experience would ever consider using.
  • Rebranding of previous standard industry practices. (SEE: paper buffing, book buffing)
  • Rebranding of techniques so obvious that they previously didn’t even have a name. (SEE: paper buffing, book buffing)

Design patterns can be identified by their characteristic naming scheme (or pattern if you will) of tagging the word “pattern” after a word or phrase.

Synonyms: anti-pattern.
Antonyms: data-structures.

#2

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.

#3

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.

#4

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.

#5

I’m tired, trite, and intellectually lazy though.

Cas :slight_smile:

#6

Lazyness is good when the time comes to code, it forces you to reuse and think to avoid working to much ;D

#7

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.

Cas :slight_smile:

#8

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.

#9

Step 1 - make the code work
Step 2 - ship it
Step 3 - add features
Step 4 - inevitably fix your shitty code so you can actually add new features

Repeat steps 1-4 for several years, and eventually you’ll have a reasonably nice code base.

#10

Step 1: make game without worrying about patterns
Step 2: ????
Step 3: PROFIT!!

#11

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.

Cas :slight_smile:

#12

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.

OK. Patterns are from hell. Ergo are implicitly evil. QED

#13

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.

#14

From Roquen’s Dictionary of Computer Science:

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.

#15

Awesome, now I´m fully prepared for my first Goto argument! =D

#16

Honestly, I don’t think that I can agree with that statement…

I know that I can. Ugh, I’ve got no problem with the idea either way, but I’ve gotten to listen to both sides of the camp. xD

#17

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.

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)

#18

Imagine writing assembly language without having a JMP instruction :slight_smile:

Cas :slight_smile:

#19

CS Rain Man: Not Turing complete, definitely not Turing complete.

#20

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

Nothing’s black or white :slight_smile: 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.