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

31–40 of 50 posts

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

#31

Post by otabdeveloper4 »

pavlov wrote: post #30
jcelerier wrote: post #23

Earlier quoted context omitted.

Think about it: why are you writing a textual comment right now and not sending a picture, video, sound clip of your message ? That would be much less "silent film"-ish, no ?

Text is a good medium for communicating stories and ideas, but software systems are primarily models. Other engineering professions make heavy use of visual modeling tools. Oddly, the industry that builds these tools is itself "the barefoot shoemaker."

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.

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

#32

Post by DonHopkins »

KineticLensman wrote: post #22
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.

> spatial, visual, and tactile senses What about our olfactory senses, for code smells?

iSmell!

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

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

>Losing your sense of smell and taste is a symptom of COVID-19!

>Too bad the iSmell never took off and became ubiquitous, or it could be used to screen for COVID-19 symptoms.

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

https://www.wired.com/1999/11/digiscent/

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

#33

Post by pavlov »

otabdeveloper4 wrote: post #31
pavlov wrote: post #30

Earlier quoted context omitted.

Text is a good medium for communicating stories and ideas, but software systems are primarily models. Other engineering professions make heavy use of visual modeling tools. Oddly, the industry that builds these tools is itself "the barefoot shoemaker."

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.

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

#34

Post by jmiskovic »

daenz wrote: post #14
haunter wrote: post #11

Does anyone feel we are still in the silent film era of computer programming? Will we ever advance from text editors into something else and leave Vim, Emacs etc. forever behind for good?

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.

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

#35

Post by IOT_Apprentice »

jcelerier wrote: post #23
haunter wrote: post #11

Does anyone feel we are still in the silent film era of computer programming? Will we ever advance from text editors into something else and leave Vim, Emacs etc. forever behind for good?

Think about it: why are you writing a textual comment right now and not sending a picture, video, sound clip of your message ? That would be much less "silent film"-ish, no ?

Like TikTok?

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

#36

Post by IOT_Apprentice »

otabdeveloper4 wrote: post #31
pavlov wrote: post #30

Earlier quoted context omitted.

Text is a good medium for communicating stories and ideas, but software systems are primarily models. Other engineering professions make heavy use of visual modeling tools. Oddly, the industry that builds these tools is itself "the barefoot shoemaker."

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 utilization, registers, variable values and execution sequence based on the textual conditions described. Contrasts of expected execution vs actual.

Perhaps using GPT-3 that is taught each programming language and then a designer can specify the behavior and GPT-X* can build a solution that can be formally verified as provable. Then generate test cases and show the flow and proof of correct execution based on test conditions.

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

#37

Post by jpaulmorrison »

DonHopkins wrote: post #17
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

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!

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

#38

Post by jpaulmorrison »

wdanilo wrote: post #28
djedr wrote: post #27

Cool stuff. Wish I found this a few years ago when I dug into this topic for a thesis. Back then I analyzed this incredible resource (warning: clicking this link will load looots of images): http://blog.interfacevision.com/design/design-visual-progarm... and came up with my own provisional taxonomy where major categories were "Line-connected block-based", "Snap-together block-based", "List-based", "Enhanced text", an…

@djder thanks for referring to us (Enso)! The topic you mentioned - leaving the graph structure (layout?) entirely up to the user - why do you feel it is a bad choice? In our experience (strongly influenced by VFX tools, like Sidefx Houdini), people are designing the 2D workspace similar to how you structure your code. For example, "on left top corner we will have database filtering", "on right bottom space we will h…

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 actually fits in with the idea of "loci" alluded to elsewhere in this page. In FBP, "stepwise refinement" is a key part of the design process, so you get a hierarchy of simple structures... I agree that you could add a function to "prettify" your diagram(s), but this should still be under the developer's control. And if you make it simple to move blocks around (as in DrawFBP), it's probably not worth the trouble!

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

#39

Post by wdanilo »

jpaulmorrison wrote: post #38
wdanilo wrote: post #28

Earlier quoted context omitted.

@djder thanks for referring to us (Enso)! The topic you mentioned - leaving the graph structure (layout?) entirely up to the user - why do you feel it is a bad choice? In our experience (strongly influenced by VFX tools, like Sidefx Houdini), people are designing the 2D workspace similar to how you structure your code. For example, "on left top corner we will have database filtering", "on right bottom space we will h…

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 (business people, developers, etc).

To be honest, I was thinking about contacting you, Paul, for a long time already, however, I always felt like we are not yet in the stage of the development to bother you. Right now, when we are very close to Enso 2.0 public release, I would truly love to spend an hour with you on a call – I'll write an email to you about it and I hope you'll agree to chat with us! :)

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

#40

Post by wdanilo »

djedr wrote: post #29
wdanilo wrote: post #28

Earlier quoted context omitted.

@djder thanks for referring to us (Enso)! The topic you mentioned - leaving the graph structure (layout?) entirely up to the user - why do you feel it is a bad choice? In our experience (strongly influenced by VFX tools, like Sidefx Houdini), people are designing the 2D workspace similar to how you structure your code. For example, "on left top corner we will have database filtering", "on right bottom space we will h…

Hey, thanks for the response. :) I see it as analogous to structuring source code text. The sweet spot IMO lies in the place where the editor offers guidance for common use-cases (think auto-indent, on-demand auto-format), but allows you to arrange code in a non-standard way when appropriate. That I think would be ideal. Not all good programmers care about maintaining perfect visual order and I think that's fine. The…

I fully agree that the visual environment should arrange the newly created graph nodes in a nice way automatically. In the Enso 2.0 version we have a very early support implemented exactly for that. However, there is a lot to be done yet to have it working fluently in the case of bigger and complex graphs. It is a fascinating research topic for me, TBH.

Thank you for nice words! <3

Post reply on HN