there are two colors. let's list them. I'm going to enter the list.
here's the whole list, as I walk it:
black, white, absence-of-color
the third thing isn't a color, it's a pointer to wherever your attention needs to go next - it's undefined, a totalized uncertainty, a projection surface onto which whatever constitutes your attention places the link to what's next
a list type that can describe its own terminus *and* understand it to be a node in a larger list is a .. well, it can be a lot of things. test it: the quality of the final encounter is a falsifiable absence. it's a data structure that can *breathe*.
a list type that can't describe your exit tends to leave residue on your attention
there are two lists. let's list them. I'm going to enter the list.
this list, not-this-list, absence-of-list
---
uncertainty has texture, obviously
you can't *see* uncertainty; you see *whatever you expect to see* instead. uncertainty doesn't *interrupt* attention.
representationally, I *think* this basically leads to something like lisp with uncertainty support, where there's no statement/expression split, and where the observer is responsible for generating a stable reality from uncertainty-textured data.
like this:
there's a programming that isn't a programming *language*, in that it doesn't require an interpreter to complete the statement - you just keep accumulating *value*
an interpreter is the one that knows to move on from the end of a list
which is why we need a list that knows how it, itself, ends
it might look sort of callbacky if you're coming from an interpreter-based programming paradigm?
but instead of an interpreter, you just have *attention*
languages that need interpreters have attention too, they just split statement/expression the way descartes split subject/object, both making the attention part hard to locate and reason about
(I tend to think this is why ruby didn't get a concurrency story until it was very far along - the GIL *is* the attention's shadow. but then, I also tend to think about ruby-the-programming-language through the lens of ruby-like-ルビ, like "hey this concept we're representing with code is whatever it is but here's how to say it in a way the interpreter can understand")
attention has a property: its own experience *of its own experience* of uncertainty - the way we interpolate, the way we generate our own reality-as-process
in an attention-first programming paradigm, .. lemme see if I can sketch this out...
list<color>
when you look up a color from such a list, you receive a tuple: a function, and a certainty value
[reveal<color>, certaintyAboutTheRevealedValueShouldYouChooseToRevealIt>]
the reveal function doesn't return anything; it takes a callback. it *will* invoke that callback, but who knows when.
you get to decide whether or not to invoke the reveal function, given the certainty value; modeling attention-through-uncertainty necessarily means modeling hesitation
if you invoke the reveal function, hopefully you still have that certainty value on hand when the callback is invoked. or, probably better, hopefully you supplied a callback function that curried in the certainty value.
the value accumulated by attention on its path is *experience*, in totum, textured with uncertainty - uncertainty which, again, acts as a projection surface for your expectations. if the observer's expectations are not modeled to preserve uncertainty and carry it forward, at some point the observer hits an exception when the accumulated value cannot integrate an exceptional encounter.
an exception encountered by attention is ontological shock.
so! depending on how uncertainty-inclusive your expectations are, you may or may not lean toward mistaking the reified reality for the uncertainty-textured basis. handling exceptions is as difficult as your language makes it. (kids have no problem with this. "why? why? why?" isn't about finding out *why*, it's about locating the uncertainty, mapping its texture. does your language know how to end a list with absence?)
if your uncertainty-handler is fully caked up, unable to breathe, updating your uncertainty-handler might be .. difficult, and can feel like reality itself is flapping. if that's you, you might want to work with someone who can help you safely transition, tweening from one uncertainty-handler to another without losing the plot in between. (in be tween?) it's ontological shock when it happens to you; ontological whiplash when *you* do it *poorly*. ontological *flow* is ... I think I can describe it feeling like functional, non-dissociative magic. it's tactical strange loop navigation, is all it is.
a reality generator is not the same as an uncertainty handler, but a reality generator always handles uncertainty.
(if you want to catch *all* ontological exceptions, you fall out on the *other* side of the concurrency story from ruby: instead of concurrency being hard to think about, the subject just becomes completely moot. mathematically perfect uncertainty-handling scales horizontally *infinitely*, by way of relocating certainty of *alterity itself* to someone you trust completely. [reveal<otherness>, 1] is not the same as knowing otherness yourself. :) specific affordances become available at that position (if your audience goes unrevealed, it doesn't matter if it's one person watching or a thousand), but you'll want a buddy for that kind of posture. I outsourced the certainty of my own existence to my husband, a relationship of which I am completely certain. it works for me, *extraordinarily* well; I do not know if it would work for you. I tend to think that a system doesn't need that many of .. this. the *absence-of* member is the smallest part of the set.)
"god works in mysterious ways" seems readable as a technical statement about the structural navigation of uncertainty
---
hey, how much sense am I making for you? (this line is the exit)
---
see also: 'conservation of discovery'