I want all speculation to fly in a transient layer above the existing stable codebase.
These live systems are closest to the speculative execution described above. But there is still too much hand-holding required to inspect the interesting values, to save and restore state, and replay some execution from stable states.
And of course, none of these do tracing with partial information.
Primitives like what_if(x=3) and traces would need to be created
doeg-moen asked an interesting question on lobste.rs about what else might be needed, which I replied to. I think we want an easy way to express and visualize "partial information", whatever that might mean for your language.
Comments
wcrichton@ made a good point on twitter about collapsing abstraction stacks.
This is also a part of offloading mechanical mental work.
Like "type a number into a spreadsheet cell" easy.
khinsen@ asked a good question on twitter
Doesn't that also imply "data as basic as a number"? What about code processing deeply nested data structures? Or huge arrays of floats?
You can commit your transaction, if you have done other meaningful worksince you last committed, and then follow these steps:1.Remove the index in which the instance participates.2.Migrate the instance.3.Re-create the index, this time using a constraint appropriate to thenew class version.4.Commit the transaction
Indexes may have to be temporarily removed an recreated if the structure does not carry over.
Transforming Variable Values
Example of transforming variables - old class Point (x,y) to new class Point(radius, angle).
Class Histories and Constraints
Example of a simple refactoring - moving a set of class attributes to a new nested class, which has more constraints (new fields) as well.
To support this inevitable need for schema modification, GemStone allows you todefine different versions of classes. Every class in GemStone has a classhistory—an object that maintains a list of all versions of the class—and every classis listed in exactly one class history. You can define as many different versions ofa class as required, and declare that the different versions belong to the same classhistory. You can migrate some or all instances of one version of a class to anotherversion when you need to. The values of the instance variables of the migratinginstances are retained, if you have defined the new version to do so.
Simple case - migrating one class to a new version.
Future of Coding Community
Would be nice if the footer had a link to the community as well. Folks often jump over the intro paragraphs, and also we expect the footer to remain mostly the same for all of these letters.
https://www.youtube.com/watch?v=9G0r7jL3xl8
For this future from the past section, would be great to again have more context - the title of the video and the year that project is from. Also maybe the name of the creator.
A note-taking tool for networked thought
For links, we should have a bit more context, specially the title (in this case 'Roam research'). One benefit is we don't have to click the link to see the name. The other benefit is it is easier to search (e.g. ctrl-f on this page or finding in your mail).
From our community
Would be great if these headers were a bit more prominent - they tend to get lost in the text. I'm suggesting making these bigger, bolder and with more whitespace.
computer revolution
Has the real computer revolution not happened yet?
nodeBreakSymbol
What is a node and how is it different from a cell?
By combining cells to increase the cellSize
I assume you mean the cellSize of the existing cells doesn't increase, but you have a new cell where the size is the sum of the member cells?
A Tree consists of a line of cells and/or a plane of child Trees.
A little lost here. Since cells can be combined to form larger cells, what's the difference between a tree and a cell? A tree consists of a line of cells.. but a cell could also consist of many cells?
Most CRDT research operates in a model where all collaborators immediately apply their edits to a single version of a document. However, practical local-first applications require more flexibility: users must have the freedom to reject edits made by another collaborator, or to make private changes to a version of the document that is not shared with others. A user might want to apply changes speculatively or reformat their change history. These concepts are well understood in the distributed source control world as “branches,” “forks,” “rebasing,” and so on. There is little work to date on understanding the algorithms and programming models for collaboration in situations where multiple document versions and branches exist side-by-side.
doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.
Interestingly this idea is in sharp contrast to what has become mainstream OO programming.