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.
I suspect the problem which will be illustrated by Eidora is that most efforts at abstraction lead to oversimplification. I can give examples using European languages: German is capable of a precision of expression that is simply not possible in English, while in Italian (I am told-I don't speak it) there are types of poetry which have no analogue in English, at all. You cannot discuss Italian poetry in German other than to catalogue it as to type, pretty much the rows of butterflies pinned to a board in the museum of natural history.
My point is that metalanguages are constructed in such a way that they provide a gross oversimplification of the processes going on in real language, they are very hard to enlarge (for exactly the same reason it wasn't until 1917 that mathematicians accepted their first inductive proof-concern that the sky will fall if you tweak the rules even slightly), and tend to be Boolean in orientation, etc.
Having said that, there is a place for languages which may be limiting in their richness of possibilities, but which may be adaptable to deterministic predictable construction of code with determinable performance paramaters, etc. These folks seem to be wandering around down by the creek, exploring like eight year olds, and may bring home something we'll all find interesting, and maybe they'll only come home wet and dirty. Wish them luck.
It's nice to see that people are rediscovering all the consepts that are in the ANSI Common Lisp language.
:).
In true lisps (like Common Lisp not Scheme) only one function READ is concerned about textual representation of programs. You can change read syntax any way you like. There actually exists reader macros that read FORTRAN
In the lanuage standard, only chapters about function READ discuss textual representation of forms.
When READ has done it's job program is represented as bunch of lists inside lists, vectors, structures and classes.
READ syntax is just like XML but better for programmers. (XML is just another consept that has been familiar to Lispers for 40 years now.)
After READ has done it's job MACROS are executed. Unlike C-preprosessor, Lisp macros are like normal Lisp functions. Only differences are execution time (after read before compiler macros) and that macros don't evaluate their arguments.
After macro expansion it's time for compiler-macros. compiler-macros are nice for many things I'm not going to tell you.
After that it's time to compile to machine-code. Most CL-implementations compile to machine code.
In short. CL-programming is like programming a compiler. READ is like lexer (you can change syntax of the program anyway you like). Then we have intermediater representation using internal datastructures. Macros are like what compiler does to intermediate structures in conventional programs. Compiler-macros are like local optimizations. After that is compiling to machine code, but that is the job for the CL implementor.
I think we need a new moderation category: -1 technobabble.
Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
I read the internet for the articles.
You're completely misunderstanding the point of this language. "Representation-independent" semantics does NOT mean that you'll code in little happy egyptian symbols rather than text. It means that code can be presented to the programmer in whatever form best suits the task at hand, whether that be text, a call graph, a class hierarchy, etc.
We in the US haven't had to deal with this since we gained our independence from Britain in the 1700s. I say we take a stand, and show these totalitarian swine what we're made of!
Who's up for the Boston CD Party?
"Time flies like an arrow; fruit flies like a banana." --Groucho Marx
*any* knowledge of Wittgenstein is liable to influence just about everything. :-) The *Tractatus* is very proto-OO in places, for example.
If an Eidola program crashes, does it bleed out too?
--K
So all computer languages are already in a sense "independant from the text of their source code".
Most of the usual languages such as C, C++ or even Java have rather non-rigorous semantics, due to thir being too close to the complexity of the computer their run, which makes it difficult to have a mathematical model of execution, and also due to making to many compromises toward such things as compatibility and readability.
But there exist languages that have always been developped keeping very rigorous semantics, such as the Haskell and OCAML functional languages.
For more on this idea--sometimes called "Programming by Example"--see Henry Lieberman's PBE home page, or the fascinating book (now available online) Watch What I Do.
Do they have a problem that doesnt fit the constructs of the languages available?
If so, define the problem so I can see the usefulness of a new programming paradigm.
If not, a new language is not needed.
Often times it seems (to me) that crazy languages are created by crazy people who dont know how to program.
I've written one in Prograph, although it has been several years since I last looked at the language. Basically, you define blocks with input and output data streams. At the top of the sort block, you make a sort of gateway block that splits into two streams, each of which sends data to the block itself. It is actually pretty easy.
I disagree totally with the statement that text is not a good way to represent program structure. Humans are very good at representing complex ideas with language and this is represented as text in the written for of almost every language.
Why move back to the equivilent of cave paintings to write programs, just make text even better!
Sig is taking a break!
Look at that! No textual representation, object oriented, what an idea!! Geez, somebody should have thought of this 30 years ago!! Oh, wait, they did....it's called smalltalk!!!
Hmmm.. Another means of representing the same old programs. I suppose its target was to make the programmers life easier, and the code easier to understand. Both of which are great targets.
On the other hand, I suspect that what we really NEED is a language that can be REALLY well optimized. In the "good old days" when PCs had 1Mhz processors, 10Mb HDD and 64Kb RAM, programmers had to struggle to make their code fast, tight and clean. These days, with 1GHz CPU, 30Gb HDD and 1Gb RAM, that ain't so. Programmers can just add a "-O6" flag, and hope for the best.
Can you imagine a programming paradigm that meant code could be written as readily as it is today, but which compiled to that old-fast 'n' tight code.
We wouldn't be needing to upgrade our hardware every 5 minutes just to cater for the latest greatest office suite, desktop, or version of 'X', which now take 4 full CDROMs to install because the code is so lazy, and re-use is still just a pipe-dream!
--
Enjoy Y2K? Roll-on Year 2037!
Alright, I'm a fool. Can't even post to the right thread. Sorry.
http://www.linuxguruz.org/foldoc/foldoc.php?aleph+ 0
This one's just a lame joke.
---
Clearly the internals are the same as any other language, so what makes Eidola revolutionary is its representation (or independence thereof).
And they have ZERO examples of any good Eidola code! Maybe some white knight will step in and write some good representation engines for them?
Have they thought this through even once??? Uh, Eidola guys, you might want to spend a few more days thinking before calling for help. On damn near every page on your web site...
I agree; text is a horrible mechanism for representing semantic concepts. Look at English, for example, I can't remember the last time I saw anything that conveyed high-level ideas in English. oh wait... I forgot about that whole 'literature' thing....
--Jered
Er, you'd think than the hardware engineers would have stumbled across this idea, considering it's they're job to put little IC's together. Oh, wait, I bet they did....
The primitive objects should just be sensors and effectors which can be connected together into higher level objects.
How does this work, exactly? How do I set up some sensor so that it knows what to look for if you won't allow me any sort of programming language? You can't expect people to build a mountain of objects -- without being able to configure any of them -- just so they can tell when someone has finally given up on the system starting and hit ^C.
Just drop them in and they find the right connections, automatically and reliably.
Of course, this sort of automatic programming has never worked. And even if it did work you'd never be able to prove it, because all of the vast resources computer science has devoted to proving program correctness assume that you have some idea of what the program is actually doing, and that you can translate it into a logical (that is, linguistic) framework.
Programming for the masses!!
Oh, great. I hope that isn't supposed to win over any converts. The "masses" have never been terribly enthusiastic about programming, and most of those who are, can't.
There are other non textual programming abstractions out there. The Mozart project is one, but there are others such as Microsoft's own Intentional Programming. You can find other related links from the Mozart page.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Proposed definition of infinity:
I call "infinite" the solution of: x * 0 = 1.
This definition takes my brain about 1/2 second to process.
Historically, much of the mathematics have been built by defining something as the result of an equation with no result. For instance, x*x=-1 yields the complex numbers, x*x=2 yields the non-rational numbers, etc.
-- Did you try Tao3D? http://tao3d.sourceforge.net
1/ Words such as "absurd" and "existance" or "doesn't work" do not have much place in my own understanding of mathematics.
2/ The proof you gave, at best, proves that the 'x' solution of the above is not a natural number. The exact same reasoning you gave proves that there is no solution to x+1 = 0. Do you deny the "existence" (whatever meaning you give to that) of the number -1?
3/ You use a recursive proof which you claim as being invalid in some other posts. This is internal inconsistency. While this has no mathematical value whatsoever, this puts in my "brain" a serious doubt regarding the rest of your "reasoning."
So you say that infinity has no place in your own mathematics. Fine. Then, you are using the word "mathematics" in a sense which is not the sense I use myself.
To me, mathematics is a methodology for reasoning derived originally from idealized physical entities (such as square, lines, etc), but which has since then been formalized using logic, axioms and formal derivation. This formalism is useful because it has been shown by historical experience that it helps us "discover" and "model" physical properties.
Complex numbers are a very good example. The original "existence" of complex numbers is the observation that you can build a set of consistent rules with numbers built using the "imaginary" solution of x * x + 1 = 0. Even better, the resulting rules are quite close to those that we have previously defined for "natural" numbers.
But the most interesting thing about complex numbers is that they turn out to be a very good way to describe, for instance, electromagnetic fields or wave equations. And the circle is complete, we are back to "real" things. The same thing happens to infinity. A physicist will use an infinite line as the model because it works well, regardless of the existence of any such line in "the real world." Remind me of the old joke about the physicist asked to model a horse race, and who starts with "let's assume a spherical horse." That's really all there is.
So mathematics, in my opinion, do not work because of their abstract beauty or whatever. They work because they allow us to make predictions for what we call the "real" world.
As a last comment, the use you make of "absurd" or "beauty" makes *you* behave as a religious zealot who owns The Only Real Trush of The Saint Intuitionism. And, frankly, I don't see why the fact that Cantor was Jewish has anything to do with the quality of his maths. Oh, or maybe it is because 42 is the answer?
-- Did you try Tao3D? http://tao3d.sourceforge.net
At the very least it seems pretty early on. It seems to be in theory almost entirely. Without code examples (how would they be represented?) its very dificult to fully comprehend. Or maybe Im just too used to coding in the traditional way. This could be the biggest leap since Java (or assembler or C etc) or nothing but theory.
"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."
The trouble with this whole concept is really simple and has nothing to do with computers, but with problem solving in general: people DON'T know what they want! You're asking for a DWIM machine. You may as well forget about it cause it ain't gonna happen.
This is a result of something deeper, in part. There's no canonical solution to even a rigorously defined problem. Solutions vary and so will their bytecode or other mathematical representation. Your mileage will vary.
There's not a lot new here, and an awful lot of rubbish. Lets look at the differences page...
/runtime/, which indicates a duff type system.
"Traditional programming languages are heavily tied to their representation as textual source code", well, no, they are heavily tied to their syntax representation as a context-free language, usually one that has to be LALR(1). The syntax of the language is ultimately represented by a tree. If you don't like the usual textual representation of that tree, why not make a utility that manipulates the structure output by the compiler's parser directly? (Because the tree is fiddly to build, which is why we don't do that). LISP or Scheme have a syntax that show the tree structure of the language very explicitly.
A text file can represent anything that can be stored in a computer (a sequence of numbers seperated by spaces is all that's required). Admittedly that's not terribly easy to manipulate; if it were we'd all be very happy with writing machine code with no assembler. So we try to invent computer languages that better represent how we use natural language, because we are very good at using natural languages (what we got was things like COBOL). Mathematicians are very good at using mathematical languages, so we also got languages like ML. Engineers gave us FORTRAN (probably because they hate us). Computer Scientists noticed early on that higher-level languages were well represented by trees and lists, and gave us LISP and Scheme (and lots of parentheses)
They say that the other two of the general differences exist in one of C++ or Java. Um, so they're nothing new, then.
"Explicit member inheritance". Hmm, would it really be helpful to be able to inherit a function from a superclass but not the member variables it uses? I can't find any reference to what they mean by a signature, though context would indicate that they mean declaration here, though that still makes no sense... In the languages I have used that have 'signatures', they are pure type definitions. Usually these languages also have type inference, so the compiler can spot an error in your code by ensuring that it matches the type, but this definition seems to be too strict for their usage of the word. Last time I wrote Java, it did not have these, and doesn't do type inference anyhow so it doesn't need them anyhow. (C's extern declaration does have some of these properties, though)
I can't see through the bollockon field on the Multiple Inheritance thing. Are they talking about aggregation here?
"Virtual members". Hmm, that's just overloading the new operator. Operator overloading is all yuck anyway from a type analysis point of view, which is why they have to generate type errors at
"Signature specialization". This is a problem that polymorhphism addresses much more neatly, with compile-time type checking too. C++'s templates does a sort-of impression of this, but a language like ML does it better.
- fun append a b = b::a;
> val 'a append = fn : 'a list -> 'a -> 'a list
- append [ "Hmm" ];
> val it = fn : string -> string list
- val newappend = it;
> val newappend = fn : string -> string list
- newappend "Blah";
> val it = ["Blah", "Hmm"] : string list
- newappend 1;
! Toplevel input:
! newappend 1;
! ^
! Type clash: expression of type
! int
! cannot have type
! string
"Multiple function outputs". Hmm...
- fun whoo (x, y) = (x+1, y*3);
> val whoo = fn : int * int -> int * int
- whoo (1, 2);
> val it = (2, 6) : int * int
They're talking about tuples here. C people call these mysterious things structs.
"Parameter names in signatures". Uhm... They didn't explain themselves very well here... Why? Parameter names only matter inside a function definition. Outside the types are all that matter, as you have to be able to pass the parameters.
Andrew.
The APL design goals were the same as the those listed for Eidola.
I wrote an APL system to keep track of my LP collection back in the 1980's - one line was all it took.
But APL code tends to be "write-only" code - if Eidola is easier to read, maybe it will become something big.
-- From Denmark
> It's all been tried before and it never works because programming is not maths.
Actually all computer science (with the possible subset of computer architecture, which is engineering) is applied mathematics, including the subset of programming.
Wasn't it Don Knuth that compared writing a computer program using a specific language to proving a mathematical theorem using a specific set of axioms?
Eventually programming comes down to boolean operations and base two arithmetic. Sounds like math to me.
"I'm an old-fashioned type of guy. I worship the Sun and Moon as gods. And fear them."
What do you consider "visual"?
One of the Java demos has an interactive sorter that performs Quicksort.
CLR or Knuth Vol 3. tell you on paper what a quicksort algorithm is. I have to read the paper to "visualize" that algorithm.
How about a flowchart?
"I'm an old-fashioned type of guy. I worship the Sun and Moon as gods. And fear them."
I don't think an obfuscated eidola constest would be challenging enough. How about an UNobfuscated APL contest? Now that would be something!
Yeah, but that would make those inductive proofs really hard ;-)
But seriously: There is no way to design a language for a Turing machine (or any real machine of your choice) that would allow the set of programs have a cardinality other than \Aleph_0. Think about it, it's quite easy. And besides, I don't see what you would gain with that.
EagerEyes.org: Visualization and Visual Communication
I think it could be graphically oriented and at the same time doesn't have to be. I think that is what they mean when they talk about filters. You can view how you want to view it. Say you view it in an UML type way, then you use a UML filter, and if you want to view it with text, you'd use a text filter.
There is something I would like to point out. IT DOESN'T COMPILE. From what I have read, it is an interpreted language. You need what they are calling the kernel to run it. I am assuming that this is their version of a virtual machine.
This leads me to another feature. They are writing it in JAVA! I understand the "coolness" and "cross platform" abilities you get by writing in something in Java, but do we really want to write an interpreted language using an interpreted language? I don't think so. I would think it would be better to write it in C,C++,Pascal,Fortran, et. al.. This would be the equivilant writing a c/c++ interpreter in the old interpreted basic in which you had to be in basic to run the code. Does this make sense to anyone?
Don't get me wrong. I like the idea, I disagree with how they are doing it. I would write it in another language taking time to design it so that the platform dependant sections are together to make porting easy. I would also write it so that you could either run the code in the kernel or compile down to a native binary and run the code independant of the kernel/virtual machine. I would probably have done a proof of concept in python, or another scripting language, to get peoples appetite wet for the project and allow for people to be creating code.
I think this has potential. So far, I don't like where this is going. I am sure somebody will come up with a similar methodology that with the benefits I want, but the question is when.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
I would have to disagree to a point. The idea is ok, but the implementation is bad. This is just another interpreted language instead of a virtual machine (like java uses) you have a kernel.
I would also miss the use of pointers and references. They can save on memory and space instead of requiring the copies to be made. Althought the could implement it so this is not a problem.
I like the idea. It would open up new avenues in developement. I don't like the idea of forcing OOP as much as they do. I think a good tool set would allow for adaptions of better designs as they come along (like C++ does). Java is pretty much stuct in OOP model because of its rigid focus on OOP. It appears this is where they want this to go.
I also don't like the idea that the code doesn't appear to compile down to a binary. I would like an enviornment like for development, but I would want the final product to have the option of creating a binary that would run faster then when you use the kernel to run it.
Scripting languages are great--as we all should know, but do we want to go back to an interpreted language format. The kernel idea reminds me of the old basic days when basic was only interpreted.
Overall, I think this is a good start, but I thik they need to reconsider the design a little. There is a big potential when removing "dangerous" stuff like pointers for more programmers to not bother learning what is going on and to think things through. This again reminds me of my childhood, and programming in basic.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
Well, like many others, I poured over this site for some information on how this whizz-bang magic of freeing ourselves from text files is supposed to work. The excessive flurry of barely-defined buzzwords sorta makes me want to shy away from it, too. After reading everything, I can come to no conclusion about anything, save that if this ever gets finished, it would probably not be useful for much more than rapid prototyping (did I read that right, a *java* compiler?!) and the like.
"In short, Eidola is a programming language which separates a program's structure from how that structure is presented."
Maybe I'm too locked into the square, obsolete, "old-school" world of text files, but I can't for the life of me figure out what the hell that's supposed to mean.
Maybe I'm just old-fashioned, but this really seems like a drastic new approach for the sake of a drastic new approach. Maybe it'll pan out and be of value to people and projects, but I'm not holding my breath. In any case, it can't hurt to try.
Well, if I'm not mistaken, they aren't just talking about graphical objects with textual code behind it. If they are, jesus, hasn't that already been done a million billion zillion times? Visual Basic is by no stretch of the imagination "representation-indepedent," at least, I don't think it is, but then again they never really went into much detail that I could understand (and I'm usually pretty skilled at reading technical journal type material) about what that means, anyway.
In the words of Pete Venkman, pretend for a second that I don't know anything about programming, data modeling or system architecture, and just tell me what the hell is going on.
"You never studied..."
3. Runtime Semantics
This section descibes the execution of an Eidola program. The extent to which this is actually formalizable remains to be seen, and Lord, we've got a ways to go before we get there.
So they can't define how a program executes? The most important part of the specification ("what happens when I run my program") is left completely undefined! That's scary!
It's also interesting that they haven't even finished the language yet (1.9 Scoping rules - TBD). Maybe it will be more worthwhile when it is done.
The creator of this language asserts that text is on the wrong medium for communicating program meaning. He implies that Eidola will enable a visual approach to describing programs.
Why the hell isn't he looking at UML?
I put that forward as a comparison, because a *lot* of people have spent time and energy developing the semantics of UML models, and they are beginning to offer a reasonably complete toolkit for describing programs and program behavior. And because UML is a language, it certainly does not dictate how you represent programs or how you use UML: it provides an existensive "vocabulary" for communication, and all it argues for is consistency of use.
Can someone send this guy a book on UML? Amazon ships up to Canada, doesn't it?
Oh, but HA! I was not debating the correctness of the poster's grammar, but the content of his signature file!
;)
Obviously, "our friend" IS aying that sneakermail and spam filters hold the same worth, but I don't believe that is what the poster intended
*reclaims victoriousness*
An ounce of prevention is worth a pound of cure...
I think you need to reconsider your sig
Looking at the FAQ it claims that the big difference from other PLs is:
"a clean separation between the substance and the appearance of a program"
This does not seem so different from any other graphics-oriented language. According to the docs, it seems not so much that this is a new idea, but rather an attempt at a more robust implementation accomplished by allowing the language to be represented visually.
There are a couple key difficulties in such an approach: a) how do you compare (i.e. diff) two graphic programs? You must rely on its binary form, and hope its equivalent even if you move a component over 5 pixels; b) programs must be kept small due to complex relationships obscuring parts of the code; c) no matter how revolutionary you get, you still must be able to form logic gates, and so it all boils down to a text-version.
If this is anything like labview from Nationial Instruments, it could be pretty cool. I did a ton of work with labview while programming some data aquisition projects. You draw a box for loops, all data runs in pipelines, you create input output connections for your custom components (i.e. functions). It's fun : ) If it was open source I'd still be using it.
One thing I've thought of is that the visual input/output model might match input and output pipes in unix.
-Jeff
there have any use at all in the "real" world -- but they are valuable
because they prove concepts and explore territory otherwise unknown.
Example : Not too many people program in smalltalk, but quite a few can do
object orientated stuff -- which smalltalk played an important role in developing.
This thing will probably not be used on next time you're doing some ASP work, but there's a good chance that will clear the way for some cool language that'll be around 5-10 years from now.
willis/
there is no thing
what else could you want?
There's not much philosophical difference between Eidola and the Action Semantics addition to UML due to be finalized next month.
I never said that *all* code belongs in tables. Only that tables can suppliment code-based programming.
At least tables work for me.
Perhaps it is all subjective, and if Dingleberry-Oriented-Programming makes programmer X more productive, then let him do his/her stuff.
Software engineering is about modeling the developer's mind as much as it is about modeling the real world. Is there a third alternative?
Table-ized A.I.
>> Of course LISP can do objects (CLOS) and tables (alists, or Scheme vectors) too. <<
I have found that tables can do lists and objects. And, objects can do lists and tables.
Everything is everything.
I just like tables. I look at other things, but keep coming back to tables. Some say that the "acceptance curve" is U-shaped for some paradigms--thus you have to submerse yourself in it for 5-years or so to "get it". I am not sure I fully buy that. It if takes 5 years to click, then something is wrong.
If I watch french films for 5 years, will they finally "click"?
Same for Jerry Lewis?
Table-ized A.I.
The first thing I thought of was old Star Trek episodes where they met aliens who were composed of 'pure energy'.
IIRC, Russell & Whitehead had it that the lowest level of 'anything' was a "set" which was "a carefully defined logical abstraction".
Others may (hell, others DID) differ.
It took many pages to arrive at unity & many more to arrive at "mathematical abstractions" such as addition.
Reading the Eidola pages, this is a project more in the spirit of studying formal languages, and more focused on 'semantics' as opposed to 'notation'. Thus the absence of a "Hello Dolly" program.
I seem to recall that Turing spent a number of years on the sematics & logical design of ACE, & the damn thing was never even built.
Is it OK to use the 1.3 runtime instead of 1.2 like their site recommends?
Free music from Jack Merlot.
Supposing that exists some code parser which reads code files and stores them in databaser, this looks to me as an interesting idea.
Ciao
----
FB
...Visual Basic! :)
Last night I shot an elephant in my pajamas. How he got in my pajamas I'll never know.
I think every language has fundamentals that can be represented by many notations. But there's never a way of communicating these fundamentals without using notation(s).
So, they (kind of) have a new language, and they have a notation. Big deal.
I'd find multiple representations (including non-text representations) for any usable language, new or old, a lot more interesting.
Like to see you try!
Old COBOL programmers never die. They just code in C.
The three langauges I use regularly are:- C, perl and Java. Plus I do like rexx, python and tcl.
The thing all these languages have in common is that they were written by experienced programmers who wanted a new langauge because they couldn't do what they wanted to do with the existing languages.
While both python and tcl were developed at academic institustions, the languages were not part of a research project they were developed to aid other research projects. ie they were written to get things done!
Its easier to do things in languages that were written to get things done!
Old COBOL programmers never die. They just code in C.
OK. So I wus abel to find it spelt booth weys on the internat.
"You saved 1968." - Ms. Valerie Pringle to the crew of Apollo 8
In both Java and C++, the signature of a member in a subclass must be identical to the signature in the superclass. Eidola allows a subclass to specialize types when it overrides a member. For example, if StringList extends List, then StringList.add(String item) can legally override List.add(Object item)
Ahh, but this is exactly what inheritance and overloading are for. if List defines add(Object) then StringList can declare a add(Object) to be private and a publc add(String).
This is just one example of their poor C++ complaints in the page.
"You saved 1968." - Ms. Valerie Pringle to the crew of Apollo 8
To me this sounds like a fabulous idea, though it's obviously not yet developed to the point of being practical for day-to-day use. And I don't think the benefits are limited to having multiple represntations of the language.
Large software systems get very hard to manipulate and understand. It becomes particularly hard to answer questions about the code. For example, given 10,000 lines of C++, do the following:
To do any of the above, you would first need to parse the code to discover its semantics and represent them in a way that you could examine in detail with a program. Writing even a simple parser is a little difficult. Parsing C++ correctly is very difficult.
Being able to directly access the true semantics of a program would make solving these kinds of problems feasible. I'm sure we can all imagine other fun things it would enable as well.
CVS is teh suck. Use Vesta instead.
have being around for years. In fact CASE tools are graphical representation of a program where diagrams are used to define logic: conditions, loops, assignments, objects, procedures, data structures etc. I thought it Eidola was about mathematics rather than graphical presentation but then I remembered Fortran....
You can't handle the truth.
This is worse than TopMind's "All code is tables" diatribe that was highlighted on /. last month. At least TM provided specific complaints and possible solutions. This "new paradigm" is all fluff and no substance.
Yes, all programming languages suck. We agree. Programming is hard: it is conversion of pure ideas into concrete reality. Now show us why your system is better. What does it solve? Why should we use it? How does it help us see the deep meaning in other peoples' code?
This is a huge area of research that has been active for at least the past 15 years. See A Theory of Objects for a taste.
Ha! So many people were fooled by Cantor and his absurd theories of infinity, which have no mathematical foundation. Infinity (especially Cantor's heirarchy of infinities) is NOT a mathematical concept, and until you understand that, you do not truely understand mathematics.
It is impossible for you to conjure up "infinity" in your mind, because that would take forever. Things that you can conjure up in your mind: a finite list of natural numbers and certain aspects thereof.
The concepts of aleph null and aleph one are silly dreams of a religious mathematician. So religious in fact, that he let religion pollute his mathematics.
The concept of doing anything which is infinite is completely absurd!
Next time an "infinite set" is used by someone, maybe your proff, ask that person what an infinite set really is. Heh, something which you claims exists, yet it cannot even be created, it cannot even exist by its own definition.
The concept of graphical/visual programming languages is not new, and anyone who claims that it is similar to certain LISP projects are most likely correct, because the Lambda-Calculus has had graphical representations long before LISP was created.
Graphical/Visual programming languages have been a hot area of research for the past 20 years, at least. However, this current approach seems a bit naïve. With any language, you will have representations. To say that a language is representation independent is a paradoxical statement at best. Whether your language represents meaning with three-dimensional graphics, or it represents it with a symbol-string based method, you will still have the same restrictions that all languages share. One of the benefits to generalized graphical languages is that your code can contain far more self-documentation, without the use of additional comments. In a language like the C programming language, self-documenting techniques consist of a few basic constructs like descriptive identifier names (variable names, function names, etc...) and a healthy use of white space (carriage returns and tabs for code blocking, etc...). In fact, it is often considered a bad programming practice to not use a good amount of self-documentation in C. So why not take self-documenting code a step or two further?
Well, just imagine a generalized version of "white space" for a programming language like C from something, which controls a very rigid 2D orientation to a generalized Cartesian 3-space, and you start moving towards a graphical/visual programming language. Generalize the concept of "identifier" from just a plain string of text to a full color 3D graphical object.
There are other more fundamental differences that most visual programming languages have over this simple generalization of the C programming language to a Graphical C., and those fundamental differences deal with the representation of computation. They could choose a von Neumann model, a functional model (lambda-calculus), a mobile model (pi-calculus), or maybe a constructive logic, etc... all of which are popular (read widely used) mathematical models of computation.
So, besides cramming a bunch of buzz words into their language description, and coming close to stating a complete paradox... I don't know why this is supposed to be so exciting.
Don't get me wrong, I love alternative programming languages, such as PICT (based on the pi-calculus) and Haskell (based on pure lazily evaluated lambda-calculus), and whenever a new post is made about a language attempt like Eidola, I laugh and I cry - asking myself, "Why doesn't slashdot ever post news about serious alternative programming languages?"
An algorithm is not necessarily a language dependent concept. In fact, mathematical intuitionists would claim that algorithms exist independently of language, as do all mathematical concepts.
Ahhh!!! Good recommendation, but the more recent theory can be found here (CSP is "so last week"): Calculi for Mobile Processes
For those who were lied to in school: Foundations of Mathematics?
For those who were lied to in school: Foundations of Mathematics? (preview is still screwy)
I hate ignorance. Listen, I am not trolling, please trust me.
The concept used in "The Matrix" the movie is not new or original, but it makes a good point. Its based around solipsism - the realization that you cannot know anything outside of your mind. With a little contemplation, you can see that you accept the theories of science on faith alone. Physics is just man's use of his mental concepts (mathematical concepts) to describe the world. If infinity is not mathematical, then the claim that its use in physics justifies it is naive at best.
Stop. Think. How do you know? Ask yourself that. Ask yourself, "What is the foundation of mathematics?" Many men have, and could not answer. Some chose faith, while others choose to understand, to know.
If you are confused, then let me help you, since your schools could not:
Constructive Mathematics
Intuitionism
From Brouwer to Hilbert : The Debate on the Foundations of Mathematics in the 1920s
Trust me, you are confused. Many people are. They have accepted mathematics on faith alone, but you do not have to. The way to understand is easy! I highly recommend checking out/buying the book From Brouwer to Hilbert to truely understand what Intuitionism is. The book consists of a series of papers which carried on a drawn out arguement about the foundations of mathematics. These weren't joe blows arguing. These are arguements of legendary mathematicians, so there is some serious insight in their work that I cannot give you. Finally, the papers in that book are strung together through use narrative of the editors. Its a great buy and you will not regret it.
Now, when you are done checking out all of those links and the book, if you really want to know more, then check out "Brouwer's Collected Works". Its a two volume set. The books are big and out of print, so ask your library. Its worth it.
Don't be so naive. If the foundations for mathematics are not chosen correctly, then you do not end up with the require properties of math: certainty, free from paradox, completeness, and decidable.
See, you build your foundations on mist, air, nothing... for what is an axiom? What is an inference rule? Do you have the required attributes of mathematics? You use these things as your foundations, but there use is not math (certainly free from paradox and completely decidable).
Here is a story for you, about an educated man that existed a long time ago, when civilzations were just begining to form. He knew how to read and write, among many other things that the masses didn't know. People of the small village that he went to starting trusting him, because his teachings, his wisdom worked as promised.
Then, shortly after the educated man's arrival, the previous village leader took a stand out in the center of the village, fearing that he was losing control of the people - this educated man was becoming more popular. A croud formed around the original leader, who has the educated man at his side. The original leader spoke out to the croud, "If this man is so great, then let him write a snake in the dirt on the ground." The educated man then proceeded to spell out the word "snake" in the written language (cuniform or an ancient arabic language). The original village leader then laughed, as right next to the educated man's "snake" writing, the village leader drew a long squiggly line - a picture of a snake. He then said, "...and who succeeded in writing a snake in the dirt?" The croud then turned on the educated man, being illiterate, they couldn't grasp the concept of a written language based on a small alphabet and grammar. The couldn't see through their ignorance. They could no longer see the value of the educated man's teachings.
Ok, now let me disprove your supposed foundations with a reduction to absurdity.
System Gamma AXIOM OMEGA: A is true AXIOM ALPHA: if A then B is true AXIOM BETA: if B then C is true AXIOM DELTA: if C then A is false
So a proof in this system could go:
OMEGA and ALPHA imply B, which implies C, which implies not A which contradicts OMEGA
What did I do, 3am? I used your arguement against you. I used your misunderstanding of Godel's incompleteness proofs against you. Godel proved that a formalist method, as you describe, is incomplete, and therefore the consistancy of a formal system based on axioms, cannot always be verified to be free from such contradictions. Sure, in my case, you can see that a contradiction arises from the axioms, but in general mathematical systems, a proof of consistancy is impossible! Your system could be as valuable as pure garbage, pure nonsense.
So, join the croud of the illiterate. Denounce those who bring you the truth, simply because you are too ignorant to see the error of your ways.
My point is I am not telling you how to truely understand infinity, because that is impossible. Infinity cannot exist in a mathematics which is not based on faith.
I do not care when people use infinity, but I do care when they claim that it absolutely exists, in a mathematical sense. Just because Plato and Cator and other injected religion into mathematics, doesn't mean that we have to use such broken uncertain foundations.
Mathematics is the only thing which is not based on faith and is therefore an achor in a see of uncertainty.
Now, as I eat my breakfast, I do so, mainly with faith alone. Its a damn good thing that I don't try to completely mathematically understand "eating breakfast", because such a thing is impossible... I would die from lack of nutrition.
Yeah, I disagree with the status quo, the popular misconceptions of mathematics, and I am a troll, with posts that should be modded down? Have you ever considered that not only that you could be wrong, but an entire institution that you had faith in was also wrong? If your mathematics is so pure, so great, then why does it contain paradoxes, contradictions, undecidability and incompleteness? These things make your mathematics anything but exact, sure, true, or anything that it is supposed to be. It becomes nothing more than a religion.
After you mod my posts down, don't forget to mod down the entries of the Encyclopædia Britannica on Intuitionism.
Oh, and don't forget to mark one of the greatest founding fathers of modern computing as a troll too, because Kleene was also backed intuitionist ideas.
Some of you guys are so blind in your ignorance that you destroy good things - all the while, believing that you are fighting for the just.
Godel proved that general mathematics cannot be verified to be free from paradox, inconsistancies, etc...
Bertrand Russell, among many other mathematicians have discovered the existance of paradoxes and inconsistancies in various mathematical systems. Note, as Godel has proved, even if we don't currently know of the existance of any of these paradoxes, we cannot be sure that they do not exist. Huge parts of mathematics could easily turn out to be bunk, simply because, overall, there are paradoxes or inconsistancies in the mathematical system. I realize that you have faith that such inconsistancies don't exist, but mathematics isn't a religion.
In addition, Church and Turing showed how certain parts of formalist "mathematics" are undecidable.
Now, you can continue to disagree with me, but history has shown that the formalist system which you describe mathematics to be, is nothing more than a faith based phantasy.
"Have you ever had a dream, 3am, that you were so sure was real"
"Some can never be free from the Matrix."
I disagree. I recently read through Milner's new book on the pi-calculus, which is very readable. You don't need to know anything about the CSP or CCS. The pi-calculi and cousins are far more generalized in the aspect of concurrency, than CSP or CCS. I suggest Milner's new book. Its short and to the point. From that book, you can branch out into reading all of the papers listed at the Mobile Calculi link I gave in the above comment.
I am placing my bets on the Ambient Calculi and family, as the canonical mobile/concurrent calculi. Need some proof? Check out Girard's recent Linear Logic and Ludics, and be reminded of the lambda-calculus/Intuitionistic Logic isomorphism. Its happening all over again, except this time, we are dealing with completely concurrent computation, as opposed to completely sequential.
Do you see a pattern?
First of all, Brouwer's Intuitionism and Intuitionistic Logic are two different, but related things. You seem to not be aware of the difference. Most likely because you haven't read Brouwer's original papers or lecture notes. Here goes a little history for you, since whereever you got your education from neglected to make you read the works of those "better minds" that you speak of.
During the end of the 19th century, Cantor polluted popular mathematics with his Jewish tendencies and beliefs about infinity. Another popular mathematician of Cantor's time objected to the transfinite crap of Cantor. This man's name was Leopold Kronecker. Of course, those times consisted of people mainly like you, so they laughed Kronecker out of public influence.
A little while later, Bertrand Russell and others started discovering paradoxes in popular mathematics. This was a problem, because a little digging showed that mathematics was without a sound foundation, which we could use to fend of fear of paradox and other errors of a mathematical system. Anyway, Russell preached formal logic as a foundation of mathematics and Hilbert preached a more general formalist foundation of mathematics.
Around the same time, a mathematician named L.E.J. Brouwer objected to both foundations proposed by Russell and Hilbert, pointing out that those foundations required metaphysical claims, faith, uncertainty, etc... The foundations also had demonstratable inconsistancies, which Brouwer showed. (go read his original works or translations if you don't believe me). Brouwer wasn't correct because I believe what he said. No, it just plain makes sense to anyone with enough independent thought to check out/interlibrary loan originals.
Brouwer went on to denounce logic and all other formal mathematical systems, claiming that logic "is an interesting but irrelevant and sterile exercise." Yeah, 3am, really sounds like Intuitionism is a variant of logic. Whatever led you to believe so is misleading and incorrect. However, back to your history lesson...
Ok, so Hilbert and Russell's foundations are shown to be flawed, mainly by: Church, Turing, Godel. Don't believe me? Great. I don't want you to, I can only show you the door. You must walk through it. How? By reading the originals!!! Most popular books/professors on Intuitionism, Godel's Incompleteness theorems, Church and Turing's undecidability proofs - misrepresent what the original "better minds" have shown us Why would they misrepresent the truth?
Time passes and history shows that Brouwer's Intuitionism works and is not flawed, but it has one drawback, best described by Hermann Weyl:
What Weyl describes is the frustration that arises with Intuitionism, because it does not allow for formal synbol manipulations in proofs, as does popular mathematics. Classical and intuitionistic logics use symbols with axioms and inference rules, in order to formally derive proofs. Brouwer's Intuitionism does NOT claim that such things are mathematics, so their use is limited to documentation and communication, not derivation.
Now, the intuitionistic logic that you speak of, is not Brouwer's Intuitionism, and it was never directly approved of by Brouwer (though he was tolerant of it and grew more appreciative of it as he aged). However, it was his student, Arend Heyting, who formalized a logic which is not contradictory to Intuitionism. Gentzen, another famous logician, also contributed to the intuitionistic logic that you refer to, but I will leave the details of your history education up to you. Libraries will help you for free. You just have to ask.
Now, just to give you another modern example pointing out your ignorance, think about this quote (in relation to your comments) about intuitionism, from another "better mind than yours":
Now, 3am, don't you feel like the ignorant one? Don't you feel like your education has mislead you? If not, then read the original works of the "better mind than yours", and you will feel like your education has mislead you. Hopefully you are not so blind as to pull yourself from your ignorance.
Finally, note that my use of the word infinity is as used by Cantor, which is the common interpretation of the word. Boundless and no upper bound are different from infinity (and its not just me making this up, the "better minds" seem to agree too). Infinity implies a definite concrete existance of something which is "infinite" (yeah, a recursive definition, but I can't think of a better way to describe such nonsense without recursion). "Without bound" and "boundless" refer to something that can be repeated or continued as long as desired, but the use doesn't necessarily mean that the repetition goes on "forever". It literally means, as extreme as you want, but still finite. A variable without bound could never be "infinite", but it could be as big as you want to make it. So, as you should see, infinite is something which exists (supposedly), while something without bound is something which can be chosen as artbitrarily large/small/etc as you want. Subtle but important difference to mathematicians.
Tell me, who is confused? It appears that you have not even read the original papers and works of Hilbert, Brouwer, Heyting, Kleene, etc...
Do so, and you might save yourself from ignorance.
Infinity should also not be considered a mathematical construct, as it cannot be based on anything besides faith. Sure, infinity is needed, just as is love, god, etc... but these things are not mathematical.
Formalist mathematics relies on the belief that the symbols written on a piece of paper and the finite set of inference rules and axioms can be used to derive truth by applying such rules. This belief cannot be be justified without an appeal to faith or metaphysics (read Arend Heyting's "Introduction to Intuitionism" book for a full explanation).
Infinity might be needed, as a concept, same as many concepts like God, but you can no more claim the existance of God than you can claim the existance of infinity - without the use of faith.
Now, as far as us imagining infinity, you are correct that the way that we imagine infinity is similar to how we imagine tooth fairies. Tooth fairies are mental constructions, not basic core, inherently a piori concepts. Tooth fairies are in a sense, phantasy. Now, the natural numbers 1,2,3,4,5,... (use a different name, symbols, its the same concept) are a different kind of mental construction than infinities and tooth fairies. The natural numbers can directly be built from our intuition of time. We all have an inherent a priori base construct to our thinking, which we cannot escape from: the present is different and comes after the past. This Present soon becomes part of the past, as the next present is experienced (in the most direct form of experience). This a priori understanding is called the natural numbers by some people. Now, other people believe the natural numbers to be something akin to a form of Plato's ideal realm, but that is religious, not mathematical.
I realize that I am just a geek with a poor ability to communicate what I mean, but I hope you see how our mind/self/conciousness/brain/whatever-you-call-it has a direct and a priori understanding of the natural numbers. We are only taught names for them, among other formalized rules for the natural numbers. When we are young, before we "can count", we still have an a priori understanding of the natural numbers... we just don't know how to communicate that understanding. Its kind of like going to another country, where they speak a completely different language than us... we could say "one", "two", "three", etc... when asked to count, but we will not be communicating our understanding well enough to let the witnesses understand.
True mathematics, the mathematics which is certain, complete, decidable, and free from contradction is the mathematics which is based on this a priori understanding (Brouwer uses the word intuition) of time - our natural numbers.
Note that by understanding of time, I am not refering to anything about physics or relativity or anything outside of the self. I simply mean how we are fundamentally aware (in pure thought), of thought that comes now and thought that came before. Its because of this squential intuition, that we precieve the world outside of us, as also flowing through time. Now, some interesting philosophical discussion can proceed on time not actually existing outside of us - in reality as part of, say, physics. Einstein's theories make good arguements for such... but I don't wanna go there and I will just admit that with regards to the outside world/physical reality... I don't know.
Finally, my point is that while a large part of popular mathematics can be created from our intuition of natural numbers, a similar concrete, undeniable intuition does not exist for the creation of infinity.
"Infinity", while defined better than, say, a "tooth fairy", is still more phantasy than mathematics.
I erge you guys to check out the original works of L.E.J. Brouwer for more insight on these topics. You won't regret it. Oh, and be careful of the many different interpretations of "intuition". Some uses mean "ways of knowing which are completely fuzzy or ambiguous". I use it, as Brouwer did, to refer to an undeniable (you can't deny it to yourself) a priori knowledge possessed by our minds, which to yourself individually, is so immediate that it doesn't need explanation or justification. It is absolute!
On that above quote of yours, I couldn't agree more! Its sad though, that others cannot see the truth. Whoever it was that said that "science is the religion of the day" (I think that it was someone in this thread), I am in great debt towards. I am going to use that quote, a plenty.
The set of all dead presidents surely doesn't exist as a mathematical concept, and neither does the set of "all" natural numbers. I can't create the entire set, so how could the concept exist in a mathematical sense? It can exist through phantasy and faith, which is erroneously implied by many a mathematician to mathematics. This is what I refer to as the pollution of mathematics. It doesn't negate nor does it verify. However, religion and faith have no business in mathematics. Its a dangerous mix. It sends many mathematicians astray into uncertainty.
Finally, someone who realizes that I am not trolling. Sheesh! However, there is a small misconception about my points about mathematics (try to checkout the stuff that I have been linking too, especially the book "From Brouwer to Hilbert")... mathematics is the one thing that doesn't have to be taken on faith. It is the only thing that you can know directly and exactly, because it is constructively built from ideas which are based on our a priori intuition of the continuum (our intuition of time). So, my point is that mathematics is absolutely true and real, but only to the mathematician. Math doesn't exist outside of us. Without people, math does not exist. Mathematics are concrete ideas, which are exact, free from paradox, etc... I know they exist in my mind because I directly experience them, but the claim that they exist outside of the mind, independent of it... that is a religious claim. Because of this, it can be seen that mathematics is only used to understand our world - this is what science does, its the use of our concrete ideas to describe the world outside of us, but the world does not necessarily obey mathematical rules or laws.
Finally, if you cannot directly create a concept, constructively, from the a priori intuition, then the concept is not mathematical... its fantasy or confusion or something else. Mathematics is this way because otherwise, it would be full of paradoxes, contradictions, uncertainty, etc...
Notice how the popular understanding of and use of and foundations of mathematics are full of paradoxes, contradictions, uncertainty, etc...? Its because the popular foundations for mathematics are faith based.
Ok, and this historical practice somehow justifies something as being mathematical. Throughout time, many people have done questionable things, and we should not use historical use as sole justification. I mean, reality used to consist of ether, according to historical account, and any number system based on absurd numbers is absurd itself.
Emphasis should be on the word "Crash".
...oh, and there has to be some way around the marking of such posts as the one I am replying to, as "Offtopic". The post is ontopic to the post that it is replying to, therefore it is not offtopic for its context.
All discussions twist and turn. Its unnatural to limit that.
"Do you think that your Wu Tang sword can defeat me?"
...
*shreek* En guard! I will let you try my Wu Tang style!
The proof of such extensions is fairly immediate, as was the one I gave. I mean, the proofs are so trivial in the first place, that the inductive proof that I gave can be easily seen as working for negative numbers. I am not going to be pull a Bertrand Russell and write a 10 page proof of formalisms for something so immediate. I made the point that the existance of such a number x such that x*0=1 is absurd - absurdity meaning that it is contradictory. Note that no real mathematician would ever knowingly claim that an absurd construct is math. The generalization of my proof to fractional numbers, negative numbers... they are trivial and nearly immediate.
I assume you are referring to my explanation of the existance of the natural numbers. I blame this on the failure of natural language. I was attempting to describing something which is a priori (having always existed), as long as I have existed. This a priori intuition (of time) is concrete, precise, undeniable, etc... it needs no justification, because no matter what name I wish to give it, no matter how hard I deny it, it always exists. Basing mathematics on something this understandable, something this exact and precise, is what gives intuitionism certainty of truth. In no sense, with regards to itself, can such a system be wrong.
Now, if you are referring to my lame attempt at an example of a formal system which turns out to be paradoxical... well, it was just supposed to be a simple example. I guess it didn't get across the point. If not, go read Godel's incompleteness papers.
For me to be a religious zealot, I would have to have claimed the basis of mathematics as that which is faith based. I did not. "Absurdity" is a commonly used comcept for contradictory constructions. My use of the word "beauty" with regards to mathematics is purely in the sense that something which is part of my Self, something which is precise, noncontradictory, certain, decidable, etc... I see these things as beautiful. If your idea of beauty is different, well then, sorry. I will claim that many mathematicians associate parsimony with beauty. Now, I would regard things which are wrong and uncertain as lacking the beauty of that which is correct and certain.
Remember, religion involves faith. I am encouraging the basis of mathematics on that which doesn't require faith. Its the faith based foundations that have been causing the problems.
Applied mathematics, which you describe is a useful thing. It helps us do stuff in order to obtain a predicted outcome. However, applied mathematics is a faith based occupation as I have already described (mainly in previous posts). Anything based on faith cannot have certainty and garrenteed freedom from contradiction, but it can have faith in such properties. Without a developed "way of knowing" which is certain as is mathematical Intuitionism, you will be lost in a sea of uncertainty. However, if your mind is like mine (in the basic sense), which I have faith in such a thing being true, then you will always have your innate intuition of time. You were born with it and you will die with it. Turn to it if you desire to construct that which is certain. Think of it as your anchor for your boat, which you are sailing through the sea of uncertainty. (use of metaphor, even if bad use, doesn't imply religious zealotry, so don't even start)
The claims of Cantor's religious tendencies influencing his "theories" are well documented. For example this book is a good starter for you.
I realize that according to the majority of religions in the world, I am sinful by requiring the use of as much non-faith based reasoning as possible. Christianity for instance preaches such stubborness as a sin.
I left out one thing. My use of "existance" means that it exists as a mathematical construct within the mind from the Self's priomordial intuition of time. This use of the word "existance" implies that for something to exist, it must be known in an undeniable and certain way. Sorry, but describing these things is difficult. I can only hope it inspires the correct thoughts in your mind. I obviously seems to be failing at that. Well, such is communication.
If you don't limit the length of the programs, then you end up with programs of unbounded size, not infinite programs. Infinity is a phantasy, not a mathematical construct.
Again, you are right, but infinity is not definable with natural numbers alone. You might say, "Well how about the set of all natural numbers?" Remember, we have an innate understanding of something which is happening, this constant shifting of our selfawareness from now to being a past memory because of the next now coming into awareness.
I would calim that the existance of myself is "true". Sure, you might just say that I am a dream or whatever, but I need no justification for my existance... its immediate. This is how mathematical intuitionism gains its "truth". Mathematics is supposed to be as immediate as your own self-awareness, because otherwise it would lose its certainty, its "truth".
Now, you could get picky and win the arguement by claiming that your mind is completely and totally different than mine. In no way are you self aware or whatever. Yeah, its a claim based on faith that your mind (selfawareness) is somehow, in the most basic way, similar to mine.
I know this is no way to win an arguement. I can only hope my horrid use of natural language will somehow inspire something in you. Anyway, if you are the least bit interested in learning why and how the popular mathematics is flawed, and you want to learn a little bit about a mathematics which is free from contradiction/paradoxes/many other problems associated with popular math, then check out the "From Hilbert to Brouwer" book that I linked to, or even better (but more expensive), is Brouwer's Intuitionism by W. P. Van Stigt
Intuitionism is the most sound mathematical system, yet it is the least known, taught, and therefore it is the most misunderstood. Its not a new thing nor is it an unproven thing.
You take the blue pill, the story ends. You wake up in your bed and you believe whatever you want to believe. You take the red pill, you stay in wonderland. And, I show you how deep the rabbit hole goes.
Actually, by definition of the philosphy of mathematical intuitionism, if you disagree and claim Platonic ideals like Cantor's infinities, you obviously don't understand. Now, if you define mathematics as a faithed based way of knowing, then we are arguing about two different things.
Happy with Cantor's infinities? Then you are stuck with a mathematics that is uncertain, inexact, full of paradoxes, contradictions, incompleteness, and undecidables. All because it is based on faith: "that which is hoped for".
With a mathematics so ambiguous, you can not be sure that you truely know what you believe you know. Your sciences, your theories, your infinities... They turn to mist as you realize that such a baseless mathematics is nothing more than confusion, when put to use as that which is obsolute/concrete.
I still recommend the "Brouwer to Hilbert" book, even if you disagree, so that you can see for yourself, the importance of at least one aspect of your understanding, not being based on faith. The book is a weekend's reading, and you can only benefit from such a solid understanding of the foundations of mathematics. Think of it as an anchor in the sea of uncertainty.
Dunno bout you, but I want to know.
I just wish that schools would cut the crap and start teaching a more open-minded mathematics program. We need to stop teaching our kids that platonic mathematics is absolutely the truth, because history has shown that it is not necessarily so with created paradoxes, undecidables, and incompleteness.
One more thing, just to help out a fellow slashdotter (or maybe I am just trying to brain wash you into agreeing with me). Since you seem to be a man more convinced by arguement of science, as opposed to an appeal to philosophy, check out this book: Where Mathematics Comes From: How the Embodied Mind Brings Mathematics into Being
The book is written by two cognitive scientists who use cognitive science to explain the origination of mathematics, as a phenomenon of our squash... *erghh I mean* brain.
Now, because of my philosophical standings (uncertainty of science), I cannot accept such arguement as a foundation for mathematics (which is supposed to be certain)... but I do enjoy the book and think that it is inspiring because it feeds our human need of scientific evidence, and I am sure that the arguement of science rings louder for you than it does me.
Supposedly the authors have insued allot of anger because of their counter-intellectual stance on biological origins of mathematics.
Random icons never quite give me the view of what the program is doing that text does. It's hard to conceptualize pipes and filters without text. Now, we want to program without it... Hrmm, how far from the damn machine language do we need to get? People seem to think that having fast machines is an excuse for writing sloppier code. I want professional programmers writing my code, who know what they are doing, and know what will happen. Just because nobody actually wants to know how to operate a computer doesn't mean that I should accomodate them. If you want to be a professional programmer, learn how to be one. I've never seen a program builder that I've liked. I'll tinker with this, but better pour some brown sugar on it.
-Gristled Young Man
Eh...
I wish there were some pictures of it.
In any case, I am surprised that no one has
mentioned LabVIEW-- a graphical programming
language that people can learn very quickly
and that can do serious work like machine vision
and motion applications as well as being
the language of choice for data acquisition
and process monitoring. LabVIEW has been around
for more than 10 years now.
Unix is hardware independant because it can be compiled for more than one piece of hardware. This does not mean that it would actually have more than one representation. As you know Windows NT is hardware independant, you just can't buy it for anything other that wintel anymore.
However, I don't know if this is what the guy means, because the lack of pictures makes it difficult for the hard of understanding (such as myself) to get a handle on what he is talking about. I wonder if this representation-independence what Microsoft is trying to do with .NET? They want an underlying runtime bytecode that can be compiled from several languages.
No.
Who is APL?
text is a very poor notation system for the concepts of a high-level language
So you are saying that English is not a high level language?
Sorry, but for those of us that read books instead of watched tv, text is crystal-clear.
love is just extroverted narcissism
and intrigued!
Clean good (C, Java, Scheme); monstrous and messy bad (C++, Perl, Ada)
I see this as a big generalisation. You can write simple clean code doing very usefull things easily in Perl, and you can have the bad dangerous code in C. You always need to look to the task at end to chose. I don't really believe in a unique language that will rule them all.
---
Guillaume
give me all your garmonbozia
I too parsed that as Ebola Sorry
Well there's your problem.
Computer Science is about the science of computing. You look at different approaches to computer programming, you study algorithms, you theorise about how things could/should be done. That science (or as close to it as we tend to get in computing).
If you just want to know how to pull data from a database and display a graph of it, then most universities have some form of "Information Systems" course that doesn't look at the theory of computing, but only the practice.
In my experience, too many people do CS that should do IS, and too many people do IS that should do Business.
--
Read more of this story at Slashdot.Read more of this story at Slashdot.Read more of this story at Slashdot.
The book "Generative Programming" covers this, referring to Microsoft's up-and-coming "Intensional Programming" system, IIRC. An excellent book. I'm anti-M$, I confess, but this looks interesting.
Lisp is better than C, Smalltalk is better than Java, Modula is better than Ada (not looking for flames, those "better"s are just my generalized opinion). But Unix was written in C, Java tools were cheaper than Smalltalk's and Smalltalk was fragmented (many incompatable vendors) and Java could make applets, the DOD required Ada be used for many things and pumped tons of money into Ada (back in the '80s)...
So, great idea or not, even if Eidola solves a significant number of problems significantly better than existing languages/tools, it won't be a major factor in Eidola's popularity. The major make or break factors will be things outside the language - for example, if IBM, MS, and Sun all get solidly and cooperatively behind it, that would make it. If Amazon decides the design of the Eidola kernel infringes on some of their patents, that could break it.
I too think it's a good idea, and I agree with It'll be hard for this to go mainstream. Nevertheless, it could be successful without being popular, couldn't it?
The AI community went through this stuff in the early 60's and came up with Lisp. These guys will thrash for a while and then they will invent Lisp, too. Maybe they can even patent it!
The engineering and test sectors have already had similar "languages" for a while now. LabVIEW is a graphical "language" that was designed for data collection and analisys systems and control systems. It operates using widgets that represent transfer functions or devices or whatever to create block diagrams of the system. Data flow is the central concept instead of control flow. Engineers are able to quickly design test systems to collect data and process it. It is quite robust to write even nontest oriented "code" and integrates very nicely with C when more power is needed. Not to make this a sales pitch for one product, HP has something like it to work their test equipment, and Matlab has a similar package to work with it. Any way you look at, very low learning curve, not much syntax to get in the way, very quick turn around from concept to product.
Eidola is, as Paul has noted in his response post, in the very early vaporware stage. My intent in writing the treatise was not to argue that we should all go start using Eidola Right Now for mission-critical work-- that would be silly. Rather, I intended to demonstrate that the Eidola concept, if and when realized, has the *potential* to make mission-critical development better, easier and cheaper. This, then, is an important reason why realizing the Eidola concept sooner rather than later would be a Good Idea.
If you have any more substantive feedback on the treatise, I'd be happy to hear it; you can email me (nweininger (at) pobox (dot) com) or Paul. I'd be grateful for critiques of my view of the problems with software verification, or the discussion of how an Eidola-like language might alleviate those problems.
Nick Weininger
"The Intentional Programming group is investigating a kind of programming abstraction (called an Intention) whose syntactic look, implementation details, and feature-driven variations may be defined by the programmer. Reusable libraries of such Intentions lend themselves to the automatic generation of custom reusable componentry that, over many applications, expresses both greater variation and better performance than one can get from reusable libraries of object oriented concrete classes, abstract classes, or templates."
In case thats too taxing for ya, here's a nice screenshot.
I agree, but that's like saying that Civil Engineering is a subset of physics. It is, but making construction workers and architects use the methods of physics is not going to get you anywhere fast.
It's the same with programming, the working methods and, frequently, the thought processes of programmers are not like those of "straight" mathmaticians.
Wasn't it Don Knuth that compared writing a computer program using a specific language to proving a mathematical theorem using a specific set of axioms?
I rest my case: a programmer writes programs, the mathmatician writes theorems (theori ?). They are both doing maths, but the methods are not interchangable (unless you're Don Knuth).
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Part of my point was that Eidola is not visual programming at all, it's just complicated text. The success or failure of visual programming is not an issue as it is not a genuine feature of the system, at least from what is shown on the website.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Also, the notation they are using is, in fact, textual. Just because the text in question has a wider range of characters than some programming languages does not mean you aren't using text. I assume they've never heard of APL. Indeed their whole effort seems to be based on C++/Java. Building a better OOPL based on those two is like trying to build a better horse by starting with a camel (no offence to Perl programmers intended).
Finally, they seem to think that "Semantic" means "behaviour"; and that "TeX" means "LaTeX" for that matter.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
I'd like to see a trend start for GPL'd software to become "mission critical" -- in other words, for there to be certification standards, and have libraries then pass that certification, and then have programs which are built using only certified libraries, etc.
I suppose this could be one aspect of the Linux Standard Base, on further thought. Here's a URL: linuxbase.org.
--
I feel fantastic, and I'm still alive.
Does this thing remind anyone of APL?
I can't get the idea of National Instrument's 'G' (the language used to program LabView) out of my head. In case you haven't used it, it's all icons for functions, wires for data flow, and frames for loops. Completely point-and-click. Sometimes G is easy. Sometimes you want to just type a for loop.
This is true - if migration weren't an issue, then the entire software industry would have switched to Ada in the mid-80's. It's a good language, but too many people already knew C and didn't want to learn a new language.
I was thinking more on the lines of an average end user. The advancement of tecnology allows machines to do exactly what we want. This includes and will include obeying spoken commands and one day interpretting sentences. I'll take back my saying about people don't think like that,because that is false. Programming does map logical thought clearly and precise but nobody talks like that. When you teach your kid to use a toliet or give someone directions to your house you don't give them variables you increment and complex logic tests. You simply tell them how to get there. Logically, and clearly. Automated computers will have to adapt to this in order to be more seemless in peoples lives. We are far off from this happening. (I'm 21 and hopefully I will see something of this nature in my lifetime but who knows).
Can you imagine a computer that would always try to do what it thought you wanted instead of what you said?
Well this is the challenge isn't it. Do you think that humans will have the ability to create machines capable of thought process? And if so will they be sophisticated enough to understand "what you say" and even learn? I believe so.
This is capable with the interpretation of true language.
Sigs are for suckers
This is a great project, since many projects don't challenge the concepts of programming languages themselves. I think programming languages have evolved over the years into the fairly advanced OO languages we see today.
With that said I feel the team of Eidola is really impressively questioning the boundries in which the rest of us work. However I feel that programming languages are slowly but progressively evolving closer to true language. Math symbols and Score music takes a serious form of training to understand and interpret. Assembly language at much lower level deals more with math and harder to understand symantics. The move to text based languages that use common words like if, switch, return, class, etc. becomes clearer to understand. The problem is still it is an aweful form of communication and idea representation. Languages will continue to progress but not towards symbols and notations but rather to pure language. Imagine ordering food at a resteraunt and saying something like:
if(jim==bathroom && Waitress) {
orderburger(Tomato=false, pickels=true);
}
while(burger==true){
if (burger=raw)
sendBack(burger);
else
eat(burger);
}
PayCheck(tip=0);
return;
This segment although logical is a silly way to communicate. Nobody talks or thinks like this, so why do we program like this. conversation of pure lanugage sounds much more like:
"Hey I am going to the bathroom if the waitress comes order me a burger with pickels and no tomatoes"
"Waitress I'm sorry but this burger is raw can you cook this more for me"
"This place sucks and this waitress is a bitch. I'm not tipping her anything"
"Lets get out of here!"
If AI is ever possible this is how we will program. We tell the computer what we want it to do and it will do it. Not right obscure confusing langues and certainly not symbols or notations.
Sigs are for suckers
Oh, OK, meta-classes?- straight-boring-imperative-code languages come and
Erm, I know comparisons are odious, but how does this now compare to Smalltalk? Or CLOS?
I'd love to see something new, but (being a mathematician) I've seen two dozen mathematical/logical/whatever-as-long-as-it's-not
go. The thing that they all lack is intuitiveness, the aspect which makes them obvious, and 2nd nature to program.
FatPhil
-- Real Men Don't Use Porn. -- Morality In Media Billboards
Also FatPhil on SoylentNews, id 863
Is it just me or does it seem that every other week a new language has been created that does wizz bang stuff? Do any of these new languages matter unless alot of people use them? I mean at what point does a language matter? When it is useful? When it is popular? When a person can make decent money programming with it? Or if I create one, that only I use and like, does it become relevant? Any thoughts?
Actually, if you read the about Eidola web page you'll notice that there will be no binary form for an Eidola program.
---
Video meliora proboque deteriora sequor - Ovidius
Submit ur Eidola version now! :)
m l
http://www.ionet.net/~timtroyr/funhouse/beer.ht
Must destroy mankind! (His watch alarm goes off) Ooh, lunchtime! -- Homer Simpson
Sound like a compiler with a graph-oriented high level language. Could be implemented around nearly anything. So in fact, instead of being a new language, it may be more precise to say it's a notation on top of a language.
-- javaDragon is an instance of JavaDragon.
Hey, if its good enough for Star Trek, its good enough for Slashdot.
Numbers 31:17,18 Now kill all the boys. And kill every woman who has slept with a man,but save for yourselves every virg
Is it really possible to separate representation from meaning without losing the meaning?
Check out AppleScript ... It even allows dialects.
Now they can never be sure what represents what!
I looked at it. I played with it. I'm having a hard time figuring out how it's different from Lisp, or Forth.
It just seems to me another way to build a dictionary of words that have to all hang together for a program to execute.
If you're looking for interesting ways to represent/view/play with a universe, take a look at zigzag.
668: Neighbour of the Beast
I think this is not really about visual programming. Actually it's far from it - it's about programing *without representation* - be it text, pictures, etc.
Yes, text *alone* might be better than pictures *alone* at representing a computer program. But the point of this is - why pick one? Maybe pictures *and* words is the best way of doing it.
I am very used to reading code. However, I have to agree with this guy about one thing: it is very difficult to grasp a program's design by reading its code. It is too complicated because you must navigate through your source files in a totally non-linear fashion. It is usually a long, tenuous and not-so-interesting project.
With a language like this, we can have the best of both worlds. Different viewers could represent the program in different ways. One viewer could show source code while the other could show the program's structure graphically. Heck, maybe you could even represent the program using various code syntax: you know Java best? we'll show you the program in Java; C is more your thing? Well, C it is then.
I think this is a great experiment, one that has the potential to give us important insights into how programs are constructed and how they are represented. Maybe the fact that these two are so interlinked in today's language is part of why programs are usually difficult to write and maintain.
What would be truly revolutionary, is a language that would allow you to write a program from a set with cardinality aleph[1] and above.
Both word-based and picture-based languages have their benefits, as do GUI-based and command-line-based interfaces. Understanding the strengths of the both are often critical in choosing the right tool. Eidola seems be nothing more than use a picture-based (mathematical) language to represent what other programmers might use English to represent. if you already understand the mathematical language involved, you'll be more productive. I can't make heads or tails of it, and would prefer to use an English-based language.
Beware typoes.
What we really need is a programming language that caters to poets and versifiers. Eiku could answer that. Declare C As Type T Create C Without Single Default Add 5 to C End
Or worse...Limerdola There once was a variable V2 Who's parameter P3 just grew By 3001 (Oh isn't this fun) Now set the screen background to blue
Beware typoes.
It's an obscure reference to "Calvinball", from the Calvin and Hobbes comic strip. Calvinball is a game with constantly changing rules.
Floating face-down in a river of regret...and thoughts of you...
http://www.eidola.org/implementation/java/howto.ht ml
:-(
:-
Looks like this is just going to put a GUI on top of a new language on top of java. Sun had a visual tool that I thought was pretty neat, shame they canned it
Read this book, 'Visual Object-Orientated Programming' 0-13-172397-9, to have a better understanding of the problems involved and some of the tried approaches.
Personally I don't think GUI Dev Tools are going to solve any of our problems. The Sun tool had the right approach, plug components together. Forget about defining members/functions etc Rather concentrate on putting useable components together.
At present the most productive dev tools are those catering to a specific niche. For example, Client/Server database tools are prolific and allow for rapid design/implementation and reuse. The big drawback is that you have to do things the way the tools wants you to.
Some not so novel ideas for improvement
A language that seperates design from implementation
Understanding that different projects need different tools/skills.
Programmers that seperate GUI from business rules
Acknowledgement that OO is just the beginning not the end
World peace and universal happiness, ok technically that's not in the remit of programming, but it's far more likely than the prior four.
oooh. A Gary Larson calender. I dont't get it. I dont't get it. I...don't get it.
Personally I'd like to see an example program given alongside the same in C/C++ just so that we can all see just what the hell they're on about. my $.02
Java: can have different binary codes (at the CPU level, unless you happen to have a CPU for which bytecode is a supported machine language), still has a canonical binary form (the .class files). Eidola: has no canonical binary form... It's mathematical. The compilers for this should be interesting...
Jeez, they're already trying to justify this as a mission-critical OS, when the kernel's in Java and they haven't even resolved important issues like scoping? I think they're a bit ahead of themselves...
Sorry about that, replace OS with language...
is it just me (usually is) or does this remind ya of SGML/XML. I realize it's 'object oriented' but it has that removed ... structured description of information (rather than information itself) feel to it. Self-describing language. I guess it just gets tricky when you try to make that language actually *do* something other than talk about itself.
but as I said, I'm probably just confused...
*kill your sig*
closed minded is as closed minded does
I think this is cool, but having read the "about Eidola" page, I think it is rather poorly explained, and possibly not as useful as it could be. They talk of the actual program taking a purely mathematical form. However, in an actual implementation, this will not be the case. The Eidola kernel, which has the job of maintaining this mathematical structure, will be dealing with some form of internal representation of it - it may not be specified by the language, but it will be there in a real implementation (I'll call it the kernel representation). This is where I have a problem with the explanation and the idea itself. Given that this representation will be there, it will serve logically the same purpose as the source code you manipulate when using a modeling language. The differences are these:
1. You will not see this kernel representation. You can only manipulate it through the various, er, representations of it.
2. The kernel representation will, unlike source code which is meant to be directly manipulable by a human, be designed to fulfill this role of intermediary between design tool and compiler. A Good Thing.
3. Changes to this kernel representation are communicated throughout the development environment by an event mechanism. Another Good Thing.
4. The kernel representation, because of the ambitions of the authors, will not be fully specified, which means that programs written in one Eidola environment will not be compilable in a different Eidola environment. Aaaarrrggghhh....
This is a cool idea, but why not accept that computers handle representations of things, not mathematical abstractions and specify a format for this kernel representation, getting rid of point 4 above and making this really useful.
I agree with a lot of what you say in your other comment Language==Representation, but what do you mean by this one? Why should using the same notation twice cause problems?
Looks like some moderator has just gone along and modded about 5 consecutive posts up. This one's not even attached to the right artice.
here's one
---- Just another spud server.
I understand that existing object oriented programming languages are created so that you have a list of objects that you can assign or map to any command or function that you want to.
What is Eidola bringing to the table that is any different or new that these existing programs are not capable of? From what I am reading, it appears to me that you are able to create templates of commonly used routines or algorythms so that programming is faster.
Send all information this way please...
...is that they are languages. When is the computer science folk going to realize that the algorithm should never have been the basis of computer programming? That is the root cause of the software reliability and productivity crisis. Wake up!
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.
This is all primitive to the extreme. Computer programming should involve no syntax, grammar or any such thing. It should all be objects, connectors, sensors, effectors and signals. When is everybody going to wake up and realize that the algorithm should not be the basis of programming? This is the real problem with software engineering. A software application should be viewed as a set of communicating objects.
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.
That's because they're doing it wrong. There should be no logic diagrams. Just objects with plug-compatible connectors, kind of like ICs. The primitive objects should just be sensors and effectors which can be connected together into higher level objects. Just drop them in and they find the right connections, automatically and reliably. Programming for the masses!!
I think a very fascinating concept for a language, although it does look all greek to me :-)
My guess is it will be highly favored by mathemeticians, but not widely used, as the "Representation" looks to be extremely mathematical.
---
The (Hopefully) Great Slashdot Blackout
Does this thing remind anyone of APL?
That can spring either way: A mathematician may want an interface to it that gives him a representation with only mathematical symbols. A C programmer may insist on manipulating text. Or you may end up with some for of completely visual programming.
By decoupling the human readable representation of the language from the system internal representation of the language implementation, you make it possible for people to use a multitude of tools that are extremely difficult to deal with currently, because they have to do stupid hacks to get around the use of text, such as inserting lots of "DO NOT EDIT" comments.
Your suggestion of "teaching" the system what you want it to do is certainly one interesting approach that would be much simpler to experiment with with a system like Eidola.
Current programming languages are poor at doing that, because they're built around the language syntax, and the textual representation is the canonical form of the language. This makes it incredibly difficult to make good integrated tools, because you have to expect that programmes will reorganize the source code from time to time, and that will affect your tool and how it deals with the code.
I see this is an interesting endeavour because it explicitly tries to decouple the syntax of the language from the semantics: If you want to, you could still write a frontend that would give you a text representation.
But what would you have gained from that? And what would you gain from using an existing language if its syntax was ripped away
This misleading analogy (from a linguist, who should know better) needs to be buried once and for all. That the English word "language" is used to refer to both English and Perl does not make them examples of the same thing. Computer languages control Turing machines; human languages are a very different animal.
in linking high and low levels of language. After all, the lowest level of anything is a "set of carefully defined mathematical abstractions"
" if x then... !x "
Okay conceptually it's brilliant, and possibly even the direction in which computing as a whole is going, while us retro geeks resist and resist. But I have to wonder is it really necessary to invent a whole new language. We already have many languages that are both efficient and effective. Would the time not be better spent building front ends to existing languages (uggh the retro geek in me cringes at the thought).
Java Kernel,is this another feather in Sun's cap?
This is a Sig, there are many like it but this one is mine! I wish I had more than 120 chars... whats a char?
Eidola seems set on the notion: "text is a very poor notation system for the concepts of a high-level language" It seems to me that text is the best working representation for the highest-level language that we speak (i.e. English). Maybe I'm just old fashioned . . .
I'm no programmer. I model business I know (financial trading/sales) in UML and in Rational Rose. Then our developers pick it up, and obviously they improve the model a lot. But still they claim to generate 80% of (Java) code directly from the model? So isn't it the future of all programming languages? When UML can describe a system, and tools (like Rose) can generate machine code, then coding is dead. From graphic notation - directly to machine code. Isn't it what everyone wants? Not only Eibola, but... sry... Java would RIP.
--
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!
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.
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.
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!
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.
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.
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....
And they have ZERO examples of any good Eidola code! Maybe some white knight will step in and write some good representation engines for them?
Uh, Eidola guys, you might want to spend a few more days thinking before calling for help.
From my FAQ for this article:
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.
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.
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.
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.
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
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.
---
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
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?
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.
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
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.
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.
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.