No, this page isn't a rant or treatise on nuclear weapons, nuclear power, or particle physics. Instead, it's about software (or at least has a large software dimension).

The name "atom" for instances of TheElements (hydrogen, helium, all the way up to wherever-they-are...see TomLehrer) is, of course, ironic.  The word "atomic" means "indivisible"; something the elements were long believed to be.  Now we know otherwise--atoms are composed of electrons, protons, neutrons, and a whole bunch of other stuff.  (Many of those particles are in turn composed of quarks and the like).  The ability for us to split atoms (or alternately, fuse the smaller particles into new atoms) is rather controversial--its main two applications are power generation (with possibly nasty environmental consequences) and weaponry.

Turning to software:  Many programmers/computer scientists/software engineers, in their quest for a better understanding of the discipline (as well as better and more complete abstractions), often look for opportunities to ''split the atom''--to take something which is indivisible (or usually considered to be indivisible) and find a way to split it into parts.  As part of scientific inquiry, this is always a good thing.

On the other hand, especially in production programming, we may be better off dealing with whole elements (elementary "particles", if you will, arranged in "stable" configurations).  It may be less powerful, but it frequently is safer and easier to deal with.  Chemists are much more able to control chemical processes (which operate on whole atoms, and molecules thereof) than are particle physicists able to control processes at the particle level.

Conversely, many great advances in computer science have occurred when someone discovers how to ''fuse'' two or more independent entities (which might be ConsideredHarmful by some) into a higher-level form which does the same thing, but is more difficult (or impossible) to use inappropriately.

Some examples:

* The GoTo statement (and its cousin the continuation--see ContinuationsAreGotos) is the fundamental building block of flow control.  Any assembly language program consists of zillions of "jump"/"branch" instructions--gotos essentially.  However, use of GoTo has long been discouraged in high-level programming; instead, higher-level control structures (which combine one or more gotos in a "safe" manner) are used instead.

* PointerArithmetic.  CeeLanguage programmers frequently love this; a wizard at C can use pointer arithmetic to do wondrous things.  And again, programs at the AssemblyLanguage level manipulate pointers in all sorts of wonderful ways.  However, most high-level languages severely limit what one can do with pointers; the word has such a negative connotation that they are often called by different names (handles, references, etc).

* Semaphores.  C programmers are stuck with raw semaphores/mutexes as their control structures, which can lead to all sorts of problems if someone forgets to wait on a semaphore before entering a critical section of code, or forgets to release one, etc.  Higher-level languages provide more advanced mechanisms for synchronization and mutual exclusion, such as monitors, critical regions, and the like.  (In turn, some think that these are also too low-level; so other mechanism like CommunicatingSequentialProcesses are frequently advocated).