Szoup has it right -- Eidola is young. No notations for it currently exist. The example posted on this thread is not code -- it is a low-level testing interface.
I suggest you read my answers to common comments about Eidola on Slashdot, which covers this one.
You say, "The land does not represent the map." Indeed. But you have the metaphor backwards -- think about it. The land is what's real; it's what doesn't change no matter how you show it. The map is a tool of understanding, a visual presentation for humans, using notation that we invented. You can have many maps of the same land, but you can't have many lands of the same map.
land => semantics
map => notation
So we actually design programming languages backwards, as though the land (semantics) represents the map (notation). In Eidola, the map represents the land.
The title of this article, "Programming w/o Representation", is a bad one. Eidola is not "representation free"; it is "representation independent." Of course language == representation, but in the case of a programming language, where meaning is cleanly separable from representation, it's foolish for us to limit ourselves to just one representation. We should have choices.
The semantics document with all the mathy Greek stuff is not Eidola code. It is a specification. Of course there will be different visual representations -- but this is a young project, and it's not to that stage yet. Be patient.
I recommend you read my answers to common themes in these comments.
One of the problems that seems to be missed by the academic research community is that the more abstract something is made, the fewer are the number of people who can work with it.
I think what the author means is not "abstract", but "theoretical". The reason Eidola is so theoretical now is that it is very young, and it is still in the midst of design. Do not treat it like a finished product!
In fact, abstraction can help more people understand. That's why we write software with high-level languages (abstract) instead of machine code (less abstract) or just wiring transistors together (not very abstract at all).
BTW, I'm not an academic researcher (though I have a high regard for those who are); I'm a professional programmer. Don't jump to conclusions, Skapare. This project is based on my experience writing real-world applications. I don't expect Eidola to be real-world applicable for 10 or 20 years, but I am thinking of developers here, not just the research community.
This notation (visual) part will come in time. But I want to think about what we're trying to notate, and have a good foundation in the kernel ready, before we start thinking about how to notate it.
Projects like this take time to grow. But I promise that notation will have its day!
It looks like they've got a kernel in development, but the actual symbolic creation of a program is in the future.
Thank you for understanding that Eidola is a work in progress. That's been a point of some confusion!
Viola, instant cash register:)
Please note that Eidola will remain free and open source, and I will release the reference implementation under GPL (or a comparable license) when it is ready for release.
The Java you are seeing is a reference implementation. But Eidola itself is not necessarily tied to Java.
The whole idea of representation independence is that this does not lock you in. Write a kernel in another language. Write a compiler for your favorite platform. Write an interpreter. Write ten cool notation systems. They will play nicely together, because the language isn't locked into just one.
It's a very UNIX-like idea -- instead of having one big, monolithic design that sticks you with one representation, you have little modules that do specific things, like notating code, or compiling it.
Think of how your file system works. You can use a command line, or a GUI file browser, or both at once. If you don't like either, you can write your own. They are all showing the same structure underneath, and the file system itself doesn't care.
Eidola's author here. I am not opposed to text. I am just opposed to blindly always using it, without considering the options. No one kind of notation -- picture, text, whatever -- is inherently better than another. It's a question of what you're notating, and why.
A programmer should be able to look at code in different ways. Maybe a very textual presentation is best for editing expressions, but maybe a very graphical view is better during design, or understanding the large-scale structure of a program.
It's a very UNIXy idea -- there are lots of little modules working together, and programmers have a choice. A file system is representation-independent like Eidola. You can use a command line, you can use a GUI file browser, or you can use both at once. It's still the same structure underneath. If you don't like either view, you can write a new one, and it won't screw up the old ones. Get it?
A note: several of you seem confused by the semantics. The mathematical symbols are not what Eidola syntax looks like. The semantics is a specification. An Eidola program will not look like the semantics, any more than a C program looks like the C grammar.
There are no notations for Eidola yet. It is a very young project. It is mostly theory and vaporware. Bear with it -- it is growing one step at a time.
Author of Eidola here. Vaporware? You bet. It's a young project, and to tell the truth, it wasn't my idea to post it to Slashdot! But it's good to be here.
I expect Eidola's ideas to be practical for everyday programming sometime around 2015. That seems to be about how long it takes a for a new idea like this to either mature and catch on, or die off.
Excellent comments. Somebody moderate that post up!
I think it's misleading to draw too much of an analogy between natural languages and programming languages. Eidola's prime directive of representation independence would be meaningless for natural languages for the same reason that it isn't possible to write poetry in a computer language.
In a natural language, words are ambiguous, and meaning is inseparable from representation. Connotation can carry more weight than denotation, and the two are rarely even separable. Computer languages, however, need to be completely unambiguous, and even though code can carry connotation for a human reader, every program has an explicit meaning which is separable from the code.
Therefore it is quite reasonable to talk about separating meaning from presentation. In fact, this has been done with many languages (Scheme, SML, etc) with no oversimplification. It's just that with Eidola, that's step zero; notation follows.
All that said, you're right about the danger of oversimplification by abstraction!
You're right on target. Yes, I mean multiple representations are possible. And as some other posts suggest, some of those representations could be database tables. Imagine doing a select to find every assignment to a particular member variable....
I apologize for having no representations on the site for you to look at. The project is not to that stage. To be honest, this Slashdot post caught me completely off guard!
It is the design methodology that is novel. Eidola is obviously based on a lot of existing ideas. Obviously there are many formal models of OO. The new idea is to separate semantics and 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).
Remember, Eidola is not just a language translator. Having the structure-knowledgeable kernel running at edit time means that you can have many notations working simultaneously with the same code, and you can interact with the structure of your program while editing.
On some similar but different ideas:
Smalltalk had some of this idea, though not to the same extent. It tried to get away from source files a bit, but wasn't really thinking about its user interface as a notation system with conceptual power.
Lisp's separation of the parser from the rest of the language is a similar idea. But this is a step in the compile process, not a core idea of the language design. In Eidola, this syntax-independent form is there even while you're editing.
UML is a primarily a meta-tool for modeling other languages. It's a great idea. I'm trying to make it possible to bring its ideas closer to the language itself -- i.e. you're not generating your code from a model, but viewing your actual code in a modeling-friendly way whenever you want to.
Visual Basic is a primarily textual language with a UI that hides that language from you sometimes. It is a useful thing, but a totally different idea.
My limited knowledge of Wittgenstein has influenced Eidola. We often think too little about how programming languages form a whole way of thinking. I'd like Eidola notations to be powerful conceptual tools -- not just ways of seeing code, but ways of thinking about it. Hopefully, Eidola's design will make it easy for people to try out interesting new notational ideas, and really encourage creativity on the notation front.
Eidola's author here. From the set of general answers I posted:
It's true that programmers are very resistant to change. It's actually depressing, for all our talk of innovation, what a bunch of luddites we really are. Simula happened in 1968, and Smalltalk in...what, 1970? Both were academic pipe dreams, and OOP didn't catch on until the mid-eighties.
So it will probably take 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.
Imagine this gentle programmer's surprise this morning upon finding that he'd been Slashdotted. When I saw the size of my inbox, I thought one of my scripts was thrashing.... I was totally not ready for this, but what the heck! I'm glad Eidola has drawn some interest.
Here are some answers to questions and themes I saw recurring in the postings. I hope you'll find them helpful.
Paul
_______
"You have absolutely no examples of code, not even 'hello world'. All that you have is really just theory."
Well, duh. Before a project is finished, it's unfinished. This is a project in its very, very early stages. Eidola is very far from being a complete language, and obviously there are a lot of major missing pieces! Consider the ideas that are there now; others will come in time.
I cannot emphasize enough: Eidola is a young project. It is vaporware. It is mostly theory. Bear with it -- these things take time to grow.
Slashdot rang the doorbell on Eidola while it was still in the shower, naked, unshaved, and only half-soaped. It's not quite ready to go out on the town. So take it all in that context. If you can't deal and demand to see it finished, check back on the Eidola site in ten years.
_______
"This is all just academic pipe dreams and people will never actually use it. Plus you are a hippie."
It's true that programmers are very resistant to change. It's actually depressing, for all our talk of innovation, what a bunch of luddites we really are. Simula happened in 1968, and Smalltalk in...what, 1970? Both were academic pipe dreams, and OOP didn't catch on until the mid-eighties.
So it will probably take 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.
Being imaginative does not make me a hippie. My long hair might, though.
_______
"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? You're writing in English!"
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 should be, too.
I must emphasize that I am not inherently opposed to text. Text does some things very well -- I see little to improve on in "a = b + c". I'm just saying that all we have in our languages is text, whether it's a good idea or not. People are moving away from that with things like UML, which I consider evidence that text is not perfect on its own.
_______
"We've already heard about formal semantics, graphical notations, objects, etc. What's so new about Eidola?"
It is the design methodology that is novel. Eidola is obviously based on a lot of existing ideas. The new idea is to separate semantics and 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).
_______
"Well, duh, it's just like ASCII only with all these 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.
_______
"Isn't it just some kind of interpreter built on Java?"
Eidola is not 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). This is what "representation-independent" means.
Eidola could be interpreted, I suppose, but I imagine it being compiled. Write a new runtime for it if you like -- representation independence encourages it.
_______
"Hasn't this already been done? What about Smalltalk? UML? Visual Basic? Lisp? "
Smalltalk had some of this idea, though not to the same extent. It tried to get away from source files a bit, but wasn't really thinking about its user interface as a notation system with conceptual power.
UML is a primarily a meta-tool for modeling other languages. It's a great idea. I'm trying to make it possible to bring its ideas closer to the language itself -- i.e. you're not generating your code from a model, but viewing your actual code in a modeling-friendly way whenever you want to.
Visual Basic is a primarily textual language with a UI that hides that language from you sometimes. It is a useful thing, but a totally different idea.
Lisp's separation of the parser from the rest of the language is a similar idea. But this is a step in the compile process, not a core idea of the language design. In Eidola, this syntax-independent form is there even while you're editing.
_______
"Why not build new front ends to existing languages?"
Because existing languages are fundamentally based on text; the whole idea here is that different notations aren't hokey front ends. People are writing such front ends now, and although they are cool, I don't believe they're as powerful as they could be.
_______
"I just don't get why representation independence would be useful."
I am working on a list of Eidola usage scenarios that might help explain this, and show a little more how the language would look and behave. Check back on the Eidola site in a few weeks.
_______
Thanks to for all your questions and criticisms! I am still working through them all....
Slashdot Mirror
Szoup has it right -- Eidola is young. No notations for it currently exist. The example posted on this thread is not code -- it is a low-level testing interface.
I suggest you read my answers to common comments about Eidola on Slashdot, which covers this one.
You have completely missed the point.
You say, "The land does not represent the map." Indeed. But you have the metaphor backwards -- think about it. The land is what's real; it's what doesn't change no matter how you show it. The map is a tool of understanding, a visual presentation for humans, using notation that we invented. You can have many maps of the same land, but you can't have many lands of the same map.
land => semantics
map => notation
So we actually design programming languages backwards, as though the land (semantics) represents the map (notation). In Eidola, the map represents the land.
The title of this article, "Programming w/o Representation", is a bad one. Eidola is not "representation free"; it is "representation independent." Of course language == representation, but in the case of a programming language, where meaning is cleanly separable from representation, it's foolish for us to limit ourselves to just one representation. We should have choices.
The semantics document with all the mathy Greek stuff is not Eidola code. It is a specification. Of course there will be different visual representations -- but this is a young project, and it's not to that stage yet. Be patient.
I recommend you read my answers to common themes in these comments.
One of the problems that seems to be missed by the academic research community is that the more abstract something is made, the fewer are the number of people who can work with it.
I think what the author means is not "abstract", but "theoretical". The reason Eidola is so theoretical now is that it is very young, and it is still in the midst of design. Do not treat it like a finished product!
In fact, abstraction can help more people understand. That's why we write software with high-level languages (abstract) instead of machine code (less abstract) or just wiring transistors together (not very abstract at all).
BTW, I'm not an academic researcher (though I have a high regard for those who are); I'm a professional programmer. Don't jump to conclusions, Skapare. This project is based on my experience writing real-world applications. I don't expect Eidola to be real-world applicable for 10 or 20 years, but I am thinking of developers here, not just the research community.
This notation (visual) part will come in time. But I want to think about what we're trying to notate, and have a good foundation in the kernel ready, before we start thinking about how to notate it.
Projects like this take time to grow. But I promise that notation will have its day!
It looks like they've got a kernel in development, but the actual symbolic creation of a program is in the future.
:)
Thank you for understanding that Eidola is a work in progress. That's been a point of some confusion!
Viola, instant cash register
Please note that Eidola will remain free and open source, and I will release the reference implementation under GPL (or a comparable license) when it is ready for release.
written in java... :-)
The Java you are seeing is a reference implementation. But Eidola itself is not necessarily tied to Java.
The whole idea of representation independence is that this does not lock you in. Write a kernel in another language. Write a compiler for your favorite platform. Write an interpreter. Write ten cool notation systems. They will play nicely together, because the language isn't locked into just one.
It's a very UNIX-like idea -- instead of having one big, monolithic design that sticks you with one representation, you have little modules that do specific things, like notating code, or compiling it.
Think of how your file system works. You can use a command line, or a GUI file browser, or both at once. If you don't like either, you can write your own. They are all showing the same structure underneath, and the file system itself doesn't care.
Eidola's author here. I am not opposed to text. I am just opposed to blindly always using it, without considering the options. No one kind of notation -- picture, text, whatever -- is inherently better than another. It's a question of what you're notating, and why.
A programmer should be able to look at code in different ways. Maybe a very textual presentation is best for editing expressions, but maybe a very graphical view is better during design, or understanding the large-scale structure of a program.
It's a very UNIXy idea -- there are lots of little modules working together, and programmers have a choice. A file system is representation-independent like Eidola. You can use a command line, you can use a GUI file browser, or you can use both at once. It's still the same structure underneath. If you don't like either view, you can write a new one, and it won't screw up the old ones. Get it?
A note: several of you seem confused by the semantics. The mathematical symbols are not what Eidola syntax looks like. The semantics is a specification. An Eidola program will not look like the semantics, any more than a C program looks like the C grammar.
There are no notations for Eidola yet. It is a very young project. It is mostly theory and vaporware. Bear with it -- it is growing one step at a time.
Author of Eidola here. Vaporware? You bet. It's a young project, and to tell the truth, it wasn't my idea to post it to Slashdot! But it's good to be here.
I expect Eidola's ideas to be practical for everyday programming sometime around 2015. That seems to be about how long it takes a for a new idea like this to either mature and catch on, or die off.
Thanks, Jilles, for your excellent post.
Excellent comments. Somebody moderate that post up!
I think it's misleading to draw too much of an analogy between natural languages and programming languages. Eidola's prime directive of representation independence would be meaningless for natural languages for the same reason that it isn't possible to write poetry in a computer language.
In a natural language, words are ambiguous, and meaning is inseparable from representation. Connotation can carry more weight than denotation, and the two are rarely even separable. Computer languages, however, need to be completely unambiguous, and even though code can carry connotation for a human reader, every program has an explicit meaning which is separable from the code.
Therefore it is quite reasonable to talk about separating meaning from presentation. In fact, this has been done with many languages (Scheme, SML, etc) with no oversimplification. It's just that with Eidola, that's step zero; notation follows.
All that said, you're right about the danger of oversimplification by abstraction!
You're right on target. Yes, I mean multiple representations are possible. And as some other posts suggest, some of those representations could be database tables. Imagine doing a select to find every assignment to a particular member variable....
I apologize for having no representations on the site for you to look at. The project is not to that stage. To be honest, this Slashdot post caught me completely off guard!
It is the design methodology that is novel. Eidola is obviously based on a lot of existing ideas. Obviously there are many formal models of OO. The new idea is to separate semantics and 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).
Remember, Eidola is not just a language translator. Having the structure-knowledgeable kernel running at edit time means that you can have many notations working simultaneously with the same code, and you can interact with the structure of your program while editing.
On some similar but different ideas:
Smalltalk had some of this idea, though not to the same extent. It tried to get away from source files a bit, but wasn't really thinking about its user interface as a notation system with conceptual power.
Lisp's separation of the parser from the rest of the language is a similar idea. But this is a step in the compile process, not a core idea of the language design. In Eidola, this syntax-independent form is there even while you're editing.
UML is a primarily a meta-tool for modeling other languages. It's a great idea. I'm trying to make it possible to bring its ideas closer to the language itself -- i.e. you're not generating your code from a model, but viewing your actual code in a modeling-friendly way whenever you want to.
Visual Basic is a primarily textual language with a UI that hides that language from you sometimes. It is a useful thing, but a totally different idea.
See also the general answers I posted.
My limited knowledge of Wittgenstein has influenced Eidola. We often think too little about how programming languages form a whole way of thinking. I'd like Eidola notations to be powerful conceptual tools -- not just ways of seeing code, but ways of thinking about it. Hopefully, Eidola's design will make it easy for people to try out interesting new notational ideas, and really encourage creativity on the notation front.
Eidola's author here. From the set of general answers I posted:
It's true that programmers are very resistant to change. It's actually depressing, for all our talk of innovation, what a bunch of luddites we really are. Simula happened in 1968, and Smalltalk in...what, 1970? Both were academic pipe dreams, and OOP didn't catch on until the mid-eighties.
So it will probably take 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.
Imagine this gentle programmer's surprise this morning upon finding that he'd been Slashdotted. When I saw the size of my inbox, I thought one of my scripts was thrashing.... I was totally not ready for this, but what the heck! I'm glad Eidola has drawn some interest.
Here are some answers to questions and themes I saw recurring in the postings. I hope you'll find them helpful.
Paul
_______
"You have absolutely no examples of code, not even 'hello world'. All that you have is really just theory."
Well, duh. Before a project is finished, it's unfinished. This is a project in its very, very early stages. Eidola is very far from being a complete language, and obviously there are a lot of major missing pieces! Consider the ideas that are there now; others will come in time.
I cannot emphasize enough: Eidola is a young project. It is vaporware. It is mostly theory. Bear with it -- these things take time to grow.
Slashdot rang the doorbell on Eidola while it was still in the shower, naked, unshaved, and only half-soaped. It's not quite ready to go out on the town. So take it all in that context. If you can't deal and demand to see it finished, check back on the Eidola site in ten years.
_______
"This is all just academic pipe dreams and people will never actually use it. Plus you are a hippie."
It's true that programmers are very resistant to change. It's actually depressing, for all our talk of innovation, what a bunch of luddites we really are. Simula happened in 1968, and Smalltalk in...what, 1970? Both were academic pipe dreams, and OOP didn't catch on until the mid-eighties.
So it will probably take 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.
Being imaginative does not make me a hippie. My long hair might, though.
_______
"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? You're writing in English!"
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 should be, too.
I must emphasize that I am not inherently opposed to text. Text does some things very well -- I see little to improve on in "a = b + c". I'm just saying that all we have in our languages is text, whether it's a good idea or not. People are moving away from that with things like UML, which I consider evidence that text is not perfect on its own.
_______
"We've already heard about formal semantics, graphical notations, objects, etc. What's so new about Eidola?"
It is the design methodology that is novel. Eidola is obviously based on a lot of existing ideas. The new idea is to separate semantics and 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).
_______
"Well, duh, it's just like ASCII only with all these 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.
_______
"Isn't it just some kind of interpreter built on Java?"
Eidola is not 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). This is what "representation-independent" means.
Eidola could be interpreted, I suppose, but I imagine it being compiled. Write a new runtime for it if you like -- representation independence encourages it.
_______
"Hasn't this already been done? What about Smalltalk? UML? Visual Basic? Lisp? "
Smalltalk had some of this idea, though not to the same extent. It tried to get away from source files a bit, but wasn't really thinking about its user interface as a notation system with conceptual power.
UML is a primarily a meta-tool for modeling other languages. It's a great idea. I'm trying to make it possible to bring its ideas closer to the language itself -- i.e. you're not generating your code from a model, but viewing your actual code in a modeling-friendly way whenever you want to.
Visual Basic is a primarily textual language with a UI that hides that language from you sometimes. It is a useful thing, but a totally different idea.
Lisp's separation of the parser from the rest of the language is a similar idea. But this is a step in the compile process, not a core idea of the language design. In Eidola, this syntax-independent form is there even while you're editing.
_______
"Why not build new front ends to existing languages?"
Because existing languages are fundamentally based on text; the whole idea here is that different notations aren't hokey front ends. People are writing such front ends now, and although they are cool, I don't believe they're as powerful as they could be.
_______
"I just don't get why representation independence would be useful."
I am working on a list of Eidola usage scenarios that might help explain this, and show a little more how the language would look and behave. Check back on the Eidola site in a few weeks.
_______
Thanks to for all your questions and criticisms! I am still working through them all....