Eidola Notation Gallery

	Notations and Visualizations
	User Interface Philosophy
	User Interfaces of Note
	Existing Visualizations of Programs
	Possible Eidola Notations

Discussion

Eidola home

• It presents many features of program structure poorly, particularly large-scale structure.
• It unnecessarily ties the fundamental design of the language to its human presentation.
• It privileges one form of a program over all others, and that form happens to make it particularly inconvenient for software to work with the semantic structure of a program.
• It creates translation messes for alternate visual presentations and storage formats.
• It creates a very high barrier to entry for creative new developer tools of any real sophistication.

In spite of all that, I've been programming for nearly twenty years using good old fashioned source code, and most of that programming has been with great pleasure. I'm implementing the first version of Eidola in Java, even though it has all the problems I mention above. People have created a lot of fantastic software in spite of these problems -- usually not even considering them. Clearly, source code does not make programming impossible!

The fact that it's simultaneously so problematic and so successful raises some important questions: Why do we use source code? Why has it been successful? What does it do well?

Even when computers developed graphics capabilities, they weren't necessarily ready for graphical programming languages. The original Macintosh had rather impressive hardware for a home computer of 1984 (except for the lack of color), and it took most of what that hardware could offer to provide graphical interfaces for the file system and word processing -- much simpler interface problems than a programming language. Even now, graphics rendering speed, resolution, memory, complexity of GUI code, interface conventions, and design methodology place serious constraints on what user interfaces can do. It is only quite recently -- I leave it to the reader to decide whether it's more like 15 years or 5 -- that representation independence could offer a compelling alternative to source code.

The Language Factor: Another reason we use plain text source code is that the fundamentally different ideas of human languages and computer languages are very intertwined. We imagine both kinds of language in similar terms: they are something you can write down; they are made of words (or tokens); the words are made of letters; the language has a syntax. Even context-free grammars, fundamental to computer languages, are due to Noam Chomsky, a linguist, who invented them to describe human languages. Chomsky's grammars have probably proved even more important to programming than to linguistics, but many of the ideas we carried over from human to computer languages are not so apt -- for example, source files have a sequential structure, even when that structure has no meaning (such as the order of class members). The most fundamental difference, which we often forget, is that computer languages have a meaning which is separable from the language, and human languages do not.

In spite of this imperfect match of concepts, programming languages tap into something very powerful in the human mind when they imitate natural language. If the language centers in our brains are so incredibly flexible as to adapt to languages as wildly different as English and Chinese, they must be able to take on just about anything we could call language. The idea of "language" proves a very successful foundation for a bridge between our thought process and the vastly different internal workings of a computer, and it's been a very successful bridge. Eidola must not overlook this success -- whatever else it may be, and whatever strange forms it takes, it should continue to be a language.

The Intransigence Factor: There is one point which always comes up in this discussion: programmers, like all humans, hate being pushed out of their comfort zone, and are generally very resistant to new ideas. At heart, we're a bunch of luddites. (One study on language preferences concluded that the single largest factor in programmers' opinions was a bias for the familiar, to the extent that the study doubted it could draw any other conclusions!) While this may have a lot to do with the slow acceptance of important new ideas, it is not sufficient to explain the existence and longevity of source code. Eidola must pay attention to the other reasons above, especially the ties between human and computer languages.

A tremendous advantage of source code is the plain-text format itself. Since the structure of the data doesn't reflect the semantics of the code, tools that manipulate source code can cheerfully ignore any levels of abstraction irrelevant to their task. Jeff Putnam made several good points about this in the forum, which I'll elaborate on here:

• There's a large existing body of textual tools useful for source code. Any text editor or text munger is potentially useful for code, and there are a lot of them. Text-savvy scripting languages are so numerous they may soon exhaust all four-, five- and six-letter names. UNIX shells rely on this multitude of tools, making un- or semi-structured text (pipes and command line arguments) their medium of data interchange; while this creates many problems, it also makes it possible to patch a plethora of isolated tools into a coherent whole.

• It's easy to write programs which manipulate text. Graphics are relatively difficult to manipulate in code; text is relatively simple. Even in the unlikely event that there isn't already a tool to do what you want done, it's probably not hard to write one. Inspired hackers write great new text editors every other week. This advantage has a caveat, however: it's easy to manipulate text, but it's very hard to manipulate it with semantic awareness.

• Text editing is syntactically unconstrained. Source code only has to be meaningful at compile time; during editing, programmers have absolute flexibility. They can type the left parenthesis without having to type the right one immediately. They can paste in pseudocode, or code from another language, and incrementally transform it. They can type twenty asterisks in the middle of the code as a reminder to fix something later.

Eidola should, in priciple, be at least as convenient and easy to use as a textual programming language. What does that mean in light of these advantages of text? Should Eidola provide a standard textual syntax which programs can transfer to and from? It would be useful, but standardizing on one seems to defeat the purpose of the project. Should Eidola notations be partially textual, attempt to behave as if they were textual which manipulating the deep structure, or even allow unexecutable "untreated text" elements to mingle with structured code?