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

21–30 of 50 posts

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

#21

Post by cjfd »

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 hope not. The 'advancement' from text editing to something else would in all likelihood not be an advancement at all but a retardation instead. There is a reason that the invention of writing is the basis of civilization. The only way for leaving text editing to be left behind is if all these big companies forbid ordinary users to do any programming besides a very dumbed-down/graphical version of it. I am sure they would very much like this but it would be a form of tyranny.

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

#22

Post by KineticLensman »

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.

> spatial, visual, and tactile senses

What about our olfactory senses, for code smells?

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

#23

Post by jcelerier »

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 ?

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

#24

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…

10. Conclusions

Visual Programming and Program Visualization are interesting areas that show promise for improving the programming process, especially for non-programmers, but more work needs to be done. The success of spreadsheets demonstrates that if we find the appropriate paradigms, graphical techniques can revolutionize the way people interact with computers.

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

#25

Post by Firadeoclus »

cjfd wrote: post #21
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 hope not. The 'advancement' from text editing to something else would in all likelihood not be an advancement at all but a retardation instead. There is a reason that the invention of writing is the basis of civilization. The only way for leaving text editing to be left behind is if all these big companies forbid ordinary users to do any programming besides a very dumbed-down/graphical version of it. I am sure they…

"Plain text" writing using a "text editor", is much more limited in its expressiveness than writing on a piece of paper. There is no reason to believe that a character grid somehow is the pinnacle of programming.

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

#26

Post by ArnoVW »

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 ?

If you ask me : because I can "scan" in 10 seconds a page of different replies, something which would be impossible to do visually or aurally.

This is why 10-minute videos of "how to" in programming always enrage me. Though of course it makes a lot of sense for visual tasks such as 3D animation.

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

#27

Post by djedr »

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", and a few others.

Looking back I still think that the most promising direction when it comes to real-world applications of visual programming is the hybrid approach: make a language which has "real-time" interchangeable text and visual representations -- you get the best of both worlds this way (that was basically the topic of my thesis[1]).

I thought it was an original idea when I started out with my research, but sure enough there were attempts in the past. And towards the end (4+ years ago) I discovered a fresh one which seems to be still going strong, albeit rebranded: https://github.com/enso-org Last time I checked they were making what I consider a bad design choice by leaving the structuring of the visual representation entirely up to the user, but maybe that's fixed now.

Anyway I think it's a cool topic and worth keeping an eye on.

[1] If anyone is interested it's available here: https://djedr.github.io/masters_thesis.pdf

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

#28

Post by wdanilo »

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 have credit risk analysis". This way authors of workflows are able to navigate trough hierarchical graphs really, really fast, knowing where are things they have designed. With auto-generated layouts, the layout can change drastically when you apply even small semantic changes (like when you pass a new parameter between two nodes), and thus, it will break this mental space-mapping between nodes positions and their responsivities.

Anyway, we are building Enso in a completely open way, allowing third-party auto-layouting algorithms to manage the graph visual layout, and we are very open to investigate it further - that's why I asked this question :)

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

#29

Post by djedr »

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…

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. They would appreciate the automation and would be discouraged by the lack of it. Same as in text languages/IDEs.

Of course it's totally fine if your audience does not care about such features or they are not a priority.

But for a good general-purpose system I think that would be a must.

Now the sweet spot is not trivial to achieve and I haven't completely solved it, but I feel it can be done and I'd invest in researching it.

PS I hope your project succeeds!

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

#30

Post by pavlov »

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 ?

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."

Post reply on HN