Journal entry for March 10, 2023

More thoughts and questions:

SmallTalk-y environments and distributed programming

Why does it feel like SmallTalk environments don’t do so well for distributed programming? (Pure ignorance here, maybe they do.) Does any “more than text” environment do well?

Concrete examples vs abstractions

I listened to the FoC podcast episode on Magic Ink. In it the thought comes up that design tools should work via concrete examples instead of starting with abstractions, like “normal” programming does. This may sound like it’s in opposition to the category-abstract-as-much-as-we-can vibes we have in the FP community, but I believe it’s actually extremely compatible, even necessary. The thing that’s missing is a database of concrete examples and a user friendly interface.

A programming environment should say “you have two numbers, here are the combinators that work on them”. It should then save the chosen combinator both as a concrete one and as a more abstract monoidal operation. If the code changes and you e.g. switch from numbers to matrices it should pick a new sensible operation or ask if multiple exist.

Undo via timeline-of-actions manipulation

My master’s thesis was about making timelines/events in FRP first class values which can be modified, and using that to implement things like undo. I think this is a concept which should be explored more, and which would render an FRP-based programming environment super useful, because you could ask “what-if” questions and have a much better interactive development/debugging experience.

Causality of actions, “why can this happen?”

When thinking of implementing undo functionality with the above timeline-of-actions concept one of the first problems which comes to mind is deleting an action which makes future actions meaningless. E.g. if in a drawing program you remove the action which created a circle, then later actions resizing that circle no longer make sense. Can we invent a programming language in which it is easy to ask “which parts of the future exist only because of this thing which happened in the past?”.

UI designs/programs should be testable

Could you record interactions with a UI and replay them in various contexts (resized windows etc.) so that they still work? This needs predictable identifiers for the UI components. What does a programming language which natively supports these predictable IDs look like?

In common OO programming object identity is not predictable, because the system is not pure and not replayable.