Slashdot Mirror


Eidola - Programming Without Representation

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.

10 of 258 comments (clear)

  1. Re:Is it? by Anonymous Coward · · Score: 3
    Those who don't know Lisp are doomed to reinvent it, badly.

    Take a look at the Common Lisp Hyperspec, in particular, the descriptions of what the Lisp Reader does - It parses the textual input stream into Lisp objects.

    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.

  2. What's novel here? by jbuhler · · Score: 3

    I'm having difficulty seeing the novelty of Eidola. It's certainly not the first language to have a basis in a formal semantic calculus -- the lambda calculus for functional languages goes back to the 1930's. Eidola is also not the first to aim at a rich yet provably correct type system.

    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.

  3. Programming is a problem in N-dimensional topology by crovira · · Score: 3

    If properly modeled, any NP complete computing problem can be reduced to a topology network (even behavior can be seen as transition in the temporal dimension.)

    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.

    --
    MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
  4. Re:Still aleph[0] of programs by Jerf · · Score: 3
    It is impossible for you to conjure up "infinity" in your mind, because that would take forever.

    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!

  5. Not yet by Animats · · Score: 3
    The Eidola papers are rather arrogant for the amount of work he's actually done. It looks like he's reinventing Smalltalk, but it's too early to tell.

    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.

  6. Migration/Transition issues by aliebrah · · Score: 3

    While this is a great idea, I wonder how many people will be willing to make the change. When moving to a fundamentally new type of language there must be some real big advantages over the current status quo. For example, Vorbis is better than MP3 ... no question. But its not *much* better, so no one switches.

    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.

  7. heh.... by mpak · · Score: 3

    "Eidola is a representation-independent, object-oriented, visual programming language."

    written in java... :-)

  8. This is an old, good idea by woggo · · Score: 4

    I've yet to read the semantics document, so I won't comment on the language itself. However, the idea of multiple representations for a single program is a good idea both from a philosophical standpoint (a la Wittgenstein -- "to imagine a language is to imagine a form of life" -- so allow different forms of expressing a program), and from an engineering standpoint. In the latter arena, Eidola mimics the venerable ancestor of Scheme and Pascal, Algol 68, which allowed users to construct their own grammar for the language's constructs (an early attempt at i18n!); also, it could allow Literate Programming with great facility.

  9. Re:Use of Text by joss · · Score: 5

    > Maybe I'm just old fashioned . . .
    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.

    --
    http://rareformnewmedia.com/
  10. Eidola scare? by KevinMS · · Score: 5


    I though it was discovered that that person in canada didnt have Eidola?

    --
    Sneakemail is to spam filters what an ounce of prevention is to a pound of cure.