‪Ya, graphic programming.‬

There's this scene in Lain where she's programming on a portable device with a stylus, just dragging and pointing and clicking to navigate and stuff.
I want such an programming environment. I want it to death.
So I'm wondering, how would a language for such a purpose look? They used LISP in the series, but while LISP syntax is very simple (good), I'm thinking you'd want a slightly less dynamic language, to allow the environment to do better definition lookup, autocompletion, etc. If you don't have a keyboard, you'll want to avoid typing as much as possible.

So, language suitable for making a kickass drag-and-drop, point-and-click code editor interface. Any existing out there? How would a new one look?

>>40
Yeah, and the programming environment sucks ass. Fortunately the Mindstorms platform is open.

>>39
You are correct: there is very very little chance of me producing anything meaningful in the near future, unfortunately.

Yes, I am not speaking of library dependencies, though ultimately that will need to be looked at sometime too.
I mean the dependencies between sections of code. Apparently (from reading various articles) one of the major sources of bugs is that when a piece of code is changed, the dependent pieces of code are not updated and a bug is introduced. This is the reason for encapsulation in OOP, for example.
When you look at code, you can see that each operation in an expression is a dependency of the next operation in the expression and that each expression is a dependency to the next expression in a statement and so on for functions/procedures, classes/objects, modules and whatever other abstractions you may use.

My little toy language works by specifyung that "X depends on Y" and "Y depends on Z" and so on, building up expressions, functions, objects and modules (in reality, each of these work in the same way - I simply call them functions for convenience).So you can build up functions from other functions (just as you do in other languages).
Because of the way this works, I guess it's a graphical "functional" programming language.

The language contains a single statement: Function X depends on function Y (where Y could be a list of functions). Thats it.

There would, of course, be a number of primitive functions (add, subtract, whatever) and all others would be built up of these.
The way the code is executed is that if a function has no dependencies (or it's dependencies have been met) then the function is evaluated. This may, in turn, meet another functions dependencies and the cycle continues.

Very very simple example:
integer a initialized to 10
integer b initialized to 20
integer c depends on addition1
addition operation addition1 depends on integers [a] and [b]

addition1 is evaluated because both of it's dependencies can be met. c can be set to 30 because it's dependency, addition1, has now been met.

It's a little more complicated than that, but thats more or less it.
While I don't really know if this does indeed eliminate dependency based bugs, it does have a certain charm to it, IMHO. Namely, that a language could be built up of a SINGLE statement and still be able to do everything. In reality more statements would exist, but they would sit around the single statement core.


PS: I wrote a class in Python which could evaluate code as described above. I know it works, what I don't know yet is how well - I wont know until the editor is complete - and I'm not quite decided what the "syntax" should be... real life is getting in the way :-/



RE: purely graphical programming is only worthwhile if...
That is true. My first approach was to create a textual programming language, but then I realised that it wastoo awkward and tedious to code in, yet using diagrams (on paper) to write an algorithm was quite easy (and converting the diagram to text code was also straightforward). this is why I chose to use a graphical language instead of a textual one.
I suppose that ultimately it would require both.. Perhaps with correctly designed keyboard shortcuts, I could eliminate the use of the mouse and have a hybrid graphical/textual language without too much tedium. I don't know..

One thing I was thinking of recently was to have each element of the graphical language annotated with a textual expression (for example, a mathematical formula), but I need to play with this idea some more.

All in all, even though I came up with this idea a year ago, it is still in extremely early stages. I don't see myself getting anywhere meaningful in the near future... :-(


Sorry for tl;dr post. Comments appreciated.

>>39,42
It would be much easier to exlain with diagrams, but I'm too lazy to draw any.

Continuing, in case anyone is actually interested, here is some python code as mentioned in >>42

Heres whats being done:

int   [i]a=0[/i] depends on [i]add[/i]
+     [i]add[/i] depends on [i]a, 1[/i]
!=    [i]neq[/i] depends on [i]add, 10[/i]
print [i]prn[/i] depends on [i]a[/i]

Heres the python code:

# Here are the dependencies built up out of Python objects.
f_int_a = func_int()
f_add = func_add(const=[1])
f_neq = func_noteq(const=[10])
f_prn = func_print()

f_int_a.add(f_prn)
f_int_a.add(f_add)
f_add.add(f_neq)
f_neq.add(f_int_a)

# By passing a value to 'a', we fulfill its dependency and start a chain reaction of function evaluation.
f_int_a(0)

The f_* functions are defined as:

def func_int (const=[]):
    def func (inputs):
        return inputs[0]
    return Function("int", func, 1, const)

def func_add (n=2, const=[]):
    def func (inputs):
        return reduce(lambda a, b: a + b, inputs)
    return Function("+", func, n, const)

def func_noteq (const=[]):
    def func (inputs):
        if inputs[0] != inputs[1]:
            return inputs[1]
        else:
            return None
    return Function("!=", func, 2, const)

def func_print ():
    def func (inputs):
        print inputs[0]
        return 1
    return Function("print", func, 1)

Where Function is a class which stores a list of dependencies and evaluates func when all dependencies are met.
It's parameters are: name, function to evaluate, number of dependencies and constants (constants being pre-evaluated dependencies).

Running the code outputs 0 through 9 to the console (one number per line). So far, this isn't exactly useful or anything, but serves as a proof of concept.


If anyone wants the code for Function, let me know and I'll clean it up a bit and post. Otherwise, I won't bother.

an actual discution? in MY /PROG/?!?!

>>45
rare, i know

>>45
It's about as likely as you think!

>>32
lol cant even enter a url right...

>>44
It's like the critical path analysis of programming. You should think about using this dependency information to prioritize calculations.

>>27
lol no
>>26
C for Win32 API calls, Assembly for the main layout engine (this used to be a DOS program)

>>49
Actually, thats a very good idea.

I was thinking that, ultimately, I could use the graph of dependent operations for more than simply generating code (or interpreting it directly, which would be good for RAD and debugging). Graph analysis may be useful for profiling, optimization and other useful tools.
Another note is that to compile it do machine code directly seems to be a little out of my ability right now, but compiling to a stack based intermediary language would work. Initially I'll simply execute that in a VM, but ideally I'd like to perform pattern analysis on this to further optimize code and then use the processed code to generate machine code (or gcc intermediary code allowing gcc to further optimize and generate executables for a number of platforms).

Like, it has potential - I just haven't found enough time and motivation to get it all working :-(

>>51
The thing is that goto is ``considered harmful'' among highlevel languages, but is quite natural for something based on flow diagramming. Get used to it.

>>52
Computed goto as a language primitive.

why don't you install puredata and become an experimental media artist?

>>52
What has goto got to do with anything?

Ignoring the fact that it was a troll, just got to say that I have no use for goto's. Though, technically, everything could be seen as a perform-operation-and-goto.

>>54
I might actually do that. Simply because the wikipedia screenshot looks crazy ;-)

That scene from Lain FUQIN ANGERED me.

>>1
I want such an programming environment. I want it to death.
Loser

while LISP syntax is very simple (good), I'm thinking you'd want a slightly less dynamic language
More loser

OKAY YOU FUQIN ANGERED... etc.

>>1
Heres a graphical language for you, can you see the graphics:
(begin (display "Hello, World") (newline))

The FUTURE I SURVIVE   ON A DIET   OF DIOXIN AND!