Patterns...
-
R. Giskard Reventlov wrote:
"Drunken ugly-donkey style".
Is that the style that uses the 'five-point-palm exploding heart technique'?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
I pefer the one point foot exploding rear technique. Usually it`s not lethal, triggers high brain activity and helps over the steepest learning curves.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
I find it hard to take design patterns seriously when they have names like "The Revealing Module Pattern". Makes me think of those badly made seventies kung-fu films where someone boasts that he can do the "Drunken ugly-donkey style". Ignore me. It's Friday and my mind is wandering...
This is making sense :) ....so keep wandering :thumbsup:
-
I find it hard to take design patterns seriously when they have names like "The Revealing Module Pattern". Makes me think of those badly made seventies kung-fu films where someone boasts that he can do the "Drunken ugly-donkey style". Ignore me. It's Friday and my mind is wandering...
1. Design patterns are a response to solving the entanglement nightmare that OOD, while not creating, made more complex. 2. While the formalization of the patterns was in some ways useful, the implementation often results in over-complexity and misapplication, especially by inexperienced programmers. 3. Experienced programmers were already implementing decent ways to disentangle non-OO and OO code, so really, I think very little was gained by formalizing patterns. If anything, it made things worse for experienced developers who had to go in and fix the insanity of bad pattern application by less experienced developers. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
1. Design patterns are a response to solving the entanglement nightmare that OOD, while not creating, made more complex. 2. While the formalization of the patterns was in some ways useful, the implementation often results in over-complexity and misapplication, especially by inexperienced programmers. 3. Experienced programmers were already implementing decent ways to disentangle non-OO and OO code, so really, I think very little was gained by formalizing patterns. If anything, it made things worse for experienced developers who had to go in and fix the insanity of bad pattern application by less experienced developers. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
I can relate to 2 & 3, we let a senior guy loose using MVC on one of our internal apps, bloody thing is unsupportable, he used a weird collection of patterns and achieved a brilliant form of obfuscation. I hope nobody wants changes before we get it rewritten!
Never underestimate the power of human stupidity RAH
-
1. Design patterns are a response to solving the entanglement nightmare that OOD, while not creating, made more complex. 2. While the formalization of the patterns was in some ways useful, the implementation often results in over-complexity and misapplication, especially by inexperienced programmers. 3. Experienced programmers were already implementing decent ways to disentangle non-OO and OO code, so really, I think very little was gained by formalizing patterns. If anything, it made things worse for experienced developers who had to go in and fix the insanity of bad pattern application by less experienced developers. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
What an excellent analysis (+5). I am an old dog learning new tricks. When Design patterns were first revealed a decade ago, I didn't embrace the hype surrounding them that others were so eager to display... but I tried to give them a chance and accept them where appropriate. Your comments describe perfectly what I experienced and struggled to encapsulate.
I'm retired. There's a nap for that... - Harvey
-
I find it hard to take design patterns seriously when they have names like "The Revealing Module Pattern". Makes me think of those badly made seventies kung-fu films where someone boasts that he can do the "Drunken ugly-donkey style". Ignore me. It's Friday and my mind is wandering...
R. Giskard Reventlov wrote:
I find it hard to take design patterns seriously
:thumbsup:
-
1. Design patterns are a response to solving the entanglement nightmare that OOD, while not creating, made more complex. 2. While the formalization of the patterns was in some ways useful, the implementation often results in over-complexity and misapplication, especially by inexperienced programmers. 3. Experienced programmers were already implementing decent ways to disentangle non-OO and OO code, so really, I think very little was gained by formalizing patterns. If anything, it made things worse for experienced developers who had to go in and fix the insanity of bad pattern application by less experienced developers. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
First your programmer's oath, then this. I can't fill my sig or bio with all of your posts! :D I can relate to #2 and #3, we now have a lot of perfectly obfuscated code full of guru tricks that simply does not what it was supposed to do. Secretly my developing team isn't using that code - since 15 years and nobody noticed.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey "just eat it, eat it"."They're out to mold, better eat while you can" -- HobbyProggy
-
I find it hard to take design patterns seriously when they have names like "The Revealing Module Pattern". Makes me think of those badly made seventies kung-fu films where someone boasts that he can do the "Drunken ugly-donkey style". Ignore me. It's Friday and my mind is wandering...
Wow, after all these years, the "pattern" was the BAD names! (Light goes on) That's what you get for taking coding advice from a Gang! Which also explains why the term "Singleton" has an almost blatant "idiot" sound. They like gangs. They hate individuals they are required to rely on.
-
I find it hard to take design patterns seriously when they have names like "The Revealing Module Pattern". Makes me think of those badly made seventies kung-fu films where someone boasts that he can do the "Drunken ugly-donkey style". Ignore me. It's Friday and my mind is wandering...
It does seem as if many developers use patterns as an excuse to create a monument to their own ego, rather than actually solving the problem at hand. It's a tough thing though, finding that balance of enough flexibility to make things extensible, without making it so complex that maintenance becomes an overwhelmingly costly proposal.
-
What an excellent analysis (+5). I am an old dog learning new tricks. When Design patterns were first revealed a decade ago, I didn't embrace the hype surrounding them that others were so eager to display... but I tried to give them a chance and accept them where appropriate. Your comments describe perfectly what I experienced and struggled to encapsulate.
I'm retired. There's a nap for that... - Harvey
It always seemed to me that Patterns were a sort of matryoshka doll attempt to fix that OO design mixes data and code, and not in the functional, 'the code is the data,' sort of way. And I'm not too big on premature encapsulation, either. As much as I am fascinated by Conway's Life, I wouldn't use gliders as a data transmission mechanism.
-
I find it hard to take design patterns seriously when they have names like "The Revealing Module Pattern". Makes me think of those badly made seventies kung-fu films where someone boasts that he can do the "Drunken ugly-donkey style". Ignore me. It's Friday and my mind is wandering...
Patterns are, like many other IT fads, an attempt to 'make it easy/more predictable/more maintainable' for noobie developers. Or stoopid developers. Surprising lot of these apparently. It is somewhat analogous to a "paint-by-numbers" system. And all the hide-bound, bureaucratic jobsworths out there in corporate developer-land loved it! My claim: show me a developer who swears by patterns, and would not let go of them if asked by Jesus, then I will show you: (a) a developer of below (developer) average intelligence (b) a person who fears original thought (c) a "real" case of "imposter syndrome". Ie, in their case they really are posing as skilled developers, and they are not.
-
Patterns are, like many other IT fads, an attempt to 'make it easy/more predictable/more maintainable' for noobie developers. Or stoopid developers. Surprising lot of these apparently. It is somewhat analogous to a "paint-by-numbers" system. And all the hide-bound, bureaucratic jobsworths out there in corporate developer-land loved it! My claim: show me a developer who swears by patterns, and would not let go of them if asked by Jesus, then I will show you: (a) a developer of below (developer) average intelligence (b) a person who fears original thought (c) a "real" case of "imposter syndrome". Ie, in their case they really are posing as skilled developers, and they are not.
Have to agree with everything. I wrote this a couple of years back:
Quote:
A slavish adherence to the fool's gold that can be design patterns may lead you down the path of over-engineered solutions that are hard to maintain and build upon. Whilst patterns, in a generalized way, are good for thinking about how to address a known or recurring problem they are not a one-size-fits-all solution to whatever you are trying to model or solve. They have a place and a part to play, just don't let them become the raison d'être of your solution. I say that because I've seen it. Experience trumps exuberance.
-
Wow, after all these years, the "pattern" was the BAD names! (Light goes on) That's what you get for taking coding advice from a Gang! Which also explains why the term "Singleton" has an almost blatant "idiot" sound. They like gangs. They hate individuals they are required to rely on.
Kirk 10389821 wrote:
Which also explains why the term "Singleton"...
I've been around for a while (I got my CS degree in 1978). An interesting programming "technique" called "The singleton" was described to me by one of my professors circa 1975. This was long before OO technology was thought of and likewise long before patterns were formalized by the gang. The patterns guys stole the concept and described it as their own.
I'm retired. There's a nap for that... - Harvey
-
Kirk 10389821 wrote:
Which also explains why the term "Singleton"...
I've been around for a while (I got my CS degree in 1978). An interesting programming "technique" called "The singleton" was described to me by one of my professors circa 1975. This was long before OO technology was thought of and likewise long before patterns were formalized by the gang. The patterns guys stole the concept and described it as their own.
I'm retired. There's a nap for that... - Harvey
LOL, the GoF did not invent ANY of the patterns (IMO), what they did was codified the concepts of standard objects and their integrations and responsibilities. When I went to college some 15 years after you, the hole grail was finding a way to build software like they build computer chips. Well known pieces/components that slide together. Making the building of software so much easier. Even then, I realized. Wait. How much does it cost to make the FIRST CHIP? (The rest are basically free). Is this the pattern (pun intended) that we want to follow? And it is a lot of UNCHANGEABLE fixed functionality. Anyways, patterns/refactoring and permanent tests are a nice step in the right direction, but their overuse is just as bad as their under-use. I have no interest in testing with 6,000 mock objects, and believing that those passed tests means it will work in production... Again, we were making light of the situation. They were like any other gang! Patterns are the drug they push, and they have to protect their brand, and show off their successful followers.