Hacker News Reader

Comment by wrnr | Hacker News Reader

To represent a program as a graph you need a hyper-graph. That is a graph where every edge is also a node, for example:

  (1)--[2]-->(3)
  (2)--[3]-->(4)

There is no good way to draw this visually without losing the ability to be able to draw all possible programs. The grammar of both natural and programming languages use various strategies to get around this, and they are actually very efficient at it (from an information theoretic point-of-view).

Thats not to say one can't improve on the current culture of writing programs in what is basically ASCII text, but visual programming is just not powerful enough to describe arbitrary computations.

View on HN

Could you go into detail why you think that a hypergraph is needed? I think every program can be represented by a directed graph of basic blocks.

First-order functions maybe?

The following function has an obvious visual representation as a processing block:

    int add(int a, int b);

But how do you represent a function allowing other functions in its signature, e.g:

    void transformInPlace(int* input, int (*func)(int));

In LabVIEW I wire in a reference to a VI that provides the functionality or I use a design similar to the command pattern where there's an override method and I specify the class instance as the argument. Depends on the granularity of the design needed and how many different classes I want to define (usually not that many).

The same way the processor does. The function argument becomes a pointer you jump to when you want to call the function.

I don't think you are wrong about the DAGs, though in programming language parlance they are called abstract syntax trees (AST). Sure you can do like Scratch, which is basically an AST editor instead of a code editor. Not a bad idea in of itself, but what if you start writing those basic blocks in your language of choice? Keep looking up the function definition in your IDE and at some point you end at some assembly with long jumps all over the place.

The point I wanted to make was that no matter what design choice you make as a language author, to make this DAG/AST as palatable for the end user, be it with a imperative, functional, logic or concatenive style of programming, a price is aways payed, in terms of complexity at some level (time, space, ergonomics), no matter what you do.

I'm not thinking of the AST, but of a graph of https://en.wikipedia.org/wiki/Basic_block

You didn't answer the question. ASTs are not DAGs, they are just trees. They also do not represent the computation, but the language syntax.

Many visual programming languages are based around DAGs and they do represent the computation itself. The edges are usually not nodes either, so those DAGs are not hypergraphs.

hi wrnr,

can you explain your graphic? what is the difference.between (2) and [2]?

It is a bit like neo4j's cypher, (2) is an edge, like a circle, [2] is a label, like in a property graph.

  (Alice)--[loves]-->(Bob)
  
  (loves)--[type]-->(Property)
         --[domain]-->(Human)
         --[range]-->(Human)
  
  (type)--...

Sort of like that, cypher does not support this type of expression though.

Reply on news.ycombinator.com