Hacker News Reader

Comment by doorhammer | Hacker News Reader

I haven't read the rest of the article, but I got to that phrase and my disposition instantly turned from "huh, this is interesting" to "snake oil", whether deserved or not.

Reminds me of the recent "One weird trick!" article [0] and lines like, "the simple solution dietitians don't want you to know!"

Content aside, that kind of thing immediately sets off alarms for me.

[0] http://www.slate.com/articles/business/moneybox/2013/07/how_...

View on HN

For me it's the fact that I've seen this whole spiel a lot of times already, in EVERY DETAIL. Visual programming will save us all. Nonprogrammers should be able to program. Suppressed, blah blah blah. For something so revolutionary, it sure is some awfully-well-trodden ground. And I don't just mean that this is an old paradigm, I mean this spiel is well-trodden ground.

In a nutshell, it doesn't work. Using Fred Brook's venerable terminology, the essential complexity of programming is too difficult for nonprogrammers. Even if you entirely get rid of the accidental complexity... and visual layout does not do that, it's full of incidental complexity involved in the layout itself... you still can't get non-programmers into a programming situation, and trying to get them into a concurrent programming situation is just sheer insanity.

And we know it doesn't work because it has been tried. Over and over. Ad naseum, as in, yeah, I'm sick of hearing these ideas as The Answer as if nobody has ever heard of these before. Tell me what's different about your solution and all the other people who have tried this.

I agree with you about the visual-layout-makes-programming-easy spiel, but it does seem like there might be a little more to flow-based programming than that. At least a few smart people seem to take it seriously (e.g. on LtU), and dataflow as a computational paradigm has a lot of research behind it and hasn't seen a whole lot of implementation. It's not out of the question that someone could apply it in a new way that would make some classes of application easier to build. I'm open to that and would find it interesting. But after having looked repeatedly for an intelligible technical explanation of FBP, I'm starting to think that the idea is either a trivial repackaging of a well-known model (like Unix pipes, or CSP with directed graphs) or is better shelved with the snake oil. The fact that it's typically accompanied by rather sensational language is not a point in its favour.

Edit: it's too bad that the programming model is getting lumped in here with the visual programming schtick. Those are two different things. (Of course the former would get no PR without the latter.)

To be clear, I fine with their attempt to make any product they intend to make. I'm very skeptical about it due to the fact that it's been tried a lot, but hey, their money, their choice, maybe they'll make it stick, maybe they'll make a niche market work (LabVIEW, etc), who knows. It's the rhetoric I'm objecting to. Which bodes poorly, IMHO; if they really believe this gibberish then it's more likely they'll make some very bad business decisions, such as resisting finding a good niche in favor of trying to take over too much stuff. There's a lot of prior art to learn from here, and if they've learned as little of it as that marketing spiel implies, their odds of success are very, very low.

I consider this an instance of stream programming.

Do you think of stream programming as a kind of dataflow programming? If not, what's the difference?

I suppose "dataflow" is an overloaded term, and the fact that its various meanings have quite a bit in common doesn't help.

Definitely, yes. In section 2 of this paper, I tried to explain how our language is related to what are typically called "synchronous dataflow" languages, or just SDF languages: http://www.scott-a-s.com/files/pact2012.pdf

Slide 11 of this talk makes the same point, but with less words: http://www.scott-a-s.com/files/debs2013_tutorial_slides.pdf

Data flow when used as a converse of control flow is quite well defined. Are you thinking in terms of how data flows across the system or in terms of control? Stream programming usually uses data flow at the top level and control flow in the atomic components connected together (we can have compound components that involve more data flow). Once you add control lines to your system, however, you are basically re-encoding explicit control flow as data flow.

I might have been unclear; what I meant was that the different programming languages or models that people call "dataflow programming" (spreadsheets, Lucid, Oz, FBP, etc.) have a lot of differences between them; and on top of those there is dataflow analysis in compilers, dataflow hardware architectures, and so on.

Data-flow is a broad term that doesn't mean one specific thing, but it is usually used correctly in what it means; e.g. data-flow analysis contrasts nicely with control-flow analysis. I don't find it confusing.

I believe FBP primarily deals with data flow, not control flow, but the "flow" in FBP seems to be left intentionally ambiguous.

This reminds me of my experiences learning programming and web development. For a while I used Drupal for everything, because it allowed me to 'program without programming'. The views module (now in core drupal, or slated to be, I think), is essentially a visual query builder.

What I discovered after a while, was that there was a tiny sweet spot where it was nice to do complicated things without writing code, but that it had huge drawbacks. Queries became ridiculous, for one.

And very soon, the stuff I'd build using the Views module was 'complicated' enough conceptually that a normal SQL query would not only be much faster, but easier and quicker to write. The fact that this query could be version-controlled and didn't live in a database was nice too...

Agreed. It's easier to teach someone python than it is to teach a programmer visual programming.

It's interesting that business processes are often described as input, process, output. Whether a human or a machine accomplishes the process is another discussion. But what is not unique is that designing the process, it's all still another process. The downside is that not knowing how to effectively scale a process is the harder problem that may require different, more scalable tools later.

Move fast and break things. Replace what breaks with stronger pieces until it doesn't.

> Reminds me of the recent "One weird trick!" article [0] and lines like, "the simple solution dietitians don't want you to know!"

Computer scientists hate him!

Reply on news.ycombinator.com