The UI looks neat, but the kickstarter video was a mixed bag. Did somebody tell a bunch of people to talk very loudly? Was that the plan to make it "engaging"? Because it did unfortunately have a touch of bro-gramming.*
I'm not sure whether it really is the killer approach to writing software. Where I do see it is in customization. A lot of business logic programming relies on offering flexibility on an intermediary level. Providing the right components for software integrators seems like a very good idea. You'll still need text-based programmers to do the grunt- and architectural work, of course. Because no matter what the fancy graphics convey: Somebody is going to need to sit in front of a screen and type text into an editor.
Finally - all this and no online demo to check out? Am I missing the crucial link?
*Not all of it did - I'm not going to call J Paul Morrison a bro-grammer - but I really don't need people to seem worked up in a video at all. It just seems somewhat artificial, like a comedian dying of laughter from a joke they have already told to hundreds of audiences.
"If your bottom-line is dependent on code, you know the angst of asking a programmer, “How long will {{ insert feature }} take?” You know programmers can jargon-speak their way to your consent and when everything comes crashing down, you are to blame. NoFlo frees your businesses from a labyrinth of text files so you can get-a-grip on what-the-hell-is-going-on!"
Really? Really?
[Post Downvoting] No seriously - If you tell people that NoFlo is the solution to prevent programmers from "jargon-speaking" their way to your doom then... Sorry, that's just a lie with a topping of polarization.
The way to prevent programmers messing up your business is to not hire shit programmers and manage good programmers properly. Not hiring the programmers with the fanciest visualization.
I am not sure the kickstart video was designed for the target audience. Sorry, but "boxes and arrows" are not enough to convey what NoFlo actually is.
If anything, it reminds me of UML, even though I know it is not the same thing. But it does not get more technical than "boxes and arrows", so it is not possible to understand what it actually is all about.
The video is way, way dumbed down. It's supposed to be a tool, so explain how the tool works and what it does. A subway metaphor is not enough - we have had those every since UML came along.
Having said that, I think we need to be able to have multiple representations for code. Text is only one of the possibilities.
Fully agreed - I think the main problem of NoFlo is that I'm not sure who they're trying to get on board. Developers will be put off by the appeal for "popular" platforms and the dumbing down. But I'm not sure who else but developers is supposed to care about this stuff?
That's why I highlighted the "jargon" bit in my other reply - It seems like they have identified "people who manage or contract developers" as one (or maybe even "the") target audience.
I think that's worrying - at least if it is carried out in this tone. A good developer shouldn't need fancy flow charts to convey to you that she can or does deliver what you pay her to do. It might be what people want to have - "If only somebody would solve this problem that I cannot understand developers and they're always misleading me" - but that doesn't mean that you should pander to it. Because at its worst, you're simply giving out fancier tools for misleading clients.
Yeah, the video was to marketing-y for me to trust putting money into noflo. I've lived in (and hated) dataflow programming languages in the past (notably labview).
There's some core features I need (notably being able to do diffs/merge) to trust a dataflow language. Noflo doesn't really clarify this in their video or website.
I downvoted you because though I think your post is helpful, there's a lot of unnecessary negativity and it overwhelms the good. Point being, this is a really interesting project and they are showing an implementation of Jekyll in node, which is a boon to all of us non-ruby guys who want a solid blog engine we can hack on (e.g. for local management of posts), yet still be able to maintain compatibility with Github Pages' vanilla engine.
So thanks noflo guys, keep up the good work with the open source community.
Not sure whether there is some unwritten rule that a comment has to precisely balance positive and negative points.
I didn't even talk about a node.js Jekyll - neither positive nor negative points - I thought it was clear that I was opening a general thread of discussion about NoFlo. So I'm really not getting how that downvote is warranted. I usually don't write replies like this one, but I actually spend some time trying to properly phrase my argument to prevent somebody from seeing it as "just the typical HN snark". So I don't know - that offhanded downvote irks me.
I upvoted pretty much every other comment of yours, and the discussion thread is indeed good, but I downvoted the top-level because you decided to focus on certain aspects (mostly negative) and I disagree that such focus is warranted for the top-voted comment on this thread. There's no rule to balance anything, but I wish the top comment was more balanced, that's all there is to it.
Your post is about using NoFlo to rebuild Jekyll. So you're saying that you did that without the UI? If yes, that's not really rebuilding Jekyll in NoFlo. If no - sharing an interface that I can try and tweak is the single best way to quell concerns and incite support.
I might have a use case for a flow UI - not FBP, but a niche of an application that might be best suited to be administered with precisely this kind of flow UI. Pretty soon, I will have to make a decision on what to use there. NoFlo looks like a very strong contender, but I've had a couple of them, even with mature codebases, that turned out to be nice in theory, but not usable in practice.
NoFlo is an engine first of all... And now we're building a UI for it. But that doesn't change the fact that you can still create flows in text if you really want to :-)
But I have to admit, I wished we had the UI every step of this project!
That's the thing - I would probably end up having to write my own "NoFlo engine" since I'd only care about using it in a different (non-nodejs, non-smartphone) context. I linked to the meemoo demo above and I did like that one, even though it does have tons of bugs.
What I'm getting at is this: A good, reusable component-graph interface is a very strong pull for all those people who care about that part without being particularly interested in the server behind it. It could make your kickstarter that much more effective to make it clear that it's about making it simple to write your own engine implementation.
Screw your stretch goals* - the 250k level should be you providing a good-as-apple-pie API/documentation/support that others can write implementations for/with. Instead making it about particular implementations - Android, iOS, Python - smells a little like marketing speak. If you really believe in FBD, all you have to do is make it very simple for people to pick up the threads. You'd have tons of implementations in no time.
*Also: I don't get the stretch goals in general. I get what you try to achieve with them, but you need to look at them form a programmers perspective: What if I'm a Python programmer who wants NoFlow? Do I have to call all the people I know who care about Android or iOS so I can get to my $1M level? That's not going to happen. Likewise, Android devs won't really care about pushing it further once their level is achieved, likewise for iOS. It's a bit confusing.
Dataflow is our pre-alpha graph editor. There is a little bit of glue that connects it to NoFlo, and we're designing it to be easy to connect to other contexts. Jump in if you have suggestions: https://github.com/meemoo/dataflow/issues
https://news.ycombinator.com/item?id=6139509
https://news.ycombinator.com/item?id=6144951
The UI looks neat, but the kickstarter video was a mixed bag. Did somebody tell a bunch of people to talk very loudly? Was that the plan to make it "engaging"? Because it did unfortunately have a touch of bro-gramming.*
I'm not sure whether it really is the killer approach to writing software. Where I do see it is in customization. A lot of business logic programming relies on offering flexibility on an intermediary level. Providing the right components for software integrators seems like a very good idea. You'll still need text-based programmers to do the grunt- and architectural work, of course. Because no matter what the fancy graphics convey: Somebody is going to need to sit in front of a screen and type text into an editor.
Finally - all this and no online demo to check out? Am I missing the crucial link?
[Edit] Found this: http://meemoo.org/dataflow/
*Not all of it did - I'm not going to call J Paul Morrison a bro-grammer - but I really don't need people to seem worked up in a video at all. It just seems somewhat artificial, like a comedian dying of laughter from a joke they have already told to hundreds of audiences.