A Quantum Mechanic's View of OO

Author: Brian Ewins

Background

For many years Taligent has had a white paper on their web site about quantum mechanics and how many aspects of quantum mechanics could be expressed in object oriented programming. Much of this was hype about objects applied to scientific domains, in my opinion. The original article is still available on the web. In some argument in which the article was mentioned as support for object oriented programming, a "quantum mechanic" posted that the paper's examples weren't very good because objects have identity while many quantum-level particles do not. I found the original article interesting but not at all convincing, and found this reply to be illuminating.

--Amit

Response

From: Brian Ewins <Brian.Ewins@gssec.bt.co.uk>
Subject: Re: A cold shower for OO
Date: 21 Jan 1998 17:58:13 +0000
Organization: BT Glasgow Engineering Centre, UK

ell@access1.digex.net (Ell) writes:

> Bradley K. Sherman wrote:
> > 
> > Likewise, OO theory is of little use in my
> > work as a scientific programmer.
> 
> See the Shroedinger cat website for an example of a quantum mechanics OO
> application.
[the article referred to, which crops up here frequently, is
actually at Taligent's site, ww.taligent.com]

Actually, as an ex-quantum mechanic, I can postively state that
that paper would be of absolutely no use in quantam mechanics
whatsoever. For a start, 'Objects' have distinct identity,
fermions don't, using the classes described in that paper for
multiple fermions would lead to overcounting of distinct quantum
states. The total quantum state is the object, not the individual
fermions.

That's just a criticism of that paper, though; the idea that
OO abstractions are useful in scientific calculations is valid.
I just wish they'd chosen a better example! A *better* example
might have been looking at the many flavours of numeric integration,
or matrix algorithms; for example the Lanczos algorithm for
tridiagonalisation of symmetric matrices depends on there being
an algorithm for multiplying vectors by your matrix, but doesn't
actually care how the matrix is stored or how that multiplication
is implemented. 

We worked on stuff where the matrix representation was different in
different versions of the code (for performance reasons) but the
Lanczos algorithm (and subsequent stages for diagonalising the Lanczos
matrix) could be separated out. By combining the matrix representation
with the methods you need to operate on it you get more reuse in the
code.

[snipped the rest, which I agree with]

	Cheers,
		Baz.
-- 
****====----                                              Brian Ewins. 
Fax: (44) 141 220 6100                          Tel: (44) 141 220 6121
 "It's time we face reality, my friends...
      We're not exactly rocket scientists." --Gary Larson ----====****