When I was in college, one of the jobs I had was a TA for an intro programming class. For one of their projects, I was asked to whip up a kind of web browser “shell” in Java. The basic idea was to make a browser that would be highly extendable by students, while freeing them from worrying about the overall rendering framework.

Now, the first language that I learned was Smalltalk, which has historically been relatively design-pattern-free due to blocks and whatnot, and I had only learned Java as an afterthought while in college, so I coded in a slightly unorthodox way, making use of anonymous inner classes (i.e., shitty lambdas), reflection, and the like. I ended up with an extremely loosely coupled design that was extremely easy to extend; just unorthodox.

When I gave it to the prof, his first reaction, on reading the code, was…utter bafflement. He and another TA actually went over what I wrote in an attempt to find and catalog the GoF patterns that I’d used when coding the application. Their conclusion after a fairly thorough review was that my main pattern was, “Code well.”

That year, the class didn’t actually end up using any of the code I wrote, but a year or two after I quit being a TA for the course, they did. I took a look at what became of what I wrote. Needless to say, it now made extraordinarily heavy use of patterns everywhere—and had a massively larger code footprint as a result—but, after all, it’s important to show the young peons how to use patterns. (Euf…)

So, yes, I have to agree that dogmatic use of design patterns hurts, and that a new language won’t automatically eliminate that.

But I’d like to believe that a language that doesn’t take ten lines of code to invoke a method by reflection, or five lines to write what in any decent language would be a one-line lambda, would at least help.