I've been thinking about the limitations and shortcomings that VPL environments have when they focus on program structure instead of the desired outcome a user has in mind. Another word for structure is recipe. Recipes are difficult for most non-coders to wrestle with because they force a mental model of “do A, then B, then C to hopefully achieve the X that I want”. A recipe by its definition means that the outcome – the thing the user is trying to achieve - is a separate thing, which usually divides the UI into two distinct and somewhat disconnected parts. This brings me to outcome-driven coding (ODC). I’m making up this term, surely there is a term grounded in research? 😁 With ODC, we’re flipping the script, and letting users work in a way that follows a pattern of “Tinker and change until it (the outcome, not the recipe) feels right”. By mostly hiding the program structure, and showing the outcome of running the program live, an ODC tool can be made on top of an existing programming language, leveraging an entire eco-system of existing work, be it open source, or existing code bases that a product team is working on. This is a big deal for adoption of such a tool, and the foundation for collaboration with developers using IDEs. There’s an interesting trade-off here that has to do with expressive power versus complexity in a VPL environment. With ODC, we can manage that complexity by deciding on which parts of a code base that visual programming is best suited for, and which parts to “leave alone but still execute to show the real product outcome”. Parts of a code base are inherently about the human element and the user experience. Let's call this "design code". Design code naturally centers on using and defining design system components, the visual language, use of data, navigation flows, and pages. This is where visual programming shines. The ODC approach lets us create a tool that is optimized to work with design code visually, in a way that UX designers prefer, while allowing traditional business logic code to execute unhampered inside the tool. The key is to allow collaboration on a single shared code base, with tools specialized for the unique skills and needs of the people in a cross-functional team. Would be great to hear what this group thinks of this hybrid approach, and whether there is existing work that is similar. Thanks 🙂

This is kind of what Wrangler does http://vis.stanford.edu/wrangler/

Cool, thanks. Didn't know about them 🙂

It's definitely a very promising idea. Sketch-n-sketch is also similar. I'm not familiar enough with the research to know the right things to Google

I know the feeling 😄

Love the hybrid approach. Start with the concrete, gradually abstract. How similar/different is outcome-driven coding to programming by example? Certainly, normal people don't follow recipes, let alone write them. They have a sense for what a good outcome will be, and if it's not going that way they'll double check, tweak, and outright ignore the steps. Is improvisation what makes us human? Good programmers, on the other hand, generally have two uncanny skills: 1) Can play computer, can model, often in their heads, what the steps will actually do rather than what they should do, it's like how an artist can imagine what a subject actually looks like rather than an simpler abstraction. 2) Can sense edge cases and complicating interactions. Yes, but when you combine this with that what happens? Liveness helps to address (1). There are challenges certainly, but what do we do to help a person with (2)? You could say static checks try to address (2). I have a recent example in mind. Trying RubyMine for fun, it flagged an obviously fine stretch of code:

@instance_variable = [an, array, of, things]
@instance_variable.map(&:whatever)
# ... later in the method ...
@instance_variable = nil

as potentially raising "NoMethodError: undefined method for nil:NilClass." Smart tool not so smart? Typing

@instance_variable

based on all its uses ignoring control flow? Replace

@instance_variable

with

local_variable

no error. Why the difference? Thread safety! Would be nice if the tool explained as much, but there you have it. (Of course, no sane person uses threads in Ruby, or ever, but that's another conversation.)

ODC and Programming By Example are definitely related, but PBE is more general in my mind since it can also consist of textual/symbolic/node-based structures. With ODC, the user interacts directly with the program output on a canvas, and the examples being pulled in are also viewed based on their output before being added.

Another potential difference between ODC and PBE can be level of granularity. Instead of working back from a finished example, ODC can leverage the steps you went through. Reifying steps is a great way to understand a complex artifact and then abstract from there. I keep coming back to the Fusion 360 Timeline as a potentially crazy powerful tool. Here's a video with a flavor of how its used.

Nice, the timeline looks like a powerful learning tool. Cool how he fixed the rounding of the box. I think for code, it's way more complicated (halting problem etc.) Interesting that you thought of CAD. CAD inspired our approach, but in the sense that current vector graphics UX design tools are CAD (focus on geometry) where they should be more specialized like BIM (understand the physics, i.e. a digital product is the interplay of code and data).

Fabrik may be what you're looking for - a visual programming environment based on dataflow-style box and wire diagrams on top of Smalltalk, which lower level components are built in.

Fabrik began with an attempt to mix arbitrary layout and cell types in an object-oriented spreadsheet. The spreadsheet approach broke down with the complex expressions needed for synthetic graphics and other generative structures. The wiring approach addressed this problem and also opened the way for bidirectional constructions.

You can definitely get the feeling of a "spreadsheet on wheels" from it. Brad Cox, the creator of Objective-C, really admires it as the highest stage of programming modularity, basically as a super-object level that is directly manipulable and visible.

@Riley Stewart Thanks for the link. I wasn't able to figure out whether they we're able read Smalltalk code in the sense that the visuals were persisted/encoded as traditional Smalltalk files that you could continue working on with a text editor. One of the key things we're doing with ODC is to keep the original source language, e.g. TypeScript, intact by natively reading and writing to it so that devs can collaborate on the files without friction or loss of detail.