When you're designing a piece of software, you probably want to start out with a high-level view of your code -- something that shows just your classes and packages and their relationships, but no internals. As you start to figure out a class, you could switch to another view showing the interfaces (the public members, with the implementations hidden), or just jump straight into coding in a low-level view. If you're getting some weird error you don't quite understand, you could look at the code under the microscope of a view that shows you exactly what's going on with every little internal.

If you're using a somebody else's code -- a library, for example -- you could look at that code in a documentation-centric view. Donald Knuth had the idea of self-documenting programs, which you could run through a compiler to make the executable, or TeX to make the documentation. In Eidola, it's just a change of notation.

These different high- and low-level notations would be very different in character. The high-level modeling view would probably be very graphical; the low-level coding view would probably be much more textual. It might even look like a normal textual language, if you like it that way. If drag-and-drop appeals to you, or if you much prefer the speed of the keyboard, it's possible to write a notation to suit your taste. Variety is the rule.

These different views aren't just free-form text or widgets. They are tied directly to the kernel, an internal representation of your program in a structured form -- sort of like a parse tree, but much more interactive. Unlike many user interfaces which attempt to hide what's really going on from the user, the purpose of Eidola's notations is to show exactly what's going on -- sometimes just parts, sometimes all of it -- as it's most relevant to what you need at the moment.

So big whoop, there's a kernel. What does this mean? Suppose that you have a frequently used class which somebody called CTimedDev_BreadHtngCoilAC. You decide that the name Toaster would be a little less confusing. So you open up the definition of the class and type in the new name. And as if by magic, the name changes -- everywhere. In every view of the class CTimedDev_BreadHtngCoilAC, in every piece of code that uses CTimedDev_BreadHtngCoilAC, the name Toaster now appears. No recompile, no global search and replace -- it just happens.

All those other elements that used CTimedDev_BreadHtngCoilAC weren't referencing it by name; they were pointing to the actual object. So the name change doesn't affect them at all. They are still pointing at the same thing, even though its name has changed. Some of them might need to do some quick error checking, to let the user know if the change created any name conflicts. Other than that, there's no work to be done, no name to be updated to keep the reference valid.

Because an Eidola program is there in its structured form, it's more responsive when you edit it. The kernel can answer questions about the structure of your program, and will find errors as you introduce them. That doesn't mean that kernel stops you from introducing the errors -- it just lets you know that you're doing it, like a joystick with force feedback. So you can see if that square peg fits in the round hole by picking it up and trying to stick it in.

Because the structure is there in the kernel while you're editing, you can ask structured questions about your code. "Is this legal?" "What are the arguments to this function?" "Is this what that class was called?" "Is anybody using this? Can I delete it?"

All this means that you can poke and prod your code a bit while you're editing it, and be a little less surprised at what the compiler spits at you when you try to build.