Design Patterns == weakness in language

[Georg Wrede]

Brad Anderson wrote:
> This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
> long-term given that it's not abstracting away a majority of known design
> patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
> 
> http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns

Excellent article, thanks, Brad!

I totally agree with the article.

In a larger context, that's exactly what Man has been doing all our 
history. Anytime there's an often enough recurring pattern, it is "made 
to go away", or at least made easier to accomplish. (Dragging major 
objects: invent the wheel, food too tough to chew or digest: invent 
cooking, too long to swim over: invent boat, too hard to figure out the 
needed field area for crop to feed the village: invent arithmetic, too 
much arithmetic to do: invent calculator, find yourself typing the same 
things: write a macro, etc.)

If we'd have been content with just executing the discovered patterns, 
we'd still hunt by running, kill with our bare hands, and flog with our 
own teeth.

Also, this is exactly how the brain works. Tasks composed of a number of 
discrete subtasks are glued together and automated so that they become a 
single task. Happens all the time. A child has a heck of a job producing 
a single phoneme ("a", "k", etc.) because they require the orchestrated 
cooperation of an incredible number of small muscles -- which he has to 
individually and simultaneously control. Later it becomes just automatic 
to say any single phoneme. Then he has to learn to say words, which he 
initially does by choosing and putting these into a sequence. Later the 
same happens with words to construct sentences.

A beginning programmer tediously chooses which iterating construct to 
use, carefully figures out the starting values and ending values, the 
choice of loop variable names, and whether the check is at the beginning 
or the end. And with the seasoned programmer, this entire task is both 
thought out and even typed into the source code "without a thought". 
It's become invisible.

And in one sense, programming itself is just doing this! The programmer 
creates custom routines so he avoids writing repeated code. And a very 
good programmer creates subroutines even for things he only uses once, 
so that he can manipulate that part of code as a single named entity in 
his head. Clarity of thinking gives clarity of code.

---

D has indeed come a long way further than C++ or C, and I believe it is 
exactly because it has followed the idea in that article.

I think there are two separate things a "better" language can do:

  - make those "patterns" go away
  - give the programmer tools so he can make his own patterns go away

The latter is needed because every programmer has to live in his own 
unique domain, with its unique possibilities and obstacles. No 
programming language can be expected to be perfect for every task, but 
the easier it is to make the patterns "go away", the more time the 
programmer has for the real issues at hand.

The expression power of the language is key in this. And a large part of 
it is the template system, which (congratulations, Walter, and thanks) 
actually has turned out just incredible.

Back to the former, that is achieved of course by syntax and semantics 
that obviate as much as possible the need to do "the mundane stuff". 
Another important part is well written, coherent and orthogonal 
libraries that are easy and efficient to use.

---

Reducing the number of design patterns one uses can not, and should not 
  be the goal. As we make existing patterns "go away", we find that we 
use the time won to do other things, and they invariably do contain 
patterns themselves, which we will in time discover. But if we keep on 
working like this, in the end we are able to produce both in quantity 
and in quality a lot more. And that should be the goal.