Future of Coding is an online community with a welcoming, cooperative, and revolutionary spirit. We are unified in the belief that the common practice of programming is tragically less humane than it could be.

Future of Coding

removed all LLMs from my laptop, I better download a snapshot of Wikipedia

LLMs just break on "Who is Peter Norwig?"

Screen Recording 2025-03-01 at 11.35.58.mov

Something I've been very slowly working on for years (with long multi-month spans of not doing anything). Sharing to manifest more work :slightly_smiling_face:

Basically, a test bed for CSS and web components: allows generating permutations between various CSS custom properties, HTML attributes, and more. It was already instrumental for some of my web platform testing, as it is an effortless way of displaying all the possible options at the same time, and then cross-browser comparison can show the difference. A lot of what is there I already use in production in the design system I am working on in my company, but that implementation relies heavily on React.

What I am working will, ideally, be frameworkless, and done only with the web platform in mind. Currently, some of its bits are using Preact, but I really want to step away from it, and do _everything_ with web components, and not rely on something external.

Usage of this is just:
```	&lt;style&gt;
		.test {
			width: 100%;
			background: var(--dial-bg, pink);
			border: 2px var(--dial-border, solid);
			box-sizing: border-box;
			padding: var(--dial-padding, 16px);
		}
	&lt;/style&gt;
	&lt;css-lab dials="
		bg: pink|hotpink|yellow;
		padding: initial | 8px | 16px;
		border: solid | dashed;
	"&gt;
	  &lt;div class="test"&gt;Hello world!&lt;/div&gt;
	&lt;/css-lab&gt;```
Although, it will likely change a lot over time, but I am trying to make it as simple as possible to use for myself.

Screen Recording 2025-03-01 at 12.08.02.mov

And the way it works in our design system. The context is rather different, where we want to show the generated code to use for every permutation, but also not complete in some ways, and is less about exploration (no two-way feedback from the controls). But we're pretty happy with how it works, and even saw other design systems adopt a few things from our design &amp; implementation (with explicit mentions).

module_loading.mp4

I've got module loading working. Its a combination of a few pieces I worked on. programmatic import + modules as panels + mutable fileattachments. Its a little different to observable where you only import via an import statement. Now you add a module to the bundle, which better in the multi-module UI world as a module can be useful without being directly linked (e.g. it can just implement a useful tool).

The list of modules is recorded in a JSON file attachment. This list of extra modules is programatically imported on startup. The programatic import first tries to load the module from the bundle local-first, if it can't find it it falls back to the Observable API. So this mechanism allows you to initialize from the Observable ecosystem, but once loaded into the runtime, subsequent exports include it in the bundle and it becomes a vendored local-first dependancy.

<@UGWUJUZHT> re <https://open.substack.com/pub/programmingsimplicity/p/on-programming-using-non-gutenberg>, you might like this attempt of mine at introducing a graphical overview to a program:

<https://akkartik.name/2025-03-02-chessboard>

The drawback: I'm not trying to turn the diagrams into executable code. They're just documentation, but at a level that's not onerous to keep updated, then falling back on raw/eldritch textual code for the heavy lifting.

<@UC2A2ARPT>'s <https://futureofcoding.slack.com/archives/C5U3SEW6A/p1741017245542659|link today> also feels relevant. Every hyperlink is a counterfactual, every webpage is a choose-your-own-adventure story.

What's inside your text+diagram file? What does it look like?

The way I'm imagining it it's just a little markup language of drawing commands. <https://git.sr.ht/~akkartik/luaML.love> but with some support for a "link target" that the view switches to when you click on a rectangular area.

Basically making image maps in html is quite tedious. This is image maps but well-integrated with a vector- rather than pixel-drawing system.

Another way to think of it: this is GToolkit's customizable inspectors, if every inspector is like a little html webpage. You string together a choose your own adventure out of them.

hash_url.mov

Added the ability to store the last URL hash fragment in the exported notebook. This is useful as a lightweight, user editable persistence mechanism. Internally the state is saved as a fileattachment to survive export, so no changes to the file format were required. I needed this to provide a "default" viewof the notebook graph. hash URL is limited in size, but you can use the mutable fileattachments for big binary data. I just think the hash URL is somewhat web idiomatic for certain things and its also user editable so its nice to surface  (and then persist) for certain types of things.

chessboard.png

big-picture.png

Follow-up to <https://futureofcoding.slack.com/archives/CCL5VVBAN/p1741508045908849|my attempts at describing the internals of a program>: a typographical scale of font sizes and some color for hyperlinks.

Changing experience (CX) is part of the using experience (UX) :fist::skin-tone-3:

In my very-biased view, this looks a lot like what I think of as "layering". I don't trust comments, so I want a way to make diagrams tightly bound to the code itself, i.e. generate code from diagrams (syntax == figures, not just characters). In my view, to get "layering" you need total isolation (encapsulation of data is not enough, you also need to guarantee that the control flow is isolated). To consider: the stuff inside of boxes is important, but, are (some of) the flows important, too? I.E. I see the arrow in the first diagram as a data flow and a "sequencing" thing - it kicks off the box to the right (the Main page) box needs to wait until it gets a signal to begin (I call that sequencing and timing). The 2nd drawing shows 6 boxes and no arrows. Does that mean that they can be viewed in any order, i.e. how are they different from "TABs" on the window? I think that I want a viewer/editor that gives me hierarchical TABs, or, clickable boxes. Double-click on a box and you get to view its innards. Make some other gesture and you go back. Does this mean that you need a "map" off to the edge of the window to show where in the hierarchy you are? The popular web browsers I've used flit really close to this flame, but, don't satisfy...

I assume you consider "layering" to be a bad thing. Totally valid criticism. But there are drawbacks in the other direction as well:

• If you generate code from diagrams your diagrams now have to do double duty. They have to be a source of truth and also hide detail.
• You tend to be stuck with one totalizing way of viewing a large program. There are no arrows in the second picture because _it's a different kind of picture_. Glossary rather than blueprint. To support multiple viewpoints in your approach requires checking them for inconsistencies, and showing inconsistencies in a nice way to the programmer so the programmer can understand what the compiler has found.
These are good directions for research. But my doctrine is that I'm trying to do as little research as possible. My focus isn't to make everything perfectly clean and pleasant to use. My focus is to help people take control of their computers with the mature technology we have today.

This is why I'm adamantly not creating a new programming language.

To elaborate on "glossary rather than blueprint," we often hit points in programs where you can't stage learning. You can't learn A without knowing of the existence of B, and vice versa. In these situations it helps to have just a todo list. You need to learn these things. It won't make sense at the start, but here's a bound on what you don't know yet.

I hope this conveys that my primary audience isn't the author of a program. It's the reader. If the author has to do some extra work to engender trust, I'm ok with that. A program will always consist of more than code. Keeping the comments up to date is part of fostering the reader's trust. You can't blanket distrust all comments, I think you miss out that way. Different people put in different levels of attention to them. I'm sure my projects are hard for others to understand, but they seldom contain outright falsehoods in documentation.

I am pretty much pursuing the same goals as <@UCUSW7WVD>, just in a different setting. In particular, I use plain old code plus different views to make the system more understandable. But I am also interested in using diagrams as the ground truth, replacing code, for parts of systems.

The big difference it makes is about changing things. If there is an author who makes an effort to facilitate the work of the reader, that also means that the reader has less of a chance to become an equal to the author. And that means lower conviviality.

If your ground truth is a diagram, then you know that there is nothing else but the diagram and its semantics that you need to understand. No view can make such a promise, it's always a projection. Of course, that's also what makes this idea hard to realize. I am not aware of much work on formal semantics of diagrams, nor of their understandability.

&gt; I assume you consider "layering" to be a bad thing. ...
Actually, it's exactly the opposite. I think that layering is _vital_. Our current PLs are just forms of fancified assembler. This is a metaphor that is at least as tired as that of desktops.  The tired metaphor of assembler leads to overly-rigid beliefs about programming.

Ah, thanks for that clarification. Ok, now I fit it right with your past writings. So you think it's a step in your direction, but it doesn't go far enough. Totally agreed.

<@UJBAJNFLK> I'd suggest that overly formal semantics can also drive people away. Which is not to say my current level of formality is _precisely_ the sweet spot :laughing: I do design my data structures as tables containing tables containing strings and numbers, etc. That likely drives some people away.

But one major alternative to formal semantic guarantees is to keep things simple enough that the universe of possible things to understand is not very large.

<@UGWUJUZHT> I was thinking about your layering of "computational circuits" (which is how I tend to think of your approach) yesterday when I was looking at my own notes on code and data hierarchies, and I was wondering how data fits into your scheme.

As long as you only have a fixed set of atomic types (numbers, strings, ...) in your queues, everything is fine. But how about structured data? Every component must then include a definition of the data it expects as input or provides as output. It must also pass this data on to its subcomponents, but it may not expose their data type definitions at its own interface. This doesn't sound impossible, but I am not aware of any of today's programming language that would support such a scheme without laborious and possibly inefficient data conversions.

<@UJBAJNFLK> This is probably a dissatisfying answer... How do you do this kind of thing across vast distances? Say, a machine in Toronto, Canada speaking to a machine in Paris, France? I'm of the opinion that you don't do this. Uncomfortably, the answer is something like JSON. The concepts of Programming Languages and Data Structures were invented to appease the biases of the 1950s, wherein "efficiency" was vital and time-sharing was vital and memory-sharing was vital and memory-structuring was vital. Today's hardware is entirely different from that of the 1950s. Today's problem is how to program DPUs (Distributed Programming Units) instead of CPUs. Thinking along those lines leads to completely different answers than what we're used to (in fact, I currently think that we need to deprecate O/Ss, PLs, Programming Using the SICP Method (PUSM), data structures, etc. [Aside: note that the current trend is to offload real work from CPUs onto GPUs, anyway]). Of course, we can't just erase everything we've got and start again. The giants of the 1950s/60s/70s/80s built on what they had (vacuum tubes, transistors) and came up with something new (they didn't just glom stuff into what they had, they didn't just make better vacuum tubes by incrementally tweaking the concepts). I'm nipping away at reimagining our biases, for example, simply using boxes and arrows and HTML elements as syntactic elements for "programming languages for the 2000s" instead of just using 7-bit characters. I'm using what we've got and trying to think about it differently. We know a lot more about programming techniques than we did in 1950/60/70/80 - can we just rearrange what we've got and build something fresh? So, you're right, I don't know how to handle complex data structures, but, I don't care.

<@UJBAJNFLK> <@UCUSW7WVD> Let’s see if I can say this in a way that seems more practical. The following is about as short as I can make it for now...Composing Multi-Node Systems <https://programmingsimplicity.substack.com/p/composing-multi-node-systems?r=1egdky>

I think we have wildly different assumptions of scale in mind. I don't care much about zillions of nodes, shared memory, cache coherence, distributing computation across a room let alone timezones. They're valid use cases, but designing for them feels like the tail wagging the dog, to my mind. A single computer today can do so much in a single thread. I'd always choose the programming model that provides user-defined data types over the one that provides nice concurrency properties. So your model has some nice-to-have properties, but the lack of user-defined types feels like a deal-breaker.

Thanks <@UGWUJUZHT> for an exhaustive answer to an interesting question - but it was not the question I have. I am not so much concerned with data representation for storage and transfer, but with data models or schemas, and in particular with ensuring that there are no misinterpretations at the interface between two components.

In my corner of the computing universe, data is the primary concern of most people. For example, I work a lot with protein structures, which are structured collections of collections of atoms plus lots of annotations at all levels of this tree. What I care about is being able to feed such data structures into processing pipelines, storing those that come out of it, and being reasonably certain that all annotations have been interpreted correctly.

<@UJBAJNFLK> <@UCUSW7WVD> I argue that this is the _same_ problem, but looked at from a different end of the telescope. The tail-wagging-the-dog approach is to nip away at the problem incrementally. ... more to come ...

Yes, this seems worth digging into more. Is your "fewer functions" quest dual to "lots of concurrency," so that the proposal is you can never have compound data structures without the ability to serialize them and so on, and those considerations are first class to how they're designed. To me serialization seems a subordinate consideration to say Lua's syntax for numbers, strings and table literals. I don't need to think about serialization because anything can be converted to say JSON after the fact. It seems to be an independent question and "good design" is grabbing opportunities to decouple design considerations at every opportunity.

In my courses on computational science, I insist on the difference between "data model" and "data representation". JSON is a representation, and as <@UCUSW7WVD> has pointed out, any data can be serialized to JSON (or XML, or s-expressions, or ...). Choice of representation is a matter of convenience and efficiency. I am much more interested in the semantics part, the data model. I don't see (for now) how it could be part of the same problem.

I've been writing and rewriting further comments which have resulted in my veering off to record another article in slideshow form.

I think that my gut-feel boils basically down to:

(a) I think that it's orders of magnitude more important to figure out how to deal with composing systems of loosely connected nodes (e.g. layering)
(b) I don't think you can get there from here by tinkering with better forms of type checking and what are essentially better forms of assembler called High Level Languages.

I see the basic case as: you've got one Raspberry Pi connected to an Arduino by a wire. What's the best IDE for programming that system? I believe that programming languages are just I caveman IDEs for programming.

The Borg went all the way with clockwork thinking using their "You Will Be Assimilated" technique on Star Trek, but it probably took them a millennium to figure it out. It's Science Fiction anyway.

Interpolating more complicated forms of type checking and more complicated PL designs, like callback hell, sync/async, .then, is like rearranging chairs on the Titanic, IMO.

FWIW, if you haven't seen it yet, <https://programmingsimplicity.substack.com/p/modern-programming-issues?r=1egdky|Modern Programming Issues>, esp. the last two slides at around 2:25

<@UGWUJUZHT> While I disagree "in the small" with your claim that types are unnecessary, I do agree "in the large" that the current focus on PL and in particular type systems is not likely to make significant progress towards improving software development. I see CS academia stuck on type systems exactly like physics academia got stuck on string theory: an initially promising idea turned out not to be very fruitful, but had already acquired the critical mass to form a research community that was too big to dismantle.

I feel mostly impatient with this thread. So much blather of so little use. When you could have been writing interesting new programs to make your point. Probably just this cold I've had for weeks and weeks.

But one point of evidence just occurred to me: APL discourages user-defined types. So yes, perhaps there is more in this world than can be explained by Konrad's and my theories.

[aside: type this into ChatGPT or your favourite LLM "what was linus pauling's approach to vitamin c?"]

Thanks for this insightful comment! I am now working on filling this gap...

<@UCUSW7WVD> APL is a DSL for applied mathematics. It wasn't even designed for execution on a computer. Applied mathematics is perhaps the most concrete branch of mathematics. It focuses on concrete representations that have been chosen for pragmatic reasons (easy to handle in computation). Overall, that's a good model for programming, but transferring the idea to other domains is not a trivial task.
In a way, APL is an illustration of what <@UGWUJUZHT> proposes: a well-designed notation that reduces the need for abstraction. This is also aligned with <@U6KQ2S410>'s quest for more concrete computing, and his Subtext looks like another good example for a DSL for some types of tasks.
So maybe our real problem is the dominating focus on general-purpose languages and universality.

Here's an attempt at making this stuff a little less unclear. <https://github.com/guitarvydas/zddemos/tree/main|See README.md>. I've written about these examples before, but, I've never drawn them all together into one repo. An interesting side effect of all of this was that, in the process of creating this repo, I whipped up an LLM example and extended it into a double-LLM feedback loop in a matter of minutes (the `dpink` example) (the resulting output is actually enlightening at a philosophical level, to me, IOW the experiment was a "success" and needed only 3 Parts). The `rt` kernel involved more development work, but the LLM example shows how easy it is to create apps/experiments when the right abstraction is used.

I don't get it at all. I tried clicking around a bunch, I really did. There's some disconnect. I have no idea which way is up, what you're trying to accomplish, what your metric is for quality. It all looks like Rube-Goldberg machines.

Like the arith example. Where is the actual conversion to anything? <https://github.com/guitarvydas/zddemos/blob/main/arith/arith-main.drawio.png|https://github.com/guitarvydas/zddemos/blob/main/arith/arith-main.drawio.png> doesn't feel like the interesting part of a compiler to any single one of those languages. So what am I supposed to be looking at? Where is the algorithm, as opposed to the orchestration of coarse steps?

Is dpink running a local LLM? Dispatching to an external LLM?

Perhaps you should take me through just one of these examples. Show me what the dev experience is. If I use your approach, where do I spend most of my day? How do I make changes? How do I locate and fix problems?

But then again, I just don't know. You've certainly tried showing a single example before. You're constantly seeming to respond to my suggestions and nothing helps. Maybe I'm just dumb or blind, and you should stop running around in circles for me :sweat:

I would guess that the "problem" isn't you, it's me not saying _something_. It would probably be helpful to me to walk you through one of these and have you ask questions and have you point out what I'm not saying. Let me know what suggestions you have on poking at this further (if interested)...

[fyi, this stuff looks definitely non-Rube-Goldberg-y to my eyes. In fact, Lua, Python, etc. code looks like clunky _assembler_ to me]

You're comparing apples and oranges. On one side we have programs you have written. On the other side you're making generalizations about languages without any example programs. And the reference to assembler feels like an aesthetic judgement, but I'm not yet at the point where I have the luxury of judging aesthetics. I'm just trying to figure out how the human is supposed to read it. And there are certainly small Lua, Python programs where that's no problem at all. So yeah, it's probably a problem of presentation. It's not clear to me where the non-assembler parts are, given you're building these things out of one cartoon drawing and six different bits of what you call assembler in six different assembler dialects. Where is the insight? Am I asking what water is? :sweat_smile: Maybe we should do a call.

Focus on _communicating_ what this B is before you try to _compare_ it to mainstream A.

I'm certainly open for a call [if anyone else wants to join in, that would be OK, too, from my perspective].

I'm pondering what you've said. I can see that something is missing, but, I'm at a loss to say what it is. It's something about economy of expression, removing ice jams caused by worrying about too much detail at too low a level, something like that. I tried to poke at Claude 3.5 to figure out why Richard Feynman used Feynman diagrams instead of written equations and got no insights on how to say this differently. Continuing to use PLs based on 1960s graphics technology and only _one_ way of looking at things (sequentialism) doesn't seem like a fruitful approach. To me, it looks like we're at a precipice, the kind faced in the 1960s by people holding bags of transistors, but different. [In the dpink LLM example and the Larson Scanner example, there are wires that feed back to previous stages. That's not "recursion", that's something different. Knowing that I was allowed to draw such feedback wires simplified my thinking about how to solve those problems. Assembler, and it's derivatives like FP, don't encourage you to think that way]. I feel that FP imposes too many semantic restrictions on thought. ... continuing to ponder ...

Yeah, that again does nothing for me. You keep flying off into airy generalities. But people will only trust the abstract once they have some grasp of the concrete.

For example, from what I can tell, one major case you make for your approach is that it's more efficient. Things that don't depend on each other should be able to run in parallel, and that is only possible if there aren't accidental dependencies introduced by the tools. What you call epicycles.

Well, if the major case is that it's more efficient, show me the most powerful case for how efficient it is. Or if you want to focus on some other benefit, show me a concrete working program and convince me it has that benefit. Pick one benefit, and thread it through from start to finish.

Take me through a linear argument, I have no trust at this point to spend time clicking around on your stuff. I don't want to see multiple notations, I don't want to bounce between 3 different services, I don't want to read LLM slop. (Use LLMs by all means. I don't care how you generate your argument, and I don't want to hear about it either. It's your argument no matter how you arrived at it, and it wins or loses on its merits.)

None of us get to compare our notations to Feynman diagrams until someone else uses the notations to obtain publication-worthy levels of insight.

This demonstrates a microcosm of my problem. I wrote "... why ... ... used ... ... instead of written equations". I perceive this to be a question about _process_. Those words were taken, instead, to mean name-dropping and direct comparison of 0D to a specific famous artefact. The interesting bit is _how_ the thought process worked to solve a hoary problem (observation: the technique involved abandoning equation-based notation instead of simply embellishing it). The question should be "what are the significant semantic concepts used in 0D that supplement current programming best-practices?" instead of "what do these wires mean?". [I've tried to state what those concepts are in several ways, many times, but, the simplicity of the concepts appears to make them ignorable].

Analogy: We don't need to know how to make better internal combustion engines just to drive cars. We do need auto mechanics, but, the majority of drivers don't need to know how to service their own automobiles at a fine-grained level.  FP is like pistons (i.e. only a small % of what's needed to make an engine work). 0D is like the hood (or bonnet) that hides all of that detail. Computer Science has become like a course in automobile mechanics, albeit partial and _very_ biased (analogy: flat-head screwdrivers only, the use of Phillips and Robertson screwdrivers and pliers is forbidden). Programming should be like driving. Programming is not what Computer Science has become.

[Haha, if the question in the 1st paragraph above is correct, then why don't I simply address it? ... TBD ...]

But we're not talking as producer and consumer, we're talking as peer programmers right? If you want the world to adopt your way of building cars, you have to convince the mechanics.

I didn't think you were name-dropping or anything like that. I don't think the way you are arguing is factually wrong or bad faith. I just think it's _ineffective_. The names are distracting rather than supporting the reader.

I wonder. The mechanics still haven't adopted spreadsheets, have they? I watched assembler programmers howl at how inefficient "C" was. Then they all retired and "C" was adopted. Hmm.

That's fair too. Perhaps you should clarify what level you want engagement on. That might help me stop saying unhelpful things.

Interesting food for thought - thanks. I thought that I knew who my intended audience was. I wonder if I should reconsider? Note to self: I'm describing _how_ to do this not _why_ to do this.

image.png

I am in the fixing all the reactivity glitches before release stage. They are so difficult to debug, clicking a link opens a panel which syncs the hash URL, which retriggers another cell that get the stale version of the URL which may cause a cycle and the app starts flickering... or something like that.

I had to upgrade my <https://observablehq.com/@tomlarkworthy/ndd|in-notebook debugger >to work across notebooks so I can visualize the evolution of the runtime state w.r.t. time. It worked! I figured it out. Pictured is the trace of a self-triggering reactivity loop. Its still hard to understand but you can see a lot of ticks with a regular pattern, and critically, the name of the cells. There were over 1000 cells in the notebook, so knowing the 15 that were implicated in the cycle is helpful.

I wrote up some overall design direction for zest - <https://github.com/jamii/zest/blob/main/docs/rationale.md>.

Currently bogged down in figuring out how to combine staged compilation and modules (<https://github.com/jamii/zest/issues/1>), but once I figure that out I can finally start fleshing out the <https://github.com/jamii/zest/blob/main/lib/runtime.zest|runtime>.

I like your wish list! And your so-far-documented design decisions look reasonable. At least in theory, it takes an implementation to find out how they work in practice.

Wondering: have you compared your design in detail with existing systems? I think that would help in understanding what exactly you are missing, and to what degree such features can be added without creating problems elsewhere.

For example, at first sight your with list and design decisions has a huge overlap with Common Lisp. What I cannot judge easily is how difficult it would be to morph Common Lisp towards full alignment with your goals. Given how well understood Common Lisp is (both good and bad aspects), a detailed comparison should be helpful.

For for staged compilation and modules, Racket has probably the most sophisticated approach today, but it may well be more sophisticated that you would like for your system, given that Racket allows each module to be written in a different language.

Ah, I forgot to add the problems from <https://www.scattered-thoughts.net/writing/there-are-no-strings-on-me/> to the 'legible' side of the wishlist. I'm explicitly trying to avoid the lisp/smalltalk model where loading code means executing a series of side-effects against a mutable environment.

In particular I don't want to allow things like:

```if ((new Date()).getDay() == 1) { 
    Date.prototype.getDay = function() { return "funday" } 
}```

I added:
• code-based rather than image-based - the code running now is the code that you loaded, nobody can sneak in and change it at runtime, you can understand the system by reading the code
• no mutable environments
• file/module/expr load order is not observable
• no side-effects at load-time, <https://doc.rust-lang.org/1.4.0/complement-design-faq.html#there-is-no-life-before-or-after-main-(no-static-ctors/dtors)|no life before main>
• no non-determism at load-time - loading the same code always produces the same program
• cf <https://www.scattered-thoughts.net/writing/there-are-no-strings-on-me/|there are no strings on me>

Also under performance:
• reflection and meta-programming are predictably staged away

The closest existing languages are zig and julia, which both feature type-checking after specialization and staging via specialization (values lifted to types) rather than quoting.

The latter means you can understand the program via its dynamic semantics. Type-checking and staging only affect performance - they can't change the result of the program.

But neither of those languages have the restriction to value semantics, which complicates the module system.

<https://docs.racket-lang.org/reference/eval-model.html#(part._separate-compilation)> in particular is very unsatisfying. It means you can't give describe the meaning of a racket program without resorting to talking about a *lot* of compiler machinery.

I'm less familiar with common lisp, but searching for "common lisp load order" lead to <https://www.reddit.com/r/Common_Lisp/comments/xt7jn4/how_to_build_a_proper_loading_order_from_asdf/>, which is about the experience I expected.

&gt; you wouldn't be able to reproduce that way; file compilation has different semantics than repl interaction (the latter happens strictly at "load" or "execute" time, while the former happens partially at "compile" time)

FWIW: ASDF is not part of CL. It is a program written in CL that defines a "declarative" DSL with lots of hoary edge cases for determining dependences and loading the minimum number of files. It was invented back when machines ran slowly enough that Makefile seemed like a good idea for minimizing CPU cycles. The basic load function defined by the CL language is (LOAD ...) which you can run from the REPL. One can forego the use of ASDF and simply write a .lisp file with a bunch of (LOAD ...)s in it. It is my understanding that modern CL REPLs actually compile every command, then run the compiled command. In essence, if you type (LOAD "filename") at the REPL, the REPL compiles the command into a small binary program, then runs it, actually running the LOAD command built into the Lisp language. ASDF just generates a bunch of (LOAD ...) commands. The definitive reference for CL is <https://www.lispworks.com/documentation/HyperSpec/Front/Contents.htm|CLHS>, but it reads like a ton of bricks (it helps to have a degree in Law). If I had to re-learn Lisp, I would probably start with <https://gigamonkeys.com/book/|Practical Common Lisp>

So still the same model I was complaining about in <https://www.scattered-thoughts.net/writing/there-are-no-strings-on-me/>.

&gt; Most live systems gain their interactivity from mutable environments and late binding. Code loading is an imperative process that can cause arbitrary side effects. The behaviour of the system can depend on what order code was loaded in, and when. There isn't even any guarantee that loading the same code in the same order will reproduce the same system.

Thanks <@U71PMQ1V0> for this important complement. The tensions between liveness/malleability and immutability are well-known, it will be interesting to see which compromise you will end up adopting.

One issue I see with your idea of recompiling the world at every change, for consistency, is data obtained from obsolete code. For me this is a major reason for wanting a live system. The typical situation is that I have some code that I have used to load and process some data, burning a lot of CPU time. And then I discover a bug that makes me fix some of the code that has produced the data. I assume that in your scheme, the right way is to recompute the data after reloading the code, to ensure consistency. But if that takes an hour, the liveness is gone. It should be up to me, the user, to make the choice between consistency and fast feedback. What I expect from an ideal language/runtime is not to guarantee consistency at any cost, but to help me see and then understand critical situations. Current systems (Lisp, Smalltalk) fail mainly in not alerting me, but they are pretty good at letting me deal with the issues once I am aware of them.

Very interesting and principled set of design choices <@U71PMQ1V0>.
When live reloading code, do you support the common hack of allowing new fields to be added to the end of structures? Since you want to pack structures I’m guessing not.

&gt; I assume that in your scheme, the right way is to recompute the data after reloading the code, to ensure consistency.
The point of not allowing nominal types is that data is independent of the code that produced it, so you can keep data around while reloading the code, or send it to a different process or save it to disk.

&gt; When live reloading code, do you support the common hack of allowing new fields to be added to the end of structures? 
I think that's something that only has meaning for nominal types. If your types are structural then they have no identity and there is no meaningful way to talk about having changed the type.

But the goal of having a dynamic dialect is to have a language in which it's easy to talk about migrations. So I could write a function that adds a field to my structs.

I wanted to just keep the fun parts of programming.

Joining <@UCUSW7WVD> in the Lua club. I got Lua running in the browser (using wasmoon) and ported my spreadsheet experiments to it: <https://ezhik.jp/spreadsheet-3/>

I think I'd like to experiment more with properties. I've already got the ability to change styling of cells, but what if we could go even further? Move cells around? Make them round? Make them spin? Make them not cells but images? I want to mess with the spreadsheet formula (pun intended) even further.

Allow entry of Lua code directly into cells

You actually can! I'm just not exposing much of Lua built-ins right now.

so, write the spreadsheet code using the spreadsheet ...

Cells in cells in cells in cells... Interesting!

If you just want to “fool around” in order to understand programming better, then, stay away from the heavy-weight languages and operating systems that we have today.

You need to understand every line of code, if you think - like me- that programming can be fun.

Here are some things that helped me understand <https://programmingsimplicity.substack.com/p/mental-agility-jams-for-programming?r=1egdky|Mental Agility Jams for Programming>

Just got Lopecode's plain text serialisation format deterministic so its now git diff friendly! The first version of the new multi-notebook architecture is public <https://tomlarkworthy.github.io/lopecode/@tomlarkworthy_lopepage.html#modules=%40tomlarkworthy%2Fmodule-selection&amp;view=R100%28C50%28S50%28%40tomlarkworthy%2Fmodule-selection%29%2CS50%28%40tomlarkworthy%2Feditor%29%29%2CS50%28%40tomlarkworthy%2Ffileattachments%29%29|here> from the <https://github.com/tomlarkworthy/lopecode/tree/main|lopecode repository>. The code editing experience sucks and I lost a lot of functionality switching to dockered multi-notebook but it is so much better being able to work on two or more reactively linked notebooks at the same time it will be worth the backward step long term.

How did you make the text serialization deterministic? FYI - I've been playing with JSON (ick) as an I.R. and using `jq` to sort the fields alphabetically.

They were mostly ordered already, the notebook cell order is the serialisation order. I only needed to sort the modules by their name and it was done, but before that the git diffs were 1000 line blocks moving around randomly

first bug fix as a git commit <https://github.com/tomlarkworthy/lopecode/commit/a98f7529f869a3aa61f43ece1faedad563de457f>
still a bit messy but it is actually readable now.

Screen Recording 2025-03-29 at 11.25.43.mov

Working on a proposal for the algorithm of fit-to-width text for CSS. Planning to present it to CSSWG next week if all goes right :)

I already have a technique that handles a few main use cases (<https://kizu.dev/fit-to-width/>), but if we want it to be native, we need to handle a bunch more: specifically, a case when a line of text has “static” elements that do not change their dimensions in response to the font-size change. This, with added handling of optical sizing of a font, requires us to basically render the same line box up to 4 times, but with 2 of those being optional (when no static elements, or no optical sizing axis present in the fonts used).

So mostly working on fine-tuning the algorithm + making a prototype of it with custom elements & shadow DOM (with no runtime JS for layout, only for duplicating the content to emulate multiple renders), and also thinking about what an API for this property could look like, with possible options, etc. And will need to also think how some other edge cases will need to be handled (reverse dependence on the font-size, initial-letter, and a bunch more).

Oh wow this is awesome! Definitely interested in how the custom element comes out!

That's exciting! When you say "render the same line box up to 4 times", does that mean "paint" or just "layout" (or something else)?

Layout, but in isolation, without the need to recalc anything outside the line until we decide on its size.

Today I added Knotend-like keyboard shortcuts to my Graph editor app: <https://codeberg.org/nilesh/grapher>

Because this editor supports compound graphs where, besides adjacency edges, nodes can also be nested using at most 1 parent per node, I needed 4 separate actions on graphs for the currently selected node:
• Add a destination node (using the `Tab` key)
• Add a source node (using `Shift+Tab` )
• Add a child node (using `~`)
• Add a parent node (using `Ctrl+~`)
I haven't yet added keyboard shortcuts for adding "sibling" nodes.

Also felt sad that we don't have standardized UI components with keyboard shortcuts for manipulating trees, DAGs, plain graphs, compound graphs or hypergraphs.

oh very cool. did you see <https://futureofcoding.slack.com/archives/CGMJ7323Z/p1742762937750189> (OCWG in particular)

<@U02E4DAQGSZ> Thanks for sharing that. I remember the original discussion on Twitter but good to see the progress on OCIF file format standard.

<@U0123H7JRDM> A while ago, I added the ability to export from Grapher to Obsidian's JSON canvas format:

Cool! I am going to look into it! Thanks for sharing!

add_delete_cells.mp4

I padded my work trip to Portugal with some extra days off so I could concentrate for 2 days and do a V2 of the editor component. A great success! I switched to floaty window style near the cell, attached it to the correct DOM so it follows the scrolling properly. Got add/remove cells properly working again since the multi-module refactor broke them. Managed to remove several reactivity bugs. Removed some hacks that were working around said bugs. Fixed some low level bugs in the visualizer, causing a few other unexpected bugs to fix themselves coz of that problem.

How large is the whole thing at this point?

I have a d3, plot and code mirror dependency. Do I count them or not?

I think a breakdown would be nicest! Helps me visualize concentric circles of what a reader is most concerned with at the start vs might be concerned with in time.

Screenshot_2025-04-05-18-00-16-96_40deb401b9ffe8e1df2f1cc5ba480b12.jpg

When you export, it prints a table of sizes. I guess I care most about mb on the wire as that is the network and storage tax. I AFK but I can show you that breakdown from my phone. Code mirror is a 300kb gzipped filer dependency. Modules are notebook sources, so the exporter itself is biggest at 75kb of unminified JS. The compiler/decompiler is #2 at similar size. That one includes it's test suite. The new editor V2 is quite small at 33kb, but it's what brings in codemirror

They map to observable notebook names if you are curious <https://observablehq.com/@tomlarkworthy/observablejs-toolchain|https://observablehq.com/@tomlarkworthy/observablejs-toolchain>

I guess all the names are truncated so it's not possible to read, lol.

Oh the static file export itself gives a good estimate, excluding the gzipped dependencies which are single base64 lines. The export is designed to be human readable and unminified. The compilation process adds boilerplate so I think maybe it's 1.5x larger than the real source but it's closely related. The last export is 6300 LoC <https://github.com/tomlarkworthy/lopecode/blob/main/%40tomlarkworthy_lopepage.html|https://github.com/tomlarkworthy/lopecode/blob/main/%40tomlarkworthy_lopepage.html>

I've integrated my <https://akkartik.name/post/luaML2|recent> <https://futureofcoding.slack.com/archives/CCL5VVBAN/p1743834482122199|hypertext browser> into <https://git.sr.ht/~akkartik/template-carousel2|my template repository for building apps based on the Lua Carousel UI> which supports making changes to apps on the phone (or computer). Now any new app built from this starting point will have a rudimentary system of online help for the entire stack:
• Lua Carousel
• LÖVE
• Lua programming language syntax
And there's tooling for authors to draw box-and-arrow diagrams in the environment and hyperlink boxes to code in the app.

It's all very janky, but the combination of editing on the phone, box-and-arrow diagrams and hyperlinks everywhere seems to result in a somewhat unique programming environment worth exploring further. I'm not sure what I'll do next. Probably build some simple apps and try to build experiences for understanding their source code. This is a little bit like Literate Programming, but just a touch more graphical. LP + image maps, perhaps.

I am back on the original goal of exporting my Observable notebooks to my offline-first format (lopecode), in a way that preserves editability. I started a notebook called jumpgate, that can do the conversion, and then opens a PR against Github. The first notebook I am trying to get this working with is Jumpgate itself.
I use lightning-fs + isomorphic-git to do the Github part within a browser. The prototype is working
sourcecode on Observable: <https://observablehq.com/@tomlarkworthy/jumpgate>
git PR opened by the notebook: <https://github.com/tomlarkworthy/lopecode/pull/4>
as my repo is configured as a static host as well, we can see the result of jumpgate after going through the jumpgate here: <https://tomlarkworthy.github.io/lopecode/notebooks/@tomlarkworthy_jumpgate.html#view=S100%28%40tomlarkworthy%2Fmodule-selection%29>

Currently its slow as hell as the git checkout takes a long time. lightning-fs is storing itself in indexdb so there is not need to do a full checkout everytime, we should be able to merge with what exists. I went with simplicity for now as the stateful logic gets complicated as you have to do different git commands depending on whether you have done an initial clone etc.
I am not sure how to manage the PR branch either, I keep force pushing a single branch but thats probably not correct either, I should use a fresh one each time but then you need to be careful not to fill indexdb with orphaned work. If anyone has a strong opinion on what the ideal github workflow for syncing offline files is LMK

The jumpgate does not add the extra functionality to make a notebook editable, I need to next mixin with my editor notebooks to get the thing to do what I want. Good stage though, Having notebooks open PRs is cool.

I am writing a computational blog post and I want the windows arranged a certain way. Jumpgate supports injecting the window configuration but I have to keep specifying it and its annoying when iterating. So I added form population via URL parameters so now I just need a web link to have a specific export preconfigured. That is the next step in exporting everything repeatably, by building up a list of exports as a list of links to Jumpgate.

The other thing heavier usage of Jumpgate showed was the git checkout step was slow, over 30 seconds, bottlenecked by the necessary git CORS proxy, so I made my own isomorphic-git proxy. Its super easy to setup on CloudFlare and in reduced my checkout to 3s! The instructions are making their <https://github.com/isomorphic-git/isomorphic-git/pull/2095|way upstream> if browser interaction with git interests you.

Still, the git checkout step is not scaling well. Every notebook is 1-2Mb, and they all get downloaded before I can push a new version. I experimented with merging empty repositories, that works for unseen files, but not for updates to existing files (merge conflict between unrelated histories). git sparse checkout *should* be the answer, but not supported by isomorphic git ;'( Other ideas welcome. There have been several failed attempts to add sparse checkouts to isomorphic git, so its not an easy feature.

Keep getting sidetracked by making little Lua libraries. This one implements Python-style f-strings in Lua. Pretty cool to have a language that lets you go this far with its syntax. With just a little bit of work this could be extended to implement <https://peps.python.org/pep-0750/|Python's template strings (PEP 750)> and then we could use Lua to make all sorts of DSLs. My initial motivation was easier printf debugging, though :sweat_smile:.

I started working on this on an iPad with the Codea app, of all things. Was fun, but sadly I couldn't use any of the Bret Victor-inspired things they had in it since I wasn't using any of the app-specific libraries they had.

Though putting aside the library, I think at this point the most interesting thing I did is actually making it possible to use it right on my website without having to install or download anything.

<https://ezhik.jp/f-string.lua/>

If you enjoyed fooling with parsers, I would recommend looking into <http://ohmjs.org|OhmJS>. OhmJS (plus Ohm-editor) saves a lot of work when building parsers. A game changer. There is the other half, too - once you've parsed something, what do you do with the information? I've found that doing simple string-rewriting is very, very powerful, while sounding overly-restrictive on the surface. One can design and build whole new languages by transpiling them into existing languages for compilation (that's how I use my 't2t' and 'tmx' stuff). I consider the shell (/bin/bash, /bin/zsh, etc.) to be my IDE. PLs are just "little tools" that plug into the IDE. I don't have to stick to using one language. I can pick and choose. Transpiling a new language (or nano-DSL, or Diagrammatic Programming Language) into some other language fits neatly into this workflow. The fact that OhmJS is written in JS doesn't mean that you have to use JS. You can map XYZ to Lua (or whatever). I can supply a /lot/ more info, if this interests you.

snake-centers.png

Literate Programming with a little bit of spatiality.

snake-centers3.png

First draft of a complete running program. I automatically "tangle" the code from the markup to check that I didn't forget to include something.

The picture is blurry, but in practice I can zoom in and out using mouse wheel or pinch gesture.

The editing experience is terrible. All the lines are absolutely positioned and not integrated with the markup. But code is read more than it's written :stuck_out_tongue:

Looks promising! I do believe that it is important to start designing for the reader. Otherwise, as a developer, you will inevitable optimize for the developer side.

How would you handle bigger code? By growing the canvas, or by introducing pages?

It's hypertext, so I could have links. I'm imagining links closing some outer levels of detail and opening inner ones.

All this is influenced by reading Christopher Alexander on "the fundamental unfolding process".

Ohhh, I should read that. Is that in one of his books? Or some article?

It's "The Nature of Order". Volume 2 of 4 :sweat_smile:

Ouch... The Nature of Order is on my reading list for retirement, as I don't expect to find time before. But retirement is still many years in the future!

It's surprising short given the length, because of the number of pictures. But then I spend 6 months thinking about a chapter.

Anyways, no deferred life plans for me. And starting isn't a commitment to finishing either.

Reminds me of <https://haystackeditor.com/|Haystack Editor>.

In a visual programming environment, points (like, x/y[/z/...] positions) are as important as strings are in a textual environment.

If a visual programming environment doesn't have fantastic affordances for working with points, I can't take it seriously.

What do you think of <https://100r.co/site/ronin.html|Ronin's> `$xy`?

It's a "lisp on the left". I think it was _the_ tool I had in mind when I coined that term.

So I don't personally count it as visual programming. You aren't programming _through_ visuals, you're programming in text while looking at and lightly manipulating visual output.

$xy is a good example. It's a string. You have to type `$xy` to be permitted to use the mouse. It's keyboard-first. The text is what decides which visual things are allowed to exist.

I'm keen on the opposite.

do you count orca as a visual programming environment?

Yes — fantastic pull. I personally see Orca more truly "visual" than most things people call "visual programming" (Pd/Max/vvvv/etc), because in Orca you program by arranging things in space. 2d position matters. Sure, it's on a coarse grid, and it uses text characters as symbols, but I see that as mostly a minor aesthetic choice.

Going deeper: my interest in points is about pushing toward some kind of _bootstrapp-y / codegen-y / visual parser_ tool. I want a programming environment where I can work with things in space (a la orca), but also create new kinds of things-in-space, without ever having to work with text.

ok :slightly_smiling_face:
so do you count orca as a text-based programming environment?

Super no! Less so than Max/Pd, for sure. For me, it really comes down to… how much does what you're doing resemble written language vs drawing, sculpting, crafting or some other activity that feels different from writing.

How about you? How do you like to carve up the design space?

I guess I'm in the Allan Pavio-style 'why not both' category. My feeling is once you're describing discrete computation in visual form then it's going to be a form of text. But that doesn't mean that it isn't also visual. They are distinct categories of representation, but support each other and are integrated in human perception.

So I agree that orca is more visual than max/pd, but I don't see how it isn't also very much text-based

I think the desire to try to escape text is an accident of computer science history.. We developed text from our evolved visual and navigational capacity, so text is more 'advanced', but then computer science took text as a starting point and had to develop visual representations on top of that. So we're left with the feeling that visual representation is more 'advanced'' and that we should leave text behind. Really though they are dual sensory channels that should support each other.

Yeah, I like the "why not both" framing. If I ever rail against anything, it's that I have to do graphics by writing shit like `dot({x: 3, y: 5}, {x: -1, y: 0})`. I'm starting from a place of "we're using text for things that already have a better representation in a different form — why can't we use that form?"

Equally I find it very weird when people say max/puredata is visual and not text-based, when text is everywhere

Yeah, Max visualizes the graph of relations, and changes the authoring affordances. So it's not the same as traditional text code, but it's not very different in the grand scheme of what's possible.

Yeah or maybe it's the max user that visualises the graph of relations by painstakingly laying things out in 2d as secondary notation

you could pile up all the text on one spot and it would work the same

Did you ever see / do you remember the <https://www.youtube.com/watch?v=Gy5m091fOTU|DeepUI concept video>?

The stuff about how people think / getting ideas out of your head is hogwash. But the fact that you're working with data in a truly nontextual form is what I'm interested in exploring.

This is what I was getting at with the original post. Working with strings in a DeepUI-like environment might be awful. (It might be great, who knows, nobody's done it yet.) But working with points in space would be so much better than `position = {x: 3.5, y: 20}`, at least for certain use cases.

And if you want to get to something that allows visual bootstrapping / "codegen", having good facilities for _reading/writing objects in space_ feels like a superpower. Thus, point affordances are really interesting to me.

Just watched it.. Saw quite a bit of text, even in a game based on basic geometry that needs almost no layers of abstraction. A bit more complexity and the text would be harder to ignore, unless it gets entirely hidden by a tangle of wires

icons are text, logic gate symbols are text, check boxes are text etc

there's also a fair bit of _text_ text in the interface

It seems like it would be wonderful if you could somehow described discrete computation just by drawing stuff, but that's because it is wonderful - that's what text is!

Not sure if we agree on the meaning of text, at least as it pertains to conventional code. I'm not saying we need to avoid letters and numbers. I'm saying we need to avoid lines of text that you read left-to-right (typically, sigh, i know).

oh yep lets put eurocentric views on text in the bin

If I want to represent where something is in 2d or 3d space, I want to do that in 2d or 3d space.

well I guess that kind of text wasn't invented in europe so I hastily take that back

anyway agreed I think we need to reimagine text

So very narrowly: when you're programming something that exists in space, I want the programming to happen in the same kind of space. That's what strings are, that's why they're good! But something like `{x,y}` isn't.

I stumbled on this today, sharing it mostly unread but the title seems relevant ! <https://arxiv.org/pdf/2505.15327>

ah no preview - Let’s Take Esoteric Programming Languages Seriously by Singer and Draper

But strings are almost never used as strings (in PL), technically only strings in double quotes are "true" strings, existing in their own space. Otherwise they are symbols with a meaning. *that* is why they are so powerful, they are abstractions by default.

My next focus for lopecode is the editing experience. I've tidied most of the gitches up and its smooth, but kinda hardwork to do everything in my head. I need more hands!

So to kill 2 birds with one stone, I will redo <https://observablehq.com/@tomlarkworthy/robocoop|roboco-op> but this time with an agentic workflow following how Cline works. Early results is that it is quite good at following Observable dependancy graph and exposing itself to jsut enough context for the task at hand. Roboco-op was struggling with context management and I think this is a better path. It can add cells!
Roboco-op hit a ceiling because you have to manually copy and paste cells over in Observable, but with Lopecode you can add cells programatically so its a better substrate for this kinda of idea.

yeah it can pretty naturally inspect runtime state.  Even navigating the difficult viewof macro. I have not actually prompted observables programming model yet, it can figure it out. Note the input/output descriptions give it a handhold to navigating the dependancy graph.

reactive_dependancy_graph.mov

So for the LLM to explore the dependancy graph I added the "dependsOn" cross-links to the already well worn "moduleMap" function. Now I have that information available I can visualize it nicely! and furthermore I made it reactive to the runtime changes so its always up to date.

Запис екрана 2025-06-15 о 00.23.29.mov

accidentally I discovered that typing without backspace might be somewhat fun
<https://uprun.github.io/web-editor/keeped-2025-06-15-no-backspace-challenge.html>

Interesting. I'm more curious about the little peephole cursor you have there. Care to say more about it?

Hmm, link doesn't work for me on Firefox.

> I'm more curious about the little peephole cursor you have there.
later I would like to use this editor from tablet and since with web-pages it is impossible to ask for a virtual keyboard I need a minumum size input to be visible.
Though un-intensionally it looks like cursor on iPad (one of the things Apple thought through)

> Hmm, link doesn't work for me on Firefox
I use Firefox on MacOS and on Android it seemed to be working, can you please try one more time?

Oh I see! I didn't realize that I need to click on the "cursor" (input box) to add keyboard focus.

Very interesting approach.

I'm _still_ thinking a lot about what a "point literal" or a "vec literal" means in the context of visual programming.

In text we have "string literal", it has a bunch of affordances. In visual/spatial/tangible/etc programming, we'd probably want other primitive types with their own set of affordances. So point and vec, obviously. I wonder what else we'd want, and how it would look and act.

grammar of graphics makes me think about data spaces. a dataset occupies a place within a data space, which is not a million miles from a table (dataset) SQL schema (space).

You can look at a dasaset as a tabular dataframe OR slice into a million possible configuration of a data chart. So dataframe or chart are projections of the same underlying dataset.  I quite like things that allow you to view the same thing from different angles.

Your examples make me think you are thinking lower level but I do think its more user friendly to think at the higher level.

I'm thinking of "point literal" as, like, a little ball I can hold in my hand, and "vec literal" as an arrow between two balls I can juggle.

ah right, useful marks in a space. Then I would say vectors/arrows have a start and end, but its also useful to have a infinite line (a ruler?) for binary space partitioning.
Is a circle a thing you consider in scope or is that a composite? its a point + radius, could be defined by just an arrow though

actually even the rule is specified by an arrow/vec, its pretty strong that one.

I think for visual programming maybe there is a lot of interesting typed spatial operators like locus so a point+ locus:1d  = circle. And one you have areas then there is interesting things like is the point inside the area or intersections of areas (binary spatial operators) to create new areas with stranger shapes. Maybe a missing low level one is a curve, that has a bit more dimensionality than a vec and can represent things otherwise unrepresentable.

One example I remember from several years ago was 'bouncy numbers', which are these oscillating points. In general I'm a fan of the proliferation of primitive visual/dynamic types because even though you can represent them in text they are really their own thing.   <https://mobile.x.com/prerationalist/status/1440442305710723072>

Sidebar: Is there a good way to view content on X without logging in?

Some content (like this one) may be on Internet Archive: <https://web.archive.org/web/20210922105958/https://twitter.com/prerationalist/status/1440442305710723072>

(Probably only works for things from the pre-X days...)

Ah that's great, thanks. Really neat idea.

For pre-X tweets, there's also <http://nitter.net|nitter.net>, e.g. <https://nitter.net/prerationalist/status/1440442305710723072>

<https://github.com/akovantsev/wayback-url> browser ext

in terms of "ui widget for vectors" it needs to support precise editing (like plain text allows), but maybe limit input to valid values, e.g. dropdown with ints only, or enum, or range. Visualization "token" is trickier, because you would not be able to see a difference between 48º and 49º lines of the size of, say, capital letter.
(can't find demo of dev env with clock-like widgets for pointing to references spatially, but those are often... not useful to look at)

actually, what does "literal" even mean in visual prog context?
"dedicated representation"? "ease of creation via user input"? "no indirection", but GUI is already indirection...

this might have something relevant <https://vis.csail.mit.edu/pubs/varv.pdf>

The "what does literal even mean" question is why I'm so obsessed with this.

As for precise editing, yes.. maybe. Sometimes. It depends, right? Compare with numbers (floats, esp), rather than strings, in this regard.

wiki's definition boils down to "*literal* is a textual representation", huh.
in that sense – vpl vec literal is just a ui widget, regardless of what it looks like.

Also, choice of representation matters tremendously.

as soon as you transition from text file to "graphical canvas" – "correct" choice of default widget becomes less critical, as you already require more interaction from user, so basically you can have widget with 10 tabs where each is different projection with different amount of controls. And you are no longer constrained with "what user has on the keyboard to fast/conveniently replace current literal text fragment with"

(which is silly but very real obstacle for APL adoption growth)

So interesting but I have no clue what you’re hinting at. Do you expect textual representation or “graphical language”?

Florian — not sure who your question is addressed to.

Phew you went into full detail in the podcast. I now better understand what string literal means. Would the equivalent in visual programming be 1) A circle representing a drag handle 2) A literal circle, as in, graphical shape drawn to the end user?

On a sidenote: I find it interesting how electrical engineering has these standards for drawing schematic circuits and people seem to have lots of opinions on how to draw them well. <https://learn.sparkfun.com/tutorials/how-to-read-a-schematic/all|https://learn.sparkfun.com/tutorials/how-to-read-a-schematic/all>

Also thinking about the difference between icon, index, symbol. A literal heart represents the human heart :anatomical_heart:  vs the abstract heart :heart:  used to convey like/favorite. 

A side note / observation: electronics schematics represent behaviour that is *very* different from what synchronous, sequential programming languages represent. Any 5yo, any CEO at a whiteboard, any EE, etc. knows that a closed figure represents an asynchronous unit and that schematics represent inherent, massive parallelism. Programmers tend to think in terms of clockwork, synchronous, sequential, blocking functions which is the opposite of what is drawn on electronics schematics.

<@U01ULEWACPP> I'm experimenting with 1. The tangible things I'm programming with form the "source code" of my program. So while I could add some way to display them to the end user directly, for now I'm just using them to measure and calculate and then (indirectly) perform drawing operations. Like, the visual program is abstract, edited separately from the world of UI.

(This is fun for me because historically I've been all "there should be no distinction between program definition and runtime environment")

<@UC2A2ARPT> I have been working on this idea for a while: What if I use a diagram from Category theory to display and manipulate source code. Reading source code and writing source code through the diagram. 

I have been following a little bit the discussions here regarding visual programming but not extensively. 

The point is that when you describe a category you need to define the composition method, ie how two arrows compose in the diagram and what are the objects (points in the diagram).

It is all based on the fact that category theory can describe any abstraction. On top of that it allows you to have some formal ways to move between different categories or between levels of abstraction.

Maybe i should put something up to make it a bit more tangible because what i just described is probably too broad.

However to just give some relative perspective  for my categorical diagram, the point is really whatever i need it to be and the important thing are the arrows in the diagram. Say the category of types and functions contains types as objects, then my objects are types. Say i move up a level in the abstraction ladder, the objects could be classes in a dependency graph and the arrows the dependency direction. The points themselves are less important, as basically they just define a start and an end for the arrow, which is the important thing.

<@U071KDQALD8> check out algebraic visualization design for sure, it's an interesting twist on 'compiling to a diagram' <https://www.researchgate.net/profile/Gordon-Kindlmann/publication/265470662_An_Algebraic_Process_for_Visualization_Design/links/541030e10cf2df04e75b7707/An-Algebraic-Process-for-Visualization-Design.pdf|https://www.researchgate.net/profile/Gordon-Kindlmann/publication/265470662_An_Algebraic_Process_for_Visualization_Design/links/541030e10cf2df04e75b7707/An-Algebraic-Process-for-Visualization-Design.pdf>
c.f. an explicitly semiotic take <https://core.ac.uk/download/pdf/9991583.pdf|https://core.ac.uk/download/pdf/9991583.pdf>
tom larkworthy's latest might also resonate <https://observablehq.com/@tomlarkworthy/cell-map|https://observablehq.com/@tomlarkworthy/cell-map>

compositionality is rad but it leads in all sorts of directions!

<@U05UK5T7LPP> is think the confusers and the hallucinators were illuminating there. I was just calling them monoids over source code or the diagram, optimisations or transformations.

What initially made me post here now is the “there should be no distinction between program definition and runtime environment”

The semiotics one is really on point. Thanks for these links

It seemed worth doing: <https://archive.org/details/boyd-white|I just recorded a video> reading out every word of the 1985 paper "Law as Rhetoric, Rhetoric as Law".

(<https://futureofcoding.slack.com/archives/C5U3SEW6A/p1750125487897689|previously>)

Whoa. Didn't have this on my bingo card. I'm not familiar with this paper. Does it have some personal meaning for you?