Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 6
  ignore  |  Print  
  Generalized Rant Thread  (Read 24442 times)
0 Members and 1 Guest are viewing this topic.
Offline Roquen
« Posted 2012-04-20 12:34:57 »

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.
Offline gimbal

JGO Knight


Medals: 25



« Reply #1 - Posted 2012-04-20 12:54:32 »

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.
Offline Roquen
« Reply #2 - Posted 2012-04-20 13:31:44 »

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. 
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sproingie

JGO Kernel


Medals: 202



« Reply #3 - Posted 2012-04-20 16:45:59 »

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.

Online princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2012-04-20 18:24:28 »

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

Cas Smiley

Offline GotoCofee

Senior Newbie


Medals: 2



« Reply #5 - Posted 2012-04-20 18:49:17 »

Lazyness is good when the time comes to code, it forces you to reuse and think to avoid working to much Grin
Online princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2012-04-20 19:11:02 »

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 Smiley

Offline UprightPath
« Reply #7 - Posted 2012-04-20 19:42:00 »

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.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #8 - Posted 2012-04-20 20:38:08 »

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.

See my work:
OTC Software
Offline ra4king

JGO Kernel


Medals: 350
Projects: 3
Exp: 5 years


I'm the King!


« Reply #9 - Posted 2012-04-20 20:44:33 »

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

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2012-04-20 21:23:06 »

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 Smiley

Offline Roquen
« Reply #11 - Posted 2012-04-21 06:07:57 »

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.
OK.  Patterns are from hell.  Ergo are implicitly evil.  QED
Offline 65K
« Reply #12 - Posted 2012-04-21 07:04:09 »

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.

Offline Roquen
« Reply #13 - Posted 2012-04-21 17:37:36 »

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.
Offline theagentd
« Reply #14 - Posted 2012-04-22 05:32:22 »

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.

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

Myomyomyo.
Offline UprightPath
« Reply #15 - Posted 2012-04-22 05:37:06 »

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

Offline Roquen
« Reply #16 - Posted 2012-04-23 05:42:21 »

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)
Online princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2012-04-23 09:05:48 »

Imagine writing assembly language without having a JMP instruction Smiley

Cas Smiley

Offline Roquen
« Reply #18 - Posted 2012-04-23 09:09:52 »

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

Senior Newbie


Medals: 2



« Reply #19 - Posted 2012-04-23 20:48:32 »

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 Smiley

Nothing's black or white Smiley 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.


Online princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2012-04-23 22:10:36 »

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.

Cas Smiley

Offline Roquen
« Reply #21 - Posted 2012-04-24 04:19:13 »

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.

Nothing's black or white Smiley

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.).

there's always someone to tell you that you may have underestimated some situations.
In which case I'd ask them to point out these "situations"...ya know, so I could show them "the errors of their ways". Smiley

The only generalization that doesn't fall apart is:  All generalizations are false.   (Think about that one for a minute). 

Offline ra4king

JGO Kernel


Medals: 350
Projects: 3
Exp: 5 years


I'm the King!


« Reply #22 - Posted 2012-04-24 05:20:13 »

The only generalization that doesn't fall apart is:  All generalizations are false.   (Think about that one for a minute). 
Oh the paradox....... my mind = blown

Offline UprightPath
« Reply #23 - Posted 2012-04-24 05:27:35 »

All generalizations (models/abstractions) are incorrect: But some are useful.

Offline Roquen
« Reply #24 - Posted 2012-04-24 05:53:33 »

Ah, but over-generalization is never useful but it's sometimes subjective.
Offline StumpyStrust
« Reply #25 - Posted 2012-04-24 06:14:23 »

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.


Ok I must find this "Roquen's Dictionary of Computer Science"  Grin It seems to have a plethora of useful information.

Please master...teach me.  Shocked

Offline GotoCofee

Senior Newbie


Medals: 2



« Reply #26 - Posted 2012-04-24 19:22:31 »

This thought model in your brain is induced by your relation with computers... The bitwise thinking : something is true or false!

You could "double" your thinking by having "floating" boundaries!

(I'm not kidding)  Grin
Offline Roquen
« Reply #27 - Posted 2012-04-24 19:26:57 »

True, but then you're only retaining the most significant information.  Which may or may not be the desired goal.
Offline ra4king

JGO Kernel


Medals: 350
Projects: 3
Exp: 5 years


I'm the King!


« Reply #28 - Posted 2012-04-24 19:51:28 »

True, but then you're only retaining the most significant information.  Which may or may not be the desired goal.
Oops accidental medal for you Tongue

Offline GotoCofee

Senior Newbie


Medals: 2



« Reply #29 - Posted 2012-04-24 21:22:08 »

Oops accidental medal for you Tongue

Not accidental, that was actualy a prety good reply.  Smiley
Pages: [1] 2 3 ... 6
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (49 views)
2014-10-17 03:59:02

Norakomi (38 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (34 views)
2014-10-15 16:18:58

TehJavaDev (65 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (54 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!