Most (but not all) of the interview loops I went through included a portfolio review and a design exercise, sometimes also a deep dive into one of my past projects, including a code walkthrough. All of the companies I interviewed with, had me work on a design-engineering problem, and I've got to play around with designing a VPL, a projectional editor, and tightly integrating code deployments with an IDE. The idea wasn't to solve these problems completely, but to show how I work and think about things.

• importantly, VPLs - "node and edges" ones - are not a solution here: they swap variable names for drawing edges, but the idea stays the same - you can touch anything immediately, regardless of how "far" it is

• VPLs, understood as "nodes-and-wires", usually provide some sort of infinite canvas to lay functions on, I'm curious if this combination is necessary - can the code still be text (or some other structural approach), while I can still "keep some functions here on the right of that other thing" - basically thinking spatially about my code
  • notable work in this direction is Dark (also featuring the "embodied data" idea):

• composing functionality and vpls

• node-and-edge languages (VPLs) are DAGs describing computations - they are best modeled with streams, event emitters, etc.

• VPLs and VPL Issues

• connections to VPL of course, but not necessarily

• this might also be related to "data lives here" idea, and VPL prompts from Ivan

• it's interesting to look at "simulator" problems from the point of view of VPLs - visualizing program state/execution is more useful than visualizing the AST - this, again, ties into Solving Things Visually

  What kind of a thinker would you become if you grew up with an active simulator connected, not just to one point of view, but to all the points of view (...) so they could be dynamically tried out and compared?

  — User Interface, a Personal View - Alan Kay

There is really no boundary between the code and the world, and this allows for some wonderful workflows. For example, there is no boundary between programming and debugging - if something is acting weird, you can simply pause time, open the logic, and probe widgets and wires to see what state they're in. Tweak the logic on the fly and resume again. It's blissfully iterative and doesn't require you to learn any additional tools, e.g. a time-travel debugger or a Whitebox.

— I did Advent of Code on a PlayStation

• again, this is not about "VPL" which is node-and-wire interface, but about a VPL which:
  • shows its state to you - the values flowing through the system
  • is "live" (as in Live-Coding) and allows you to prod at the values to see what happens

• VPL is usually understood as nodes-and-wires (or colorful boxes) - but these approaches are not really "visual" in a sense of visualizing the problem domain - they visualize the program shape - the one-dimensional text buffer turns into two-dimensional canvas, and the naming of intermediate values into wires between them
  • but, this is rarely useful! - the shape of the program doesn't tell us much, the problem space of the domain does, but it rarely maps 1:1 to the shape of the program
  • additionally, in most VPLs, the output "happens somewhere else" - the domain of your problem is at best a second-class citizen (dropping a "canvas" component somewhere in the graph), at worst there is a single "output" in the end (seeing the output in a render box)

• thoughts from Ivan Reese's post (VPL here means "nodes-and-wires"):
  • Max/MSP / PureData seems to be a local maximum
  • most VPLs weaken naming - instead of giving names to things, you make connections between unnamed things
  • VPLs require constant jumping between mouse and keyboard (something I tried solving with DAS-UI)

  I don't think that the complexity issue (...) is essential. I think it's self-imposed by current visual language designers. Perhaps that's because the handful of visual languages that got traction (and thus the benefit of countless hours of design & development effort) are created for people who aren't computer scientists. These languages only need to be sufficient for solving a domain problem, not for advancing the art of the visual PL.

  • some ideas/prompts from Ivan:
    • use more of "visual" - borrow ideas from what designers are used to
    • layers - like in Photoshop
    • color-with-meaning - tags in Finder
    • shapes-with-meaning - using shapes to represent types, etc.
    • animation-with-meaning - step-debugger that plays things "slowly", Hest has even playback in reverse
    • possibly allowing programmer to specify what meaning they want to attach to which visual representation

  The fact that current visual languages are built of monochromatic text, a few box shapes, and a few colors of line, is a tremendous failure of imagination.

Secondary notation is poorly developed in the box-and-wire notations we examined, which we believe makes them harder to understand (although as yet, large-scale studies of comprehension have still to be reported). To achieve their aim of making better use of the visual medium, VPLs need facilities for colouring, commenting, grouping, modularizing, etc. (We recommend an explicit 'description level'.) Techniques to reduce the cluttered-wire problem would greatly increase the scope for using spatial layout as a form of communication.

— Usability Analysis of Visual Programming Environments - A "Cognitive Dimensions" Framework

Protoboard nodes by design encapsulate code instead of other nodes, compared to some VPLs where even basic math equations have to use blocks and connections.