Our component is a javascript modeule with a process command that gets called when the component is activated.
I would strongly recommend using DrawFBP and JavaFBP - DrawFBP lets you draw your network, automatically generate the Java for it, compile and run it! What's not to like?! Bob Corrick in England has produced a number of easy to follow YouTube videos demonstrating this process (do a find on DrawFBP). In other words do not use rhei.js for anything."! I thought that was great! In comparison, I do not understand why people (other than David) so often decide to build their own implementations. Lastly, I understand why David built his own micro-FBP, but he says, ". You ask, "Or I just need to start the network, then I need to do a loop inside each element for ever?" I would have thought this was obvious - in a factory, do you ask if the bottling machine runs forever? It just runs until it requires maintenance, or is switched off on weekends, or whatever - user's choice! That's what an FBP app is: multiple machines running concurrently! David mentions my paper contrasting these, but I will repeat the link here. , which tries to highlight the difference between doing a rather basic FBP function in "real" FBP on the one hand, and "FBP-inspired" on the other. Without node-fibers, I find JS, with all its extensions, very hard to work with - plus, I really don't like typeless! There is an interesting discussion between some JS gurus about "promises", etc. I don't understand the appeal of JavaScript - I find it almost unmaintainable! If I have to use JS, I prefer to base my software on node-fibers - see. JavaFBP is one implementation - I like it because it plays nicely with DrawFBP, but FBP is language-agnostic. don't know why you say there is too much Java - the book has very few references to Java. 3, I feel it would have at least got you started on the concepts. you say you started reading my book - if you had read Chap. However, I don't quite know what to make of your own post - maybe some of the other readers would care to weigh in!
Quite agree! The "fun" aspect is one that we keep running into with FBP users! Can we model our programs on factory machinesĪnd conveyor-belts, focusing on data? Yes! When we do, we gain many ofĪnd I think that's worth at least thinking about." We write them in such a way that they can be infinitely reconfigurable,Ĭonnected externally? Yep. Write functions/modules that can be viewed as "black boxes"? Sure. Has many advantages over textual programming, I think the real lesson toīe learned here is: "how should we think about our programs?" Can we "While FBP is certainly useful, and fun to create programs with, and
0 kommentar(er)
