4 ms·

Yeah, you're right that coding is creating computational objects. I was pointing out that "coding" is traditionally understood to refer only to the sequences o

Yeah, you're right that coding is creating computational objects. I was pointing out that "coding" is traditionally understood to refer only to the sequences of instructions in source and object code that remains unmodified during runtime execution, but there are other views that extend the definition to all the other objects involved in running the software in its environment. In this view, coding is about defining automated behaviors that can execute on their own without a human leading by hand every step. I'm thinking in particular about End-User Development approaches, which allow non-developers to create such automations without ever learning the syntax of a formal language. Under this approach, the abstraction level may be lower, since the actual instances of data used are as important to understanding the system as the code that processes them.

ontouchstart 8y ago
Another type of coding is describing the desired state and let the runtime environment achieve the transition. Unix Makefile is one of the early examples. So are HTML/CSS etc. More recent examples are dataflow graph in tensorflow https://www.tensorflow.org/guide/graphs https://www.tensorflow.org/guide/graphs and kubernetes https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/design/README.md https://github.com/kubernetes/kubernetes/blob/release-1.3/do... A new idea just occurred to me during a technical lunch meeting with a bunch of friends today: since Jupyter Notebook itself is nothing but a object graph, it might be possible to use a "computed" .ipynb for this kind of "coding", i.e., describing desired state. That would be TDD in another sense.
- TuringTest 8y ago
  Yeah, I happen to work with declarative statements + problem solver for a living :-) In this context, a precise textual description helps to exactly define what you want to achieve, but a graphical view helps to inspect how many different cases are there in your data, and how available context are connected. Representing state machines with graphs is a relatively common thing in rapid prototyping apps, so I've thinking of building a prototyping app that would also allow embedding real code and data in them (similar to Visual GUI builders, but allowing much more code to be defined visually). There are several tools attempting to achieve that, but all fail at the abstraction problem of defining new instances for your objects (i.e. you can't create new instances of arbitrary visually defined objects, only for things in tables).
  - ontouchstart 8y ago
    I really enjoy this long and insightful discussion. Let’s see how deep we can go (in terms of the thread tree and thought itself). Declarative constraints driven problem solver was pioneered by https://en.m.wikipedia.org/wiki/Sketchpad https://en.m.wikipedia.org/wiki/Sketchpad and also used in places like Apple’s https://en.wikipedia.org/wiki/Interface_Builder https://en.wikipedia.org/wiki/Interface_Builder It is interesting that you use "texture description" for byte stream based artifact that we call code, which is runtime independent. On the other hand, the term "graph" in your second paragraph has double meanings: visual representation for human eye and brain to parse, and mathematical graph that has can be serialized in JSON, XML or whatever byte stream. I think many people are excited about GUI revolution pioneered by Doug Engelbart, Ivan Sutherland and Alan Kay for different reasons. Some people are excited about the implementations: bitmap display, mouse, etc., some people are excited about the principles and abstraction: MVC, constraints, data flow, messaging, etc, etc. With Jupyter notebook system, which is based on three state machines: a persistent kernel process, a DOM session in the browser, and a message queue, it is the first time that we might have a nice abstraction to capture a graph in space and time. That is at least why I am getting excited. The other features are just bells and whistles.
    - TuringTest 8y ago
      Earlier today, I took a note to myself saying this: The next-generation development environment will be a combination of: * a wiki (outlining content + version control), * a spreadsheet (functional reactive coding + lightweight schema definition + easy working on collections), and * a mockup wireframe builder (visual layout + visual state machines + rapid prototyping). Pluggable connectors to constraint solvers and machine learning would be a plus. I'm not sure that Jupyter fully captures all parts of the computation graph; most of all, restoring a previous state after closing and reopening it is cumbersome (if I'm not mistaken you need to run each individual cell by hand in the right order). There are theoretical models that could fix that, though, like those allowing for time travel debugging. And the visuals are simple and flexible enough to support many use cases. So yes, web notebooks are a good basis for a knowledge-building programmable platform.

ontouchstart 8y ago

Another type of coding is describing the desired state and let the runtime environment achieve the transition. Unix Makefile is one of the early examples. So are HTML/CSS etc. More recent examples are dataflow graph in tensorflow https://www.tensorflow.org/guide/graphs https://www.tensorflow.org/guide/graphs and kubernetes https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/design/README.md https://github.com/kubernetes/kubernetes/blob/release-1.3/do... A new idea just occurred to me during a technical lunch meeting with a bunch of friends today: since Jupyter Notebook itself is nothing but a object graph, it might be possible to use a "computed" .ipynb for this kind of "coding", i.e., describing desired state. That would be TDD in another sense.

TuringTest 8y ago
Yeah, I happen to work with declarative statements + problem solver for a living :-) In this context, a precise textual description helps to exactly define what you want to achieve, but a graphical view helps to inspect how many different cases are there in your data, and how available context are connected. Representing state machines with graphs is a relatively common thing in rapid prototyping apps, so I've thinking of building a prototyping app that would also allow embedding real code and data in them (similar to Visual GUI builders, but allowing much more code to be defined visually). There are several tools attempting to achieve that, but all fail at the abstraction problem of defining new instances for your objects (i.e. you can't create new instances of arbitrary visually defined objects, only for things in tables).
- ontouchstart 8y ago
  I really enjoy this long and insightful discussion. Let’s see how deep we can go (in terms of the thread tree and thought itself). Declarative constraints driven problem solver was pioneered by https://en.m.wikipedia.org/wiki/Sketchpad https://en.m.wikipedia.org/wiki/Sketchpad and also used in places like Apple’s https://en.wikipedia.org/wiki/Interface_Builder https://en.wikipedia.org/wiki/Interface_Builder It is interesting that you use "texture description" for byte stream based artifact that we call code, which is runtime independent. On the other hand, the term "graph" in your second paragraph has double meanings: visual representation for human eye and brain to parse, and mathematical graph that has can be serialized in JSON, XML or whatever byte stream. I think many people are excited about GUI revolution pioneered by Doug Engelbart, Ivan Sutherland and Alan Kay for different reasons. Some people are excited about the implementations: bitmap display, mouse, etc., some people are excited about the principles and abstraction: MVC, constraints, data flow, messaging, etc, etc. With Jupyter notebook system, which is based on three state machines: a persistent kernel process, a DOM session in the browser, and a message queue, it is the first time that we might have a nice abstraction to capture a graph in space and time. That is at least why I am getting excited. The other features are just bells and whistles.
  - TuringTest 8y ago
    Earlier today, I took a note to myself saying this: The next-generation development environment will be a combination of: * a wiki (outlining content + version control), * a spreadsheet (functional reactive coding + lightweight schema definition + easy working on collections), and * a mockup wireframe builder (visual layout + visual state machines + rapid prototyping). Pluggable connectors to constraint solvers and machine learning would be a plus. I'm not sure that Jupyter fully captures all parts of the computation graph; most of all, restoring a previous state after closing and reopening it is cumbersome (if I'm not mistaken you need to run each individual cell by hand in the right order). There are theoretical models that could fix that, though, like those allowing for time travel debugging. And the visuals are simple and flexible enough to support many use cases. So yes, web notebooks are a good basis for a knowledge-building programmable platform.