Journal entry for
Thoughts I wrote down during my Fisherman’s Trail walk:
Debuggers should work on different semantic levels
For example, an FRP debugger should tell you “what is true at time t” (values of behaviors, any event occurrences). If say you wrote an infinite recursion in the non-FRP code, you should be able to drop down to a friendly execution model for that code.
Why couldn’t Smalltalk be a purely functional programming environment? Why not an FRP-inspired Smalltalk?
You’d need:
- A model of how the program definition changes over time.
- A precise, composable, and easy to understand of where the state of objects comes from. Smalltalk OO gives identitiy to everything with state, but maybe that’s overkill and we can make identity explicit in a natural way.
When developing GUIs you should be able to ask questions and edit live
- How is this element defined?
- Where does it come from?
- Why does it exist/am I seeing it?
I mean, you should be able to enter a special mode while developing which allows you to click on a button and be taken to its editable definition. Editing that definition should either change that button (like the DOM editor in your browser) or all buttons (but that might render the current state impossible to reach?). Other things which would be cool is to know the causality of the button’s existence. E.g. which other buttons were pressed in the past to get to where we are?
Why can’t state and code evolve together? (Is textual programming a dead end?)
I was recently helping a friend with a Python project and we had to use a variable to store some text that we’d modify later in the program. She was surprised to learn that this wouldn’t change the text in the source code as well. I had to tell her that this was a reasonable assumption but that the field of programming was not yet ready for her futuristic ideas :’).
This really begs the question “why can’t state and code evolve together?” The two are intimately linked. One version of the state might only make sense for one particular version of the code. The only reason I can think of why carrying state between versions of a program tends to work is because we explicitly name bits of state, e.g. with database tables. These are usually globally unique identifiers which kills composition.
To make code-state-coevolution feasible you’d have to be able to do operations like “start over with fresh state”.
This coevolution problem seems extremely hard to solve with a plain text editor. You really want to have program-and-state history as a branchable, rewritable, … history. Just like we do now with Git. I can’t see that happening unless the editor really understands what’s happening, and when you have that you might as well add a lot more UI to “code”.
How would you write a document editor in which the document is defined as an exportable program but is no different from code? In which you can define in-line editing interfaces for the document elements? This is just Smalltalk-like stuff IIRC. “Bring Smalltalk back?”