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.
Most programmers are very wired into text as their default representation - we are, after all, very textual creatures (could we have this discussion in diagrams? Conceivably, but it would be an inefficient representation of the semantics). Some specialized systems like visualization networks work very nicely as a visual interface (AVS) because they have this nicely visual metaphor: networks of sources and filters. But as for Hello World and its useful cousins, I dunno. steve d.
From a brief look at the web page, this sounds awfully similar to Microsoft's Intentional Programming project, only less general, and less sophisticated (IP is designed to be able to represent many existing languages, with their differing semantics). They don't make any mention of IP in their FAQ though. Could someone who knows more about Eidola expound on the similarities and contrasts of these two projects?
Thanks to a couple of people for pointing out to me that similar formal specifications exist for OO languages. For instance, looking at the type systems for the simple L1 and L2 languages described here, with their accompanying soundness proofs, gives me all kinds of warm fuzzies.
run aleph[1] programs.
I'm not sure what kind of keyboard you would need to write regular aleph[1] programs.
Some weird quantum analog hybrid might more
truly be considered aleph[1].
Is the notion profound, stupid, or profoundly stupid. I really can't tell.
http://rareformnewmedia.com/
Both have block structure and static, lexical scope. These were new features when Algol *68* came out.
I agree. I don't see anything on the Eidola site about the author's background or credentials, so it's hard to tell where he's coming from; but he either seems to be unaware of a lot of work in this exact field, or is ignoring it for reasons he doesn't explain. The fact that he provides no bibliographies (that I saw) or other references to prior work by others doesn't help.
Besides, the notion of different representations of the same program is an almost trivial one, and doesn't really need a special language to support it.
Calvinbola got me grinning, too. You have clearly been blessed by Jeebus. Since I don't have mod status today, you'll have to settle for my lame adulation, sorry!
In the real world, the luxuries we think programming needs to have just don't exist.
We who? Programmers? In the real world, business needs more programmers because there are more tasks. And those tasks are results driven, leaving it up to the programmer to translate result requirements into programming models. It is this step that needs to be implemented. Of course that can mean the end of programmers as we know it today.
Joe Normal will never program as we know it. But I do believe the eventual end result is that Joe Normal will be able to get a computer to get things done that would today require a programmer, and require time.
now we need to go OSS in diesel cars
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. While certain things as the C language and assembly language are not something the average person can take on, abstractions which work in mathematical constructs are no better.
One thing that will be needed more and more in time is the ability to make more people capable of accomplishing the tasks we today call programming. To solve this we need to focus on just what those tasks really are, and how people think about them. Most people think about the results they want; few can think about the steps needed to achieve those results. What will work better for the age of information is tools that work better with the concepts that average people (as opposed to academics) really think about, and use that to produce what they want.
I suspect it will end up being something more along the line of providing example results, and having the computer then try to mimic them. The cycle would be repeated with corrections and adjustments until the results are as expected, or close enough to be satisfactory. These tools still have to be programmed a more conventional way, though I suppose perhaps Eidola one approach to accomplishing this.
now we need to go OSS in diesel cars
I am personally undisturbed for other philosophical reasons (which are not worth going into) that mathematics is not self-proving, and am perfectly happy with an "infinity" that may not be definable in the conventional sense but still has definable behaviors. "The square root of negative one" isn't real either, but still has definable behaviors, and is thus as real as necessary.
(Still, kudos for the approach; it takes guts to shake the foundations of reality and see what comes out, even if I don't agree with your assessments. This is not sarcasm, it only sounds that way on the Internet.)
you don't get it, these properties of text based storage of sourcecode put an upper limit on a system's size.
Now c++ and c are typical examples where the fixed semantics of the language are not enough. Hence the use of preprocessors. If you were right, preprocessors would be redundant.
Obviously you haven't read Fowler's book on refactoring, otherwise you wouldn't claim such nonsense, I strongly recommend you do.
", but they are different conceptual entities, and should be stored and represented differently."
Just one question: why?
Answer: design uses different representations because sourcecode does not provide you with the constructs to model the design (i.e. the expressiveness of source code is very limited). Abandon the notion of text based storage and fixed semantics and that problem goes away. No more outdated designs! The system description contains all the information you need. You just have to query it in a smart way to get rid of the info you don't need.
"programmers have to do it, and managers have to build time and motivation into the the process to ensure that it happens."
Walk into your average large software company responsible for lets say around 5 million lines of code. Ask for the design documents. Presuming they don't throw you out, you'll find that in most cases either the design consists of some very outdated documents or that the sourcecode is the documentation. In real life people don't spend much time recovering designs unless they absolutely have to. Try convincing managers you want to spend the next three months just recovering the design of the product you're working on.
Jilles
Text is unsuitable for representing structured data. That's why databases exist. In fact the only reason we store programs in ascii files is because programmers are reluctant to give up their vi/emacs editors.
Because of this:
1 - Languages have fixed semantics. The text files follow a syntax which cannot be changed. Consequently the semantics of the syntactical constructs are also fixed. Ever wanted to add multiple inheritance to Java? Well, you can't because the language spec forbids it.
2 - Automatic refactoring of code is difficult, regular expressions just are not powerfull enough to do the job. You need more structure to do it properly.
3 - You don't have first class representations of design concepts. Because of point 1 you can't add them to the language either. But worse, the most abstract details about your system are lost when you store them as text. You won't be able to recover them with a parser, simply because the information is no longer there. Ever tried to recover a highlevel design from just the source code? I remember seeing something about a dependency graph of the linux kernel just a few days ago. That's the best we can do with source code.
Now does this mean we have to give up on our editors? The answer is no. All that needs to change is the primary representation of the program. Once you have a representation, you can define a view on it to be able to manipulate it. Ascii is probably the simplest form of such a view. However, it is a rather limited view also. So we'll need more advanced tools as well.
Finally, I should add that eidola should visit microsoft's site: http://www.research.microsoft.com/ip/ to learn about their intentional programming project. Charles Simonyi had a similar vision years ago and apparently the project has advanced significantly since then. The information on the page is a bit limited unfortunately, but there are some very interesting papers.
Jilles
All programs start as vaporware. This is not a product anouncement, just a few people communicating some good ideas about the way we currently build software and a plan to improve it.
Since the very basis of their idea is not to have a text representation, you won't find code examples. I think the best way to think about working with this kind of systems is as manipulating parse trees (without actually having to parse!). For instance, variables will not be represented as identifiers. Rather you'll just point at the spot in the parse tree where the variable is pointing at (i.e. some subtree). Also the pointer can point to any subtree. So if, you've built some very complex algorithm, all you have to do to reuse it is point at it in the parse tree.
Jilles
Note - important responses to many posted questions here!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
So far I've only tried in under Linux, but it worked fine using the 1.3 JDK for me.
It should probably read "Java 2" instead of 1.2.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I remember seeing an article about nano-motors that used vaporised water to move a piston that made a shaft rotate. A friend pointed out it was a steam engine. Just very small.
Now people are talking about fibre optic delay lines as storage devices. Some of the earliest computers stored data as sound waves in mercury and
nickel wires. A speaker injected sound in one end, it was picked up my a microphone at the other, re-shaped and squirted back in.
Same idea, different medium.
This isn't a programming language, it's a model of computation, and a poor one at that.
Whoop de doo. Another extra-complicated Turing machine substitute.
To quote from the semantics manual: "implementations represent the semantics instead of the reverse -- What a wild thought!"
What a ridiculous thought! What a wrong thought! The land doesn't represent the map. This is just an example of poor semantics (take that either way, both work).
It might be useful if they defined a representation, but that would cost them their gimmick, and make Eidola just another language to be judged on its true merits, wouldn't it? The sensible thing to do to avoid getting hung up on the representation would be to define a simple and consistent back-end representation meant for computer processing, not human reading or writing. Instead, he promotes his poor, overcomplicated, model of computing and discourages standardizing the representation as "limiting" (how much better we would all be if we ignored other such limiting standard representations as ASCII and two's complement!).
On the bright side, he really seems to be having fun with TeX. It all looks much more respectable with Greek letters and logic symbols, doesn't it?
---
To ensure that the program is completely independent from the representation, you can't use the same notation twice.
---
Aleph[0] is what you become when you die.
Aleph[1] is what you become when you die as an Aleph[0].
Jeebus is Aleph[CXD] (where CXD is my pathetic imitation of an infinity sign; it is also the ASCII representation of the Jeebus-fish, which eats its own tail while turning the water it swims in into wine).
Jeebus told me so in a vision.
---
I fail to see the true distinction between the mental construct of natural numbers and other mental constructs. They are all mental constructs that may or may not reflect the true nature of the physical world.
While it is true that our proof the existence of infinity is no better than our proof of God's existence, it also the case that we have absolutely no proof of our own existence or anything else in the physical world for that matter. We can prove nothing about the physical world. The best we have is "I think therefore I am" - and that is still somewhat faith based. That our perception of the passage of time reflects the true nature of the physical world is also a faith based belief. Time may very well be an illusion for all we know. We would be foolish to limit our models of the real world to only those things that are intuitive. It just might be the case that there are counterintuitive things out there. And then once you recognize these things, your "intuition" can be retrained so that what was once paradoxical is now intuitive. I don't believe that our intuitions are fixed in stone, nor do I believe that everyone has the same intuition. Intuition is plastic, like all of our other mental processes, and can be altered to suit external conditions. The "undeniable" messages we receive from our intuition are often completely wrong! The only thing my intuition tells my that I must always believe is "I think therefore I am".
Infinity", while defined better than, say, a "tooth fairy", is still more phantasy than mathematics.
But if it has definable characteristics within a mathematical system, then it is part of mathematics! Besides, all of mathematics could be called a fantasy anyway. There is no such thing as mathematics which is "true" - only various mental constructs which varying degrees of usefullness and aesthetic appeal.
If your mathematics is so pure, so great, then why does it contain paradoxes, contradictions, undecidability and incompleteness?
Sheesh! You can't have everything! As demonstrated by Godel, all formal systems will necessarily be incomplete in some way. This is not a bad thing - it's just a property of formal systems. Formal systems are not like a religion. They are simply a game with rules that we invent and follow. Nothing at all to do with the "real" world. Math is just something in your head. It has nothing to do with what is "just" or "good", and nothing to do with religion. BTW, Cantor's infinities have well defined properties and are not inconceivable at all. It doesn't matter if infinity exists in nature - we can imagine it. We can also imagine tooth fairies or anything else we want to think about.
Now if we build mathematical models of reality (eg, Quantum Chromodynamics, Superstring Theory, General Relativity), then there can be "religious" or "faith based" aspects, namely that you have faith that your model conforms to reality. Yet we have no assurances that "reality" can be mapped into a formal system.
Heizenberg showed us that, to the best of our knowledge, we can't simultaneously know both position and momentum to arbitrary accuracy. Are you going to complain about that too? How about Schrodenger's cat, which is both alive and dead? And those photons, which are both waves and particles? If nature was so great would it have all that indeterminate stuff built in? These things are just a property of nature, to the best of our ability to measure.
Text is, howver, excellent for describing the structure of data. Which is what a program needs to do.
That's not a bug, that's a feature. Fixed semantics enhance communication. Anyone who's worked on C++ code where someone has abused operator overloading knows the danger of redefinable semantics.
Refactoring shouldn't be automatic. Large changes to code should be the result of careful thought.
I wouldn't expect to be able to do so any more than I'd be able to recover the source code from the object code. You can get some idea, certainly, but they are different conceptual entities, and should be stored and represented differently.
The difficulty is in keeping the different representations in synch. If they are actually useful representations, automated tools won't do the job; programmers have to do it, and managers have to build time and motivation into the the process to ensure that it happens.
Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
this is the bridge pattern applied at the language level. the pattern, as defined by the gang of four:
/.ers, but i had trouble grasping the bridge pattern when i first read it, and wanted to point out this great example.
Decouple an abstraction from its implementation so that the two can vary independently.
from the Eidola front page:
In short, Eidola is a programming language which separates a program's structure from how that structure is presented.
i know i might be stating the obvious to a lot of OOP-savy
if you do OOP for a living -- hell, if you're a programmer of any stripe -- i encourage you to read the book.
As somebody working in information visualization, I would love to see a useful visual representation of programs. The idea is great, but they should better start working on the visual parts real soon, because this is going to decide between success and failure. Their underlying system might be a huge leap (which I doubt, but there you go), but if they don't have a good visual representation and no textual one, who is to use it? But if they have, this might become a great thing.
I'm really looking forward to more news from them.
EagerEyes.org: Visualization and Visual Communication
Like, say, English? If the first principle these people are starting from is that text is a bad way to express ideas, then I have a very hard time imagining what it is that could be better. Pantomime? Grunts & gestures? Pictograms? From their page:
Hey, different strokes for different folks and all that rubbish, but the thing I like most about Perl (for one) is that it is *intentionally* messy, just like human languages. You can tell that a linguist came up with it. Complex problems simply don't always map well against simplistic solutions. A complex language, and the rich expressiveness that it allows, is often just the thing that is needed. English & Perl both work so well because they are flexible, adaptable, messy, and dynamic. "Orthogonal" languages are so hell-bent on rigorous mathematical structure that they often get in the way of more natural (to humans) ways of conceptualizing they problems at hand.
It also bugs me that I can't find any samples of the source code (or whatever -- graphical flow charts, who knows) of this language. The best I've found so far is a high level description of their design criteria, which is all well and good, but if they can't even formulate their concepts well enough to express them in something looking like code, then I can't imagine how they expect anyone to wnat to use it. "I know, they'll just, like, think really hard about stuff, and it'll work better." "Radical man, really radical. Hey, pass me that willya, I need another hit..."
Riiiight.....
DO NOT LEAVE IT IS NOT REAL
Dude, read the FAQ on their site. Eidola is an experiment right now, not a working model. Even they admit it may not pan out how they've planned it.
If you have to ask all these questions, then forget about it. It's not what you're looking for.
------------------------------
www.eidola.org is running out of my closet. Since it's posting on /. last night I've come to be very thankful for that fact.
Incedently, the reason for this is that Eidola is in its infancy, and rather than make snappy screen-shots, Paul's instead decided to spend his time focusing on the language itself. It's not necessarily inherently visual, but given that it's NOT necessarily text-based either, the idea of having lots of different and useful graphical views of your program seems an obvious one.
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
Scheme: Functional language, very stack based, makes heavy use of LISP-style lists, funky weak-ass typing scheme, extremely recursive syntax. . . essentially lambda calculus on steroids.
Pascal: Imperative language. Annoying typing scheme that the programmer is always tripping over, standard infix imperative language type syntax. . . Basically, C without all the things that make C C.
I'm failing to see the family resemblance here. . could someone help me out?
> Personally I'd like to see an example program
This follows on from what I was saying - you cannot see an example program without using a representation. Heck, you can't even do abstract maths on paper (or blackboard, web page etc) without a representation. You can't save to disk without a binary representation.
My Karma: ran over your Dogma
StrawberryFrog
You cannot program without a representation of your code, be it lines & boxes, 10pt Courier or whatever.
What this seems to say is that the language is independant of the representation. For eg the pascal and c uses of { and begin repectively are just representations of the same thing. So are indentation styles. IMHO representation-independance is a good thing, as it makes some silly flame wars about who's style is better irrelevant.
In order to really be representation-independent they would have to have at least 2 working representations for the coders to use, which is the opposite of the title. Sheesh.
My Karma: ran over your Dogma
StrawberryFrog
In fact, I've seldom seen a website since 1994 that contains so little images as this one (not a single). The author must be a very non-visual, text oriented person.
Yeah, this looks alot like Fourth too.
Someone you trust is one of us.
Now that could be a cute contest...
Researcher 1: I tell ya, Eidola is spreading across the campus like wildfire!
Researcher 2: Shouldn't we be quarantined or something?
Java still doesn't hava a canonical binary form at the class file level. It is conceivable (and in fact happens) that two Java compilers would produce the different output for the same piece of code.
-no broken link
I got to meet Simonyi a few years ago. The group i was working with got interested in IP, (Intentional Programming) and sent me to go check it out. It seemed really cool, they have so far used it a little in Outlook, but we didn't have any direct need for it.
-Jon
Streamripper
this is my sig.
Nah. The hardware people used to do things that way, but went to textual representations like VHDL for complex systems. Logic diagrams for big systems are painful to work on.
Google to the rescue: A Crash Course in the Mathematics Of Infinite Sets.
Yes, that's true. OCaml adds object support to Caml, an implementation of ML.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
This reminds me of an idea I had a long time ago to make C++ more like English. I created one text document to describe the basics, and then moved on to more practical things. Here is that text document:
E++ -- what would it look like? Could it be parsed into C++ Here is what I think it might look like:
the header file:
define "Krunk" as something that has these members:
an integer called m_Int,
a long called m_Long,
and a character called m_Char.
Krunk also has these functions:
a protected function called Yell that takes 3 arguments:
a character, a long, and a float.
Yell returns nothing.
a public function called Shout that takes 1 argument:
a float.
Shout returns a long.
the source file:
The Krunk interface is in krunk.h
When you tell a Krunk to Yell, it does nothing.
When you tell a Krunk to Shout it says 2.
Create a Krunk called Blah.
Tell Blah to Yell.
Tell the Screen to Print what Blah Shouts when you give it 3.
if this is the end, then do this:
on sunny days:
take a drive.
on rainy days:
take the bus.
otherwise, do nothing.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I'm quite familiar with automata and turing machines (I'm a Senior in computer science, perhaps all too familiar on friday nights when I should be out ).
That's the way to write out programs that has any graphics. You could abstract away with this. Perhaps you could make a great language with it. I'm still not convinced that it's practical though. Especially when he mentions Verification and Validation testing. This is often done with a text based script. Now I suppose that you could have a graphic that says "Pump every number, including the ones that aren't supposed to go in here in, and tell me what it looks like," but traditionally that's done with test scripts and other such text realm goodness. Also, I can look at a whole page of text at one time, it's hard for my field of vision to look at a gigantic picture of a program. I suppose that graphical language could be ok if you're talking about making flow charts and such, but still, is it more practical than text?
Eh...
And that's where Aspect Oriented programming such as Aspect J will come in. Aspect oriented programming most likely is a big enough leap forward for developers to accept it whenever it goes mainstream. There are some definite clear cut advantages that aspect oriented programming has over OO. But It's late and I don't feel like listing any of them. Visit the site if you haven't already.
--------------------------------------
If Murphy's Law can go wrong, it will.
There's no reason why you can't use the kind of diagrams you describe, provided they encapsulate the underlying semantics of the language. I think that's actually a pretty cool idea; it certainly makes conceptualizing a program's behaviour and function much easier.
Haskell certainly allowed for this kind of formal analysis (for instance, one could prove equivalence between two programs, although I sucked at it and can't say how applicable it is for correctness proofs and other verification strategies.Nice buzzword, but think of it. Human programmers still need to look at something and tell the difference between two programs. Maybe it'll be "represented" in a different way. Ultimately, there will have to be something to describe what a program does - that something could be symbols, images, lines, whatever. It's still a representation.
:)
They could call it a "different representation" language, but that would ruin the image.
In any case, if there's a page describing the different ways Java, C++ and Eidola handle classes and methods, it can't be all that revolutionary.
w/m
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.
No, the best interfaces are invisible.
"Computer. Earl Grey. Hot."
I'm only half kidding.
"And like that
As per vorbis, I've switched.
Sure, all the mp3s I get from friends are, well, mp3s. But everything I encode is vorbis because, well, the differences are small enough that it costs me *nothing* to use them. It's open source, it's free, it's better quality, etc. So all the music from all my CDs are Vorbis.
So to answer your question, this does have some benefits.
This is *not* a fundamentally new type of language. I think if you've seen predicate calculus, cellular automata, and lexical parsing in the same class, you'll find a lot of this familiar.
What this is doing is mapping predicate logic/calculus (I think, I sucked at predicate calculus) with structured programming. It's also very different too.
But it starts to think of programs in a level even higher than text, if that makes sense. I could almost think it's trying to treat the source code as annotation and description of a program, and not the actual implementation.
Hmm, analogy...
It's different than 'visual' thinking, in which you have functional blocks with busses, data directions, transformations, blocks and checks, etc.
Eidolon almost certainly forces a different way of thinking, but I don't think it's terribly foreign. In this case, the 'language' cannot exist outside of it's runtime, or context. In this way, it's similar to lisp, or scheme(I think). Conceivable one could write a Eidolon program in a regular text file and 'open'/'run'/'compile' it with the kernal, and be able to validate it in some sense.
Argh, I feel tongue tied. It should allow for very high level structured programming in terms of thinking at an abstract object level. Things are defined in a very predicate calculus way, with the textual representation almost becoming documentation for the structure defined by the calculus. This may have more functional similarites to Lisp than I thought, but it's been awhile since I've played with Lisp.
It's probably a good start towards mission critical code style, in which there needs to be correctness, validation and verification built into the language in the first place.
Anyone want to help me out here?
Geek dating!
GPL Deconstructed
Graph oriented? I dunno.
It doesn't seem to me a new language, as perhaps a new flavor of an older idea, like Lisp?
Use some predicate calculus notation to start describing and defining functionality, as well as for allowing one to show correctness and validation.
Map it closer to today's object paradigms without the constraints of matching 'objects' as defined as nouns with verb-methods, instead using a more abstract concept of packages, super-elements, and sub-elements, and algorithms. Given that they haven't finished documenting algorithms, I'm out on a limb here.
The goal would seem to have something closer to predicate calculus, and thus something easier to hold provably correct and functionally correct.
Instead of the many to one mapping of source to algorithm, it should be closer to one to one, I guess.
Of course, I was never very good at predicate calculus, and maybe everything I've said is obvious, and I'm being stupid.
Geek dating!
GPL Deconstructed
It seems to be an implementation of this Eidola language in Java and gives a very brief example of what appears to be Eidola programming or whatever passes for it.
Here is a snippet of the example from the page:
Here's a simple example to get you started:
new Class c
new Variable v
v setType c
v setSuperElement c
c addPublicMember c.v
new Class d
d addParent c
d addPublicMember c.v
"sweet dreams are made of this..."
That would be a major pain in the butt. Personally, I like the exactness in programming and how it forces you to express your creativity in a completely logical way. Can you imagine a computer that would always try to do what it thought you wanted instead of what you said?
Ick. Not nearly enough control or exactness in that.
Nobody talks or thinks like this...
Actually, I think like that, and so do plenty of other people. I've not only found it very convenient to do so while programming, but also in solving everyday problems. Every field has its own unique language and ways of thinking. Why should the field in which we command machines be any different?
I got my Linux laptop at System76.
That was my thought on playing with the test interface. People will make comparisons to visual basic or code generators, but I think tcl or scheme is a more apt comparison.
IMHO the "visual" part of this project is intended to make the point that "code" is not the "executable", and that the way we create and build (and sometimes run) programs need not be based on text. If visual modeling tools were not already so popular they might have advocated sound instead.
As an aside, their site is the first time I've run across javadoc. Very, very, very cool. Might be the thing that finally convinces me to learn java.
--
--
The government is not my daddy.
Sounds like that time I tried to learn Perl. "Ok, with this language, it does what it thinks you meant to say."
I'd like to see this one happen. It looks like they've got a kernel in development, but the actual symbolic creation of a program is in the future. It also appears to be one more step towards representing things closer to the way we do in real life. If you could actually pick out a common everyday "object" and just use it, that would be very cool. Especially if that object has already been proven. :)
Viola, instant cash register
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.
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.
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!
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.
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.
"Eidola is a representation-independent, object-oriented, visual programming language."
:-)
written in java...
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.
> 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/
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.