Slashdot Log In
Eidola - Programming Without Representation
Posted by
michael
on Fri Feb 09, 2001 01:41 AM
from the fine-line-between-genius-and-madness dept.
from the fine-line-between-genius-and-madness dept.
Lightborn writes: "From the Web site: "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 -- 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."" We're confused, yet intrigued.
This discussion has been archived.
No new comments can be posted.
Eidola - Programming Without Representation
|
Log In/Create an Account
| Top
| 258 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re:Is it? (Score:3)
Take a look at the Common Lisp Hyperspec [xanalys.com], in particular, the descriptions of what the Lisp Reader does - It parses the textual input stream into Lisp objects [xanalys.com].
Since the Reader is modifiable (i.e., you can remodel it to take in program representation in any way you want and convert it into Lisp objects), and there is no constraint on how lisp objects are represented internally in a conforming implementation, it follows that Common Lisp is already a "representation independent, object oriented programming language" We get the "object oriented" part because the Common Lisp Object System (CLOS) is part of the standard, and part of all current implementations.
Seems to me these people would have spent their time better by writing some reader-macros for Common Lisp than reinventing the wheel.
What's novel here? (Score:3)
Standard ML is a language whose type system is formally justified. IIRC, the type system was designed to permit proofs that every program which type-checks successfully satisfies certain correctness and safety properties, e.g. it never accesses a value of one type as if it had another, incompatible type (*). ML has a very competent, freely available implementation (Standard ML of New Jersey) and has been used to write, among other things, a TCP/IP stack, a web server, and its own highly optimizing compiler.
I don't know if anyone has yet tried to reproduce this level of formal justification for the type system of an OO language. ML has polymorphism and type signatures, but I don't think it has any notion of an inheritence hierarchy. If Eidola is the first language to bring such formalism to OO, that would certainly be a nice contribution.
(*) Note that the proof doesn't go in the other direction, ie "every correct program type-checks," because useful notions of correctness are in general undecidable. The ML type-checking rules are provably sound but are not complete.
Programming is a problem in N-dimensional topology (Score:3)
There are two ways of handling n-dimensional presentation:
1) Untangle and handle one dimension at a time. While this allows for textual presentation, this approach suffers from the difficulty of "getting the 'big' picture." This leads to reams of source code of dubious quality.
2) Handle the dimensions three or four at a time and construct geodesics or geodesic transformation "movies" to present the problem space. The geodesics put objects at the terminal points of relationships.
The second approach can be entirely dynamic and generated from provably correct definitions of the objects and of the relationships in the problem space.
The object definitions can go as far as referring to specific instances of the objects but disambiguation becomes yet another dimension which might be more effectively be handles by refactoring and subclassing.
There is still the problem of selection, some dimensions will reveal very little of the problem space being limited, disconnected and/or monotonic.
The creation of an interactive "3D tank" presentation using data gloves to select and manipulate objects and relationships and the selection of dimensions themselves would be great for presenting problems for discussion and solutions for correctness of fit.
Still this would make for a promising area of research.
Re:Still aleph[0] of programs (Score:3)
Really? I can. Didn't take me forever, either.
I suppose you'll next claim that "big numbers like 'trillion' don't exist" because we can't conjure those up in our minds either? (Might not take you forever if you insist on counting each number but it will exceed your lifespan.)
The concept of doing anything which is infinite is completely absurd!
Not gotten very far in Physics, have you? Particle physics without the mathematics of infinity are, to borrow your word, "absurd".
Nice troll!
Not yet (Score:3)
Non-text programming has been around for a while, Visual Basic and Prograph being the best-known examples. There's a lot to be said for doing the graphical parts graphically, instead of writing text to describe window and widget layouts. But graphical descriptions of control flow and data are just too bulky.
One real problem we have today is that the mainstream languages are too hard to parse. C++ cannot be parsed without reading the include files first, and Perl doesn't even have a clear syntax definition. This retards the creation of tools that process program text. ("Indent" for example, has never been upgraded to handle C++. Nor is there a program that turns Perl programs into canonical Perl, with no elision.)
LISP was at the other extreme, being very easy to parse, and thus there were lots of useful tools for doing things to LISP programs. One editor had the ability to select a block of code and have it extracted as a function, with all the variable references and arguments adjusted so that this worked every time. Programmers today can only dream about tools like that.
Bad syntax has nothing to do with language power. It's a cruft problem, coming from adding stuff to a language. Remember, C started out without real types; adding user-defined typenames (typedef) to the syntax broke the ability to parse modules without seeing all the type definitions. C++ made it even worse. The Pascal/Modula/Ada family of languages, on the other hand, don't have this problem. var foo: typebar; is parseable without knowing anything about typebar, while the C/C++ equivalent, typebar foo; is not.
On the other hand, language syntax doesn't really matter much any more. Library semantics consume a much larger fraction of programmer time.
Migration/Transition issues (Score:3)
Its important that this is really a big leap forward, and this is made clear to developers before they'll even think about using this kind of code.
It'll be hard for this to go mainstream.
heh.... (Score:3)
written in java...
This is an old, good idea (Score:4)
Re:Use of Text (Score:5)
not at all.
They are the old fashioned ones. Hey language is inefficient... lets go back to scratching pictures in the dirt or hieroglyphics on the wall in order to communicate.
This visual programming crap crops up from time to time because so many people are brainwashed by that crap about a picture being worth a 1000 words. Draw me a picture of "misguided".
Programming is done with languages because programming is communication. It's communication between programmer and computer.
This is also the reason why the GUI monkeys can never understand the power of a gcommand line. The command line is a language. They are stuck on the "pictures are better than words" meme. Yeah, true, they are, until you learn to read that is.
Visual stuff, GUIs, languages etc, are more *intuitive* in the same way that picture books are more intuitive to babies. It doesn't mean they are superior. This is why the best interfaces are a combination of GUI and language. It's just like the way you give children picture books while they are learning to read.
Eidola scare? (Score:5)
I though it was discovered that that person in canada didnt have Eidola?