Substrates Vision Statement by Jonathan Edwards

Substrates have been built upon PLs (Smalltalk/LISP) and UIs (the browser). How about building upon a DB instead? (View Highlight)

UI for navigating the substrate: inspector windows, outline, zoomable canvas, etc. (View Highlight)

Modes of collaboration: multiplayer, git, and beyond. (View Highlight)

Interoperating with the mainstream: calling/serving HTTP APIs, reading/writing standard file formats. (View Highlight)

What is the role of LLMs? Will they obsolete the need for substrates? (View Highlight)

What is a “killer app” that justifies substrates? (View Highlight)

My target users are the beginners and non-technical people that embraced HyperCard, and the “power-users” of spreadsheet fame, but who need more power and generality. (View Highlight)

Who isn’t the user? I am not targeting users like myself, nor current professional programmers. I do not want to build a “tool for thought” for intellectuals. I would rather build a “tool for getting stuff done” by ordinary people. (View Highlight)

Focus on data first. Users care more about data than code. (View Highlight)

an edit calculus formalizes the interaction between a user and a stateful system, where edits are operations mutating the state. (View Highlight)

I formalize this with a set of edit operations that are surfaced in the UI to capture the intention of a type change and accordingly migrate instances. (View Highlight)

Provide a feature-complete GUI. (View Highlight)

I need an executable specification language for the migration rules. (View Highlight)