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

Visual Programming – Why It’s a Bad Idea

mikehadlow.blogspot.com

Post reply on HN
Print view View original

71–80 of 122 posts

Re: Visual Programming – Why It’s a Bad Idea

#71

Post by blululu »

Junk_Collector wrote: post #63
blululu wrote: post #57

Earlier quoted context omitted.

Having spent a lot of time using Labview I would agree that it can be an amazingly useful tool (highly performant code and easily interfaces with data acquisition devices). That being said, LabView shows the limitations of Visual Coding: Sharp Learning Curve Difficult to find help or code snippets online Lack of decent Version Control Finding the function you want is hard (requires navigating several submenus) *All o…

Some of your complaints come from the fact that LabVIEW is pretty niche. It would need at least an order of magnitude more developers to see numbers like C/C++. That's why you're not finding much online help. There is also the fact that LabVIEW is old. Like REALLY old. LabVIEW came out over 30 years ago and as such has a lot of legacy cruft along with lacking some of the more modern goals such as good scaling source…

Fair points. A lot of the issues with Visual Programming are related to the supporting tools - something the author mentions. That being said, text input easily supports search, pattern matching and code sharing, so what are the benefits to visual coding to justify building all these tools?

In my experience it is harder to implement good programing practices in a visual programing environment. For example, abstracting, consolidating and refactoring visual code is much more challenging because of the sprawl of wires...

Re: Visual Programming – Why It’s a Bad Idea

#72

Post by the_af »

crimsonalucard wrote: post #33

Last I heard text is visual... so then what is text but a form of visual programming? In essence text is visual programming limited to set of symbols and tokens parsed in left to right order. Who said that this arbitrary set of rules is the best way to represent programming logic? The number of concepts for abstraction encompass many things in the visual realm. Graphs, procedures, arrows and even 3D space can be used…

> Last I heard text is visual... so then what is text but a form of visual programming?

But the author of TFA defines what he means: "A visual programming language is one that allows the programmer to create programs by manipulating graphical elements rather than typing textual commands."

Re: Visual Programming – Why It’s a Bad Idea

#73

Post by DonHopkins »

baldfat wrote: post #70

Matrix/EA used a visual language for Spore. http://puredata.info/exhibition Pure Data (Pd) is a visual programming language developed by Miller Puckette in the 1990s for creating interactive computer music and multimedia works https://en.wikipedia.org/wiki/Pure_Data This is the one shinning example where a visual language actually accomplishes something that a general language can't not. Make programming accessible t…

Also, Cycling '74's Max is a commercial visual programming language that shares a lot of concepts and designs with PD (which you could think of as a free implementation of Max, but ideas have flowed both ways).

https://cycling74.com/

On the topic of procedural sound, you might enjoy this talk about Generative Systems with Will Wright and Brian Eno:

https://www.youtube.com/watch?v=UqzVSvqXJYg

At Maxis, we also developed a bespoke visual programming language for The Sims (first used in SimCopter), called "SimAntics".

We never officially released "Edith", the version of The Sims with the object editing and visual programming tools built in, but users have reversed engineered the byte code, and developed text based tools for programming custom objects with SimAntics.

http://simantics.wikidot.com/wiki:introduction-to-simantics

http://modthesims.info/wiki.php?title=SimAntics

Here's a transcript and video demonstrating it:

The Sims, Pie Menus, Edith Editing, and SimAntics Visual Programming Demo

This is a demonstration of the pie menus, architectural editing tools, and Edith visual programming tools that Don Hopkins developed for The Sims with Will Wright at Maxis and Electronic Arts.

Link to "Edith Sims Programming Tool" section:

https://medium.com/@donhopkins/the-sims-pie-menus-49ca02a74d...

Re: Visual Programming – Why It’s a Bad Idea

#74

Post by seanmcdirmid »

DonHopkins wrote: post #67
gambler wrote: post #9

There is more to visual programming than simple wire diagrams and "code-blocks-as-visual-blocks": https://www.youtube.com/watch?v=6orsmFndx_o https://www.youtube.com/watch?v=I9LZ6TnSP40 https://alumni.media.mit.edu/~mt/thesis/mt-thesis-Contents.h... http://worrydream.com/ And yes, this: http://www.fantasticcontraption.com/ This is not 100% real programming, because it does not include sensors, but you do create const…

There's so much interesting prior work! I really enjoyed this paper “A Taxonomy of Simulation Software: A work in progress” from Learning Technology Review by Kurt Schmucker at Apple. It covered many of my favorite systems. http://donhopkins.com/home/documents/taxonomy.pdf It reminds me of the much more modern an comprehensive "Gadget Background Survey" that Chaim Gingold did at HARC, which includes Alan Kay's favori…

We could go back farther with Sutherland's SketchPad (early 60s) and Smith's Pygmalion (mid 70s).

There are also a lot of disparate visual programming paradigms that are all classed under "visual", I guess in the same way that both Haskell and Java are "textual". It makes for a weird debate when one party in a conversation is thinking about patch/wire dataflow languages as the primary VPLs (e.g. QuartzComposer) and the other one is thinking about procedural block languages (e.g. Scratch) as the primary VPLs.

Re: Visual Programming – Why It’s a Bad Idea

#75

Post by gnode »

I remember the first programming languages I used (when I was very young) were visual. I think Flowol at primary (elementary) school was the first. They gave me a pretty much instant understanding of how imperative programming worked. Admittedly, I never created anything practically useful in it, but what's important is that I could imagine, from early in my life, what programming could do / was for, and put it on my cognitive radar.

As a child I was more inspired by seeing the inner workings of something than being told X was possible if you learn to code. Visual languages can better expose the guts of the working automaton.

That said, I agree that [current] visual programming languages have shortcomings that limit them to simple / educational scenarios.

Re: Visual Programming – Why It’s a Bad Idea

#76

Post by henrikeh »

jakelazaroff wrote: post #53
kpil wrote: post #39

Earlier quoted context omitted.

I disagree that DSLs are the right choice unless it's an extension to the suitably flexible implementation language itself. Actually, the perceived need for "dumb" DSLs is sprung from the same misconceptions as mentioned in the article and the end result is inevitably that simple problems are made somewhat simpler and complex problems turn into impossible problems. A proper DSL extension in an unobtrusive host langua…

Obviously these are sweeping statements, but the problem with this generalization is that successful DSLs become invisible because we take them for granted. Regular expressions are a DSL. SQL is a DSL. LaTeX is a DSL. The Wikipedia page on domain-specific languages even lists HTML as an example: https://en.wikipedia.org/wiki/Domain-specific_language#Examp... With regard to LaTeX or HTML, you could even argue that the…

Geometric constraint solvers are essentially graphical, declarative domain-specific languages for mechanical/physical design. As an example: http://solvespace.com/index.pl

Re: Visual Programming – Why It’s a Bad Idea

#78

Post by stinos »

jki275 wrote: post #38
alliecat wrote: post #34

Earlier quoted context omitted.

Don't be rude. LabVIEW is used in production in a lot of serious environments.

I've been in those environments. I've had to try to repair horrific "code" written in it. I've participated in "code reviews" where the straightness of the lines was carefully assessed in the massive mess of spaghetti code they had created and thought was good code. LabVIEW is a toy for EEs to write prototypes in. That would have been okay if it had stayed there -- but the problem is that people are actually distribu…

I still don't get why you call it a toy, or just for prototypes. Maybe think somewhat broader and not just about the bad experience(s) you had with it. For the things it's good at, it just works and it's pretty hard to find alternatives (well, Measurement Studio is ok, but for simple things it's usually still a bit more work than Labview). The hard part is figuring out what Labview is good at and not make the mistake of trying to use it for everything. Sound like that's where most of your bad experiences come from.

Here's an example of a place where Labview just shines: I needed something to plot 'rolling' analog and digital signals, i.e. basically provide a visualization of the inputs of a combined analog/digital input card. With ability to pause the thing, each line in a different color, data cursors, ... The data is acquired by C++ code, but since Labview has this stuff built in getting the whole thing up and running is just a matter of setting up a communication protocol between the C++ part and Labview. I just went for TCP/IP and got the thing up and running in a couple of hours. Has been used like that for years now. Not exactly a prototype, nor a toy. It just does this one thing, it's all we needed, and it does it extremely good.

Re: Visual Programming – Why It’s a Bad Idea

#79

Post by DonHopkins »

seanmcdirmid wrote: post #74
DonHopkins wrote: post #67

Earlier quoted context omitted.

There's so much interesting prior work! I really enjoyed this paper “A Taxonomy of Simulation Software: A work in progress” from Learning Technology Review by Kurt Schmucker at Apple. It covered many of my favorite systems. http://donhopkins.com/home/documents/taxonomy.pdf It reminds me of the much more modern an comprehensive "Gadget Background Survey" that Chaim Gingold did at HARC, which includes Alan Kay's favori…

We could go back farther with Sutherland's SketchPad (early 60s) and Smith's Pygmalion (mid 70s). There are also a lot of disparate visual programming paradigms that are all classed under "visual", I guess in the same way that both Haskell and Java are "textual". It makes for a weird debate when one party in a conversation is thinking about patch/wire dataflow languages as the primary VPLs (e.g. QuartzComposer) and t…

Absolutely, their important work foreshadowed and inspired so much great stuff. Also Douglas Engelbart's NLS pioneered many of the ideas of visual programming.

I think spreadsheets also qualify as visual programming languages, because they're two-dimensional and grid based in a way that one-dimensional textual programming languages aren't.

The grid enables them to use relative and absolute 2D addressing, so you can copy and paste formulae between cells, so they're reusable and relocatable. And you can enter addresses and operands by pointing and clicking and dragging, instead of (or as well as) typing text.

Some people mistakenly assume visual programming languages necessarily don't use text, or that they must use icons and wires, so they don't consider spreadsheets to be visual programming languages.

Spreadsheets are a wildly successful (and extremely popular) example of a visual programming language that doesn't forsake all the advantages of text based languages, but builds on top of them instead.

And their widespread use and success disproves the theory that visual programming languages are esoteric or obscure or not as powerful as text based languages.

Other more esoteric, graphical, grid-based visual programming languages include cellular automata (which von Neumann explored), and more recently "robust first computing" architectures like the Moveable Feast Machine.

https://en.wikipedia.org/wiki/Von_Neumann_cellular_automaton

https://en.wikipedia.org/wiki/Von_Neumann_universal_construc...

Robust-first Computing: Distributed City Generation (Moveable Feast)

https://www.youtube.com/watch?v=XkSXERxucPc

>A rough video demo of Trent R. Small's procedural city generation dynamics in the Movable Feast Machine simulator. See http://nm8.us/q for more information. Apologies for the poor audio!

Programming the Movable Feast Machine with λ-Codons

https://www.youtube.com/watch?v=DauJ51CTIq8

>λ-Codons provide a mechanism for describing arbitrary computations in the Movable Feast Machine (MFM). A collection of λ-Codon molecules describe the computation by a series of primitive functions. Evaluator particles carry along a stack of memory (which initially contains the input to the program) and visit the λ-Codons, which they interpret as functions and apply to their stacks. When the program completes, they transmute into output particles and carry the answer to the output terminals (left).

Re: Visual Programming – Why It’s a Bad Idea

#80

Post by zby »

weberc2 wrote: post #50

I'm not a visual programming proponent, but I don't think this article does a very good job of supporting its thesis. It exclusively makes claims about current VP implementations and tries to extrapolate them to VP in the abstract, but I think these are all non-sequiturs. I specifically think the article fails to distinguish between the dual problems of _modeling a program_ (hard) and representing that model visually…

"Why can't a visual programming language be functional?" - there is one: https://luna-lang.org/ and it also has a dual textual/visual representation.
Post reply on HN