[Chicago] Design ponderings

[Martin Maney]

I came to this by way of the Haskell weekly news, of all things.

  What I discovered during my time of inventing and re-inventing DSLs
  over and over is that I couldn't handle change well. Often the
  smallest change would lead to me changing the very language of my
  solution; essentially a total rewrite. This was the reality of
  software maitenance.

http://blogs.concedere.net:8080/blog/discipline/software+engineering/?permalink=The-Problem-Is-Choice.html

The "Patterns of 1972" article he links to is an interesting review of
some historical patterns that predate the Go4 and all that cataloging
that followed.  Even though he misreads the evidence to suggest that
DSLs are the True Objective (or something darn close to that):

  When we identify and document one, that should not be the end of the
  story. Rather, we should have the long-term goal of trying to
  understand how to improve the language so that the pattern becomes
  invisible or unnecessary.

http://newbabe.pobox.com/~mjd/blog/prog/design-patterns.html

Of course that assumes there's no substantial cost to subsuming every
pattern, doesn't it?  I do sympathize with his feeling that the
patterns movement seems to institutionalize visble complexity:

  If the Design Patterns movement had been popular in the 1980's, we
  wouldn't even have C++ or Java; we would still be implementing
  Object-Oriented Classes in C with structs, and the argument would go
  that since programmers were forced to use C anyway, we should at
  least help them as much as possible.

Yeah, that *would* be bad.

-- 
Some people hack for fun, some because they want things their way;
some don't because they can't, and some because they can't be bothered.
Some can make anything work, some could but would rather not,
and some would misconfigure a bowling ball.  -- unknown