Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Visual Programming Is Unbelievable (2015)

outsystems.com

Post reply on HN
Print view View original

71–80 of 107 posts

Re: Visual Programming Is Unbelievable (2015)

#71

Post by hacker_9 »

TuringTest wrote: post #67
hacker_9 wrote: post #64

Earlier quoted context omitted.

Bret Victor's ideas lack a lot more than that. Complex systems contain hundreds of sub systems which in turn can contain hundreds of algorithms, which then contain many many variables. All interacting in some way. His ideas simply don't scale to this level (he works with Chris Granger himself stopped working on LightTable because he didn't believe in the project, and if you use it, the live editing gives minimal gain…

Why do you think that doesn't scale? Hiding information is the basis for progressive disclosure, which is essential to handling the limitations of short-term human memory. Wikipedia is card-based,* and it is one of the five largest sites in the web. See Cognitive Dimensions[1] for ways to make visual systems scale. As soon as you add encapsulation and abstraction, the system can scale; it's no different than hiding c…

Wikipedia is also written in English, and made for human consumption. English is infinitely more scalable than any programming language, and the brain is far more capable of understanding than a computer. So comparing the two is unfair to say the least.

Additionally simply adding 'encapsulation and abstraction' does not equal scale. Live programming for instance requires context and re-running of code on every edit (and we could be talking millions of lines of code that need to execute), re-reading of data files, re-running of prior user input and so on. There's a reason it is only implemented for small systems (read, useless practically).

Re: Visual Programming Is Unbelievable (2015)

#72

Post by failrate »

Danieru wrote: post #22

At work we use a blend of C++ with Unreal Engine's visual programming language Blueprints. I am going to be honest with you guys here: I love blueprints. They are very limited compared, lacking even maps. When it comes to connecting existing behavior together they are king. Consider the parts of game development which cannot be made generic. By sticking those in Blueprints we get nice high level code.

I was a skeptic of visual programming, but experience has taught me that Blueprints is a good enough language for a large set of tasks.

Re: Visual Programming Is Unbelievable (2015)

#73

Post by TuringTest »

hacker_9 wrote: post #71
TuringTest wrote: post #67

Earlier quoted context omitted.

Why do you think that doesn't scale? Hiding information is the basis for progressive disclosure, which is essential to handling the limitations of short-term human memory. Wikipedia is card-based,* and it is one of the five largest sites in the web. See Cognitive Dimensions[1] for ways to make visual systems scale. As soon as you add encapsulation and abstraction, the system can scale; it's no different than hiding c…

Wikipedia is also written in English, and made for human consumption. English is infinitely more scalable than any programming language, and the brain is far more capable of understanding than a computer. So comparing the two is unfair to say the least. Additionally simply adding 'encapsulation and abstraction' does not equal scale. Live programming for instance requires context and re-running of code on every edit (…

> English is infinitely more scalable than any programming language, and the brain is far more capable of understanding than a computer. So comparing the two is unfair to say the least.

IMHO programming a large system shouldn't be all that different from writing an encyclopedia, or rather a math textbook; the same combination of informal explanation and formal demonstrations could be the shape that "visual" programs could take. Literate programming is written in English, and it provides much of the same advantages of the encyclopedia or technical book. Systems like IPython / Jupyter work in that direction, and they belong in the family of visual programming (although they use "classic" languages for the formal part, nothing stops them from also including graphical models as part of the code specification).

Programming languages should be made for human consumption, and one of the promises of visual languages is that they use secondary notation to convey the meaning of the program, so that parts that are not visible to the compiler are still relevant.

I believe that programming environments should converge towards a hybrid of programming, using the best representation for each concept - like text (to represent abstract concepts), diagrams (to represent more physical properties - time, data flows, and dependencies between modules), and raw text for the human-readable comments that explain how everything is tied together. If you build a programming environment like that, my comparison is not unfair at all.

>Live programming for instance requires context and re-running of code on every edit (and we could be talking millions of lines of code that need to execute), re-reading of data files, re-running of prior user input and so on. There's a reason it is only implemented for small systems (read, useless practically).

Modern IDEs are capable of doing a lot of that when in debug mode, I see no reason why having a language with a graphical syntax should make any difference - it just places a little more weight on the parser and graphic card.

Re: Visual Programming Is Unbelievable (2015)

#74

Post by notalaser »

DonHopkins wrote: post #51
notalaser wrote: post #27

Earlier quoted context omitted.

The Wikipedia page links to a credible article which mentions that "the software that drives it is written in C++ and consists of 200,000 lines of code for the operational system and 250,000 lines of code for the simulation systems.[2]" What am I missing?

I assume that like any mission critical benevolent guardian mega robot software, it has parts written in many different languages. It's kind of hard to count the number of lines of code written in a visual programming language. My guess is that LabView was probably used in data collection and device control, and possibly for the gui, which is what it's designed to do. I worked with someone at TomTom who worked on it…

> I assume that like any mission critical benevolent guardian mega robot software, it has parts written in many different languages.

Oh -- mine too, I'm just surprised NI's mega marketing army isn't mentioning that everywhere :-).

Also, no need to bother you colleague for me, but whoa, thanks for the presentation!

Re: Visual Programming Is Unbelievable (2015)

#75

Post by fsloth »

TuringTest wrote: post #63
hacker_9 wrote: post #57

Earlier quoted context omitted.

But at what point does simple become complex? It's all well and good saying only use it for simple tasks, but when real life complexity comes knocking, you end up with this sort of magic [1] that is far worse than any C++ I've seen in the wild. [1] http://scriptsofanotherdimension.tumblr.com

People interested in VP really, really should learn about DRAKON[1], the Russian style guide for structured dataflows. I've used it for real projects and it actually solves the spaghetti problem. Compare this:[2] with this:[3]. [1] https://en.wikipedia.org/wiki/DRAKON [2] http://scriptsofanotherdimension.tumblr.com/image/1386972466... [3] https://upload.wikimedia.org/wikipedia/commons/0/0f/Dutch_cr...

A drakon node does not seem to support multiple input values? That's why these visual graphs get convoluted. Compute nodes deal with multiple input and output connections.

Re: Visual Programming Is Unbelievable (2015)

#76

Post by rbanffy »

DonHopkins wrote: post #14
rbanffy wrote: post #10

Earlier quoted context omitted.

Not really. You still need to write formulas using a textual language.

Or selecting formulas from menus and parameters by pointing and clicking and dragging, directly manipulating rows, columns and cells, and addressing parameters by relative two-dimensional offsets.

Selecting text from lists is not visual, neither is relative 2D offsets.

Re: Visual Programming Is Unbelievable (2015)

#77

Post by thenomad »

mtanski wrote: post #9

There is one place where visual programming is alive and well and has been for a long time. That's programming PLC (Programmable Logic Controllers). It's easy to forget about PLCs[1], but it's an old and large niche in large corporations that do a lot of industrial automation like assembly lines, (automobile) manufacturing, oil & gas... Most PLC programming is done using Ladder Logic [2] and various visual tools tool…

Also 3D graphics.

Both in real-time and pre-rendered graphics, node graph-style programming languages are very much a thing. Unreal Engine's Blueprints system, Motionbuilder's nodes system, Maya's graph systems...

And they can get pretty huge and complex.

Re: Visual Programming Is Unbelievable (2015)

#78

Post by the_af »

TuringTest wrote: post #73
hacker_9 wrote: post #71

Earlier quoted context omitted.

Wikipedia is also written in English, and made for human consumption. English is infinitely more scalable than any programming language, and the brain is far more capable of understanding than a computer. So comparing the two is unfair to say the least. Additionally simply adding 'encapsulation and abstraction' does not equal scale. Live programming for instance requires context and re-running of code on every edit (…

> English is infinitely more scalable than any programming language, and the brain is far more capable of understanding than a computer. So comparing the two is unfair to say the least. IMHO programming a large system shouldn't be all that different from writing an encyclopedia, or rather a math textbook; the same combination of informal explanation and formal demonstrations could be the shape that "visual" programs…

> Programming languages should be made for human consumption

The problem here is the "impedance mistmach" between humans and computers. Wikipedia is not a good example: it is exclusively for humans. If there is a "program" for the computer, it's minimal: "search this", "when I click here, take me to this page" (you'll notice everything more complex than that, even in Wikipedia, requires its own mini-language). This is the kind of trivial systems which are easily encoded by "visual" programming.

The problem is that real computer systems need to be understood by the computer as well as by humans. In order for something to be understood by a computer, it must be specified in formal terms; English -- natural language, actually -- is terrible for this. Once you're working in a complex system with a formal language, the limitations of these "visual" tools become evident.

Re: Visual Programming Is Unbelievable (2015)

#79

Post by watty »

hacker_9 wrote: post #4

'Visual Programming' failed (and continues to fail) simply because it is a lie; just because you surround my textual code with boxes and draw arrows showing the 'flow of execution' does not make it visual! This core misunderstanding is why all these 'visual' tools suck and don't help anyone do anything practical (read: practical = complex systems). When I write code, for example a layout algorithm for a set of gui el…

Just because they haven't replaced coding in a text editors for all use cases doesn't mean they "failed". In my industry (PLC, building automation), visual programming languages are the norm and are extremely successful.

They significantly drop the barrier to entry and allow basic controlling of systems for non-programmers.

Post reply on HN