11 ms·

Taxonomies of Visual Programming (1990) [pdf]

107 points by mr_tyzic 6y ago

haunter 6y ago
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?
- kens 6y ago
  The 80-column IBM punch card was invented in 1928 and here we are almost 100 years later writing programs as a sequence of 80-column lines of text. It seems pretty obvious to me that we're stuck in a local maximum. I don't think visual programming is the solution but there must be another alternative. Sort of like how databases are based on text but are much more than text.
  - DonHopkins 6y ago
    What we don't need are 160-column punched cards. The proper response to "640K ought to be enough for anybody" is virtual memory, not 1280K. People used to complain about Macromedia Director only having 24 layers, so they increased it to 48. But then what are you supposed to do if you want to make a map of the United States: leave out Alaska and Hawaii?
- daenz 6y ago
  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.
  - hour_glass 6y ago
    Awesome, what changes can VR bring to a coding environment? It would certainly be cool to fly around and observe a complicated network of code in action.
  - KineticLensman 6y ago
    > spatial, visual, and tactile senses What about our olfactory senses, for code smells?
    - DonHopkins 6y ago
      iSmell! https://news.ycombinator.com/item?id=17476460 https://news.ycombinator.com/item?id=17476460 https://news.ycombinator.com/item?id=24853659 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://en.wikipedia.org/wiki/ISmell https://www.wired.com/1999/11/digiscent/ https://www.wired.com/1999/11/digiscent/
  - jmiskovic 6y ago
    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.
    - daenz 6y ago
      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.
- cjfd 6y ago
  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.
  - Firadeoclus 6y ago
    "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.
- jcelerier 6y ago
  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 ?
  - ArnoVW 6y ago
    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.
  - pavlov 6y ago
    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."
    - otabdeveloper4 6y ago
      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.
      - pavlov 6y ago
        Individual programs are text, but useful software systems are models.
        otabdeveloper4 6y ago
        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.
      - 6y ago
DonHopkins 6y ago
Brad Myers' paper answers the age-old argument about whether or not spreadsheets are visual programming languages! https://news.ycombinator.com/item?id=20425821 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 kind of remote procedure call. (Slower than driving Excel via OLE Automation even, and that's saying something!) Then it times out on a wall clock (not cpu time) limit, and breaks if you take too long. >A CS grad student friend of mine was in a programming language class, and the instructor was lecturing about visual programming languages, and claimed that there weren't any widely used visual programming languages. (This was in the late 80's, but some people are still under the same impression.) >He raised his hand and pointed out that spreadsheets qualified as visual programming languages, and were pretty darn common. >They're quite visual and popular because of their 2D spatial nature, relative and absolute 2D addressing modes, declarative functions and constraints, visual presentation of live directly manipulatable data, fonts, text attributes, background and foreground colors, lines, patterns, etc. Some even support procedural scripting languages whose statements are written in columns of cells. >Maybe "real programmers" would have accepted spreadsheets more readily had Lotus named their product "Lotus 012"? (But then normal people would have hated it!) I Was Wrong About Spreadsheets And I'm Sorry: https://www.reifyworks.com/writing/2017-01-25-i-was-wrong-about-spreadsheets-and-im-sorry https://www.reifyworks.com/writing/2017-01-25-i-was-wrong-ab... HN Discussion: https://news.ycombinator.com/item?id=20417967 https://news.ycombinator.com/item?id=20417967 Excerpt from "Taxonomies of Visual Programming and Program Visualization", by Brad A Myers, 1990/3/1, Journal of Visual Languages & Computing, Volume 1, Issue 1, pages 97-123: Spreadsheets, such as those in VisiCalc or Lotus 1-2-3, were designed to help nonprogrammers manage finances. Spreadsheets incorporate programming features and can be made to do general purpose calculations [71] and therefore qualify as a very-high level Visual Programming Language. Some of the reasons that spreadsheets are so popular are (from [43] and [1]): 1. the graphics on the screen use familiar, concrete, and visible representation which directly maps to the user's natural model of the data, 2. they are nonmodal and interpretive and therefore provide immediate feedback, 3. they supply aggregate and high-level operations, 4. they avoid the notion of variables (all data is visible), 5. the inner world of computation is suppressed, 6. each cell typically has a single value throughout the computation, 7. they are nondeclarative and typeless, 8. consistency is automatically maintained, and 9. the order of evaluation (flow of control) is entirely derived from the declared cell dependencies. The first point differentiates spreadsheets from many other Visual Programming Languages including flowcharts which are graphical representations derived from textual (linear) languages. With spreadsheets, the original representation in graphical and there is no natural textual language. Action Graphics [41] uses ideas from spreadsheets to try to make it easier to program graphical animations. The 'Forms' system [43] uses a more conventional spreadsheet format, but adds sub-sheets (to provide procedural abstraction) which can have an unbounded size (to handle arbitrary parameters). A different style of system is SIL-ICON [49], which allows the user to construct 'iconic sentences' consisting of graphics arranged in a meaningful two-dimensional fashion, as shown in Figure 5. The SIL-ICON interpreter then parses the picture to determine what it means. The interpreter itself is generated from a description of the legal pictures, in the same way that conventional compilers can be generated from BNF descriptions of the grammar.
DonHopkins 6y ago
An important mnemonic technique that visual programming languages can exploit is called the "Method of Loci" or "Memory Palace": https://en.wikipedia.org/wiki/Method_of_loci https://en.wikipedia.org/wiki/Method_of_loci >The method of loci (loci being Latin for "places") is a strategy of memory enhancement which uses visualizations of familiar spatial environments in order to enhance the recall of information. The method of loci is also known as the memory journey, memory palace, or mind palace technique. This method is a mnemonic device adopted in ancient Roman and Greek rhetorical treatises (in the anonymous Rhetorica ad Herennium, Cicero's De Oratore, and Quintilian's Institutio Oratoria). Many memory contest champions report using this technique to recall faces, digits, and lists of words. https://news.ycombinator.com/item?id=22090159 https://news.ycombinator.com/item?id=22090159 >The Method of Loci is an ancient technique that used to be taught for thousands of years as a standard part of a classical eduction, way back when people needed to remember things before the invention of smartphones and printing presses. But in the middle ages it was banned for being immoral! Apparently, some bad apples were abusing the Method of Loci to remember "immoral" things they shouldn't be thinking about, using "fabulous" images they shouldn't be imagining. https://www.guildsomm.com/4cb697f52c/discussion_forums/f/general-discussion/9171/advanced-memory-techniques-and-how-to-apply-them https://www.guildsomm.com/4cb697f52c/discussion_forums/f/gen... >>Remember to use physical objects in these palaces since they have easily imaginable traits; when you are dealing with more abstract or untranslatable ideas it is best to convert them into objects based on the way the words sound, so Valmur becomes Val Kilmer, Les Preuses becomes purses, etc. Additionally, you don’t need to be concerned with reality when making these memory palaces. The more slapstick, unique and vivid they are, the easier they will stick. Raunchy imagery always works well, to the point where some religious orders in the middle ages banned the practice because it was deemed immoral. >Memory Palace techniques have been known as the Mind Palace, Method of Loci, and Memory Journey, Art of Memory, Ars Memorativa, Memorative Art, Mnemotechnics, Architectural Mnemonic, Graphical Mnemonic, and Textual Mnemonic. Eric Krokos, Catherine Plaisant, and Amitabh Varshney published an interesting paper about memory palaces in virtual reality, called "Virtual memory palaces: immersion aids recall" in Virtual Reality volume 23, pages 1–15 (2019). https://obj.umiacs.umd.edu/virtual_reality_study/10.1007-s10055-018-0346-3.pdf https://obj.umiacs.umd.edu/virtual_reality_study/10.1007-s10... https://news.ycombinator.com/item?id=22093072 https://news.ycombinator.com/item?id=22093072 >I visualize and remember code that way. For me, it's hard to forget somewhere I've been, even if I only imagined being there. >Each function is a little building like an office or a shop, which has a sign out front telling what services or products it sells, and contains everything inside you need to solve some kind of problem or produce some kind of product or service (where equipment in the room is like references to other objects and functions and imported libraries). >You're standing behind the front counter, just about to receive a customer though the front entrance door with the parameters you need for one particular instance of that problem. >You go into the back room, solve the problem, then deliver the results out the exit door at the back of the building (or through any of the other earlier emergency exits, if you had to exit prematurely or throw an error and run away). >The front/back flow is a metaphor for the top/bottom flow of control through a function. https://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diagram https://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diag... >>A Nassi–Shneiderman diagram (NSD) in computer programming is a graphical design representation for structured programming. This type of diagram was developed in 1972 by Isaac Nassi and Ben Shneiderman who were both graduate students at Stony Brook University. These diagrams are also called structograms, as they show a program's structures. >If you squint you can see the example Nassi-Shneiderman diagram in that article as a map of a building, with its front at the top, and exit at the bottom. >You can have internal hallways and rooms for branches and loops, like a Nassi-Shneiderman diagram. The "Sub to Determine Wiki-Article" room is like the front entrance lobby of a theater where buy your ticket. The "Select Favourite Genre" room is like the stage of The Price is Right, and you get to pick what's behind door #1 (History), #2 (Science), or # (Geography), or else choose Other. They each have one or two rooms behind them with your rewards, and then they all finally exit out to the same back stage loading dock, where you take your wonderful prize (or consolation donkey) home. Ben explained that "Nassi-Shneiderman Diagrams have peaked out a couple of decades ago, but there were a huge success story for a 15-minute invention, with hundreds of software tools, dozens of textbooks, and 1000+ papers based on them." He has a funny story about the incredibly harsh rejection letter he received when he and Ike Nassi submitted their first paper about "Nassi-Shneiderman Diagrams" to Communications of the ACM in 1972, that should serve as an "inspiration for anyone whose new ideas are rejected by some respected authorities". http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/rejection_letter.html http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/rejectio... http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/rejection_letter.pdf http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/rejectio... >Our submission of the structured flowcharts to the Communications of the ACM was quickly rejected, on October 4, 1972, by the Programming Languages Editor David Gries of Cornell University. He included a single anonymous reference letter which is on paper that has a Cornell University watermark. I assume Gries gave our paper to one of his colleagues (you can play the guessing game too), who wrote the most brutal rejection letter I have ever gotten. >The reviewer wrote: "I feel that the best thing the authors could do is collect all copies of this technical report and burn them, before anybody reads them." As graduate students, this stinging rejection shocked us, but we kept getting enthusiastic responses from people around us. We sent the paper to the unrefereed ACM SIGPLAN Notices, where it was published in August 1973. It didn't take long for others to produce extensions, software tools, and applications of structured flowcharts. >The next problem was theft of the idea. I had sent a draft to respected colleagues, and soon others published slight variations. One of these respected colleagues was Ned Chapin, who greatly troubled us by publishing what he called 'Chapin Charts.' A friend of mine sent me his published paper with a note encouraging me to sue. For several years I feared that Chapin's reputation and his frequent professional seminars would wind up leaving the idea tied to his name, but as the decades passed, the ending has proved to be a happy one. We called the idea 'structured flowcharts, but they are widely known as Nassi-Shneiderman Diagrams. >Another problem was the appearances of patents for variations on our idea, but these have not limited the widespread recognition we have gotten over the years. >I wish every graduate student or young inventor would have the pleasure of seeing his/her ideas spread so far and influence the work of so many people. I also hope that the story of the bold rejection of our novel idea and its eventual international success, is an inspiration for anyone whose new ideas are rejected by some respected authorities. More about Nassi-Shneiderman Diagrams: http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/ http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/ https://wiki.c2.com/?NassiShneidermanDiagrams https://wiki.c2.com/?NassiShneidermanDiagrams More about Ben Shneiderman: https://news.ycombinator.com/item?id=11370099 https://news.ycombinator.com/item?id=11370099 https://news.ycombinator.com/item?id=22329274 https://news.ycombinator.com/item?id=22329274 https://eagereyes.org/influences/ben-shneiderman https://eagereyes.org/influences/ben-shneiderman
djedr 6y ago
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-progarmming-languages-snapshots/ 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 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 https://djedr.github.io/masters_thesis.pdf
- wdanilo 6y ago
  @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 :)
schpaencoder 6y ago
What happened to all the visual images in this PDF?
- nikmart 6y ago
  Looks like the linked PDF was a draft (see Brad's comment) Here is the link to paper with figures http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf
  - BradAMyers 6y ago
    The journal version (1990) is a slightly updated version from the CHI Conference version (1986).
- BradAMyers 6y ago
  I found the final version: http://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf http://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf
  - dang 6y ago
    Awesome! We've changed the URL to that from https://www.cs.cmu.edu/~bam/papers/vltax2.pdf https://www.cs.cmu.edu/~bam/papers/vltax2.pdf above, and have bumped the year from 1989 to 1990. Awesome to see you in this thread too!
- hutzlibu 6y ago
  I thought it was funny, to read about Visual Programming, without actual seeing any visuals.
BradAMyers 6y ago
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 http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf
- contingencies 6y ago
  Have you been made aware of any interesting later developments? How do you view the current landscape, eg. minecraft, scratch, blockly, kodu, etc.?
  - BradAMyers 6y ago
    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 https://en.wikipedia.org/wiki/No-code_development_platform
    - contingencies 6y ago
      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.
- dgudkov 6y ago
  Are you still interested in visual programming? If yes, I would appreciate having a chat (I develop a visual programming tool).
- DonHopkins 6y ago
  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 Widgets" video, here: https://news.ycombinator.com/item?id=11232154 https://news.ycombinator.com/item?id=11232154 >Yay Garnet! ;) I worked on Garnet with Brad Myers at CMU, on the PostScript printing driver. Brad is really into mineral acronyms, and I came up with an acronym he liked: "GLASS: Graphical Layer And Server Simplifier". Constraints and Prototypes in Garnet and Laszlo (updated link) https://web.archive.org/web/20070422104545/http://www.donhopkins.com/drupal/node/69 https://web.archive.org/web/20070422104545/http://www.donhop... All the Widgets (Fixed v2) - 1990 https://www.youtube.com/watch?v=9qtd8Hc90Hw https://www.youtube.com/watch?v=9qtd8Hc90Hw Thank you for inviting me to give a guest lecture to your UI class about pie menus: https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=f0600d9d-282e-4b83-a6f4-a9f2003ad407 https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=... Just yesterday I cited Richard Potter's "Just-in-Time Programming" paper in "Watch What I Do: Programming by Demonstration" that you co-edited, as being relevant to playing Factorio! https://news.ycombinator.com/item?id=26053703 https://news.ycombinator.com/item?id=26053703 >Playing Factorio requires starting out by performing a few tasks by hand, then thinking about how to incrementally automate factories with trains, drones, combinator circuits, and blueprints, with high level modular repeatable patterns. And estimating where the break-even point is between completing a few tasks by hand, and spending the time to automate more common tasks. >That evokes an article that Richard Potter wrote about "Just-in-Time Programming" in Alan Cypher's classic book (which is now online for free), "Watch What I Do: Programming by Demonstration", about when "the user attempts to write a program for a task that is already in progress": http://acypher.com/wwid http://acypher.com/wwid >Watch What I Do: Programming by Demonstration. Edited by Allen Cypher. Co-edited by Daniel C. Halbert, David Kurlander, Henry Lieberman, David Maulsby, Brad A. Myers, and Alan Turransky. 1993. The MIT Press, Cambridge, Massachusetts, London, England. http://acypher.com/wwid/Chapters/27JITP.html http://acypher.com/wwid/Chapters/27JITP.html >Chapter 27: Just-in-Time Programming. Richard Potter. [...] I was lucky to have the pleasure of working with Richard Potter at Ben Shneiderman's Human Computer Interaction Lab at the University of Maryland, while he was developing an early version of Triggers, which he also wrote about in that book: http://acypher.com/wwid/Chapters/17Triggers.html http://acypher.com/wwid/Chapters/17Triggers.html Morgan Dixon and James Fogarty, who were working with James Landay at the University of Washington, also did some wonderful work along those lines on Prefab, which I've written about here: https://news.ycombinator.com/item?id=11520967 https://news.ycombinator.com/item?id=11520967 Also just yesterday, I enjoyed watching Dan Ingalls' talk on "Pronto: Toward a Live Designer's Notebook", in which he demonstrated how he's been exploring Programming by Demonstration in Lively! https://www.youtube.com/watch?v=if72CFsF_SY&ab_channel=YOW%21Conferences https://www.youtube.com/watch?v=if72CFsF_SY&ab_channel=YOW%2... Also, here are some other great papers about visual programming I've linked to before on HN, in which I mentioned your brilliant acronym C32: https://news.ycombinator.com/item?id=18496880 https://news.ycombinator.com/item?id=18496880 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 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 favorites, Rockey’s Boots and Robot Odyssey, and Chaim's amazing SimCity Reverse Diagrams and lots of great stuff I’d never seen before: http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20Survey.pdf http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20S... I've also been greatly inspired by the systems described in the classic books “Visual Programming” by Nan C Shu, and “Watch What I Do: Programming by Demonstration” edited by Alan Cypher. https://archive.org/details/visualprogrammin00shu_2pf https://archive.org/details/visualprogrammin00shu_2pf https://archive.org/details/watchwhatido00alle https://archive.org/details/watchwhatido00alle 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 Customizable and Characterized by a Complete Coverage of Code and Contains a Cornucopia of Creative Constructs, because it Can Create Complex, Correct Constraints that are Constructed Clearly and Concretely, and Communicated using Columns of Cells, that are Constantly Calculated so they Change Continuously, and Cancel Confusion http://www.cs.cmu.edu/~bam/acronyms.html http://www.cs.cmu.edu/~bam/acronyms.html Also, here's an interesting paper about Fabrik: https://donhopkins.com/home/Fabrik%20PE%20paper.pdf https://donhopkins.com/home/Fabrik%20PE%20paper.pdf Danny Ingalls, one of the developers of Fabrik at Apple, explains: "Probably the biggest difference between Fabrik and other wiring languages was that it obeyed modular time. There were no loops, only blocks in which time was instant, although a block might ’tick’ many times in its enclosing context. This meant that it was real data flow and could be compiled to normal languages like Smalltalk (and Pascal for Apple at the time). Although it also behaved bidirectionally (e.g. temp converter), a bidirectional diagram was really only a shorthand for two diagrams with different sources (this extended to multidirectionality as well)"
m463 6y ago
Makes me think of gnu radio or quartz composer and more recently: https://youtu.be/M7U8dgPo0Bw https://youtu.be/M7U8dgPo0Bw https://mathinspector.com/ https://mathinspector.com/

107 points by mr_tyzic 6y ago

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?

kens 6y ago
The 80-column IBM punch card was invented in 1928 and here we are almost 100 years later writing programs as a sequence of 80-column lines of text. It seems pretty obvious to me that we're stuck in a local maximum. I don't think visual programming is the solution but there must be another alternative. Sort of like how databases are based on text but are much more than text.
- DonHopkins 6y ago
  What we don't need are 160-column punched cards. The proper response to "640K ought to be enough for anybody" is virtual memory, not 1280K. People used to complain about Macromedia Director only having 24 layers, so they increased it to 48. But then what are you supposed to do if you want to make a map of the United States: leave out Alaska and Hawaii?
daenz 6y ago
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.
- hour_glass 6y ago
  Awesome, what changes can VR bring to a coding environment? It would certainly be cool to fly around and observe a complicated network of code in action.
- KineticLensman 6y ago
  > spatial, visual, and tactile senses What about our olfactory senses, for code smells?
  - DonHopkins 6y ago
    iSmell! https://news.ycombinator.com/item?id=17476460 https://news.ycombinator.com/item?id=17476460 https://news.ycombinator.com/item?id=24853659 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://en.wikipedia.org/wiki/ISmell https://www.wired.com/1999/11/digiscent/ https://www.wired.com/1999/11/digiscent/
- jmiskovic 6y ago
  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.
  - daenz 6y ago
    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.
cjfd 6y ago
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.
- Firadeoclus 6y ago
  "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.
jcelerier 6y ago
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 ?
- ArnoVW 6y ago
  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.
- pavlov 6y ago
  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."
  - otabdeveloper4 6y ago
    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.
    - pavlov 6y ago
      Individual programs are text, but useful software systems are models.
      - otabdeveloper4 6y ago
        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.
    - 6y ago

DonHopkins 6y ago

Brad Myers' paper answers the age-old argument about whether or not spreadsheets are visual programming languages! https://news.ycombinator.com/item?id=20425821 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 kind of remote procedure call. (Slower than driving Excel via OLE Automation even, and that's saying something!) Then it times out on a wall clock (not cpu time) limit, and breaks if you take too long. >A CS grad student friend of mine was in a programming language class, and the instructor was lecturing about visual programming languages, and claimed that there weren't any widely used visual programming languages. (This was in the late 80's, but some people are still under the same impression.) >He raised his hand and pointed out that spreadsheets qualified as visual programming languages, and were pretty darn common. >They're quite visual and popular because of their 2D spatial nature, relative and absolute 2D addressing modes, declarative functions and constraints, visual presentation of live directly manipulatable data, fonts, text attributes, background and foreground colors, lines, patterns, etc. Some even support procedural scripting languages whose statements are written in columns of cells. >Maybe "real programmers" would have accepted spreadsheets more readily had Lotus named their product "Lotus 012"? (But then normal people would have hated it!) I Was Wrong About Spreadsheets And I'm Sorry: https://www.reifyworks.com/writing/2017-01-25-i-was-wrong-about-spreadsheets-and-im-sorry https://www.reifyworks.com/writing/2017-01-25-i-was-wrong-ab... HN Discussion: https://news.ycombinator.com/item?id=20417967 https://news.ycombinator.com/item?id=20417967 Excerpt from "Taxonomies of Visual Programming and Program Visualization", by Brad A Myers, 1990/3/1, Journal of Visual Languages & Computing, Volume 1, Issue 1, pages 97-123: Spreadsheets, such as those in VisiCalc or Lotus 1-2-3, were designed to help nonprogrammers manage finances. Spreadsheets incorporate programming features and can be made to do general purpose calculations [71] and therefore qualify as a very-high level Visual Programming Language. Some of the reasons that spreadsheets are so popular are (from [43] and [1]): 1. the graphics on the screen use familiar, concrete, and visible representation which directly maps to the user's natural model of the data, 2. they are nonmodal and interpretive and therefore provide immediate feedback, 3. they supply aggregate and high-level operations, 4. they avoid the notion of variables (all data is visible), 5. the inner world of computation is suppressed, 6. each cell typically has a single value throughout the computation, 7. they are nondeclarative and typeless, 8. consistency is automatically maintained, and 9. the order of evaluation (flow of control) is entirely derived from the declared cell dependencies. The first point differentiates spreadsheets from many other Visual Programming Languages including flowcharts which are graphical representations derived from textual (linear) languages. With spreadsheets, the original representation in graphical and there is no natural textual language. Action Graphics [41] uses ideas from spreadsheets to try to make it easier to program graphical animations. The 'Forms' system [43] uses a more conventional spreadsheet format, but adds sub-sheets (to provide procedural abstraction) which can have an unbounded size (to handle arbitrary parameters). A different style of system is SIL-ICON [49], which allows the user to construct 'iconic sentences' consisting of graphics arranged in a meaningful two-dimensional fashion, as shown in Figure 5. The SIL-ICON interpreter then parses the picture to determine what it means. The interpreter itself is generated from a description of the legal pictures, in the same way that conventional compilers can be generated from BNF descriptions of the grammar.

DonHopkins 6y ago

An important mnemonic technique that visual programming languages can exploit is called the "Method of Loci" or "Memory Palace": https://en.wikipedia.org/wiki/Method_of_loci https://en.wikipedia.org/wiki/Method_of_loci >The method of loci (loci being Latin for "places") is a strategy of memory enhancement which uses visualizations of familiar spatial environments in order to enhance the recall of information. The method of loci is also known as the memory journey, memory palace, or mind palace technique. This method is a mnemonic device adopted in ancient Roman and Greek rhetorical treatises (in the anonymous Rhetorica ad Herennium, Cicero's De Oratore, and Quintilian's Institutio Oratoria). Many memory contest champions report using this technique to recall faces, digits, and lists of words. https://news.ycombinator.com/item?id=22090159 https://news.ycombinator.com/item?id=22090159 >The Method of Loci is an ancient technique that used to be taught for thousands of years as a standard part of a classical eduction, way back when people needed to remember things before the invention of smartphones and printing presses. But in the middle ages it was banned for being immoral! Apparently, some bad apples were abusing the Method of Loci to remember "immoral" things they shouldn't be thinking about, using "fabulous" images they shouldn't be imagining. https://www.guildsomm.com/4cb697f52c/discussion_forums/f/general-discussion/9171/advanced-memory-techniques-and-how-to-apply-them https://www.guildsomm.com/4cb697f52c/discussion_forums/f/gen... >>Remember to use physical objects in these palaces since they have easily imaginable traits; when you are dealing with more abstract or untranslatable ideas it is best to convert them into objects based on the way the words sound, so Valmur becomes Val Kilmer, Les Preuses becomes purses, etc. Additionally, you don’t need to be concerned with reality when making these memory palaces. The more slapstick, unique and vivid they are, the easier they will stick. Raunchy imagery always works well, to the point where some religious orders in the middle ages banned the practice because it was deemed immoral. >Memory Palace techniques have been known as the Mind Palace, Method of Loci, and Memory Journey, Art of Memory, Ars Memorativa, Memorative Art, Mnemotechnics, Architectural Mnemonic, Graphical Mnemonic, and Textual Mnemonic. Eric Krokos, Catherine Plaisant, and Amitabh Varshney published an interesting paper about memory palaces in virtual reality, called "Virtual memory palaces: immersion aids recall" in Virtual Reality volume 23, pages 1–15 (2019). https://obj.umiacs.umd.edu/virtual_reality_study/10.1007-s10055-018-0346-3.pdf https://obj.umiacs.umd.edu/virtual_reality_study/10.1007-s10... https://news.ycombinator.com/item?id=22093072 https://news.ycombinator.com/item?id=22093072 >I visualize and remember code that way. For me, it's hard to forget somewhere I've been, even if I only imagined being there. >Each function is a little building like an office or a shop, which has a sign out front telling what services or products it sells, and contains everything inside you need to solve some kind of problem or produce some kind of product or service (where equipment in the room is like references to other objects and functions and imported libraries). >You're standing behind the front counter, just about to receive a customer though the front entrance door with the parameters you need for one particular instance of that problem. >You go into the back room, solve the problem, then deliver the results out the exit door at the back of the building (or through any of the other earlier emergency exits, if you had to exit prematurely or throw an error and run away). >The front/back flow is a metaphor for the top/bottom flow of control through a function. https://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diagram https://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diag... >>A Nassi–Shneiderman diagram (NSD) in computer programming is a graphical design representation for structured programming. This type of diagram was developed in 1972 by Isaac Nassi and Ben Shneiderman who were both graduate students at Stony Brook University. These diagrams are also called structograms, as they show a program's structures. >If you squint you can see the example Nassi-Shneiderman diagram in that article as a map of a building, with its front at the top, and exit at the bottom. >You can have internal hallways and rooms for branches and loops, like a Nassi-Shneiderman diagram. The "Sub to Determine Wiki-Article" room is like the front entrance lobby of a theater where buy your ticket. The "Select Favourite Genre" room is like the stage of The Price is Right, and you get to pick what's behind door #1 (History), #2 (Science), or # (Geography), or else choose Other. They each have one or two rooms behind them with your rewards, and then they all finally exit out to the same back stage loading dock, where you take your wonderful prize (or consolation donkey) home. Ben explained that "Nassi-Shneiderman Diagrams have peaked out a couple of decades ago, but there were a huge success story for a 15-minute invention, with hundreds of software tools, dozens of textbooks, and 1000+ papers based on them." He has a funny story about the incredibly harsh rejection letter he received when he and Ike Nassi submitted their first paper about "Nassi-Shneiderman Diagrams" to Communications of the ACM in 1972, that should serve as an "inspiration for anyone whose new ideas are rejected by some respected authorities". http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/rejection_letter.html http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/rejectio... http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/rejection_letter.pdf http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/rejectio... >Our submission of the structured flowcharts to the Communications of the ACM was quickly rejected, on October 4, 1972, by the Programming Languages Editor David Gries of Cornell University. He included a single anonymous reference letter which is on paper that has a Cornell University watermark. I assume Gries gave our paper to one of his colleagues (you can play the guessing game too), who wrote the most brutal rejection letter I have ever gotten. >The reviewer wrote: "I feel that the best thing the authors could do is collect all copies of this technical report and burn them, before anybody reads them." As graduate students, this stinging rejection shocked us, but we kept getting enthusiastic responses from people around us. We sent the paper to the unrefereed ACM SIGPLAN Notices, where it was published in August 1973. It didn't take long for others to produce extensions, software tools, and applications of structured flowcharts. >The next problem was theft of the idea. I had sent a draft to respected colleagues, and soon others published slight variations. One of these respected colleagues was Ned Chapin, who greatly troubled us by publishing what he called 'Chapin Charts.' A friend of mine sent me his published paper with a note encouraging me to sue. For several years I feared that Chapin's reputation and his frequent professional seminars would wind up leaving the idea tied to his name, but as the decades passed, the ending has proved to be a happy one. We called the idea 'structured flowcharts, but they are widely known as Nassi-Shneiderman Diagrams. >Another problem was the appearances of patents for variations on our idea, but these have not limited the widespread recognition we have gotten over the years. >I wish every graduate student or young inventor would have the pleasure of seeing his/her ideas spread so far and influence the work of so many people. I also hope that the story of the bold rejection of our novel idea and its eventual international success, is an inspiration for anyone whose new ideas are rejected by some respected authorities. More about Nassi-Shneiderman Diagrams: http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/ http://www.cs.umd.edu/hcil/members/bshneiderman/nsd/ https://wiki.c2.com/?NassiShneidermanDiagrams https://wiki.c2.com/?NassiShneidermanDiagrams More about Ben Shneiderman: https://news.ycombinator.com/item?id=11370099 https://news.ycombinator.com/item?id=11370099 https://news.ycombinator.com/item?id=22329274 https://news.ycombinator.com/item?id=22329274 https://eagereyes.org/influences/ben-shneiderman https://eagereyes.org/influences/ben-shneiderman

djedr 6y ago

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-progarmming-languages-snapshots/ 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 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 https://djedr.github.io/masters_thesis.pdf

wdanilo 6y ago
@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 :)

schpaencoder 6y ago

What happened to all the visual images in this PDF?

nikmart 6y ago
Looks like the linked PDF was a draft (see Brad's comment) Here is the link to paper with figures http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf
- BradAMyers 6y ago
  The journal version (1990) is a slightly updated version from the CHI Conference version (1986).
BradAMyers 6y ago
I found the final version: http://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf http://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf
- dang 6y ago
  Awesome! We've changed the URL to that from https://www.cs.cmu.edu/~bam/papers/vltax2.pdf https://www.cs.cmu.edu/~bam/papers/vltax2.pdf above, and have bumped the year from 1989 to 1990. Awesome to see you in this thread too!
hutzlibu 6y ago
I thought it was funny, to read about Visual Programming, without actual seeing any visuals.

BradAMyers 6y ago

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 http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf

contingencies 6y ago
Have you been made aware of any interesting later developments? How do you view the current landscape, eg. minecraft, scratch, blockly, kodu, etc.?
- BradAMyers 6y ago
  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 https://en.wikipedia.org/wiki/No-code_development_platform
  - contingencies 6y ago
    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.
dgudkov 6y ago
Are you still interested in visual programming? If yes, I would appreciate having a chat (I develop a visual programming tool).
DonHopkins 6y ago
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 Widgets" video, here: https://news.ycombinator.com/item?id=11232154 https://news.ycombinator.com/item?id=11232154 >Yay Garnet! ;) I worked on Garnet with Brad Myers at CMU, on the PostScript printing driver. Brad is really into mineral acronyms, and I came up with an acronym he liked: "GLASS: Graphical Layer And Server Simplifier". Constraints and Prototypes in Garnet and Laszlo (updated link) https://web.archive.org/web/20070422104545/http://www.donhopkins.com/drupal/node/69 https://web.archive.org/web/20070422104545/http://www.donhop... All the Widgets (Fixed v2) - 1990 https://www.youtube.com/watch?v=9qtd8Hc90Hw https://www.youtube.com/watch?v=9qtd8Hc90Hw Thank you for inviting me to give a guest lecture to your UI class about pie menus: https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=f0600d9d-282e-4b83-a6f4-a9f2003ad407 https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=... Just yesterday I cited Richard Potter's "Just-in-Time Programming" paper in "Watch What I Do: Programming by Demonstration" that you co-edited, as being relevant to playing Factorio! https://news.ycombinator.com/item?id=26053703 https://news.ycombinator.com/item?id=26053703 >Playing Factorio requires starting out by performing a few tasks by hand, then thinking about how to incrementally automate factories with trains, drones, combinator circuits, and blueprints, with high level modular repeatable patterns. And estimating where the break-even point is between completing a few tasks by hand, and spending the time to automate more common tasks. >That evokes an article that Richard Potter wrote about "Just-in-Time Programming" in Alan Cypher's classic book (which is now online for free), "Watch What I Do: Programming by Demonstration", about when "the user attempts to write a program for a task that is already in progress": http://acypher.com/wwid http://acypher.com/wwid >Watch What I Do: Programming by Demonstration. Edited by Allen Cypher. Co-edited by Daniel C. Halbert, David Kurlander, Henry Lieberman, David Maulsby, Brad A. Myers, and Alan Turransky. 1993. The MIT Press, Cambridge, Massachusetts, London, England. http://acypher.com/wwid/Chapters/27JITP.html http://acypher.com/wwid/Chapters/27JITP.html >Chapter 27: Just-in-Time Programming. Richard Potter. [...] I was lucky to have the pleasure of working with Richard Potter at Ben Shneiderman's Human Computer Interaction Lab at the University of Maryland, while he was developing an early version of Triggers, which he also wrote about in that book: http://acypher.com/wwid/Chapters/17Triggers.html http://acypher.com/wwid/Chapters/17Triggers.html Morgan Dixon and James Fogarty, who were working with James Landay at the University of Washington, also did some wonderful work along those lines on Prefab, which I've written about here: https://news.ycombinator.com/item?id=11520967 https://news.ycombinator.com/item?id=11520967 Also just yesterday, I enjoyed watching Dan Ingalls' talk on "Pronto: Toward a Live Designer's Notebook", in which he demonstrated how he's been exploring Programming by Demonstration in Lively! https://www.youtube.com/watch?v=if72CFsF_SY&ab_channel=YOW%21Conferences https://www.youtube.com/watch?v=if72CFsF_SY&ab_channel=YOW%2... Also, here are some other great papers about visual programming I've linked to before on HN, in which I mentioned your brilliant acronym C32: https://news.ycombinator.com/item?id=18496880 https://news.ycombinator.com/item?id=18496880 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 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 favorites, Rockey’s Boots and Robot Odyssey, and Chaim's amazing SimCity Reverse Diagrams and lots of great stuff I’d never seen before: http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20Survey.pdf http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20S... I've also been greatly inspired by the systems described in the classic books “Visual Programming” by Nan C Shu, and “Watch What I Do: Programming by Demonstration” edited by Alan Cypher. https://archive.org/details/visualprogrammin00shu_2pf https://archive.org/details/visualprogrammin00shu_2pf https://archive.org/details/watchwhatido00alle https://archive.org/details/watchwhatido00alle 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 Customizable and Characterized by a Complete Coverage of Code and Contains a Cornucopia of Creative Constructs, because it Can Create Complex, Correct Constraints that are Constructed Clearly and Concretely, and Communicated using Columns of Cells, that are Constantly Calculated so they Change Continuously, and Cancel Confusion http://www.cs.cmu.edu/~bam/acronyms.html http://www.cs.cmu.edu/~bam/acronyms.html Also, here's an interesting paper about Fabrik: https://donhopkins.com/home/Fabrik%20PE%20paper.pdf https://donhopkins.com/home/Fabrik%20PE%20paper.pdf Danny Ingalls, one of the developers of Fabrik at Apple, explains: "Probably the biggest difference between Fabrik and other wiring languages was that it obeyed modular time. There were no loops, only blocks in which time was instant, although a block might ’tick’ many times in its enclosing context. This meant that it was real data flow and could be compiled to normal languages like Smalltalk (and Pascal for Apple at the time). Although it also behaved bidirectionally (e.g. temp converter), a bidirectional diagram was really only a shorthand for two diagrams with different sources (this extended to multidirectionality as well)"

m463 6y ago

Makes me think of gnu radio or quartz composer and more recently: https://youtu.be/M7U8dgPo0Bw https://youtu.be/M7U8dgPo0Bw https://mathinspector.com/ https://mathinspector.com/