every color
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
when you look up a color from such a list, you receive a tuple: a function, and a certainty value
[reveal, 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, 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)
Last updated
Was this helpful?