Though I have found it valuable as a thought experiment for myself to make an analogy of well-factored FP code to DB normalizing/indexing. I learned the FP stuff first.

@Kartik Agaram that’s the half baked part haha. really just thinking database because (for me at least) it draws to mind visual/tabular interfaces in addition to pure text ones. i think you’re right about the graph database, or maybe more like datomic’s model where you have an entity attribute value transaction (and one other i can never remember) associated with each change (maybe plus some features like “changed by this function, reassigned by this function” for provenance

@Gary Trakhman i think the nesting stuff actually fits better with a db-style paradigm, or whatever it is that i’m describing—like with lenses, you might focus in on one data structure, or collapse it as you might in an outliner program

@Ian Rumac please also ping me when you put it on gitlab

@Kartik Agaram yeah i’m being more metaphorical/evocative than advocating for a direct copy. but the idea would be to cover a similar resolution on data changes

would love to pull apart a computation graph with my bare hands

at least once

@Kartik Agaram realized i was not clear: editor UI (but would have to be integrated with a programming model, maybe a la smalltalk)

"Interact": https://github.com/d-cook/Interact (continuing from previous) ... So the minimal UI would just expose the raw structure of everything, and provide a way to execute / evaluate code. (That's not the end goal, but I'll get back to that later) Entities (strings, numbers, lists, functions, etc.) sit freely on a canvas, where they can be moved around, inspected, expanded/collapsed, etc. Dragging values onto a function causes the function to be evaluated with those "arguments", and the result appears as a new entity on the canvas. Since there is a function for every basic operation, this is sufficient for making every kind of manipulation possible (but not necessarily ideal - I'll get back to that!) (Certain basic things like getting or setting a value could be as simple as drag-and-drop; but I'll get a working tool first, and then use the tool itself to see what works best for what -- let's call that "phase 2") Either way (e.g. whether the UI "helps" or not), any sequence of operations that can be done -- whether through user interaction or by evaluating "code" -- directly corresponds to sequence of (nested or otherwise) function calls. Therefore, by recording and replaying actions taken, all code can be created and viewed as direct interactions, rather than as the textual or structural representation one normally thinks of as "code". *(From here I might use "code" and "actions" interchangeably) So essentially you can do a bunch of manipulations, and then say "See what I did? Call that a function, and THIS value here is the result". And then edit the *actions and/or the object that represents the new function to replace certain values with arguments, etc. Now whereas "normal" code references values by identifiers (e.g. looking up variables by name), the user is able to just "grab" values that are just sitting there. So under the hood, code is stored as a list of actions, which contain either simple values or the index of some other action (referring to the result of that action) ... In other words, it's a DAG. When viewing / editing a function, actual values are substituted from the arguments, and you are shown the "aftermath" of the actions (i.e. values on a canvas), as if you had performed all the actions yourself. Changing any actions or values causes the whole thing to recompute (think FRP) This means that any operation you do becomes part of the current "function" you are editing. I'll provide a way to "cut" dependencies though, so you can use the canvas as an interactive REPL, and then either throw out the results, or "forget" how it was computed and just use the generated value directly. I could also have a "cleanup" that will throw out all intermediate operations that did not contribute to the ultimate result of the function. All editing is done in a function, so even the "top level" (global scope) is a "function" with its own record of actions taken. This also means that all the work of "programming" you do is recorded as some step somewhere, giving you multiple layers of undo/redo. Anything you do can be abstracted into a function and edited for generic reuse. E.g. "Here's how I do x to the code" ... Anyway, I'm getting lost in low-level specifics. I'll tie this up in another reply

(Continuing about "Interact" from before) Anyway, the point is not to have that specific tool per se, but to have something sufficient to edit code in a more freeform way, and to let whatever that looks like be very easy to evolve and change to whatever is more ideal for whatever context. The plan is to eventually bootstrap all the code for the tool into itself, so it can be changed and explored over time (per use, and to evolve this tool generally). The benefit is that whatever "nice way" is found to represent or edit something, can be immediately applied to itself to make it easier to make things easier, etc. One thing I'll provide to that end, is the idea of a custom "view". What I've described for viewing and editing functions is just one such "view", which is different than viewing a "function" as raw JSON. But perhaps something is better viewed as a table, or a graph, or some other interactive visualization. A custom view will contain whatever code is necessary to render something, and respond to interaction. This will probably "just be code", but (for example) there's no reason there couldn't be a custom view for specifying views using some custom DSL. And that brings me to another major goal of this tool: Things like DSLs, macros, syntax, even "programming language" (compiling, interpreting, translating), ... these can all be fluid things defined by ordinary code. The only difference is when and where it happens. But in a system like this, everything is the result of some "actions" taken to create it. So there's always some "code" that specifies how your code got created. And there's no reason to treat that code any differently! Expanding this further, with all the possible ways to view and edit "code" (or anything else), there's no reason to distinguish between "code" and a UI widget with its own custom behavior. No fundamental difference between a macro or a compiler, and anything else that let's you specify or view code/data one way, and then generate it another way.

... Sorry that took forever and is long-winded, but those are my main projects in ... something larger than a nutshell :P I also have a "Renderer" for rendering basic graphics in a declarative way (which I'm using for my other projects, but it's also generally useful). And a "Circuit" simulator I'm making PURELY just to demonstrate blurring the lines between code and interaction, etc., as I've described in my previous reply above