Do you want existing software to have this room property? Or do you want some set of independent universes to choose "standards for interoperability"? I think we have the second already, and to the extent it fails it's because of the first problem. So let's talk about the first problem.

Building a passage/wormhole between two rooms/universes is hard. Even for the programmers who built this one room you're in now. Nobody wants to make it easier, because that's even harder. Nobody wants it enough to put in the work, because everybody grew up living in a single room just like you. So it won't happen until somebody somewhere starts building it into software they didn't write, without asking for permission. We have to make it scalable to hack on unfamiliar codebases in incompatible ways.

What I am hoping for as a first step is a change of attitude. Stop talking about escape hatches, start talking about bridges.

Yes, interoperability is hard, even more so if you want to retrofit it. So let's start with new environments, which is what many us in this space are working on or dreaming of.

It's actually happening. A nice example: https://github.com/JuliaInterop. What I want is more of that. More effort for making systems interoperable.

That library looks like an example of my second option. That can certainly work! It becomes a problem more of social organization, learning about n black boxes, getting them to interoperate, opening issues. Submitting patches to n black boxes has some scaling issues for most people.

let's start with new environments

Did you mean new environments interoperating with existing ones? That still has scaling issues if you care about multiple existing ones.

New environments interoperating with other new ones = hard yes! If anyone cares.

I think "new interoperating with existing ones" is the most reasonable starting point, because the new players have the highest motivation to connect to the "old world". As in the case of Julia. And yes, this has scaling issues. But if it leads to competitive advantages ("I picked Julia because it has all those nice bridges to other languages"), it can lead to the change of attitude that is needed.

All-to-all bridging without scaling issues requires infrastructure support, and then adoption of that infrastructure. The only attempt I am aware of is Oracle's GraalVM/Truffle combo. Which requires re-implementing all languages, but apparently makes this relatively straightforward for JVM languages.

I just read Stephen Kell's paper The Mythical Matched Modules, it examines what a practical solution to this interop problem might look like. He was a language Cake which I haven't looked at but at first glance looks a bit like Cambria

I just read Stephen Kell's paper The Mythical Matched Modules, it examines what a practical solution to this interop problem might look like.When I first read Stephen's paper, it was quite an eye-opening moment for me... 😄 It pushed me to start a community to share and discuss ideas like this around user control and interoperability. Perhaps some other resources in the catalog there (https://malleable.systems/catalog/) will be of interest as well.

There's a painful absence of tooling for the "integration domain" (as Stephen calls it) in software today. Such tools would connect and unify existing languages, ecosystems, and modules, just like the wires in circuit design: they unify parts from many different sources into something new without requiring coordination or agreement between the parts themselves.

If it were (on the order of) adding wires from module / language A to B, we'd see an explosion of software reuse. It should not matter what language some useful bit of code is written in, but unfortunately today, language boundaries create high walls.

To bridge to C, SWIG has served me well. http://swig.org/

Feels like quite a bit. Why?

I was thinking how much computation is in tools of thought and how much knowledge management there is in future of coding

I think the intersection of both may be the most interesting part

Yes! In my opinion development environments could be a lot more like Roam Research and the like: We have functions, each function references other functions and is referenced by other functions, thus shaping a graph of functions. So why not make this graph the structure of the environment, rather than some more or less arbitrary folders and files.

This thread seems relevant (thanks Stefan Lesser): https://twitter.com/vgr/status/1401253631073034241

For me the future of programming is about making it simpler for everyone, especially people without technology backgrounds, to take advantage of computation and the powerful devices we carry around with us all the time.

I consider a tool for thought something that literally helps us think. Not attempting to do the thinking for us, or automate away thinking, but augmenting and enhancing our capabilities to understand, ideate, and explore. We stay in control, and our cognitive abilities are amplified.

After all, people who use tools like Roam Research are “just” modeling certain parts of their individual thinking process and the tool gives them an environment to structure their thoughts in, which is remarkably similar to designing a data model, except that it requires much more flexibility and dynamism than what we computer people think of when we talk about a “data model”.

From that perspective the overlap is huge. I do acknowledge, however, that this is just a narrow definition of both tools for thought and the future of programming, and there are plenty of other areas to explore in both.

I'd suspect both communities (FoC ToT) feel a nigh hopeless mess swirling in their head, and simultaneously a borderline New Age faith in breakthroughs that are available in that very same head – if they could just locate a catalyst, a seed crystal

I don't know the Tools for Thoughts movement very well, but I guess that it can help improve programming activities which are still too often limited to raw text code editing, even if you can write some specification doc, with design and system architecture represented visually, etc. But as programming activity is - hmm - a thought process, it has to be improvable with better tools for thoughts.

So one can dream of a programming environment that provides tools for the "thinking" of the programming artifacts that are being created, and the way the thoughts are recorded/shown to be deeply connected to the actual programming artifacts.

I mean, when we start a new relatively complex project, we often start by discussing and thinking by drawing sketches on a whiteboard. Then we move to our computer writing code to bring the architecture/design to life. But the connection between the "thoughts artifacts" and the system is lost. Why not having tools that help us keep the too connected?

Is there a Tools for Thought community (slack, discord, etc.)? Seems a little more broadly spread out between different app communities like Roam etc.

The overlap is as pointed out substantial, but the approach of either side look like they start from different philosophies. Projects that show up in Future of Coding seem to emphasize tangible experimentation with the process of engineering, often from a bottom-up approach (i.e. what are the small composable pieces and the processes that construct them). On the other hand, Zettelkasten systems and other such approaches are more top-down, in the style of trying to understand or create a specification, and in general maneuvering in graph-like space of ideas rather than lower-level processes with causal chains.

Meeting in the middle is the natural next step, but I wonder where the emphasis should be placed. Are we missing an interface between thought and implementation, due to the tremendous difficulty of translation as pointed out by many already? Are the two sides not melded enough, or instead are they not well-separated enough? Is there a missing calculus of thought somewhere floating in this space? Would love to explore these areas with anyone interested, or hear about any other interesting endeavors along these lines.

Christopher Galtenberg I feel personally attacked. :D

But seriously, I agree the intersection is very large. To me, they're both fundamentally about representing (and manipulating) ideas in digital form. I've been thinking about them as different aspects of the same problem for a while now.

You can go from a bug (or any effect), to it's cause

There's full-blown reverse execution, which is code that can run forwards and backwards. This is hard.

Then there's just rewind (as I call it), which is just capturing and restoring past program states. (This is what the game Braid does, and what I'm planning to do for Hest, and I believe what omniscient debuggers do, and what you can easily do with immutable data structures a la Elm's time-travel debugging.)

• Both would let you run some code, stop, rewind a bit, make some changes, go forward again, rewind again, make more changes, etc. It would give you a programming experience that's sort of like editing music in a DAW, or editing a video in a nonlinear editor.
• @William Taysom had a neat idea (hope this is okay to share) about using reverse execution as a way to start with some data in a desired final form, and to build backwards towards the inputs needed to get it in that form, interactively.
• A difficult thing about pure reverse execution is that you can't have a function that would return the same result for two different inputs. For example, you can't have a function that does a multiply by zero (because you'd get the same result for any finite input). You need each input to uniquely map to an output. But — and this is wild — if you can achieve this property in hardware, reversible computers can be vastly more energy efficient than non-reversible computers, because of thermodynamics: less information is being "lost", so there's less heat (entropy) as a result. (Vast simplification — others here could probably summarize this better than me)

Been summoned. 😈 Often a person wants to answer "how did this happen?" Reverse execution is one way to go back, which suffers from having too much detail usually. So it's good to take the, usually incorrect, "how can is this even possible" value and just follow its data-flow but with surrounding context because (1) you're probably looking for a control flow branch not taken and (2) the data-flow tree itself is liable to be extra bushy yet easily pruned. In contrast, stepping forward has the problem that a lot of initialization/configuration happens, especially in framework code, which is noisy and mostly irrelevant.

And for pure reverse execution, the trick is to automatically lift functions so that they pass whatever data is necessary to run in reverse in a hidden channel. In general f' x = (f x, x) works, but sometimes you can use shortcuts. But then you might as well use checkpoints like most people do. And the f' above isn't so useful since it's referentially transparent and the whole point is that you want to look inside f.