"in all situations" = interop with every program the end user could possibly run? Or every possible task someone might want to perform?

Kartik Agaram kinda yeah :). Reading "The Humane Interface" or whatever by Jef Raskin was influential to me in that regard, as a design at roughly that scope.

Another angle: it's beneficial to users if the "programming" interface of their system closely resembles how you do things "by hand". You can see this in effect today with some power-user oriented programs where there's a blurry boundary between programming and high-leverage manual interactions (I'm thinking kakoune, but Vim will do, I suspect Photoshop too). Leaning into that idea tightly ties your programming and UI models.

didn't frontpage and dreamweaver take this approach?

FP aimed to make website creation be more like templated document creation and dreamweaver went a step further. wordpress is kind of a hybrid.

I'm not familiar with Frontpage or Dreamweaver, but I see HyperCard as taking this approach. e.g. "Every user should be able to extend this in certain ways, and we're going to accomplish that though some abstraction and uniformity."

That helps a lot. I wonder if you'll find my new project to fit the bill: https://github.com/akkartik/teliva

Interesting.

Automator, which adds simple scripting to Figma, would perhaps be something that answers this in the domain of a design tool.

Of course, similar functionality exists also in Photoshop, Illustrator, etc to some extent.

https://automator.design

Also RPA (robotic process automation), which enables scripting web and desktop apps for business use, is perhaps something that is related to this.

RPA has evolved from test automation tools (think Selenium and similar tools). Many RPA tools have visual editors that let non-programmers record and script automations.

https://en.wikipedia.org/wiki/Robotic_process_automation

informing could be a database write too.

Boring but honest answer: very confused.

I could see it working if "informing" consisted of adding declarative facts to some AI or other goal-driven system that lets it figure out procedures on its own. But trying to make "inform" mean anything other than supplying declarative knowledge is always going to be a stretch at best, likely a constant source of confusion. The payoff would have to be really big.

oh, that's too bad because etymologically it fits superbly

but yeah that's what I wondered.

I guess that in french, synonyms to "informer" are more often used. With "renseigner" closer to 'supplying information' and "informer" slightly closer to 'picturing in one's mind'.

Also, 'computer science' translates to "informatique".

(in french it breaks a bit as 'informing', as in 'the act of programming', would become "information", which means 'data')

Interesting. Of course in English we do have "information technology", but that's much more about installing and running programs than writing them. What's the French term for information theory, in the sense of entropy, signal/noise ratio, etc?

My trick to find that is to go to the wiki page for, say, information theory, then I can see how other languages call it

it's still 'théorie de l'information' ! Which can be kinda confusing

Sometimes there is huge differences in wikipedia pages across different languages, it's wild to think about

Side comment: Wikidata is often more useful than Wikipedia for translations of technical terms. See e.g. https://www.wikidata.org/wiki/Q131222

oh ! thanks ☺

I've been looking for the same for a while

https://linear.app/blog/settings-are-not-a-design-failure

Maybe th discussions is even better https://news.ycombinator.com/item?id=30181291

I think the movement of no settings went too far and hurt the advanced user, so we are seeing a swing the other way a little.

Tom Larkworthy thanks for those links! In my mind at least, decisions and choices are not the same as settings and configs. I agree with the assertion in the article that users want choices and the power to make decisions but I think it's wrong to equate this with needing settings.

Settings feel like the buttons, switches and knobs that are hidden on the backside of an appliance because they're considered ugly.

This presupposes a kind of user-programmer divide: where one class of people (programmers) dictate the choices that are available to others. I want to see a world where all who use computers have equal(ish) agency, and so grappling with the notion of settings in that context seems to be an important task.

To be clear: I don't think we should get rid of settings in the current day, but think there must be far better ways to give people agency in the long run.

Even in the best of all possible worlds, user agency comes in degrees if only because users are different and agency comes with some learning curve.

I tend to be among those who want as much agency as possible in their core tools, but I am also perfectly happy with a "preferred locations" setting in the weather app on my phone: just what I need with zero learning curve.

Konrad Hinsen yeah that makes sense to me, setting a baseline and allowing people to move “up the curve” without limiting them, and without forcing them to build from nothing.

Oh this hurts — the fact that C-style colloquially means "programming language syntax".

The one I notice most with programming having broken my brain is that in a page of English prose, I will identify misplaced commas as though they are the single most important part of the writing. 😿

My god, William, you've just diagnosed me. What has become of us?!

it is wild how common programming elements/keywords stick out like a sore thumb now, the ifs and thens and ampersands send a brain ping I don’t remember them sending from before learning all of this

This related to the "the curse of knowledge", a cognitive bias where knowing something really well makes it more difficult for us to explain or teach it to someone else.

One of the solutions to this bias is to work closely with novices, which can help us develop an understanding of which concepts are difficult and why through observing the novice grapple with concepts.

also, another related note which comes to mind is that much of learning a field is becoming fluent with the notation. Once we become fluent, the particulars of the notation, which were so impenetrable at first, drop away and we see merely the concepts behind the notation.

think about a high-level pianist reading, for the first time, extremely complex sheet music

Is there any good terminology around that fluency with notation / seeing the concepts behind the notation concept? That feels like there should be a term for that.

it looks like ‘notational fluency’ is a term in the AP Calculus world

reminds me of the following:

we shape our tools, and thereafter our tools, shape us

Redefine "language" as information with interaction, presentation, translation, and nesting, with other languages. Separate the specification from implementation/concept from substrate. Compress specification across languages. Result: Common mode of input/editing, unified while specialized data model, combined with [the rest], also portable, translatable, adaptable.

@Leonard Pauli I’m not sure I understand what you’re getting at there or how it applies to what I wrote above, could you elaborate?

I firmly believe that we need to go beyond text. At least to using rectangles, ellipses, lines and text (i.e. minimalist SVG).

1. Rhetorical Q: How did Galileo get us to change from Ptolemaic Cosmology to Copernican?

2. Rhetorical Q: How did we make the switch from assembler to C and Pascal? Assembler programmers hated HLLs and gave all sorts of reasons not to use HLLs.

3. Rhetorical Q: How did we (normal people, not programmers) switch to using spreadsheets instead of ???

4. I think, the “new” way has to be an order of magnitude “better” than the old way.

5. I think that, in the interim, one has to incorporate the “old” into the “new”. Somehow. To appease the “assembler programmers”. (IMO, today’s “assembler mindset” is (1) the belief that there is “one language to rule them all”, (2) “everything must be synchronous”, (3) CALL/RETURN).

6. Maybe we need to ignore the current crop of “programmers” and target a different kind of programming?

On the technical front, we need to overcome the fear of compiling non-text to running programs (I have example WIPs of compiling draw.io diagrams, technology isn’t the biggest issue). We need to overcome the mindset of using ASCII Art instead of drawing boxes (“{...}” == box).

Programming is hitting an asymptote caused by in-the-box thinking. There are things that we could express if we didn’t limit ourselves to text. Rhetorical Q: why do CEO’s draw things out on whiteboards? Why can’t we compile whiteboards? “a = b+c” is well-covered by textual programming. DaS (mini-VPL) ain’t “a = b+c”. Rhetorical Q: what “tells” are there that current programming is not good enough? The accepted mindset that “multitasking is complicated” is a tell...

The idea of magnitude/the gradient of adoption and the question of the whiteboard I think could be really interesting if thought of in tandem. What is the gradient between modern IDE programming and wacom programming? how does one measure the impact of that evolution? what are tools that could be adopted by the modern IDE programmer that could exist in their workflow that would exist on that gradient? My mind instinctively goes to the classic cli commands. What could be built where a programmers desk includes a keyboard a mouse and a wacom tablet?

Formal standardization, as with ASCII, Unicode, or PNG (to name something non-text), happens when there are many small players but no dominating one. De-facto standards originate with dominant players who find themselves at the center of an ecosystem that is beneficial for them.

The worst environment for emergent common representations is probably the digital feudalism that we see in today's platforms.

Another dimension is formal vs. informal representations. Formal representations encourage formal standards, informal representations encourage informal standards with many variants. Markdown is probably the best illustration of the latter. My guess is that this is the preferred mode of converging on representations for today's Open Source communities. It's well aligned with the spirit of forking and adapting existing things for your own needs.

The worst environment for emergent common representations is probably the digital feudalism that we see in today’s platforms.

Yes I’d be surprised to see these kinds of things emerge under the current environment, I’d assume changes to the dominant model of tech development would correlate with new (hopefully better) common representations emerging. As in, beyond the silicon valley style, platform model, etc, this becomes a necessarily political so I’ll avoid that tangent in this thread.

Your point makes me think about the ways we can spur this kind of change. I’ve been trying to articulate recently the difference between the Smalltalk-style theory of change, a kind of “build a system based on vision/principles and show the world it’s a good idea” approach. This is in contrast to the systems that eat away at the old, culminating in a similar kind of transition through different means.

This was recently articulated far far better than my attempts by Stephen Kell in a talk (slides). He notes that the ‘Smalltalk school’ has leaned towards a ‘design and replace’ approach, whereas Unix was able to “infect” its host system and eventually became so dominant that it becomes the host itself. He advocates the latter as a more viable approach in the modern day which I agree with.

In this community there are differing theories of change and it’s always interesting to see how people view these things. Personally I think the “design and replace” approach isn’t viable (at least when it comes to systemic shifts in how we represent things)

"Design and replace" was reasonable in the 1970s, but it no longer is today, except for well-defined niche use cases. We have a huge ecosystem of information processing systems that new technology has to interoperate with. We can try to orient the evolution of that ecosystem, but we cannot decide to replace it. Stephen's approach works along these lines, but there is room for many different ones.

Hot-take: first and lowest bar is adversarial interoperability / competitive compatibility. In flowery language, combat digital feudalism by tearing down the walls of the lords against their will. No technical niceties matter if making stuff work breaks the law.