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

Taxonomies of Visual Programming (1990) [pdf]

cs.cmu.edu

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Taxonomies of Visual Programming (1990) [pdf]

#41

Post by daenz »

jmiskovic wrote: post #34
daenz wrote: post #14

Earlier quoted context omitted.

I do! I am currently in the very early stages of creating a VR-based language. I believe that if we can represent programs more intuitively to our spatial, visual, and tactile senses, we can unlock more programming potential in more people.

You are designing language from scratch? Is it too early to show screenshot or a sketch? Often I get the urge to make spatial development environment, but I always envision it as lisp with 3D rendering/manipulation.

The language from scratch, yeah. I have experience with UE4, so I'm going to be using that. Too early for screenshots, I'm still in the planning phase.

Basically I'm spending my time on a whiteboard thinking up simple programs (fibonacci sequence, graph traversal, etc), then drawing them out how I imagine they could be represented in a 3d environment. From that, I am distilling ideas of how to represent data types and algorithms in a way that doesn't look like spaghetti.

Re: Taxonomies of Visual Programming (1990) [pdf]

#42

Post by BradAMyers »

jpaulmorrison wrote: post #37
DonHopkins wrote: post #17

Earlier quoted context omitted.

By the way, something I always meant to ask you, Brad: How does "C32" fit into your acronym theme of gemstones and rocks? Is it a teeny tiny 4x4x2 carbon atom block of diamond? How many carats would that be? >Brad Myers wrote several articles in that book about his work on PERIDOT and GARNET, and he also developed C32: >C32: CMU's Clever and Compelling Contribution to Computer Science in CommonLisp which is Customiza…

That's a great acronym, but IMHO the acronym I came up with for the first iteration of FBP was also pretty good: DOORMAT (Data-Oriented Organization Running Multiple Asynchronous Tasks)! However, it was deemed to be lacking in gravitas!

C32 doesn't follow the general convention of my group of naming after gemstones or kinds of minerals, but I think it is fun. Very few of our systems strive for gravitas!

Re: Taxonomies of Visual Programming (1990) [pdf]

#43

Post by BradAMyers »

contingencies wrote: post #9
BradAMyers wrote: post #3

Thanks for your interest in my old article! That version is a draft update of this article: Brad A. Myers. "Visual Programming, Programming by Example, and Program Visualization; A Taxonomy," Proceedings SIGCHI '86: Human Factors in Computing Systems. Boston, MA. April 13-17, 1986. pp. 59-66. http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf

Have you been made aware of any interesting later developments? How do you view the current landscape, eg. minecraft, scratch, blockly, kodu, etc.?

I do try to follow the field. There are lots of modern VPs and some commercial successes. The key "large-scale" VPs are LabView from National Instruments, and OutSystems. There are a lot of what nowadays are called "No Code" or "Low Code" environments, that are mostly VPs as well - see https://en.wikipedia.org/wiki/No-code_development_platform

Re: Taxonomies of Visual Programming (1990) [pdf]

#44

Post by contingencies »

BradAMyers wrote: post #43
contingencies wrote: post #9

Earlier quoted context omitted.

Have you been made aware of any interesting later developments? How do you view the current landscape, eg. minecraft, scratch, blockly, kodu, etc.?

I do try to follow the field. There are lots of modern VPs and some commercial successes. The key "large-scale" VPs are LabView from National Instruments, and OutSystems. There are a lot of what nowadays are called "No Code" or "Low Code" environments, that are mostly VPs as well - see https://en.wikipedia.org/wiki/No-code_development_platform

LabView seems constrained to the electronics/signals world. For that sort focus-area interface, Blender has a similar 'flow' graph based programming mechanism for its filters. I think this is common in digital audio authoring apps too. I was not aware of OutSystems, it seems like it's basically VB for webapps.

Re: Taxonomies of Visual Programming (1990) [pdf]

#45

Post by otabdeveloper4 »

pavlov wrote: post #33
otabdeveloper4 wrote: post #31

Earlier quoted context omitted.

No, software isn't models. Software is text written in a mathematical language. Doing a visual interpretation of math (or interpretative dance, or a song, etc) isn't going to end in anything useful.

Individual programs are text, but useful software systems are models.

Which means that software documentation should use spatial visualization tricks, not the coding process.

Which is what we kind of have now, except that really nobody wants to use software documentation.

Re: Taxonomies of Visual Programming (1990) [pdf]

#46

Post by DonHopkins »

BradAMyers wrote: post #42
jpaulmorrison wrote: post #37

Earlier quoted context omitted.

That's a great acronym, but IMHO the acronym I came up with for the first iteration of FBP was also pretty good: DOORMAT (Data-Oriented Organization Running Multiple Asynchronous Tasks)! However, it was deemed to be lacking in gravitas!

C32 doesn't follow the general convention of my group of naming after gemstones or kinds of minerals, but I think it is fun. Very few of our systems strive for gravitas!

My transparently paned contribution of "GLASS" for "Graphical Layer And Server Simplifier" was technically a mineral, but not a very precious one. But it was great for making windows! Too bad it kept shattering because ugly X11 was on one side of it and beautiful Lisp was on the other. But at least you can cut "GLASS" to make fake gemstones of "PASTE".

https://www.gemselect.com/english/other-info/paste-gems.php

Did you ever write any projects in Ruby? ;)

Re: Taxonomies of Visual Programming (1990) [pdf]

#47

Post by jcelerier »

IOT_Apprentice wrote: post #36
otabdeveloper4 wrote: post #31

Earlier quoted context omitted.

No, software isn't models. Software is text written in a mathematical language. Doing a visual interpretation of math (or interpretative dance, or a song, etc) isn't going to end in anything useful.

Software is currently described by written text that is transformed by other process (compilers/interpreters) to a different state and then executed. Often the execution does not work as expected due to undefined conditions or states within the "mathematical language", or misunderstanding of the scope or memory allocation or release, etc. There certainly could and should be visual representations of state, memory uti…

> Often the execution does not work as expected due to undefined conditions or states within the "mathematical language", or misunderstanding of the scope or memory allocation or release, etc.

nah, 90%+ of bugs are already present in the "paper" specification in my experience, without any programming language involved (and I'm mostly writing in C++ which is prone to the issues you mention).

Re: Taxonomies of Visual Programming (1990) [pdf]

#48

Post by jpaulmorrison »

wdanilo wrote: post #39
jpaulmorrison wrote: post #38

Earlier quoted context omitted.

Soon after starting work on what later became Flow-Based Programming (FBP), I decided that I should leave the block layout entirely up to the application developer... A few years later, James Martin (1981) was working on what he called 4th-generation languages, and the blocks were prone to moving around unpredictably as the text was changed... Very confusing, as people do like things to stay where they are put! This…

Paul, its such an honor to see your reply here! I'm a big fan of your work and your Flow-Based Programming book. It was one of the most important inspirations to what I'm doing in my life now (Enso: https://www.youtube.com/channel/UC4oMK7cL1ElfNR_OhS-YQAw ). I truly love the arguments that you use there and how you describe how visual programming can unlock the communication between users of different backgrounds (bu…

Thanks for the kind words - it's a real boost when someone talks about how my work has influenced them! I would be happy to have a chat - are you in the UK? If so, we are 5 hours behind you, so we can plan a chat time accordingly... We could start the ball rolling by you pinging me at jpaulmorr@gmail.com ...

I took a look at your first (?) video, and IMO the human factors are amazing! That said, however, our areas of application seem a little different: at least your video is mostly talking about numbers, and I assume a mostly synchronous world view, whereas my work uses data objects ("Information Packets") travelling between asynchronously executing components... Given your orientation, it makes sense to be able to flip back and forth between visual and text representations - not sure it makes as much as sense in my environment! However, Chuck, IIRC, in one of the projects I worked on, built a network of around 200 processes, without drawing a single picture!

Talk soon!

Re: Taxonomies of Visual Programming (1990) [pdf]

#49

Post by DonHopkins »

DonHopkins wrote: post #19

Brad Myers' paper answers the age-old argument about whether or not spreadsheets are visual programming languages! https://news.ycombinator.com/item?id=20425821 >DonHopkins on July 13, 2019 | on: I was wrong about spreadsheets (2017) >Google sheets (and other google docs) can be programmed in "serverless" JavaScript that runs in the cloud somewhere. It's hellishly slow making sheets API calls, though. Feels like some…

Here's an example of a thread where somebody was fruitlessly trying to argue that a spreadsheet isn't a visual programming language:

https://news.ycombinator.com/item?id=22984831

>lmm 9 months ago | on: Maybe visual programming is the answer, maybe not

>If there was a visual programming language with anywhere near the popularity of Ruby, I'd be willing to consider that maybe the idea has some merit.

>DonHopkins 9 months ago [–]

>Excel.

>I could turn your argument around: If Ruby were anywhere near as popular, widely used, and successful as Excel, I'd be willing to consider that maybe the idea that Ruby is a viable programming language has some merit.

>But I won't, because whether or not something is a visual programming language isn't up to a popularity contest.

>Can you come up with a plausible definition of visual programming languages that excludes Excel, without being so hopelessly contrived and gerrymandered that it also arbitrarily excludes other visual programming languages?

[...] (TL;DR: he couldn't, since he was under the mistaken impression that Excel not programmable, and was less popular than Ruby...)

That thread was on an earlier discussion about a blog posting from 2020 about the same 1989 paper by Brad Myers that we're currently discussing.

https://news.ycombinator.com/item?id=22978454

https://blog.metaobject.com/2020/04/maybe-visual-programming...

>Maybe Visual Programming is The Answer. Maybe Not

>Whenever discussing problems with programming today and potential solutions, invariably someone will pop up and declare that the problem is obviously the fact that programs are linear text and if only programming were visual, all problems would immediately disappear in some unspecified way.

>I understand the attraction of visual programming, particularly for visual thinkers. However, it's not as if this hasn't been tried, with so far very limited success. Brad Myers, in his 1989 paper Taxonomies of Visual Programming gave, along with the titular taxonomy, a non-exhaustive summary of the problems, starting with visual languages in general:

[...]

Re: Taxonomies of Visual Programming (1990) [pdf]

#50

Post by mpweiher »

DonHopkins wrote: post #16
BradAMyers wrote: post #3

Thanks for your interest in my old article! That version is a draft update of this article: Brad A. Myers. "Visual Programming, Programming by Example, and Program Visualization; A Taxonomy," Proceedings SIGCHI '86: Human Factors in Computing Systems. Boston, MA. April 13-17, 1986. pp. 59-66. http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf

Hey Brad! Can you believe it's been 29 years since we worked together when I was visiting the Garnet group at CMU? Thank you for that wonderful opportunity, I really learned a lot from it. It's such a rare treat to actually be paid to write Lisp code! About four years ago I mentioned Garnet on HN and linked to an article I wrote about it called "Constraints and Prototypes in Garnet and Laszlo", and your "All the Widg…

Great list, thanks!

One of my favourite quotes: "Constraints are like structured programming for variables". https://web.archive.org/web/20070422104545/http://www.donhop...

Post reply on HN