search

d-cook / SomethingNew

Collaboration for reinventing software in human terms
171 stars 10 forks source link

Multiple tools #32

Open d-cook opened 6 years ago

d-cook commented 6 years ago

Chris Granger (creator of Eve) presents and interesting point about creating multiple tools instead of one general purpose one: http://www.chris-granger.com/2015/01/26/coding-is-not-the-new-literacy/#fn2

The take-away for me is to build different tools for different needs, but have a way to easily transport models from one to the other. For example, using something like Bret Victor's dynamic drawing medium for rendering, and then "dragging" the data (or code) into something better suited for editing program flow.

Ever notice the vast variety of different tools and visualizers that Bret Victor has? Imagine if they (and any other hypothetical ones) used the same underlying data-subtrate.

pbazant commented 6 years ago

Yes, a broad range of specific tools is needed. To connect them, we need some infrastructure which involves a common data-substrate. Two systems come to my mind which use this pattern of common structured data-substrate

On Wed, Sep 5, 2018 at 6:04 PM Dan Cook notifications@github.com wrote:

Chris Granger (creator of Eve) presents and interesting point about creating multiple tools instead of one general purpose one: http://www.chris-granger.com/2015/01/26/coding-is-not-the-new-literacy/#fn2

The take-away for me is to build different tools for different needs, but have a way to easily transport models from one to the other. For example, using something like Bret Victor's dynamic drawing medium for rendering, and then "dragging" the data (or code) into something better suited for editing program flow.

Ever notice the vast variety of different tools and visualizers that Bret Victor has? Imagine if they (and any other hypothetical ones) used the same underlying data-subtrate.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/d-cook/SomethingNew/issues/32, or mute the thread https://github.com/notifications/unsubscribe-auth/AHaunnIWjfxbjz8dKGxBwy_VvX_ULgmTks5uX_YOgaJpZM4WbOgq .

shalabhc commented 6 years ago

Is the key point that we want to work with multiple projections of the same thing/substrate? There is the idea of projectional editing (https://martinfowler.com/bliki/ProjectionalEditing.html). The linked post talks about an 'abstract representation' which is viewed and manipulated through multiple projects and then used to produce one executable.

Instead we could consider projectional manipulation of the whole system - we use different views of the system, each of which shows a slice of the system using a specific projection. Some of these views could be editable. New projections could be built on top of existing ones, using some 'projection creation' views. When two views are bound to the same underlying objects, manipulation in one view would update the other view live. There are no applications per se, rather we just have specialized views of the relevant system slices.

rtens commented 6 years ago

100% on board with @shalabhc But what instead of a data substrate, we'd have a computational substrate? As in: "data is just a very slowly changing process" (forgot where this quote comes from). This way, a single unit could offer different interfaces to different views and not just a single interface with every view. Integration can then happen on the view side or the "data" side.

pbazant commented 6 years ago

Yes, we definitely want to work with multiple projections of the same thing/substrate. In MPS, everything is edited through a projection. Multiple projections of the same thing are possible. Unfortunately, MPS is not an operating system, so it does not make your personal computer into a "projectional personal computer".

The data substrate of MPS is based on objects similar to Java objects. So the substrate of MPS is already a computational substrate.

I highly recommend everyone to install MPS and to learn it. It has many warts and bugs, but it demonstrates that extreme power of projectional editing.

Pavel

On Wed, Oct 31, 2018 at 8:54 AM Nikolas Martens notifications@github.com wrote:

100% on board with @shalabhc https://github.com/shalabhc But what instead of a data substrate, we'd have a computational substrate? As in: "data is just a very slowly changing process" (forgot where this quote comes from). This way, a single unit could offer different interfaces to different views and not just a single interface with every view. Integration can then happen on the view side or the "data" side.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/d-cook/SomethingNew/issues/32#issuecomment-434593051, or mute the thread https://github.com/notifications/unsubscribe-auth/AHaunoF79WaWjIyWn96_2JjSOpBEj85Uks5uqVclgaJpZM4WbOgq .