[michaelochurch]

I've always taken these "design patterns" to be a Shibboleth of the bottom 80-ish percent of programmers.

The mediocrities can't handle math. If they dig deep enough into any technical area, they get confused and insecure and pissed-off. Design patterns is the Revenge of the Not-Nerds. It's to use the language of the business to turn the tables and make the actually competent feel queasy and unsure of themselves in the (artificially stupid yet complex) environment. It ends up reinstating a mediocrity-protecting connections- or seniority-powered system because no individual can get anything done.

I call the programmers who like that nonsense "math haters". (Rhymes with "death eaters".) Instead of y = sin a*x, which is "too mathematical", it's a Vibrator object with an .apply(double x) method that returns a double. That class of functions (parameterized by a) is a VibratorFactory. But since there can only be one, why not seem extra business savvy and call it a VibratorFactorySingleton. I'm going to throw in Proxy and Abstract and Visitor in there too, not because I know what they mean in this context (I don't) but because no one else does either so I can get away with it. It's an AbstractVibratorFactoryProxyVisitorSingletonFactory.

All because I needed to use a simple trig function. But (to the math haters) trig functions are scary!

So much of this "enterprise-y" nonsense is there not just to dumb down, but to smart-out (as in, drive the smart people out of) programming. It serves the interests of characters like Twitter's PHP CEO (obviously fictional, but people like him exist) who seek to commoditize programming at all costs.

For more on this: http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol...

[philbarr]

What an obscure load of tosh. I might as well say that all the maths-nerds don't really know how to program because they don't understand design patterns properly, as evidenced by them hating on it all the time.

But of course, I wouldn't say that because I have absolutely no evidence and it would be based purely on my close-mindedness and preconceptions. (I also wouldn't say it because I have no hatred towards "maths-nerds" !)

And also - when has a pattern ever been used to abstract away a maths problem? I certainly haven't seen it!

Understanding patterns, but more importantly, design principles, help when writing code because of the limitations of the language (any language) in properly describing the problem domain. If those principles lead to the creation of patterns which are then given names and taught to the masses, I cannot understand how learning about them would make someone a worse programmer.

[AnimalMuppet]

I agree with you in general. But learning the design patterns superficially, and applying them where they don't really fit, can in fact make someone a worse programmer. Hopefully they'll grow out of it, so the "damage" is part of the student phase, but some probably do get stuck there and never progress.

[anko]

For me, design patterns are a good thing. If it's a phase, I'd prefer people to be stuck there rather than never learn them.

My reasoning is that using a pattern is like documentation. If I see a pattern in some code, i barely have to read the code. Code is hard enough to read as it is, patterns make it easier.

I've heard various figures over the years but one that i think is a decent estimate is that maintenance is 80% of the SDLC. That means reading a crapload of code. Any time you can reduce the burden is a good thing.

It's true that a lot of GoF's design patterns are particular to languages like java and c#, and not relevant to dynamic languages especially.

I think your idea about applying design patterns where they don't fit isn't really the source of the problem. Some developers aren't good at understanding the problem they are faced with, so they do the wrong thing. That isn't anything to do with applying or not applying design patterns - it's a different discussion altogether.

[angersock]

That's well and good, but quite a lot of business value can be created using sub-elite programmers.

The problem with not having a good common vocabulary is that it makes it harder and harder to ever have proper engineering in software.

That said, your example of not being able to use trig is flat out unacceptable--that's things taken much, much too far. Even an average programmer shouldn't be afraid of basic trig.

[exelius]

Completely agree. If you're building a forecasting module for an ERP system, you're probably not going to be able to hire CS grads out of MIT or Stanford to staff on it. You're likely going to get some dudes from India with little experience outside the other Dilbert-esque ERP systems they've worked on. But these guys can still be productive if given the right structured environment, and that's what coding patterns give you.

Furthermore, "rockstar" developers are often a hinderance on these kinds of projects: they take workarounds that are technically sound, but harder to maintain. Use of consistent design patterns makes maintenance a hell of a lot easier (especially when using less-talented developers). Rockstar developers are great in a startup when you need your developer to be a systems architect as well, but they're less useful in rigid functional projects like big enterprise software projects where developer and architect roles are rigidly separated.

But the example OP listed still makes sense: wrapping the example trig in a function makes sense if you plan to modify that function later and it's used in several places across the project.

[tzs]

That should be ".apply(Angle x)", not ".apply(double x)". It's not properly enterprise-y if you can actually see a primitive type anywhere.

[michaelochurch]

Good point. Unfortunately, my AngleFactory is broken, and the AngleFactoryFactory team is buried in tickets right now.

[Iftheshoefits]

The "enterprise-y" garbage you note has almost nothing to do with the mathematical competence of programmers who implement it.

You write as though programming is an exercise in mathematics. It's not, in general. There are specific problems where mathematics is actually a component of the problem/solution space, e.g. mathematical research, scientific computing, in which programming is the form of the solution to the math problem (analogous to, e.g. "express your answer using set notation", except in this case it's "express your answer in the form of a computer program"). Mathematics may underpin some of programming, and most often in some areas of computer science, but the vast majority of software development has very little to do with math.

[10098]

Why bring a thought-up ridiculous example when you can post a link to the infamous AbstractSingletonProxyFactoryBean?

Anyway, patterns aren't some "evil plot" by "math haters", they are simply recipes that solve recurring problems. They weren't really "invented" by GoF or anyone else, these things tend to emerge when a lot of people people do a lot of software engineering projects.

Also, you're wrong if you seriously think that the majority of software engineers needs to know trigonometry (or any kind of math at all) to do their jobs.

[cma]

The only thing worse than "enterprise-y" nonsense is blogs of lame psychoanalysis of characters from a fictional office sitcom complimented with its own language-stan to throw off outsiders, all in the service of some Nazi-like narcissitic crusade of "smart" vs "idiot".

[AnimalMuppet]

But see, even math can be misused in the same way. Instead of y = sin a * x, it becomes both a functor and a monad. See, that's even more mathematical!

Those who have only a superficial understanding can (and will) mis-apply anything. That includes all of us, at some time in our careers. Those you dismiss as the "bottom 80" include anyone starting to learn anything. Some of them will grow to know how to use the tools well; some may never do so. But don't condemn the entire tool because you've seen it used badly.

More: You seem to be condemning everyone who doesn't program your way as being stupider than you. That is far more likely to be arrogance than to be the truth.

[trollingTroll]

Further, he didn't decompose the sin function into a Taylor series, while insulting other people's maths and programming skills.

Uncool, bro. Uncool.