Some of these goals are partially in contradiction. It might be useful to identify such pairs as lines of tension.

Example: "good defaults" vs. "don't hide things from the user". Unless all defaults are always visible (e.g. pre-filled entry fields). using a default effectively hides the existence of a choice from the user.

That's a tricky UX problem for sure, but I don't think it's a contradiction. You should be able to inspect your defaults, even if you don't feel like changing them. Somewhere down the line there's probably "see how this thing was generated" UI operation that you can use on generated content of all kinds, including defaults, materialized views, etc.

Would it be better to say something like, the information should be possible to access by some reasonably short and predictable route (depending on how obscure the info is), not that it needs to be on display all the time?

That sounds better, but it only pushes the limits of the contradiction a bit further out. In the end it all depends on the number of default values. One or two are easy to handle. Ten are a UX challenge, but doable. When you reach a thousand, the mere number makes it impossible to make them easily accessible. You need to sort them by relevance, which is already a judgement that developer and user may not agree about.

This is an essential feature of computing, which philosophers label as "epistemic opacity". Once an information system has features that exceed the cognitive capacity of an individual, new rules apply.

Sure, at some point you're just reading the source code, and no clever UX can save you from how hard that is. But before too long you've zoomed in far enough that the defaults and specific preferences are just data with no particular relationship, and the defaults/visibility tension is no longer even well-defined. Honestly, any way of finding out what an app is thinking that's more accessible than hooking up a debugger is an improvement on the state of the art.

I have trouble commenting on these sorts of high-level goals. They all sound reasonable, but many of them are vague or extremely broad, and the measure of success is unclear. The document reads like a general guiding light for the human race, rather than the set of goals for any one project.

I would fare better at commenting on narrower, more concrete goals for a particular project, especially a language design project.

If you're looking to refine this brainstorm into a presentation, try to: (1) tighten up the list, (2) provide specific good/bad examples, this helps with vagueness, (3) show connections between your bulleted items.

I imagined it as a sort of purely conceptual piece, but that's a classic blunder in math pedagogy, so maybe examples are in order here too.

The intended context is that these are the first section of a longer text document that gets progressively more concrete and detailed, going from these philosophical goals to (very much WIP) technical ones, with each layer referring to previous ones for justification (chain of reasoning is important, because some of them get pretty weird). That would be where most of the meat is, and maybe I've been assuming that those will serve as examples that clarify the very abstract parts. So I'm reluctant to make this part longer. Maybe one of those side-by-side formats would be good with examples and explanations off to the right?

With what I've given you, maybe it's enough that people aren't actively confused on what I'm even saying. Like I said up front, this is primarily an exercise in whether I can convey the ideas at all. I've historically had trouble putting them into words at all. I know it's a little weird using this slack as basically a writing critique group, by that's where I am right now. :)

I almost posted, and still might, an even more abstract question about what even can serve as justification for, e.g., one set of data modeling primitives over another.

I’m not confused by the wording of the broad principles you’ve outlined, but I'm confused as to the justification behind them, and whether you plan to act on any or all of them, and how 🤷‍♀️.

i’m surprised how many of the intuitions line up given there are practically no hints on implementation. 😄 only thing that jumps out is the ‘platonic realm’ - worth noting even that’s encoded in physics (as are bits), and ultimately intent is a world-derived model. i wonder if you resonate with this writeup: https://alexanderobenauer.com/articles/os/1/

Yes, my concept of the end user UI is extremely similar to the one in your link. If that OS existed today in a way that was interoperable with the rest of the world I would have to consider shelling out serious money for it.

I'm realizing I have a hole in my definitions of intent as written in bits and platonic intent. The practical upshot is that I want to write my intents as if in terms of a non-physical platonic intent (and don't want to get into the philosophical question of whether that's meaningful when all/most of our intents arise in the real world :D). Certainly, programs written that way (exceptions for low level code) should be independent of any particular encoding of the things on which they operate.

I would look at HCI (human-computer interaction labs), but honestly / arguably … a lot of computer science, data science, and information science research falls under this umbrella. Don’t forget about all the hidden / lower level inventions that needed to happen to let us dream of cool new tools / interfaces for thought!

"tools for thought" and "end user programming" are very very different things from an academic perspective

how so

how are they even similar? a paper and a pen is a great tool for thought, but have nothing to do with end-user programming. and programming a Lego Mindstorm robot is done by an end-user, but has nothing to do with being a tool for thought.

Using one to facilitate the other is an explicit choice, and should be a conscious and well-reasoned decision.

yeah I guess these days its fashionable to focus ‘tools of thought’ to ‘computational tools of thought’, but you’re right that the framing there is too specific

These days, "tools for thought" is popularly used to refer to all the Roam-likes, even though they hardly cover a sliver of the original meaning of the term.

My feeling is that voting mechanics are fundamentally at odds with deep and sustained collaborative work.

I think the wiki model is the best I’ve seen for this kind of thing. Ncatlab is a great example.

The problem with voting based system is that they subordinate their ordering to popularity metrics which means fashion rules. It’s too common for unpopular ideas to be critical/decisive but end up overlooked for lack of popularity. In fact, this is a lot of the reason we’re in the current mess we’re in, afaict.

The group blog is also nice, but for different purposes than the organization of deep collaboration. The n-category cafe is a good example of the success of this I think! Or lambda the ultimate.

yeah maybe voting is not a great idea. The part that was more interested in is indexing niche interests through group tagging, so you can find what interests you.

I see ncatlab has some kind of topic cross linking which is helpful for exploring and discovery.

n-category cafe doesn't have anything, on my initial look it doesn't seem to be particularly discoverable, am I missing something?

In the observable world notebook is the unit of content (which is very close to a blog post). In FoC a slack thread is the unit of content.

In ncatlab, articles are wiki and can share space with the index, which is super great for zooming around for discovery. Hmmm, maybe thats an important feature of wikis and something to carry over?

Thanks for the pointers they are great to think about what makes them great

What I've seen working in practice is explicit "top of the week", "top of the year", etc lists based on voting. I don't think you'll be able to usefully fit both new items and old good ones in the same "front page", but if you relax that requirement it gets easier.

yeah thats probably the simplest way of generating long term insights and providing a reason to check occasionally. Long term is difficult because you need to normalize against usage at each point in time too, Doable though.

We've talked a bit about how to turn the ephemeral stream of Slack (and others like it) into a more durable knowledge base on the #G016MGK6QE7 channel. Things have been pretty quiet lately, but maybe a good time to restart that convo?

Thanks for the pointers everyone! I made an initial implementation. https://breckyunits.com/aftertext.html

If by orthogonality you mean cross product kind of things, I think Concurrent Hierarchical State Machines / UML statecharts can represent orthogonality well with a closed form PARALLEL operator for two state machines.

But this is orthogonal in the sense the two things are independant, the state of the system is the cross product. In the simplest form they do not interact, though it does have mechanisms for communicating.

https://link.springer.com/content/pdf/10.1007/3-540-44929-9_24.pdf

Is this the right lines of thinking?

@Tom Larkworthy You are reading my thoughts!

cool, so the root of these machines is the ragular language thingys. So maybe a regex can be considered a representation with orthogonality at its core too (you can concatenate and | regex expressions). I like HSM formalisms though because they play well with formal verification and somewhat resemble normal programming if you squint really hard.

@Tom Larkworthy Yes, I think HSM takes state machines in a great direction! I am pondering the following way to perceive orthogonality in HSM’s. Traditionally we would look at is as the typical concrete representation invites: { a: { b: { c: ... } }, d: ..., e: ...} . So I consider the idea that this is more concrete than it need be philosophically. Here is an attack: Let’s define two operators: & for combining values into and-states, and : for combining values into hierarchies. Then we write a:b:c & d & e . Traditionally, the CS practitioner and programmer would ask for precedence rules or brackets to disambiguate the expression:

{(a:b:c), d, e} or {a:(b:c) , d , e } . Here is the point where an alternative orthogonal model might be possible and might be valuable from a language-design point-of-view: In stead of nesting we lay out the values in a two-dimensional grid, e.g. drawing the & relation horizontally, and the : vertically upwards. Then, a noteworthy thing can be observed: The a value is now both an element in the and-state (horizontal relation) and the first element in the hierarchy (vertical relation). This is my criteria for detecting of orthogonality, as I meant it in the OP.

Wow thanks!, it was kind of cool to actually write it down.

Follow-up question: So, while this evidently is drawable; does it map well to cognition, implementation? Is it view-point in the eye of the beholder, or does it open up them HSM model for e.g. generalization/deeper understanding?

My own experience is that HSMs are hard to program, but they are amenable to machine verification because their state space is enumerable. So thats useful, and in practice the paxos protocol is a runner for state machines, so they are used in technical domains for real (not sure about flavour of state machiens though, maybe not HSM).

I also see them in realtime systems (https://www.state-machine.com/) again, coz they are complex enough to be useful, but simple enough to really figure out and trace symbolically.

The QP frameworks people make a strong argument that HSM is necessary to avoid the state space explosion problem that basic state machines suffer from. This is directly because of the orthogonality. When you can express things as two orthogonal basis vectors you avoid having to flatten them into their non orthogonal space (the cross product). So yeah, I would say orthogonality has made state machine scale to the realtime systems domain. Of course, HSM are still less expressive than turing machines so they clearly are not used much when we have access to higher level languages and want to move fast and break things.

This page expresses it much better and I think it is about orthogonality https://www.state-machine.com/fsm

(yes I agree with your orthogonality picture, except that the H itself is an orthogonal, so we don't really need the concurrency bit for HSM to add orthogonality to FSMs). I think in this diagram the edges are dimension in your orthogonal space diagram

two, maybe three axes of orthogonality is nice for cognition. nesting is one way to manage more dimensions than that. seems to me you want to make it easy to navigate a variety of representations without losing context. https://www.quantamagazine.org/the-brain-maps-out-ideas-and-memories-like-spaces-20190114/

So many interesting ideas! There may be many features that is prevalent in perception, but under-supported in the PL tradition for mundane reasons; e.g. Regular Expressions/ matching on pure text; I see at least two perceptual features that could be nice to support: Context/Refinement and Othogonality of Horizontal/Vertical directions (2D): Refinement of selections are described e.g. in Structural Regular Expressions by Rob Pike [ pdf ]. But I’m not aware of Regexp’s that do 2D matching. It’s pretty clear programmers make use of the vertical dimension e.g. by the tradition to align similar lines of code (pervasively done in Haskell and similar languages.)

The a> value is now both an element in the and-state (horizontal relation) and the first element in the hierarchy (vertical relation).> This is my criteria for detecting of orthogonality...

Is this not satisfied any time the stuff nested under a is fully contained inside it?

I'm having trouble seeing this as anything other than a syntactic change. Nesting is still going to crop up in the semantics, or at least, it will cause a lot more trouble to get rid of it than you could possibly benefit from. Syntax should clearly express that.

I do think things that don't explicitly depend on each other should be allowed to be going independent. For instance, finding all the natural concurrency in a program. I don't know if this is exactly what you're saying, but I think it's related.

Somewhat aside: I've come to think of nesting and sequencing as being different sides of the same concept, namely dependency. I think this is supported by the way nesting-based encodings of sequences, like linked lists and fixed points, keep cropping up.

Haven't read it. But what you describe sounds very much like Daniel Dennett's

Intuition Pumps And Other Tools for Thinking

https://www.amazon.com/gp/aw/d/0393082067/ref=tmm_hrd_swatch_0?ie=UTF8&qid=&sr=

mental models? https://fs.blog/mental-models/

https://www.amazon.com/Super-Thinking-Book-Mental-Models/dp/0525533583

https://www.amazon.com/-/de/dp/1999449002/ref=pd_bxgy_img_1/136-7556104-6433603

World Beyond your Head by Matthew Crawford is an uncoventional choice, but its a nice “Field manual” for someone who used to be a knowledge worker and then pivoted into a craftsperson

There's a very neglected type of thought called "nested agent modeling" or "recursive mind reading," which I think is in fact the real reason humans have large brains. Gentle graphical explanation here:

https://medium.com/@ThingMaker/common-knowledge-and-miasma-20d0076f9c8e

A related paper here. Explains 7+ layers of nesting is actually possible to keep track of, but I can show 20 layers is not out of the question in some situations.

https://www.researchgate.net/publication/271539325_The_ease_and_extent_of_recursive_mindreading_across_implicit_and_explicit_tasks

Another common but not often mentioned approach to thought is provisional reasoning about new paradigms, where you provisionally accept a claim as 100% true and then look at how well the known facts interlock in that scenario, seeing if it altogether ends up making more sense than the existing belief system /paradigm (rather than questioning each piece in turn with reference to the current paradigm, which heavily biases one in favor of it).

An example would be imagining your stock portfolio has fallen greatly a month from now and seeing how much sense the currently known facts would make in light of that, if in that scenario you would say the writing was on the wall or not; then imagining it has risen greatly a month from now and doing the same; then imagining it has stayed roughly the same; then seeing which one altogether makes more sense.

Compare the plausibility of the two at the end, as unified wholes, rather than midway through. Very few seem able to avoid the error of switching scenarios midway through.

You might enjoy ‘The Last Question’ by Asimov:

https://www.physics.princeton.edu/ph115/LQ.pdf

But of course 🙂

I've read this before, not sure from your blog or somewhere else. Great story, made a mark. :)

I have a central concept of simulation in a different sense, like having a fine-grained hierarchy of (often very domain-specific) language interpreters, running programs in a hermetic sandbox, and other Turing-flavored simulation things. :D (It's an outrage that sandboxing software is so hard in practice when simulation is so foundational to computing.) I'm probably still missing some nuance on the model-centric perspective of simulation, but I bet they can be unified.