Re Paul Tarvydas's VF papers
138 views
Skip to first unread message
timtheli0n
Jan 3, 2017, 8:12:07 PM1/3/17
to Flow Based Programming
Hi,
I decided to respond to Paul Tarvydas's papers in a new thread rather than in the thread about writting GUIs using FBP techniques as my questions are of more general character.
I have read the CCECE06-0379.pdf paper but I haven't read the other one yet. Asking questions first. I appologize if my questions are a result of uncareful reading. I am writting up these notes as I read and not looking back to see if things are clarified elsewhere in the text ;P
1. Event handling within parts is automic however parts are independent and their executution is asynchronous. Is there a concept of having a collection of parts which act like one big part? In the classical FBP model I think there is, and this would allow more than one event to pass through one of these megaparts at a time. What is the reasoning behind needing events to be atomic within parts?
2. In figure 1 what is the broken line between the status pin of the Receive Controller and the Tx Driver?
3. Compiler interprets visual information? This seems to be a strange practice, the open source DRAKON editor also does it, but I don't get why. I kind of get why the opensource umlet does this. But to me it makes far more sense to me to save the data about the diagram in a semantically correct fashion and only add the minimum of "object location" information that you need to allow the user to drag parts around to appeal to their visual egos. Does VF serialize to a format which is version controll compatible? Did you have good reasons for serializing using a weakly semantic image-like format that had to be interpereted rather than a strongly semantic one?
4. Section 4.4 figure 3: Do I understand that the "correct order" is the order of the shortest path first? Can two events arrive at the same time in a tuple like grouping? That was my "intuition" about what should happen, that y should recieve one "event" that looks like {"ip3":b,"ip4",a}...
5. I don't think you ever say in the paper what kind of programms are typically written in VF? Real time operating systems like you sugest in an early post on your blog? Other types of program as well?
6. Does VF still exist? http://www.visualframeworksinc.com/ redirects me to a rather boring corner of Mordor...
Regards,
Timothy Hobbs
I decided to respond to Paul Tarvydas's papers in a new thread rather than in the thread about writting GUIs using FBP techniques as my questions are of more general character.
I have read the CCECE06-0379.pdf paper but I haven't read the other one yet. Asking questions first. I appologize if my questions are a result of uncareful reading. I am writting up these notes as I read and not looking back to see if things are clarified elsewhere in the text ;P
1. Event handling within parts is automic however parts are independent and their executution is asynchronous. Is there a concept of having a collection of parts which act like one big part? In the classical FBP model I think there is, and this would allow more than one event to pass through one of these megaparts at a time. What is the reasoning behind needing events to be atomic within parts?
2. In figure 1 what is the broken line between the status pin of the Receive Controller and the Tx Driver?
3. Compiler interprets visual information? This seems to be a strange practice, the open source DRAKON editor also does it, but I don't get why. I kind of get why the opensource umlet does this. But to me it makes far more sense to me to save the data about the diagram in a semantically correct fashion and only add the minimum of "object location" information that you need to allow the user to drag parts around to appeal to their visual egos. Does VF serialize to a format which is version controll compatible? Did you have good reasons for serializing using a weakly semantic image-like format that had to be interpereted rather than a strongly semantic one?
4. Section 4.4 figure 3: Do I understand that the "correct order" is the order of the shortest path first? Can two events arrive at the same time in a tuple like grouping? That was my "intuition" about what should happen, that y should recieve one "event" that looks like {"ip3":b,"ip4",a}...
5. I don't think you ever say in the paper what kind of programms are typically written in VF? Real time operating systems like you sugest in an early post on your blog? Other types of program as well?
6. Does VF still exist? http://www.visualframeworksinc.com/ redirects me to a rather boring corner of Mordor...
Regards,
Timothy Hobbs
Paul Tarvydas
Jan 4, 2017, 6:21:11 PM1/4/17
to flow-based-...@googlegroups.com
> ...
rules for these conferences put strict limits on how long they could be.
>
> 1. Event handling within parts is automic however parts are
independent and their executution is asynchronous.
> ...
components.
> In the classical FBP model I think there is, and this would allow
more than one event to pass through one of these megaparts at a time.
What is the reasoning behind needing events to be atomic within parts?
This is where I slightly break from FBP. bmFBP was invented for
control-flow problems, embedded systems, sensor reading, etc. Patterned
after digital electronics. Events (short IP's, bursts of IP's) can
happen at any time and overlap in time.
The design rules for digital electronics are based on the concept that a
reaction to an event happens "instantaneously". Voltage on an input
goes from 0V to 5V, output goes to 5V (almost) instantaneously[1].
bmFBP simulates instantaneousness in software. Software takes more time
than hardware, so the simulation rule is "act as if this were an
instantaneous reaction to a single event".
And, if every component is "instantaneous", then composite
(hierarchical, non-leaf) components must act like they are
instantaneous, too, i.e. a top-level composite component cannot consume
the next event until all of its children have finished with the current
event.
When working on problems in the control-flow domain, this is a very
convenient abstraction. It does not conform with FBP, but it does
simplify solutions in the control-flow domain.
>
> 2. In figure 1 what is the broken line between the status pin of the
Receive Controller and the Tx Driver?
Haha. In electronics of the day, one showed a port as a line jutting
out of the component. "Status" is N.C. - no connection. Likewise,
"config" is N.C.
If the innards of RS232ReceiveControl sent an event to the "status"
output port, it would go nowhere (a "drop" in FBP). And, nothing would
ever appear on the "config" port of RS232TxDriver.
In this architecture.
Other architectures might use these pins, and there would be solid lines
connecting them to other ports.
>
> 3. Compiler interprets visual information?
Are you referring to section 3.7?
The tried and true method for building compilers for text languages is
four phases (passes): scan -> parse -> semantic analysis -> emit.
I treat bmFBP as a visual - 2D, diagrammatic - language.
The diagrams are syntax. Just like ASCII.
Replace "scan" with a thing that produces descriptions of graphic
primitives - line from x,y to x1,y2, etc.
Replace "parse" with a thing that recognizes line1 connected to line2
connected to line3 connected to line4 connected to line1 as a box. And
so on.
Doing it this way is simple and clean.
> But to me it makes far more sense to me to save the data about the
diagram in a semantically correct fashion and only add the minimum of
"object location" information that you need to allow the user to drag
parts around to appeal to their visual egos.
This is a losing strategy.
It leads to a world of pain.
Pain for the user, because an unfinished program cannot be saved -
because it is not semantically correct.
Pain for the implementor, multiplying the complexity of the
editor/compiler by orders of magnitude, like jamming red-hot pokers in
one's eyes.
Semantic editing for textual languages was tried and tossed.
Scan -> parse -> semantic analysis -> emit occurs in these phases
because it makes everything manageable.
> Does VF serialize to a format which is version controll compatible?
It does. It uses the concept of factbases. A bag of triples -
relation, object, subject. Possibly the most flexible (aka agile) data
structure on the planet. The semantic web and Web 3 uses triples,
albeit with ugly syntax. See
https://github.com/guitarvydas/vsh/blob/master/docs/internals for an
example.
Sort the bag of triples, then git it.
> Did you have good reasons for serializing using a weakly semantic
image-like format that had to be interpereted rather than a strongly
semantic one?
I think this was answered above. If not, I will try to re-phrase.
>
> 4. Section 4.4 figure 3: Do I understand that the "correct order" is
the order of the shortest path first? Can two events arrive at the same
time in a tuple like grouping? That was my "intuition" about what should
happen, that y should recieve one "event" that looks like
{"ip3":b,"ip4",a}...
No.
Interesting question, though.
Despite what I said above, in electronics there is "propagation delay".
IP0 arrives at X.IP1 and Y.IP4 at the same time "instantaneously". X
cannot produce its output X.OP2 until it sees the event on IP1. That
means that Y necessarily sees an input on Y.IP4 before receiving an
output from X on IP3.
An event tuple brings us to the question - which part of the tuple
should we process first? The answer to the question must be explicitly
supplied by the designer.
This is software.
Reality.
Time matters.
Nobel laureate Ilya Prigogine spent the first 100 pages of his book
"Order Out of Chaos" ranting about how the functional view of physics -
time removed - has set the progress of physics back by at least 100 years.
Causality involves time.
>
> 5. I don't think you ever say in the paper what kind of programms are
typically written in VF? Real time operating systems like you sugest in
an early post on your blog? Other types of program as well?
The paper was given a limit of 4 pages. See where the last line ended
:-). I might have even screwed with the font size, I don't remember.
bmFBP: anything reactive. Which is just about everything these days.
O/S'es, windowing, GUI's, servers, IoT, hardware control, etc.
FBP is great for processing flows of data. Lots of web-based apps
process huge amounts of data.
Both realms prefer slightly different semantics.
>
> 6. Does VF still exist?
No.
(Further discussion of this issue in private emails, if you care.)
pt
[1] This is not strictly true if you measure very small amounts of time
or over large distances. There is propagation delay through components
and even through wires if they are long enough (e.g. 9 inches) and
events are fast enough.
> I appologize if my questions are a result of uncareful reading.
These papers are, both, "industry experience papers". The academic
rules for these conferences put strict limits on how long they could be.
>
> 1. Event handling within parts is automic however parts are
independent and their executution is asynchronous.
> Is there a concept of having a collection of parts which act like one
big part?
Components are hierarchical, i.e. a non-leaf component contains other
big part?
components.
> In the classical FBP model I think there is, and this would allow
more than one event to pass through one of these megaparts at a time.
What is the reasoning behind needing events to be atomic within parts?
control-flow problems, embedded systems, sensor reading, etc. Patterned
after digital electronics. Events (short IP's, bursts of IP's) can
happen at any time and overlap in time.
The design rules for digital electronics are based on the concept that a
reaction to an event happens "instantaneously". Voltage on an input
goes from 0V to 5V, output goes to 5V (almost) instantaneously[1].
bmFBP simulates instantaneousness in software. Software takes more time
than hardware, so the simulation rule is "act as if this were an
instantaneous reaction to a single event".
And, if every component is "instantaneous", then composite
(hierarchical, non-leaf) components must act like they are
instantaneous, too, i.e. a top-level composite component cannot consume
the next event until all of its children have finished with the current
event.
When working on problems in the control-flow domain, this is a very
convenient abstraction. It does not conform with FBP, but it does
simplify solutions in the control-flow domain.
>
> 2. In figure 1 what is the broken line between the status pin of the
Receive Controller and the Tx Driver?
out of the component. "Status" is N.C. - no connection. Likewise,
"config" is N.C.
If the innards of RS232ReceiveControl sent an event to the "status"
output port, it would go nowhere (a "drop" in FBP). And, nothing would
ever appear on the "config" port of RS232TxDriver.
In this architecture.
Other architectures might use these pins, and there would be solid lines
connecting them to other ports.
>
> 3. Compiler interprets visual information?
The tried and true method for building compilers for text languages is
four phases (passes): scan -> parse -> semantic analysis -> emit.
I treat bmFBP as a visual - 2D, diagrammatic - language.
The diagrams are syntax. Just like ASCII.
Replace "scan" with a thing that produces descriptions of graphic
primitives - line from x,y to x1,y2, etc.
Replace "parse" with a thing that recognizes line1 connected to line2
connected to line3 connected to line4 connected to line1 as a box. And
so on.
Doing it this way is simple and clean.
> But to me it makes far more sense to me to save the data about the
diagram in a semantically correct fashion and only add the minimum of
"object location" information that you need to allow the user to drag
parts around to appeal to their visual egos.
It leads to a world of pain.
Pain for the user, because an unfinished program cannot be saved -
because it is not semantically correct.
Pain for the implementor, multiplying the complexity of the
editor/compiler by orders of magnitude, like jamming red-hot pokers in
one's eyes.
Semantic editing for textual languages was tried and tossed.
Scan -> parse -> semantic analysis -> emit occurs in these phases
because it makes everything manageable.
> Does VF serialize to a format which is version controll compatible?
relation, object, subject. Possibly the most flexible (aka agile) data
structure on the planet. The semantic web and Web 3 uses triples,
albeit with ugly syntax. See
https://github.com/guitarvydas/vsh/blob/master/docs/internals for an
example.
Sort the bag of triples, then git it.
> Did you have good reasons for serializing using a weakly semantic
image-like format that had to be interpereted rather than a strongly
semantic one?
>
> 4. Section 4.4 figure 3: Do I understand that the "correct order" is
the order of the shortest path first? Can two events arrive at the same
time in a tuple like grouping? That was my "intuition" about what should
happen, that y should recieve one "event" that looks like
{"ip3":b,"ip4",a}...
Interesting question, though.
Despite what I said above, in electronics there is "propagation delay".
IP0 arrives at X.IP1 and Y.IP4 at the same time "instantaneously". X
cannot produce its output X.OP2 until it sees the event on IP1. That
means that Y necessarily sees an input on Y.IP4 before receiving an
output from X on IP3.
An event tuple brings us to the question - which part of the tuple
should we process first? The answer to the question must be explicitly
supplied by the designer.
This is software.
Reality.
Time matters.
Nobel laureate Ilya Prigogine spent the first 100 pages of his book
"Order Out of Chaos" ranting about how the functional view of physics -
time removed - has set the progress of physics back by at least 100 years.
Causality involves time.
>
> 5. I don't think you ever say in the paper what kind of programms are
typically written in VF? Real time operating systems like you sugest in
an early post on your blog? Other types of program as well?
:-). I might have even screwed with the font size, I don't remember.
bmFBP: anything reactive. Which is just about everything these days.
O/S'es, windowing, GUI's, servers, IoT, hardware control, etc.
FBP is great for processing flows of data. Lots of web-based apps
process huge amounts of data.
Both realms prefer slightly different semantics.
>
> 6. Does VF still exist?
(Further discussion of this issue in private emails, if you care.)
pt
[1] This is not strictly true if you measure very small amounts of time
or over large distances. There is propagation delay through components
and even through wires if they are long enough (e.g. 9 inches) and
events are fast enough.
timtheli0n
Jan 7, 2017, 3:40:51 PM1/7/17
to Flow Based Programming
Thankyou for the explanations. I'm only going to reply to one point for now, and that is your point about the ability to create incorrect programs in your editor and semantic serialization formats.
First off, I'm not aware of many editors that do not allow for semantically incorrect programs. This seems to necesarilly dictate a so called Hole Driven Development model http://matthew.brecknell.net/post/hole-driven-haskell/ . One editor that I can think is http://www.lamdu.org/. It isn't done yet, so I haven't been able to play with it and form an opinion. You say you have developed a strong opinion over many years of experience what historic editors existed that didn't allow for incorrect programs?
One advantage of being able to create incorrect programs is that I see typecheckers and static compilers as preforming a sort of checksum on the user's input. If the program compiles, it means that the program is actualy what the user intended to type. If you had a language in which all strings were valid programs, than small typos, rather than being caught, would lead to radically incorrect behavior that was very hard to track down.
I feel that there must be some middle ground, between having an entirely non-semantic serialization format and having a semantically based one. Afterall, a compiler for C doesn't include a handwriting recognition engine. It uses text which is already semantically reduced to 7 bit ASCII.
I've made some Venn diagrams to demonstrate my point.
First off, I'm not aware of many editors that do not allow for semantically incorrect programs. This seems to necesarilly dictate a so called Hole Driven Development model http://matthew.brecknell.net/post/hole-driven-haskell/ . One editor that I can think is http://www.lamdu.org/. It isn't done yet, so I haven't been able to play with it and form an opinion. You say you have developed a strong opinion over many years of experience what historic editors existed that didn't allow for incorrect programs?
One advantage of being able to create incorrect programs is that I see typecheckers and static compilers as preforming a sort of checksum on the user's input. If the program compiles, it means that the program is actualy what the user intended to type. If you had a language in which all strings were valid programs, than small typos, rather than being caught, would lead to radically incorrect behavior that was very hard to track down.
I feel that there must be some middle ground, between having an entirely non-semantic serialization format and having a semantically based one. Afterall, a compiler for C doesn't include a handwriting recognition engine. It uses text which is already semantically reduced to 7 bit ASCII.
I've made some Venn diagrams to demonstrate my point.
Similarly, if I'm creating an editor for a flow based programming langauge, I might not want to limit my editors serialization formats to valid FBP programs, but I'm pretty sure that I do want to limit its serialization formats to valid di-graphs.
Regards,
Timothy Hobbs
Paul Tarvydas
Jan 8, 2017, 1:39:52 PM1/8/17
to flow-based-...@googlegroups.com
I tend to agree with your Venn
diagrams, so maybe we're just misunderstanding one another.
I string the bubbles out from left to right, though. Outer-most bubble to the left, inner-most to the right.
I string the bubbles out from left to right, though. Outer-most bubble to the left, inner-most to the right.
> what historic editors existed that didn't allow for incorrect programs?
They were called "structure editors" back then. There were many
attempts. The Synthesizer Generator was the most famous (IMO):
https://www.ics.uci.edu/~taylor/ics228/SynGen.pdf
> ... a compiler for C doesn't include a handwriting recognition engine
In fact, my ideal for FBP would be to draw diagrams on paper (or whiteboard) and then input them using a scanner.
I know that this can be done, because my Apple Newton (ca. mid-1990's) accepted hand-drawn diagrams and "fixed them up".
https://www.ics.uci.edu/~taylor/ics228/SynGen.pdf
> ... a compiler for C doesn't include a handwriting recognition engine
In fact, my ideal for FBP would be to draw diagrams on paper (or whiteboard) and then input them using a scanner.
I know that this can be done, because my Apple Newton (ca. mid-1990's) accepted hand-drawn diagrams and "fixed them up".
> I might not want to limit my editors serialization formats to valid FBP programs, but I'm pretty sure that I do want to limit its serialization formats to valid di-graphs.
Why?
This sounds like untested opinion.
I used
to opine about strong typing. I *thought* it would help me.
Instead it hindered my design. Architecture matters more than
coding. Code is cheap. Architecture is hard.
We went all the way back to very primitive diagram elements - straight line, curvy line, ellipse, text, point - and found this to be extremely workable. Back in the '80's, it was thought "impossible" to use a backtracking parser, but nowadays it is laughably simple (my favourite is PAIP Prolog for Common Lisp). We've done it in a browser using JS, too. Extremely simple drawing elements, sent to the server for compiling.
The
point of all this simplicity is - simplicity.
And
flexibility.
What if it makes more sense to represent the innards of a component as a ping-pong diagram (aka Sequence Chart, see Harel's "Come, Let's Play")? Using a simple, keyboard-based drawing tool, I could draw it. Then I would use a different 2D parser and analyzer to figure out what the diagram means and what code should be emitted.
pt
timtheli0n
Jan 11, 2017, 9:26:30 AM1/11/17
to Flow Based Programming
On Sunday, January 8, 2017 at 7:39:52 PM UTC+1, Paul Tarvydas wrote:
I tend to agree with your Venn diagrams, so maybe we're just misunderstanding one another.
I string the bubbles out from left to right, though. Outer-most bubble to the left, inner-most to the right.
> what historic editors existed that didn't allow for incorrect programs?
They were called "structure editors" back then. There were many attempts. The Synthesizer Generator was the most famous (IMO):
https://www.ics.uci.edu/~taylor/ics228/SynGen.pdf
Thankyou for the article, but it is hard for me to respond as to the usability of such a system, that article seems to concern itself mearly with the technical side of defining abstract syntax trees using a context sensitive grammar.
> ... a compiler for C doesn't include a handwriting recognition engine
In fact, my ideal for FBP would be to draw diagrams on paper (or whiteboard) and then input them using a scanner.
I know that this can be done, because my Apple Newton (ca. mid-1990's) accepted hand-drawn diagrams and "fixed them up".
If you want, you can play with the FLOSS Xournal's shape recognizer. It works quite well.
"""
 The shape recognizer
The shape recognizer is also a special operating mode of the pen and highlighter tools. When it is enabled, Xournal attempts to recognize geometric shapes as they are drawn, and if successful will replace the drawn strokes accordingly. The shapes that can be recognized are: line segments, circles, rectangles, arrows, triangles and quadrilaterals. Polygonal shapes can be drawn in a single stroke or in a sequence of consecutive strokes.
The recognizer is set to be as unobtrusive as possible, and should not interfere too much with handwriting. (It differs in this and other ways from another shape recognizer written for Xournal by Lukasz Kaiser). As a result, it may only recognize shapes if you draw them carefully and deliberately. Specific tips for better recognition: (1) for circles, a closed curve that isn't quite round works better than a rounder curve that doesn't close; (2) for arrows, it is better to lift the pen before drawing the tip of the arrow, and make sure the tip consists of two straight line segments; (3) for very elongated rectangles, recognition tends to be better if you lift the pen between consecutive sides.
"""
http://xournal.sourceforge.net/manual.html
"""
 The shape recognizer
The shape recognizer is also a special operating mode of the pen and highlighter tools. When it is enabled, Xournal attempts to recognize geometric shapes as they are drawn, and if successful will replace the drawn strokes accordingly. The shapes that can be recognized are: line segments, circles, rectangles, arrows, triangles and quadrilaterals. Polygonal shapes can be drawn in a single stroke or in a sequence of consecutive strokes.
The recognizer is set to be as unobtrusive as possible, and should not interfere too much with handwriting. (It differs in this and other ways from another shape recognizer written for Xournal by Lukasz Kaiser). As a result, it may only recognize shapes if you draw them carefully and deliberately. Specific tips for better recognition: (1) for circles, a closed curve that isn't quite round works better than a rounder curve that doesn't close; (2) for arrows, it is better to lift the pen before drawing the tip of the arrow, and make sure the tip consists of two straight line segments; (3) for very elongated rectangles, recognition tends to be better if you lift the pen between consecutive sides.
"""
http://xournal.sourceforge.net/manual.html
> I might not want to limit my editors serialization formats to valid FBP programs, but I'm pretty sure that I do want to limit its serialization formats to valid di-graphs.Why?
This sounds like untested opinion.
I'm sorry that I didn't back up my opinion. This very much is not an untested opinion. I have worked with every FLOSS diagram editor which I can find and which is available as well as a few non-free ones for Windows. I have had the consistent experience that diagram editors which allow more freedom than a simple di-graph require me to switch too often between the keyboard and mouse. I have to first drag out some boxes and lines with a mouse or stylus, and then fill in the text of the boxes, clicking on each one, or tabbing between them.
However, diagram editors which do limit the user to valid di-graphs seem quite effective. There are two varieties which work well IMO:
1. The first requires you to create a bunch of nodes, using the keyboard. Later, one switches to the mouse and connects up those nodes.
You can see an example here: http://skov.software/en/
By limiting the user to valid di-graphs, the UI can be very simple.
2. The second allows the user to navigate the graph using the arrow keys, adding leaf nodes. This is basically just a tree editor, later the user can create loops by using a special connection command. The best known example of this is Ted Nelson's ZigZag editor, which after some sort of disagreement between Nelson and his programmers (apparently quite a viscous one) has been basically destroyed/eliminated from existence. There is a clone/continuation of this editor done by some of the original ZigZag programmers here: http://fenfire.org/ though it also does not run in its current form I have used it and it is very effective. If you are very interested, I can build you a working copy but this would take me several hours of work, so only if you're dying for it. If you are interested in the lurid details of the Nelson experimental software design sitcom there are some hints here http://lambda-the-ultimate.org/node/233
I am also working on such an editor. I don't have anything presentable yet, however I have a video on my website which demonstrates a very early version, basically 45 minutes of very simple live coding. http://thobbs.cz/tg/tg.html
Since that video was made, the editor and ecosystem have advanced significantly, however, they are still in a very much alpha state. I will be publishing more about the system shortly, but for now, besides the video, there is nothing worth looking at.
I have, however, found that the use of the very simple file-format has allowed me to very quickly add support for new tools. It is actually easier than using a text-based language from a tooling standpoint, because essentially no parsing is required.
I used to opine about strong typing. I *thought* it would help me. Instead it hindered my design. Architecture matters more than coding. Code is cheap. Architecture is hard.
We went all the way back to very primitive diagram elements - straight line, curvy line, ellipse, text, point - and found this to be extremely workable. Back in the '80's, it was thought "impossible" to use a backtracking parser, but nowadays it is laughably simple (my favourite is PAIP Prolog for Common Lisp). We've done it in a browser using JS, too. Extremely simple drawing elements, sent to the server for compiling.
The point of all this simplicity is - simplicity.
And flexibility.
What if it makes more sense to represent the innards of a component as a ping-pong diagram (aka Sequence Chart, see Harel's "Come, Let's Play")? Using a simple, keyboard-based drawing tool, I could draw it. Then I would use a different 2D parser and analyzer to figure out what the diagram means and what code should be emitted.
pt
While I certainly grant that di-graphs are not the be-all-and-end-all of everything, I personally am convinced that for flow based programming they are the best representation, and a representation for which effective editors and tooling can be easily created. I now firmly believe that by limiting ourselves to digraphs with utf-8 textual vertex and edge labels, we can simplify the parsers across the entire FBP ecosystem and that this will allow us to focus on more pressing questions, such as the visualization and manipulation of such graphs, and additional language features for FBP and other graph based programming paradigms.
The text based langauges currently rule the world. The fact is, that in the realm of general purpose programming there is not a single non-text based language. I believe that this is due to the universal nature of text-based tooling as well as the simplicity of the format. Text is used for functional programming, stack based programming, flow based programming, imperative programming, schemas, query languages, logic languages, constraint solvers. And when I write in Python, I don't use a python editor, I use vi. And when I write in Haskell, I don't use a Haskell editor, I use vi, and when I write a manual, I don't use a manual editor, I use vi. But when I try to use noflo.js, all of a sudden, I'm not using vi anymore. I'm not even using a universal editor, I'm using an editor specially designed for flow based programming. And that editor cannot be used for any other type of programming, and the version control mechanisms are either weird and non-native (version control on a text based representation) or unique and non-universal. And when I want to run grep on the code, or do some sort of larger search and replace scheme, I have to either revert to text or build new tools.
But if noflo didn't think of itself as being totally unique and special, and rather realized that it is a digraph language, which should be edited with a universal digraph editor, using universal digraph tooling... These problems wouldn't occurre. And and I would be able to use the same editors and tooling for:
- FBP
- Control flow graphs
- Non-fbp dataflow
- GNU-Make style dataflow / dependency resolution driven execution
- Systemd service management
- Lisp-like/functional function composition
- Hierarchical/semi-hierarchical documents akin to html.
- OOP class hierarchies/graphs
- The static representation of data-structures
- The description of molecules
- Maps that can be used by blind people which describe how the sidewalks connect in a graph
- Social network analysis
- Supply chain analysis
- ect.
With a UNIVERSAL digraph format, an ecosystem of digraph tooling and editors could rule all of these problem spaces, just as text rules the entire universe of general purpose programming today.
That is my dream,
I will be presenting my continued work on the textgraph ecosystem along with a working editor and basic tooling soon.
Tim
Paul Tarvydas
Jan 16, 2017, 4:25:39 PM1/16/17
to flow-based-...@googlegroups.com
On 2017-01-11 09:26 AM, timtheli0n wrote:
> http://xournal.sourceforge.net/manual.html
Thanks.
> very early version, basically 45 minutes of very simple live coding.
> http://thobbs.cz/tg/tg.html
I've watched the video 1.n times and I'm sure that there is something I
don't understand.
It appears that you've made new major mode (if it's called that) for vi.
There seem to be 3 main fields on the screen. I suspect that something
hasn't clicked for me. Can you describe their purpose?
thanks
pt
> http://xournal.sourceforge.net/manual.html
Thanks.
> very early version, basically 45 minutes of very simple live coding.
> http://thobbs.cz/tg/tg.html
don't understand.
It appears that you've made new major mode (if it's called that) for vi.
There seem to be 3 main fields on the screen. I suspect that something
hasn't clicked for me. Can you describe their purpose?
thanks
pt
timtheli0n
Jan 17, 2017, 5:34:24 PM1/17/17
to Flow Based Programming
Well, vi isn't programmable, so I have to write everything from scratch. But it could be a major mode for emacs if I still remembered how to write elisp. There are two ways of thinking of the myopic graph editor. One is to think of it like looking at a city with one way streets using google map's street view. In this model you have 4 screen regions
1. The stack area is used as a kind of clipboard in order to connect vertexes. In order to connect one vertex to another, you add the first vertex to the stack area, navigate to the second vertex, and issue the connect command. You can of course add multiple vertexes to the stack at one time.
2. The incomming streets. Imagine that you are standing at an intersection with 4 one way streets, two facing the intersection and two going away from it. The two comming into the intersection will come into the incomming streets area.
3. The current vertex's label. Or the textual "contents" of the intersection.
4. The outgoing streets/connections/edges.
The second way of thinking about this editor, is by imagining org mode, used to edit an infinite tree. You convert a graph to an infinite tree by way of lazy loop unrolling.
I know that this seems like a bad way of editing graphs on the face of it. And with the current, buggy, editor, I do find it to be frustrating sometimes. However, I have implemented the entire editor, along with a very simple self hosting compiler for a graph based controll flow language (piggy-backing on python) using the editor and toolset. The editor's graph has 450 nodes, and I just cannot imagine drawing and editing a graph of that size using any other editor I have worked with. Using DRAKON editor or gnome dia to draw a 450 node graph would drive me truely insane.
Attached are some maps of the editor's source and the self hosting compiler, so you can understand the kinds of grahps I can create and edit reasonably with the myopic grpah editor.
You might notice that the mge.svg file is mostly hierarchical, but its hierarchy is broken by several "comment" conections between the keypress methods of the various objects. These comment lines can be removed by using an external filter command to create mge-nocomments.svg and they can also be extracted using the same filter command to create keymap-hierarchy.svg. The filter command is only 52 lines of python code, has no external dependencies on any textgraph specific parsers and is a good example of the power of using an extremely simple file format!
The editor can also be used to easilly edit graphs which cannot be easilly drawn, such as the mge-config.svg file. This doesn't look like horrible spaggetti in the editor the way it looks in the svg, and there is a lot of logic to having a graph like this. In different modes different sets of keys are mapped to commands which are sometimes shared between modes. This is a simple logical mapping. Far simpler conceptually than some kind of bastardization of this simple idea that would be required by a typical hierarchical config file. The editor is more powerful even, than our pitiful abilites when it comes to drawing non-planar graphs on flat surfaces using computer algorithms ;P
1. The stack area is used as a kind of clipboard in order to connect vertexes. In order to connect one vertex to another, you add the first vertex to the stack area, navigate to the second vertex, and issue the connect command. You can of course add multiple vertexes to the stack at one time.
2. The incomming streets. Imagine that you are standing at an intersection with 4 one way streets, two facing the intersection and two going away from it. The two comming into the intersection will come into the incomming streets area.
3. The current vertex's label. Or the textual "contents" of the intersection.
4. The outgoing streets/connections/edges.
The second way of thinking about this editor, is by imagining org mode, used to edit an infinite tree. You convert a graph to an infinite tree by way of lazy loop unrolling.
I know that this seems like a bad way of editing graphs on the face of it. And with the current, buggy, editor, I do find it to be frustrating sometimes. However, I have implemented the entire editor, along with a very simple self hosting compiler for a graph based controll flow language (piggy-backing on python) using the editor and toolset. The editor's graph has 450 nodes, and I just cannot imagine drawing and editing a graph of that size using any other editor I have worked with. Using DRAKON editor or gnome dia to draw a 450 node graph would drive me truely insane.
Attached are some maps of the editor's source and the self hosting compiler, so you can understand the kinds of grahps I can create and edit reasonably with the myopic grpah editor.
You might notice that the mge.svg file is mostly hierarchical, but its hierarchy is broken by several "comment" conections between the keypress methods of the various objects. These comment lines can be removed by using an external filter command to create mge-nocomments.svg and they can also be extracted using the same filter command to create keymap-hierarchy.svg. The filter command is only 52 lines of python code, has no external dependencies on any textgraph specific parsers and is a good example of the power of using an extremely simple file format!
The editor can also be used to easilly edit graphs which cannot be easilly drawn, such as the mge-config.svg file. This doesn't look like horrible spaggetti in the editor the way it looks in the svg, and there is a lot of logic to having a graph like this. In different modes different sets of keys are mapped to commands which are sometimes shared between modes. This is a simple logical mapping. Far simpler conceptually than some kind of bastardization of this simple idea that would be required by a typical hierarchical config file. The editor is more powerful even, than our pitiful abilites when it comes to drawing non-planar graphs on flat surfaces using computer algorithms ;P
timtheli0n
Jan 17, 2017, 5:37:06 PM1/17/17
to Flow Based Programming
If you want to see the svgs properly, it seems you'll have to download them and open them in an external viewer. The google drive viewer doesn't seem capable of drawing svgs of that size...
timtheli0n
Jan 18, 2017, 6:34:44 AM1/18/17
to Flow Based Programming
Another way of understanding the mge is by first looking at a text based file manager such as midnight commander:
http://www.ibiblio.org/mc/images/mc-view-vfs.png
You will see that you can edit the file contents in one section. In another section, you have a directory listing starting with a .. entry, (sometimes followed by a . entry) and then a list of files in the directory. Now imagine if rather than there being only one .. entry, there was a full list of all symlinks pointing to the directory. Finally, imagine if there was no distinction between directories and files, that every directory had a text file associated with it, and every text file could contain links to other text files/directories.
http://www.ibiblio.org/mc/images/mc-view-vfs.png
You will see that you can edit the file contents in one section. In another section, you have a directory listing starting with a .. entry, (sometimes followed by a . entry) and then a list of files in the directory. Now imagine if rather than there being only one .. entry, there was a full list of all symlinks pointing to the directory. Finally, imagine if there was no distinction between directories and files, that every directory had a text file associated with it, and every text file could contain links to other text files/directories.
Paul Tarvydas
Jan 29, 2017, 5:38:33 PM1/29/17
to flow-based-...@googlegroups.com
[Sorry about the delay in responding. Expect further delays, my
schedule has become crazy.]
You haven't convinced me yet, but I do remain interested.
Some questions / comments:
- Why are the arcs numbered?
- The diagrams look to be much too detailed. I treat 2D as a syntax for
a language of s/w architecture. IMO, the diagrams should hide
complexity using diagrammatic hierarchy. E.g. about 7 boxes on any
level, punch down into a box to see what it is comprised of (e.g. about
7 more boxes, or code in leaf nodes).
- Why display code in the boxes? An indicator ("this box contains
code") of some kind would be enough.
- "Using DRAKON editor or gnome dia to draw a 450 node graph would drive
me truly insane." Yes. But, if you think of diagrams as syntax, then a
450 node graph is already a non-starter.
- You seem to prove that GraphViz is completely unusable as a syntax. I
concur.
pt
schedule has become crazy.]
You haven't convinced me yet, but I do remain interested.
Some questions / comments:
- Why are the arcs numbered?
- The diagrams look to be much too detailed. I treat 2D as a syntax for
a language of s/w architecture. IMO, the diagrams should hide
complexity using diagrammatic hierarchy. E.g. about 7 boxes on any
level, punch down into a box to see what it is comprised of (e.g. about
7 more boxes, or code in leaf nodes).
- Why display code in the boxes? An indicator ("this box contains
code") of some kind would be enough.
- "Using DRAKON editor or gnome dia to draw a 450 node graph would drive
me truly insane." Yes. But, if you think of diagrams as syntax, then a
450 node graph is already a non-starter.
- You seem to prove that GraphViz is completely unusable as a syntax. I
concur.
pt
Reply all
Reply to author
Forward
0 new messages