interesting.. I think I understand what you're referring to

Not sure it's just about "debug views" as you can achieve visual debug views using conventional coding with external tooling - such as appmap.io

For me, the fact the "building" phase being visual has big advantages too

Need to ponder over it a bit more 🙃

I think part of what you're pointing to is what many would call "liveness" in the programming environment, which is orthogonal to whether the notation would be considered "visual" (itself a vague thing, usually meaning "not exclusively text based").

I don’t think the question of liveness, as Jack frames it, has a 1-size-fits-all kinda answer.

For me, the draw of programming systems that offer more than the normal REPL loop, or compile cycle, is that they empower novel, or deeper understandings of how a program functions.

This can take on so many different forms, and varies depending on the goal and the audience.

I think different sorts of liveliness in a programming system can help to promote different sorts/scales of understanding.

• do you need folks to understand your program from top to bottom?
• are you using the program to communicate data external to the program itself?
• does the program facilitate the creation or processing of something? Is there a representation of the thing being worked on that is more intuitive than whatever the default mode is (JSON, binary data, etc.)

Another way to frame it is through point of contact — as the person using a programming system, am I manipulating the live interface, or am I just viewing it? Both?

not just that - people approach manipulation (and viewing, but lets focus on manipulation) with different intents and as part of different workflows. Whether my intent is

• to hunt down and fix a bug that happens a small proportion of the time
• track through and identify the source of an error that happens all the time
• perform a complex refactoring to improve maintainability
• read-by-refactoring
• add tests after-the-fact
• write tests beforehand
• or just plain fix up a few things that are annoying me personally under the radar

Each of these could merit completely different - and individually personalizable - views onto the same system

Points of contact might be what I was thinking about. Maybe I used “debug” too broadly. (Sorry to keep giving 3D examples) In Houdini you have:

• Output display: a viewport (destructive edits) and attributes pane (read only)
• Multiple timelines for changes by speed or value
• nodes and boxes (similar to a dependency tree or control flow)

You can choose what visualizations to use, but most manipulation happens in an additional Properties pane. But they all still work while writing VEX (C/C++ inspired scripting), which is what set of the “its all debug view” idea.

I've never encountered the term "visual programming" as meaning anything other than the code itself being in a visual format. That's quite distinct, at least in principle, from representing the output or internal runtime state visually, which seems closer to your examples, and from the general concept of "debug views". (You could presumably define a language so its code and runtime state can be expressed with the same visual notation, but absolutely don't have to)

So visual, not liveness, would be something like Scratch or Piet?

Piet is not usually the first example that comes to mind, but definitely Scratch, at least in my understanding of the term. :D (For anyone who hasn't encountered it: esolangs.org/wiki/Piet)

@Ibro Your "points of contact" examples make me think of projective editors that can show the same thing (code/state/whatever) multiple ways 🤔

Oh 👀 have you got any links?

enso.org for example

@Ibro a bunch of stuff around this topic starting at ~35:00 minutes into the talk I gave at StrangeLoop last year: jackrusher.com/strange-loop-2022

the next improvement I want to add - is a simple parser that checks which helper functions are called inside each of the functions and build dependency graph, so I will copy all the dependencies automatically

Aside: As soon as the word “parser” is used, I think of DSLs for parsing. Ohm-JS, PEG, <ugh, other names will come to me in the fullness of time ... >. It used to be that parsing was usable by only a select few programmers (compiler writers), but PEG changes all of that. I have several unfinished manuscripts/essays/githubs wherein I try to show examples of how to build quickie text transpilers, kinda like REGEX-on-steroids (but different). Anyone is welcome to contact me, if interested in these WIPs.

Oleksandr Kryvonos I like your approach, I've been doing similar things going back as far as Mu and Teliva. However it's not clear to me what problem your tool is solving. Is the <script> tags intended to mimic an editing experience or something else? Could you describe the larger context or workflow in which you use this tool?

currently all I did is - implementation of inliner for <script> content, in other words I implemented a bundler

but this approach I can also use to decompose large files into smaller ones

I am very interested in tooling that helps get rid of files containing multiple definitions. The reader often wants a very different organization than the writer can anticipate.

can you describe the example for your scenario?

For any change I make, I need to modify multiple files. But I'm often not consulting all of each file. There's usually some "cross-cutting concern" that's a slice of multiple files/modules/namespaces. Having all of multiple files open is almost always a waste of screen space.

This isn't the most important problem in the world. Just something small that has always seemed easy to fix.

I also wrote a very simple bundler! It only really works if you code exactly like me though :)

github.com/TodePond/Frogasaurus

I really enjoy pushing for a minimal build process where possible, and I'm glad to see more and more people trying it out too, like this post: elk.zone/social.jvns.ca/@b0rk/109876329094276212

A Small Matter of Programming by Bonnie Nardi is great (though that's a book, not a paper)

This is a good question to pick at periodically. Previous thread: akkartik.name/archives/foc/thinking-together/1631287181.168700.html

wow ANTLR in c#, that takes me back a while.

I don't have any recommendations but a starting point: Look through the top N contributors in the antlr repo, track down any blogs or other projects they've written about or committed to. It seems likely they would have had some of these need as well

thanks, not a bad idea! 🙂

For me the question is "continuation" (analogous to "analytic continuation"). For source code transformations, I imagine robust automatic error handling stemming from the fact that most transformations are somewhat compositional, I mean the action on the whole text is sort of a combination on the action of the parts f(text) = f(text.some_part) ** f(text.some_other_part) .

In as much as LLMs "think" and "are creative", I'd say it comes from the attempt to find the "conceptual space" defined by the training text. Here the core transformation is from some chunk of text to the next chunk plus some attention data structure that gets updated along the way.