41–50 of 51 posts
I would like to know if NoFlo is being bootstrapped, i.e. are NoFlo developers actively using NoFlo to further develop NoFlo? Some video of this type of development process would be an amazing proof-of-value.
Watching the Kickstarter video, it felt very forced. I get that you are trying to revolutionize programming, but try not to keep telling me that and instead show me. I feel that if you had a screen cast of working on a simple demo application (longer than 10-15 seconds), it would've conveyed the message of how powerful NoFlo really is, much better. I'm not trying to take away from all the work you've done (it looks l…
http://c2.com/cgi/wiki?ActorsAndFlowBasedProgrammingDiscussi...
One big difference between actors and FBP is that actors can give feedback whereas flow-based programs can only send data from one port to another (so, providing feedback to the process feeding it information requires the creation of an input port on the feeder and a feedback output port on the processor...)
As with anything else, FBP isn't a hammer that turns everything else into a nail, but it's an interesting architectural pattern. I'll be curious to see their noflo-based Jekyll replacement.
This reminds me of Quartz Composer[1] in a lot of ways: you wire the inputs and outputs of a bunch of different nodes together (called patches in QC) and each patch gets you a step closer to the solution. This seems to work especially well for graphics programming type problems where there are many different variables to tweak and you're applying many transformations to the image at each stage. The problem is each co…
I think this is a great idea, but experience is everything, as others have stated, the diagrams presented still have quite the learning curve, knowing what names connect where. I think if NoFlo allowed actual coding through a visual interface like Scratch, with the ability to group components into functions and classes, this could really go somewhere.
Throwing this out there, I have shelved a similar web-based project that did this with Verilog designs, which lends itself more naturally to this struture imo. I stopped because I don't believe there's a big enough market for it. That, and I wasn't sure how to tackle the problem of thousands of I/Os in a visual format (would make things real hard to see).
[innerHTML "hello"] -> [div]Looks like an interesting way to enforce the pattern of testable, reusable components for developers that tend to end up with spaghetti code. However, I think it's a little dubious to say that designers without coding experience will suddenly become empowered to contribute to the code base (or write their own applications) in any meaningful way. Looking at one of the sample pictures on the Kick Starter page I see Anc…
What would have happened if the question had been rephrased to "Ok, you have stop car, start car and check car. What do you do to restart a car"? Perhaps they would have done a lot better because they have a better understanding of the car domain. The purpose of a visual language is not to replace domain experience. If you put me in front of a drawing program with a pallet of red, blue and green and ask me to create…
I still think that connecting up a hundred little boxes is just as complicated as actually looking at code syntax, but even more so since everything is a black box. How do you suggest people fix errors in the output when the only action they can take is to connect boxes with lines?
Looks like an interesting way to enforce the pattern of testable, reusable components for developers that tend to end up with spaghetti code. However, I think it's a little dubious to say that designers without coding experience will suddenly become empowered to contribute to the code base (or write their own applications) in any meaningful way. Looking at one of the sample pictures on the Kick Starter page I see Anc…
The tools for interactive prototyping for designers will be built on the foundation that we're building now. So the draggable/spring example could be inside of a black box that exposes the important variables. Designers can use that box as-is, but there is very little friction to seeing and experimenting with how it works inside.
Earlier quoted context omitted.
What would have happened if the question had been rephrased to "Ok, you have stop car, start car and check car. What do you do to restart a car"? Perhaps they would have done a lot better because they have a better understanding of the car domain. The purpose of a visual language is not to replace domain experience. If you put me in front of a drawing program with a pallet of red, blue and green and ask me to create…
The participants in the study were IT professionals that managed servers for a living. Servers and actions regarding servers were definitely within their domain experience. So we did exactly what you were suggesting we did. I still think that connecting up a hundred little boxes is just as complicated as actually looking at code syntax, but even more so since everything is a black box. How do you suggest people fix e…
Or with the circuit board metaphor, a debug "probe" that would show the data (or a graph of data) traveling through that point.
Different debugging tools will make sense in different domains, but we're considering the challenge.
Fundamentally, forcing yourself to do visual programming like this, is like tying one arm behind your back. It's so impossibly difficult, that you'll demand that the tools you use are the best quality, and intelligently solve as many of the problems at your layer as possible.
The truth is, if developers insisted on good tools with good abstractions, they'd achieve all of the supposed benefits of visual programming.
Most developers forget they're responsible for making their own living space well-organized. They just code, leaving a mess everywhere.