Self host at least part of the editor about drawfbp HOT 4 CLOSED

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> .

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> .