[slacka]

> Code is complex in the best of times...The Holy Grail of a visual, drag and drop environment that could create meaningful business value would have manifest years ago if it were possible or even desirable to do so. This latest attempt may end up having some limited utility for simple applications, but I'm beyond skeptical or pessimistic. This seems hopelessly naive to me.

Before Einstein showed up, most experts in the field of physics thought that they solved nearly all the major problems. It saddens me that the nascent field of CS is showing the same close-mindedness. I refuse to accept your claim that we must live with the complexity. My mom struggled with my Win Mobile 2003 smartphone. If Jobs had your attitude, she probably wouldn't be using one today. There are too many unexplored areas of CS for this defeatist attitude toward complexity.

That being said, I actually agree with most of your criticisms of visual languages on todays HW. But I have an open mind. Like what if the problem with visual languages is that they need a 3D display and a minority report/speech input for UI to resolve the spaghetti code readability issue and all your criticisms? Look at leap motion/Siri. These UIs are not that far off. See what I’m getting at?

I’m sure that with new ideas in HW and SW, we will be able to reduce the complexity of parallel programming. And even if Visual programming is a dead end, I’m thrilled to see people continuing to flush our this area. Call back hell is a real and present problem with JS, I welcome creative attempts to solve it like NoFlo.

[davesims]

The Einstein example is a non sequitur. This isn't a technical, algorithmic or scientific problem that needs special genius. Where's the 3D rendering of Relativity that makes E=MC2 perfectly comprehensible for the masses? Or is that defeatist?

Neither is the problem with representation. We've had 3D visualization for years -- spaghetti flying at you in perfectly rendered HD 3D is still spaghetti.

The problem is not with the technology, but in the subjective perception of complex domains, and the real world fact that codebases tend to be more unclear than not, acquire massive amounts of technical debt, and even the cleanest codebases, in pure Uncle Bob and GOF-approved architectural clarity, present a cognitive domain that requires a lot of specialization to understand.

It's like saying -- what if the problem with understanding French is that we need better visual representations of French? Cool -- that might help the French and other Francophiles, but it doesn't remove the conceptual barrier and basic training required to understand the underlying language.

Likewise, if I presented you with a perfect 3D model (whatever that means) of my pub/sub solution built with a Reactor Pattern that messages N number of clients and takes asynchronous events from N number of other clients and persists the results of processing those messages in a sorting algorithm to a key-sorted Hash inside a NoSQL store -- you'd still have to have the conceptual vocabulary and experience to have any idea what was going on.

In other words, the issue is not an extrinsic problem that needs innovation, but a subjective problem of conceptualization that floats independent of language and implementation.

I love Steve Jobs' attitude and take inspiration from it -- he put user experience and elegance over the needs of programmers. But let's stay with Jobs for a minute. Because he was focused on user-centric experiences, the tools he left developers were serviceable but mostly afterthoughts. It was up to coders to service tools, not the other way around. XCode is not widely admired as an IDE, Objective-C is a good language but has its warts, and in general Jobs himself didn't see the biggest challenge as technical or code-centric, his innovations were mainly a finely-tuned intuition for the difference between elegant and simplistic, combined with a will, attention to detail and leadership drive to make those intuitions reality. He simplified touch interfaces, and left coders mostly to their own challenges, and I think he was right on with those priorities. In that, he totally "shared my attitude".

I do have an open mind, or I wouldn't still be coding and pushing myself to learn decades after scribbling out my first lines of BASIC on a TRS-80. But I also have enough experience with many, many codebases and have spent years learning techniques for simplifying and expressing complex domain problems. And the class of visual representation of those domains, of which NoFlo is just one more iteration, has very limited utility in that regard.

Is it possible that a better visual vocabulary for code will come along? Sure, why not? But it will be of a completely different class than what we've been presented with so far, and it certainly won't have been invented by IBM in the 70s.

[slacka]

"Everything should be made as simple as possible, but not simpler." -Einstein

We are failing to communicate here. Did you watch Bret Victor's from yesterday? I’ll do my best to explain. I said I agreed with most of your critiques on visual programming, it's your assertion that we've tried it all and just have to deal with the complexity that I was referring to. Einstein’s refusal to accept status quo, led him to that beautiful, simple equation. I was not saying that visual programming is or is not that solution. I was questioning your dismissal of it at this stage.

My 2nd point about the 3d Minory Report UI was a whimsical example of being open minded towards technology. Which is why I said "Like what if" I was trying to demonstrate a creative solution to the problem by combining it with an outside tech. I doubt it is a viable solution. On second thought, programming with a Leap Motion controller on an Oculus Rift display sounds very cool, but of course google beat me to it in the 2013 I/O.

> It's like saying -- what if the problem with understanding French is that we need better visual representations of French?

Of course, every field takes training, but some representations do have steeper learning curves. I started off learning simplified Chinese. After I changed representations to pinyin, I was able to learn words about 5-10x faster. So I don't see how your analogy holds with natural languages.

> Likewise, if I presented you with a perfect 3D model....

If you describe it in words or show me a flow chart, I will pick up the flow chart much faster. Machine code, not so fast. NoFlo does not limit you to the visual editor. You can also use FBP text language if you desire.

> But I also have enough experience with many, many codebases and have spent years learning techniques for simplifying and expressing complex domain problems. And the class of visual representation of those domains, of which NoFlo is just one more iteration, has very limited utility in that regard.

"The most dangerous thought you can have as a creative person is to think you know what you're doing." -Bret Victor

I don't know how much experience you really have with FBP like NoFlo. I have done some programming in LabVIEW, and I found it much easier to reason about concurrency than thread based languages. You may think it's a waste of time with its "limited utility" but I'm with MZT on this one, "Let a hundred flowers bloom"