| Eidola FAQ | Home |
| The Project |
| There's a lot of stuff on this site. Where should I start? |
| Start with the "About Eidola" page, which lays out the basic big ideas of the project. If all that discussion is a bit too abstract and philosophical for your taste, read some examples. Then read this FAQ, and look at the project's current status. The status page has links to other pages of current interest. |
| What is Eidola? |
|
Eidola is a representation-independent, object-oriented, visual programming language.
Eidola is an experiment which takes a wild new approach to the structure and representation of programming languages. Traditional programming languages are heavily tied to their representation as textual source code, which is unfortunate -- pure text is a very poor notation system for the concepts of a high-level language. An Eidola program, however, exists independent of any representation; its "fundamental" form is as a set of carefully defined mathematical abstractions, opening the possibility of having many different notations. Representations of the language thus exist for the benefit of the programmer instead of the compiler, and freed from the constraints of text files, we can tackle the question of how to notate a program well. In short, Eidola is a programming language which separates a program's structure from how that structure is presented, so that the presentation can focus on being a powerful, useful notation. Read more about the project. |
| What does "Eidola" mean? |
|
It's the plural of eidolon, a word English takes from the Greek. It means "phantom",
and also "an image of an ideal". It's the latter meaning I intended,
but the former also applies, since the language is currently just a pipe dream!
In English, we often use seeing as a metaphor for understanding: "I see"; "it's quite clear"; "shed some light on the subject". It's apparently a metaphor that's been around for a few millennia -- eidolon comes from the proto-Indo-European weid, which refers to both seeing and understanding, and gives us the words "video", "vision", "wit", and "wisdom". As "the image of an ideal", eidolon is a rare word which retains both senses of weid. Incredibly, my friends Joel and Nick both independently suggested the word when I mentioned my need for a name and my love of this etymology. |
| How do you say it? |
| Pronunciation is a matter of individual taste. I say "EYE-do-la"; many others say "eye-DO-la". Say it in such a way that it rolls pleasantly off your tongue, and you have my blessing. |
| Who's behind this project? |
|
It's the product of my (Paul Cantrell's) free-range imagination.
It began as a
project at Macalester, where my advisor,
Dick Molnar,
guided the first concrete thoughts on the language, and reviewed my thesis on the
subject along with
Susan Fox and
Michael Schneider.
After college, the project sat neglected...until the summer of 2000, when the
Mad Monkey Construction Agency
inspired me with their work on
Jao to make this project happen.
The inimitable Nick Weininger
has made major contributions to the project, including
a fantastic paper, a specifications/code review, and
numerous invaluable editorial suggestions.
Jesse Morris kindly hosted this web site on
his server for many months before
Sourceforge took over the task.
Vahe Poladian and Florin Ibrani took care of the domain name registration.
Numerous other excellent people have contributed their invaluable thoughts, questions and criticisms to the project. Not one of them yet? You should be! |
| Who's going to get rich off of Eidola? |
| Nobody. It's a free and open project, the semantics is an open standard, and once it's mature enough, the reference implementation will be released under GPL or something of the sort. There's no coporate or otherwise profit-minded entity behind the project. It's possible that somebody could make money writing software based on the ideas of this project -- for example, somebody could sell a high-performance Eidola kernel, or Microsoft could do a crummy knock-off and corner the market -- but the core of this project will always remain free in both senses of the word. |
| Who can I contact? |
| See the contact information page. I send out an informal Eidola newsletter, which you can sign up for from the contact page. |
| Do you have a plan, or a timeline? |
|
This is a home-grown project that a few people are running in their spare time. Of course,
some amazing things have happened that way! But this project is still too small to have the
momentum for such concrete planning as versioning and release schedules -- though it is
gaining momentum as people other than Paul start to contribute substantive work.
Eidola is not going to happen fast. It takes a long time for software to mature, and even longer for a new idea to catch on. I imagine it or a descendant to become a reasonably full-fledged programming language in 10 to 15 years. Yes, that is a long time, but it's realistic. This doesn't mean that there won't be some really exciting progress even in the next six months, though! So keep an eye on the project. |
| How can I help out with this mad endeavor? |
| Look at the current list of ways to help. You can give some casual input for one of the "Calls for Ideas", or commit some more serious to one of the "Calls for Volunteers". And, of course, fresh ideas not on the list are always quite welcome! Even the simplest questions and comments help me out a lot. If you don't understand a page, send me a two-line e-mail saying "I don't understand page X", and I will know I need to make that page clearer. |
| The Idea |
| How can you program without representation? |
| You can't. Eidola isn't "representation free"; it's "representation independent." That means that you can show it in many different notation systems, store it in many formats, and implement it in different ways, and they all play nicely together. |
| What's so bad about text? Are you saying natural languages are bad? |
|
Natural languages are wonderful! Language is but the stream I go a-fishing in....
But our human languages represent very different kinds of meaning from programming
languages. We should not presume that a programming language works best if it looks like
a human language.
Consider music notation. How hard would it be to read music if we spelled it out in words instead? Sheet music is well-suited to what it's communicating; a programming language's notation should be equally well-suited. I must emphasize that Eidola is not inherently opposed to text. Text does some things very well -- "a=b+c" is pretty clear. The problem is that we always represent everything in our programming language with text, whether it's a good idea or not. People are moving away from that with things like UML, and that's good evidence that pure text is not perfect for programming. |
| Isn't it just like ASCII, only with all those math symbols? |
| The semantics is a specification. That is not Eidola syntax you are looking at. Eidola programs will not look like the semantics -- no more than a C program looks like the C grammar. |
| What's so new about Eidola? Hasn't this already been done? |
|
Yes, much of Eidola is not new. Object-oriented programming, formal semantics, and visual
languages are all old topics. What's novel about Eidola is the design approach --
separating semantics from representation from the beginning, not as a meta-tool (UML),
an add-on (code browser), editing sugar (syntax highlighting), or a separate layer over a
mostly textual base (Visual Basic).
Several people assure me that Lisp does exactly the same thing, although none of them
know Eidola well -- and I don't know Lisp well enough to say either. One important difference
is the emphasis on architectural nuance in the language primitives
(see this question).
Here are some other projects which are similar, related, or just interesting. |
| Why not build new front ends to existing languages? |
| Because existing languages are fundamentally based on text; the whole idea here is that the different Eidola notations aren't front ends grafted onto something that wasn't originally designed for such a thing. People are already writing such front ends, and although they are cool, I don't believe they're as powerful as graphical front ends could be. |
| Why would representation independence be useful? |
There are many reasons, which fall into these general categories:
|
| What a pipe dream. Do you actually expect it to work? |
|
Who knows? It's an experiment. Many of the ideas in the project now will inevitably turn out
to be wrong, and there's no telling how far Eidola will go. However, it's inevitable that
something like Eidola will become reality -- programming languages are going to have to
take this step at some point.
Even if Eidola turns out to be a really great idea, I don't expect it to catch on quickly. Programmers are very resistant to change. It's depressing, for all our talk of innovation, what a bunch of Luddites we really are. And it takes a long time for an interesting pipe dream like this to become practical. Simula was around in 1968, and Smalltalk happened in the very early seventies, but object-oriented programming didn't catch on until the mid-eighties. I expect it will take about 15 years for the ideas of Eidola to either catch on and be practical, or die off. But somebody has to start thinking about these things now if we want them to be usable by 2015. |
| The Language |
| Why are there no code examples? Where are the cool graphics? |
|
In Eidola's design, notation (what you're looking for) is based on a kernel, and a kernel
is based on the semantics. Right now, the kernel and the semantics are so incomplete and
present so many design questions that notation is only in the preliminary phases.
The focus now is on laying a foundation.
The Notation Gallery contains some ideas and possible inspiration for Eidola notations. It's not actual Eidola code, but it may satisfy some of your desire to see pictures. |
| How is Eidola similar to/different from other languages? |
| The big difference is that Eidola makes a clean separation between the substance and the appearance of a program. Although this crazy idea of representation independence makes Eidola a fundamentally different beast from more traditional languages, it still has many familiar features. Take a look at the comparison with Java and C++. |
| Where is the design at this point -- what's done, and what's not? |
|
We have a good semantic description of the high-level structure of Eidola (packages, classes,
functions and variables), and a working Java implementation of this semantics.
Many major pieces are missing: the semantics still do not describe the interiors
of function (i.e. algorithms), scoping, or program execution; the existing languages structures
are in a very basic for (e.g. no constructors, no static or protected members);
and there is no concrete work on notation.
More specifics are on the status page. |
| Why doesn't Eidola have important features X, Y and Z? |
| Right now, even in the limited scope of the semantics, there are some notable omissions (e.g. protected and static members). The plan is to start simple, and make the language too skinny at first. In the future, the language will become more robust, but additions to the language will always be minimal and judicious. The Eidola aesthetic is toward a small set of powerful constructs. Clean good (C, Java, Scheme); monstrous and messy bad (C++, Perl, Ada). |
| Why not follow a cleaner semantic precedent, like Scheme? |
|
Scheme and company take the admirable goal of semantic minimality. There's very little
in the language, but that means there's very little to notate. Eidola wants lots of stuff to
notate, so its semantics are much thicker.
Functional languages have lovely and famously brief semantics, and if the goal of a language is semantic specification, they're the right way to go. But the end purpose of Eidola is not semantic specification; it's making as much deep and useful large-scale structural information available to the programmer as easily as possible. Langauges like Scheme and SML are semantically simple precisely because they do not attempt to capture this kind of structure using language primitives, which is fine -- but it precludes certain kinds of programmatic analysis of the nuances of a programmer's architectural intentions. Eidola tries to encourage this kind of analysis, and to that end, it carries a lot of semantic baggage in the form of strongly typed, strongly encapsulated objects. There is the separate question of why Eidola is procedural and not functional. The answer here is much simpler: I'm not familiar enough with functional languages to invent one. It could be quite wonderful to create a strongly-typed object-oriented functional language after the model of Eidola; if somebody who knows what they're doing took on that task, they would have my support. |
| Isn't it just a layer on top of Java? |
| Eidola is not inherently tied to Java. I chose to do a reference implementation of a kernel in Java, but you can write a kernel in a different language if you want. The formal semantics will help ensure that your kernel and the Java kernel are compatible, and can exchange programs through some common representation (XML, database, whatever). Neither kernel is more special than the other as far as the language is concerned. This is what "representation-independent" means. |
| Will Eidola be compiled, or interpreted, or what? |
|
It depends on the kernel and the compiler. Right now, the project is a long way from
worrying about runtime environments. Eidola should be a compilable language, but writing
an interpreter on top of a kernel shouldn't be hard, and would provide intriguing testing
possibilities. There will eventually have to be a set of standards for runtime environments,
but that's a long way off.
One of the great benefits of representation independence is that it's much easier to implement some part of the language in a new way, and still have the new play nicely with the old. So there will potentially be many runtime environments, many storage formats, many notations, and so forth. |
| Will Eidola be compatible with my favorite language/platform/OS? |
| Eidola's representation independence certainly puts it on a good footing for being platform-independent, but the sorts of issues Java has had to deal with to achieve this (the virtual machine, OS-abstracting libraries, etc.) are certainly outside the immediate scope of the project. The specificity and abstraction of the language specification should make it easy to write new implementations for new platforms, and to determine the kind of wrappers necessary for working with other languages. But once again, runtime environments are a long way off. |
| Will Eidola have a standard set of runtime libraries? |
|
Probably -- a good set of standard libraries is a fine thing. Aaron raised the intriguing
possibility of having Eidola compile to Java bytecode and use its libraries, although this
presumes quite a bit about the previous two questions in this FAQ, both of which remain
unanswered.
A special mission-critical version of Eidola would have a reduced set of runtime libraries, since those libraries would have to go through the rigorous process of mission-critical verification. |
| What is Mission-Critical (MC) Eidola? |
|
Nick Weininger has made a compelling case for the importance
of a representation-independent language in the writing and verification of software
which must not fail -- such as control systems for airplanes and medical devices.
Nick's argument influences Eidola in two ways. First, there will eventually be a specialized version of Eidola, Mission-Critical (or "MC") Eidola, with special features and constraints that make it suitable for these types of applications. Second, whenever possible, insights from the mission-critical development process will influence the general version of Eidola, in the hope that even mainstream applications can benefit from the techniques of mission-critical development and not break all the time. |
| Home | Copyright 2000-2001 Paul Cantrell |