Thanks! I guess I'll clean up my notes and post them on futureofcoding.org community through the share-your-work section, to explain all the details and possibilities.
I took inspiration from this [1] classic article by Henry Lieberman, where tags are applied to elements of a composite as a way to edit its structure; and I combined it with the idea of a templating system to process or generate items in bulk (all templating systems do this, my idea is to abstract it into a generalized, always present interaction mechanism).
I liked that book so much I bought it in paper form; also YWIMC. Lieberman's work in particular has always been inspirational. I think he sits down the hall from Jonathan, but I could be misremembering.
This morning I was working on a problem that I was thinking would be ideal for a system like this: I was taking notes in prose about potential blowing agents for waterglass or other geopolymer foams—things that produce gas when the polymer is heated to its softening point. For example, chalk, ammonium chloride, sulfur, aluminum hydroxide, sal mirabilis, saltpeter, or carbon plus silica. Each of these blowing agents produces a certain number of moles of gas per mole of blowing agent, has a certain molar mass, a certain density, a certain cost, and a certain activation temperature, plus certain material-compatibility concerns—you can't disperse hydrated sal mirabilis in an aqueous solution, for example, or chalk in an acid solution, if you want them to be intact in the unblown geopolymer preform. These are "givens" that can be found in a literature search or, in some cases, a search on MercadoLibre.
In the prose document, I would like to be able to tag the gas production per mole, molar mass, density, activation temperature, and material compatibility in such a way that I can render a table of the candidate materials in the document itself, and then sort it by gas production per mass, per volume, or per dollar, and filter it by activation temperature. Gas production per mass is calculated from molar mass and molar gas production; gas production per volume is calculated from gas production per mass and density, and similarly for gas production per dollar.
Is that the kind of thing you're thinking of, or am I imagining wits very differently from what you really have in mind? I look forward to reading your notes! (I'm not in the Slack. I hate Slack. It's ransomware.)
A step beyond would be to type the reaction equations into the prose document and calculate the gas production per mole from that, and use a database of atomic weights to calculate the molar mass from that as well. With a database of the formation entropies and enthalpies of the compounds, I could not only calculate how endothermic the decomposition is (or, rarely, exothermic) but plot an Ellingham diagram as well, which would be pretty useful as a double-check on the sanity of the reported activation temperatures from the littrachaw. Together with combinatorial search functionality, it might also enable me to anticipate problematic side reactions, or how the activation temperatures would shift if the foaming was carried out at 1 MPa.
Some of the quantities I'm calculating on have units attached, such as temperature and density, and some have intervals of uncertainty, such as price, and it would be useful to have the computer track those things instead of the human. Confusing a Gibbs free energy in kJ/mol with kJ/kg can be a problem; similarly gas production per gram or per cubic centimeter.
Some of Jonathan's work on Subtext has focused on variants of or alternatives to test-first programming; in spreadsheets people sometimes do test-first programming (for things like the equilibrium-temperature calculation I mentioned above, for example) and then delete the tests. In a context like the blowing-agent survey, being able to hide them instead would be better.
Finally, ideally, I'd like to be able to transclude at least the givens and possibly the calculation results in other notes: "According to my notes in [0], aluminum hydroxide is stable at atmospheric pressure up to 220°, ..." perhaps eventually refactoring those inputs into a centralized database so that I don't have to remember which note has the boiling point of sulfur in it.
The calculation part would be easy to do in Gnumeric or localc, but those handle the prose, units, and intervals very poorly at best; and they would be hopeless for the equation parsing part and, at best, clumsy for the database queries and Ellingham-diagram plotting.
> In the prose document, I would like to be able to tag the gas production per mole, molar mass, density, activation temperature, and material compatibility in such a way that I can render a table of the candidate materials in the document itself, and then sort it by gas production per mass, per volume, or per dollar, and filter it by activation temperature.
Yes, that seems be a very direct application of my wit concept, with one wit for each magnitude, placing each wit as a column of the table and having one row for each material. In the end, a wit is basically like a user-friendly version of a typed pointer in C, with a 'visual' GUI for combining them like an Excel pivot table or a OLAP 'data cube'. You can read the value at the end, or you can iterate it over a collection to process a list of values; the meaning is located in the code that uses it, more than in the object itself, and you can share the reference to the same value in many different places.
Of course there are already several systems where you can define a data structure in code and show it rendered as labels on a document (see idyll[1], or the original Explorable Explanations), but I have the idea that using such system shouldn't require any code for basic or moderately-complex programs:
1) the user should be able to define the data structure through direct interaction, like on a spreadsheet (e.g. Airtable does this fairly well). But the raw data could be extracted from existing documents, like a web scrapper, with the scrapping expressions defined through point-and-click over the actual data. The now extict kimonolabs[2] had a good interaction model for this part. **
2) this structured data could be transferred between applications with a copy/paste-like universal protocol (most current applications require coding against APIs for this),
3) calculations can be defined and re-applied to new data collections through simple formulas and more direct manipulation, possibly with Programming-by-example assistance tools. The people from MS Excel are doing this, but they lack the universal API - everything happens inside Microsoft applications.
For your example, you could store your database of atomic weights as "hidden wits" somewhere else, extract the desired value by naming the label (wit labels are global variables under a particular namespace), and feed its values to the expression where you want to calculate a function application with the data.
> The calculation part would be easy to do in Gnumeric or localc, but those handle the prose, units, and intervals very poorly at best; and they would be hopeless for the equation parsing part and, at best, clumsy for the database queries and Ellingham-diagram plotting.
The good thing of wits is that you could chain them and transfer information between applications, with each app handling what it does well, and returning the data back to the origin; i.e. any workflow that you could do manually with copy-paste. In this sense it's like a Unix pipe, but in a visual environment and transferring structured data (which can be de-composed at the receiving end, extracting one wit at a time). They are also like those awkward connector lines in dataflow visual languages, except that instead of a line you have a label with the wit name at the origin and destination.
Again MS has Power Automate as a tool with these capabilities (I think its way more complex and powerful than the classic Apple Automator), but again Power Automate restricts you to a closed runtime environment of applications that support it, which you glue only through code.
> Is that the kind of thing you're thinking of, or am I imagining wits very differently from what you really have in mind? I look forward to reading your notes! (I'm not in the Slack. I hate Slack. It's ransomware.)
I don't like walled gardens either; I've heard Matrix.org and Element.io are lovely this time of the year... :-P
I've bought the domain http://witclay.com, though I never managed to clean up my notes and publish them over there. If I manage to gather an audience in that group, I will probably summon the will to publish my use cases over there so that I can show them in the few next months, providing some concrete examples that are more intelligible than just abstract ideas.
** The wits here would be the yellow bubbles with the extracted data. Again, many of my insights I've seen realized in other systems; my idea is an orchestration of all them into a single user-centric system that made all them compatible, at the user fingertips.
I'm reading through The Lab Notes from Alexander Obenauer[1], and I'm noticing lots of coincidences. Universal data portability [2] in particular shares the same code insight of reusing all user data in any context where it's needed, and Universal reference containers [3] are the primary use case for my idea of Wit.
With the example interactions in that website you can get very close to what I imagined my system to be (though I would use a "select+tag" metaphor more often than the cumbersome drag&drop).
I still have the idea to allow spreadsheet-like processing on top of those metaphors, but the essence of the system is quite similar to that one; many information systems are converging in that same direction toward a similar model of interaction.
I took inspiration from this [1] classic article by Henry Lieberman, where tags are applied to elements of a composite as a way to edit its structure; and I combined it with the idea of a templating system to process or generate items in bulk (all templating systems do this, my idea is to abstract it into a generalized, always present interaction mechanism).
[1] http://acypher.com/wwid/Chapters/23ProblemSolving.html Making Programming Accessible to Visual Problem Solvers