This page contains an archived post to the Design Forum made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Specific vs. Generic - lean towards specific?

Posted by Harald Mueller on 21 Mar 1998, 3:32 PM

[...]
> I want to talk about when to solve the specific
> problem versus the general problem. My thought is
> that you should always lean towards solving the
> specific problem, unless your product is
> a library or component that is supposed to solve
> a generic problem for other programmers.

Interesting.

Just for the sake of the argument, let me throw in
3 (not really well-thought-out ;-) ) thoughts that,
IMO, point to the opposite, i.e. "by default, do it generically":

a) Probably you are familiar with Kernighan/Ritchie's classic
Programming in C, where they quite forcefully argue more than once
that one should think, design, and code as generic as possible.
[I know - that's not a valid argument, because it is "citing
a guru to intimidate you" - but I think it's worth to think
about the effect that this opinion has had on the development
of the "Unix culture"]

b) I do have a general rule of the thumb that is about:

- if you do/use/... something once, make it dirty
- if you do/use/need/... it a second time, you will need/use/... it very often -
hence you should make it generic.

c) Orthogonal (i.e., generic) designs allow users to more easily
use a system in ways the implementor did not expect. Together with
the axiom "Users will use a system in novel and unexpected ways",
this points strongly to a generic design for software: Make everything
scriptable; make everything programmable; make everything open so new
systems with (at least slightly) modified behavior can be "derived"
from the present system; etc.

Ok. However, now, after I have thrown around with enough intelligent
top-level unconcrete ponderings about the only rightful attitude, which
is "think generically, and do so", I admit that in many cases (a) I do
not know how to make a class, subsystem, tool, etc. generic; and (b) even if
I know it, it is mostly a quite expensive endeavour, where either I or my
project manager (who controls the time=money) or we both quickly runs out
of patience.
So, hard real life forces us to keep to painful specific solutions most of the
time, instead of flying on the clouds of the real generic solutions to
every- and anything.

Nevertheless, in my heart I'm with Terence Parr, who wrote in the
foreword of his thesis (about ANTLR) something along the lines of
"Before I solve a problem once in five days, I rather spend five years
on designing a really generic solution, from which the specific one can
then be derived in just 5 seconds."

Harald

• More specifics Bill Venners 22 Mar 1998, 3:05 PM (9)
  • Generic being made specific Harry Keller March 13, 2001 at 10:18 AM (0)
  • Empty subject - how to access? Harald Mueller 07 Apr 1998, 1:39 PM (7)
    • Fear not, that message is redundant Bill Venners 08 Apr 1998, 1:52 PM (0)
    • Oops Harald Mueller 07 Apr 1998, 1:41 PM (5)
      • oops mtrl sangmesh June 25, 2001 at 10:58 AM (0)
      • OP sangmesh June 25, 2001 at 10:58 AM (0)
      • inheritence g.rkvarma February 25, 2001 at 7:12 AM (1)
        • object orineted programming grkvarma February 25, 2001 at 7:19 AM (0)
      • Clarification Thameem Farook October 23, 2000 at 1:02 AM (0)
• body 22 Mar 1998, 3:00 PM (0)