Self host at least part of the editor

[timthelion]

It would be very interesting to me to see at least part of the editor self hosted, aka created with JavaFBP. That would be a good way for me to see FBP used in the real world and would go a long way in proving the philosophy.

[jpaulm]

Hi Timothy, nice to hear from you! Your idea has been brought up before, and I continue to feel that the editor (I assume you mean DrawFBP) is not a great choice for this. There are differences in people's views about FBP, and it is certainly possible that some variants of what are called FBP or FBP-like systems (the more procedural ones) could lend themselves to this. However, my interest is in what I have started calling "classical" FBP - a highly asynchronous, streaming, component-oriented approach to application development, lending itself to distributed, multi-core computing - and I feel that DrawFBP's function isn't really a good fit. If you have played with DrawFBP, you probably realize that there are multiple listeners, which *could* generate separate streams of data being processed by asynchronous processes, but there are relatively few actual objects (blocks, connections, etc.), and a lot of interlocking "states" (component-drag, diagram-drag, editing, font-changing, component-selection, etc.). So, suppose we decided to allow one process to edit a block in the diagram, while another process looks after dragging it - would you want both these processes to be executing concurrently? It probably could work, but I'm not sure it would buy you much... at the cost of significantly increased complexity. OTOH, it would probably be trivial to put all of DrawFBP into a single FBP process, and then stream various outputs out into an FBP network - possible candidates might be the various language generation modules... Would this be of interest to you? If so, please let me know, and we could perhaps collaborate on something along those lines. Thanks again for your feedback - look forward to hearing from you. Regards, Paul M.

…

On Fri, Dec 30, 2016 at 7:17 PM, Timothy Hobbs ***@***.***> wrote: It would be very interesting to me to see at least part of the editor self hosted, aka created with JavaFBP. That would be a good way for me to see FBP used in the real world and would go a long way in proving the philosophy. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#11>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AATGJ7qyHcDMGAEjDYsWSSIb0UPQD-L1ks5rNZ8BgaJpZM4LYcvg> .

[timthelion]

Hi Paul,
I believe that you are convinced that FBP is a novel general purpose programming technique which can ease developement and reduce complexity. Yet here you throw up your hands and say that FBP is not a good fit. I think you may be disuaded, however, not by the dificulty of the problem, but by the GUI frameworks which you have been subjected to.

Modern GUI frameworks on the desktop are all written in what is refered to as OOP-Callback style. You have objects, such as buttons and text areas, which have event handlers(methods) which get called when some external event source calls them.

This technique is quite a natural one, and can seem like "the only way" to a person who is familiar with it. However, there are other ways of providing a graphical user interface which don't look like this at all. For example, users can interact with CGI powered web-pages and in this case, the server, rather than having a spider web of callbacks, sees itself as basically a single function/actor which takes a requst and produces a responce:

Client <-> Server
responce = f(request)

This request and responce model is far more simple than the OOP-callback method, and is more generic/flexible (you can implement the OOP-callback architecture in a webserver but you don't have to).

Would you consider FBP to be a good paradigm for writting a web server? If your answer is yes, is there a fundamental difference between that and writting an interactive editor?

Another example of a GUI architecture is that of OpenGL. OpenGL has an event loop which is usually triggered by a timer. Basically, your program runs by having its "draw" method called over and over again. This is also far simpler than the OOP-callback method. I think that the reason why we don't all write our GUIs in OpenGL has to do with edge cases, like the need to provide support for braille displays and screen readers. Otherwise, thinking about simply producing a changing image in responce to an event stream seems quite appealing to me.

If you think about the distinction between the client/server architecture and the OOP-callback architecture for GUI design, you will find that they have a very different shape.

OOP-Callback programs look like octopi (right click to view full size):

Where-as OpenGL draw loop programs look like hammocks.

My interest in the architecture of DrawFBP is somewhat accademic. I don't care how it works on the inside from the standpoint of the user. I'm more interested in how you solved the various interesting problems which occure in the real world ;) .

One project which did do interactive GUIs using discrete-packet data-flow was the early versions of elm-lang http://elm-lang.org/ http://elm-lang.org/assets/papers/concurrent-frp.pdf Don't get put off by the letters "FRP". When reading "FRP" just say "ladedadeda" in your head and everything will make sense.

[jpaulm]

Hi Timothy, Thanks for your very complete response! Actually, do you think you could post it to the Google FBP group - https://groups.google.com/forum/#!forum/flow-based-programming - and I will post my response to your response... I feel this discussion would be of interest to quite a few people... Actually I agree with you - I just wasn't seeing the split that you show in your bottom diagram as particularly significant, but I agree it should be pretty straightforward to implement. I previously mentioned the output flows, but we could certainly split the inputs and screen display out as well. At least for now, I would probably put the "FBP magic" in a single process, per user, as it it is not clear to me how that should be decomposed... As I said before, the "FBP magic" (in DrawFBP-prime) for a single user deals with relatively few objects and quite a lot of states. For instance, consider all the possible actions for a single mouse-click. One glitch might be the problem of dragging, where you probably only want to send the final mouse position over the link - actually, there is a connection attribute in JavaFBP and C#FBP that would be useful here, called "dropOldest", where older IPs are dropped if the connection is full... Yup, steam-engine time! It might be fun to try a proof-of-concept - do you think it would useful in its own right? Thanks, and best regards, Paul M.

…

On Mon, Jan 2, 2017 at 5:43 PM, Timothy Hobbs ***@***.***> wrote: Hi Paul, I believe that you are convinced that FBP is a novel general purpose programming technique which can ease developement and reduce complexity. Yet here you throw up your hands and say that FBP is not a good fit. I think you may be disuaded, however, not by the dificulty of the problem, but by the GUI frameworks which you have been subjected to. Modern GUI frameworks on the desktop are all written in what is refered to as OOP-Callback style. You have objects, such as buttons and text areas, which have event handlers(methods) which get called when some external event source calls them. This technique is quite a natural one, and can seem like "the only way" to a person who is familiar with it. However, there are other ways of providing a graphical user interface which don't look like this at all. For example, users can interact with CGI powered web-pages and in this case, the server, rather than having a spider web of callbacks, sees itself as basically a single function/actor which takes a requst and produces a responce: Client <-> Server responce = f(request) This request and responce model is far more simple than the OOP-callback method, and is more generic/flexible (you can implement the OOP-callback architecture in a webserver but you don't have to). Would you consider FBP to be a good paradigm for writting a web server? If your answer is yes, is there a fundamental difference between that and writting an interactive editor? Another example of a GUI architecture is that of OpenGL. OpenGL has an event loop which is usually triggered by a timer. Basically, your program runs by having its "draw" method called over and over again. This is also far simpler than the OOP-callback method. I think that the reason why we don't all write our GUIs in OpenGL has to do with edge cases, like the need to provide support for braille displays and screen readers. Otherwise, thinking about simply producing a changing image in responce to an event stream seems quite appealing to me. If you think about the distinction between the client/server architecture and the OOP-callback architecture for GUI design, you will find that they have a very different shape. OOP-Callback programs look like octopi (write click to view full size): [image: oop-callback] <https://cloud.githubusercontent.com/assets/1391608/21596882/f0c6ec24-d141-11e6-8556-c78be23feffa.png> Where-as OpenGL draw loop programs look like hammocks. [image: hammock] <https://cloud.githubusercontent.com/assets/1391608/21596883/f0c70272-d141-11e6-8e31-c2c18dec0d98.png> [image: procesing-engine] <https://cloud.githubusercontent.com/assets/1391608/21596884/f0c70a9c-d141-11e6-8ed9-3ff325b587a0.png> My interest in the architecture of DrawFBP is somewhat accademic. I don't care how it works on the inside from the standpoint of the user. I'm more interested in how you solved the various interesting problems which occure in the real world ;) . One project which did do interactive GUIs using discrete-packet data-flow was the early versions of elm-lang http://elm-lang.org/ http://elm-lang.org/assets/papers/concurrent-frp.pdf Don't get put off by the letters "FRP". When reading "FRP" just say "ladedadeda" in your head and everything will make sense. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AATGJyBgNlTtzHYuZv6Zpn3fPTrv26C8ks5rOX2ngaJpZM4LYcvg> .

[timthelion]

I have posted a new topic here: https://groups.google.com/forum/#!topic/flow-based-programming/CvXEkdQ-SIc

Unfortunately, it is extremely time-consuming to embed images in google groups(at least on my machine the google groups software runs incredibly slowly) and so for now I have not moved my post over there.

Regards,
Timothy