Design Patterns == weakness in language

[Steve Horne]

On Wed, 13 Sep 2006 17:25:37 -0400, Brad Anderson <brad at dsource.org>
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

Eh!

I'm sure that languages will naturally get higher level over time, and
that as a result the number and complexity of patterns needed to
achieve any given result will get smaller. But you're missing three
crucial points...

1.  As languages get higher level, software generally gets more
    complex. New, higher level patterns arise to cope with that
    complexity. So you need at least as many patterns, just different
    ones.

2.  There's not much to gain by adding compiler support for
    pre-existing patterns. Patterns exist because they are easy. If
    they were hard, people would find other patterns.

    The real complexity is in how patterns are combined to form an
    overall design.

3.  The most useful new language features are never based on
    pre-existing patterns anyway.

The final point is the most interesting. What were the most obvious
big advances in programming languages? - well, just off the top of my
head...

- Structured programming.
- Functional programming.
- Object oriented programming.
- Exceptions

NONE of these was a pattern prior to becoming a language feature.

Structured programming resulted from the observation that some
programmers had a 'cleaner' style than others, and their code tended
to be more reliable. But there were no hard 'if' or 'while' or similar
patterns before then. People with a more structured style still
invented whatever 'structure' suited each problem individually. The
idea of having a predefined set of block structures was a language
feature first. It only became popular to imitate those specific block
structures in assembler when they were already popular in high level
structured languages.

Functional programming can be considered a similar thing, also heavily
influenced by math and computer science theory. A functional 'style'
of programming has become more popular as a result of people using
actual functional languages. To the extent that there was a choice in
Lisp (which is strictly speaking an imperitive language) this was a
general style thing, not a pattern to solve any specific problem.

As for object oriented programming, prior to Smalltalk (the first
object oriented language) there was no such thing. The patterns for
writing object oriented code in non-object languages came later - as
hacks for getting C to work with object systems like COM, for
instance.

Object oriented programming was originally a set of ideas and
metaphors which were aimed at making a whole bunch of programming
tasks easier. The nearest anyone had got to C++-style object
orientation, for instance, was bunging a few related values into a
parameter block with maybe a few function pointers for company.
Virtual tables - no. Inheritance - no.

And there is a good solid reason why this is the case. Treating
'object oriented programming' as a pattern in a non-object language is
an absurdity. It doesn't make life easier - it makes all kinds of
things more complex and awkward, and far more error prone. Sure, it is
a flexible and powerful technique - but that flexibility and power
costs in terms of fiddly error-prone code overheads. The only serious
reason to do it is because you have no choice, e.g. if you need to
interface code in a non-object language with existing object-based
code.

Exceptions were never a pattern before they were added to a language
either. Dealing with stack unwinding manually would be a absurd - OK,
there's the old C longjmp, but that was never used in a pattern that
could be honestly compared with modern exception use. Exceptions were
invented as a new and original idea, and added to a language as an
experimental feature, and they worked.

So, creating genuinely useful new language features has never been a
matter of just adding support for pre-existing patterns. And no
surprise, really. As I said, the whole point of everyday patterns is
that they are easy. If they were hard, people would find different
patterns instead.

Add language support for pre-existing patterns one at a time, and you
get a bloated dinosaur of a language with very few benefits to justify
that bloat. And your style stagnates because of that huge commitment
to always using those same patterns, which don't mix well with new
ideas. And let's face it, use a compiler-supported pattern and you
need to look up the right syntax and keywords out of the thousands in
your every-single-pattern-gets-special-syntax language, instead of
simply expressing the pattern using general purpose language features.

All you prove is that you have no creativity or problem-solving
skills. That you can't spot the general themes in the problems that
happen most often, or that you are unable to create new general
purpose ideas that could simplify a wide range of problems.

A key goal of language design should always be to get the most bang
for you buck. Having a full toolkit is a good thing, but each tool
should give real value.


Actually, I don't see any reason to worry about this. Looking at
what's happening now, I don't see any sign of a catastrophic change
for the worse. After all...


The D 'scope' statement makes a whole bunch of cleanup tasks easier.
It isn't the RAII pattern, but it can replace the RAII pattern in many
cases and in others it can complement RAII, making it simpler and more
reliable.

Aspect oriented languages (Aspect Java, Aspect C++) were created to
solve problems with cross-cutting requirements. There's a lot of
'include this code at this point in every method matching this regular
expression' kind of stuff. If Aspect oriented programming was ever
done as a pattern, it was 'scattering similar fragments of code all
over the place'. Aspect orientation as a pattern would be absurd, but
aspect orientation as a language feature makes a lot of sense.

I could go on, but everyones bored. So I'll just say that if you
really want better support for existing patterns, the obvious thing
you should ask for is better template support. That can help automate
many patterns, not just one or two.

-- 
Remove 'wants' and 'nospam' from e-mail.