It is Object Oriented, but is classless. It also weakly typed, and most type conversions are handled automatically. The primitive type is called the Atom. All atoms know their manifestation on the user interface. Different flavors of atoms include simple text and numeric data, lists and booleans. The numeric atom includes built-in type conversion between US and metric units for a variety of measurements (including lengths, velocities, energy, power, area...etc).
Molecules are collections of atoms and other molecules. These units are actually the models or programs that one would use. They are run through behaviors assigned to them. Molecules are the data structures of DHARMI, and the programs as well. They are their own architecht. There is no workbench or compiler needed to modify them to the developer's liking. DHARMI thus provides an infrastructure, not a platform.
A Behavior is akin to a method in OOP design. The difference is that the behavior is usually triggered to a change in the value of an atom, rather than externally called. A behavior may trigger another behavior to occur. Atoms may be linked together, so that a change of data in one molecule can trigger a behavior in an other. Behaviors are currently programmed directly in java, and compile then themselves directly into the molecule. This makes it interesting for modelling, as behaviors are only triggered by a change in value. Once an atom is 'stable', it no longer needs to trigger a behavior. (Just think of the EE applications alone.)
While all of the Atom types, and molecules and behaviors are descended from the abstract Atom class, there is a package called subatomic that provide handly little utilities for atomic development. There is a subatomic class that allows for automatic unit conversion. There are also classes that handle groupings of numbers and some that provide the infrastructure for linking together various atoms' data.
All compiling, file, and memory management is handled by the Habitat, letting the developer concentrate on such things as program design. DHARMI blurrs the boundaries between program, data and source code.
Currently, DHARMI is implemented in java. It could be written in any threaded language that support dynamic loading. In fact, as long as the primitves' data structure is kept sound, there is no reason why DHARMI can have many implementations. A Guile implementation is in the planning stage (as soon as the author finishes The Little Lisper :-). A perl implementation is also likely.
A DHARMI program right now has 3 modes of presentation. While in running mode, it presents a GUI to the user. A CLI(even curses) is not out of the question and should be done (yes, parts of this were done backwards, but I learn). Each primitive has what is effectivly a property window which is used to edit things like how the atom is displayed, what precision it is and what tolerance it has in order to trigger behaviors.
Finally, there is the Edit Mode. In this mode, the structure of the Molecule (program) can be changed and its behaviors edited. This mode comes complete with a command line.
Expect to see a Guile version and a Perlversion. I welcome suggestions.