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 ----====****