6 ms·

There is a deeper question undercutting this project (and Bret Victor's Drawing Dead Fish talk and related approaches). That question is: how can we represent c

There is a deeper question undercutting this project (and Bret Victor's Drawing Dead Fish talk and related approaches). That question is: how can we represent computation in an intuitive and scalable way? Conventional programming languages is one answer. They associate programs with text. Some believe there is another way, by associating programs with diagrams. A more abstract example: machine learning associates programs with parameters and weights. In some weird way, I feel these are all skeuomorphisms. We choose text because that's how we comprehend literature. We choose diagrams because we are visual. We choose ML because we mimic how our brains work. We don't, however, try to understand what "thought" is, and work backwards to form a representation of it. For example, take thinking of programming textually. Text assumes a beginning, an end, and an ordered sequence between them. But in this small programming example, is there a well-defined ordering? a = 0; b = 1; c = a + b; Since the first and second lines can be switched, in some sense Text itself does not do Thought justice. Visual representations like the one in this video also have their shortcomings. The most obvious being, a monitor is 2D. Thought is not 2D. Going to 3D won't help either. Thought also not only spatial and temporal. For example, how would you represent concatenating strings visually? I think the more interesting question is how we can accurately represent thought?

Naeron 10y ago
String example: if you have "foo" and "bar", both are a list of characters. Now, "bar" has a beginning represented by a handle and you drag that handle to the end of "foo". Very briefly something like that. Of course, not everything is set in stone and we need to try multiple approaches to see which one is the fastest.
dustingetz 10y ago
> is there a well-defined ordering? > a = 0; b = 1; c = a + b; In pure functional languages, these expressions form a dependency graph and the interpreter or compiler may choose an ordering and may cache intermediate results We may even represent the program itself as a graph, just like you suggest with ML programs, but this is a general purpose program Obviously we can't do this in imperative languages. I think pure functional programming enables this future of thinking about programs as graphs and not as text.
- zackmorris 10y ago
  Back in the late 80s/early 90s after I learned C, I remember wondering in awe how in the world compiler optimizations worked. But they do the same thing, they build (often intricate) dependency graphs. In the end, if a human can translate between imperative and functional programming, then there's no reason a machine can't. I think the move towards functional programming, and putting the onus on developers to do the mental elbow grease of converting what are largely macro-style tasks (do this, do that) into functional code (feed this transform into this one) has done a great disservice to software engineering, especially with respect to productivity. For a specific example: I use map() frequently with a use() clause or some other means of passing immutable variables to the inner scope. I have done the work of building that dependency graph by hand. But I should be able to use a mundane foreach() or even a dreaded for() loop, have the compiler examine my scope and see that I'm using my variables in an immutable fashion, and generate functional code from my imperative code. What I am getting at is that in the olden days we used synchronous macros do a series of tasks and even though it was mediocre at best, it gave tremendous leverage to the developer. Today the amount of overhead required to map-reduce things or chain promises and carry the mental baggage of every timeout and failure mode is simply untenable for the human brain beyond a certain complexity. What we really need is to be able to read and write code imperatively but have it executed functionally, with every side effect presented for us. I realize there is a lot of contradiction in what I just said but as far as I can tell, complexity has only increased in my lifetime while productivity has largely slipped. Shifting more and more of the burden to developer proficiency is just exactly the wrong thing to do. I want more from a typical computer today that is 1000 times faster than the ones I grew up on.
  - swift 10y ago
    I enjoy functional programming because it's easier to reason about the code. Often it's easier to write it, but it's true that sometimes it's harder. I find that when I need to read and understand that code later, though, functional programming is usually a win. The same factors that make it sometimes harder to write - state must be passed around explicitly, idiomatic control flow constructs are less general, mutability is explicit and discouraged - make it much easier to understand later, because the interactions between different parts of the system are very clear. Compilers can certainly transform imperative code into the same form in many cases, but the benefit of functional programming is for my ability to reason, not the compiler's. That said, you can write spaghetti code in any language. =)
dragonwriter 10y ago
> We don't, however, try to understand what "thought" is, and work backwards to form a representation of it. Yes, we do. ML/AI is a moving target that literally represents the current SOTA in doing just that, and even symbolic logic itself is the outcome of an older, a priori, way of doing that. Actually, analytic diagrams are also an outcome of one approach to that. So, all programming methods you mention come from some effort to model thought and make a representation of that model.
- dmvaldman 10y ago
  Perhaps I spoke too broadly. You're right, many disciplines try to understand thought. From CS to philosophy to neuroscience to psychology etc. My real point is that thought is not visual or textual. Those things are simply ways of transmitting thoughts. When I have a thought, and I write it down, and you read it, I am simply hoping you are now having a thought related to the one I had. Some interaction in your brain is similar to the one in mine, when I had the thought. Civilization has spent a lot of time in mechanisms that correlate thoughts between people. Hence, language. Hence literacy. Etc. Now we are trying to create a shared language between humans and computers, where we both understand each other with minimal effort.
  - TheOtherHobbes 10y ago
    Developer tools have always been biased towards text manipulation, and - in a Sapir-Whorf kind of a way - that has influenced which ideas are imaginable in computational languages. Even the word "language" is biased towards text, or at least an atomic symbolic representation which is probably verbal. I agree this is unimaginative, and probably naive. But dataflow/diagramatic systems tend to produce horrible messy graphs that are incredibly unwieldy for non-trivial applications. (My favourite anti-example is Max/MSP which is used for programming sound, music, and visuals. It's popular with visual artists, but its constructs map so poorly to traditional code that using it when you're used to coding with text is a form of torture.) I think it's hard to do better, because human communication tends to be implicit, contextual, somewhat error prone, and signals emotional state, facts, emotional desires, or more abstract goals. Computer communication lacks almost all of the above. Programming is a profoundly unnatural pastime that doesn't come easily to most of the population. The fact that written languages and code both use text is very misleading. They don't use text in anything like the same ways, and code systems are brittle, explicit, and poor cousins of the formal theorem description used in math. So the domains covered have almost no overlap. Coding is machine design, and human thought mostly isn't. It's hard to see how they can work together with minimal effort unless the machines explicitly include a model of human mental, emotional, and social states, in addition to the usual representations of traditional formal logic.
ibgib 10y ago
> We don't, however, try to understand what "thought" is, and work backwards to form a representation of it. I had to laugh here, because that is exactly how I designed ibGib over the past 15 years. It is built conceptually from the ground up, working in conflict (and harmony) with esoteric things like philosophy of mathematics and axiomatic logic systems, information theory, logic of quantum physics, etc. Anyway, like I said...I just had to laugh at this particular statement! :-) > Visual representations like the one in this video also have their shortcomings. The most obvious being, a monitor is 2D. Thought is not 2D. Going to 3D won't help either. Thought also not only spatial and temporal. For example, how would you represent concatenating strings visually? > I think the more interesting question is how we can accurately represent thought? In ibGib, I have created a nodal network that currently can be interacted with via a d3.js force layout. Each node is an ibGib that has four properties (the database has _only_ these four properties): ib, gib, data, and rel8ns (to keep it terse). The ib is like a name/id/quick metadata, the data is for internal data, the rel8ns are named links (think merkle links), and the gib is a hash of the other three. The ib^gib acts as a URL in a SHA^256-sized space. So each "thought" is effectively a Goedelian number that represents that "thought". This is essentially the "state" part of it. The way that you create new ibGib is for any ibGib A to "contact" an ibGib B. Currently the B ibGibs are largely transform ibGibs that contain the state necessary to create a tertiary ibGib C. So each one, being an immutable datum with ib/gib/data/rel8ns, when combined with another immutable ibGib, acts as a pure function given the engine implemented. This pure function is actually encapsulated in the server node that the transformation is happening, so it's conceivable that A + B -> C on my node, where A + B -> D on someone else's node. So the "pure" part is probably an implementation detail for me...but anyway, I'm digressing a little. I'm only starting to introduce behavior to it, but the gist of it is that any behavior, just like any creation of a "new" ibGib, is just sending an immutable ibGib to some other thing that produces a tertiary immutable ibGib. So you could have the engine on some node be in python or R or Bob's Manual ibGib manipulating service where Bob types very slowly random outputs. But in the visual representation of this process, you would do the same thing that you do with all other ibGib. You create a space (the rel8ns also form a dependency graph for intrinsic tree-shaking btw) via querying, forking others' ibGibs, "importing", etc. Then you have commands that act upon the various ibGib, basically like a plugin architecture. The interesting thing though is that since you're black-boxing the plugin transformation (it's an ibGib), you can evolve more and more complex "plugins" that just execute "their" function (just like Bob). Anyway, I wasn't going to write this much...but like I said. I had to laugh.
azeirah 10y ago
There's someone who definitely spent a lot of time on this, definitely check out Ted Nelson's ZigZag structure: http://xanadu.com/zigzag/ http://xanadu.com/zigzag/ It is exactly that, an attempt to structure data in a similar way that our thoughts are formed. I believe it was this video where he shortly explained that concept; https://www.youtube.com/watch?v=Bqx6li5dbEY https://www.youtube.com/watch?v=Bqx6li5dbEY Although it might be a different video since Ted Nelson is all over the place with his documents and videos.

Naeron 10y ago

String example: if you have "foo" and "bar", both are a list of characters. Now, "bar" has a beginning represented by a handle and you drag that handle to the end of "foo". Very briefly something like that. Of course, not everything is set in stone and we need to try multiple approaches to see which one is the fastest.

dustingetz 10y ago

> is there a well-defined ordering? > a = 0; b = 1; c = a + b; In pure functional languages, these expressions form a dependency graph and the interpreter or compiler may choose an ordering and may cache intermediate results We may even represent the program itself as a graph, just like you suggest with ML programs, but this is a general purpose program Obviously we can't do this in imperative languages. I think pure functional programming enables this future of thinking about programs as graphs and not as text.

zackmorris 10y ago
Back in the late 80s/early 90s after I learned C, I remember wondering in awe how in the world compiler optimizations worked. But they do the same thing, they build (often intricate) dependency graphs. In the end, if a human can translate between imperative and functional programming, then there's no reason a machine can't. I think the move towards functional programming, and putting the onus on developers to do the mental elbow grease of converting what are largely macro-style tasks (do this, do that) into functional code (feed this transform into this one) has done a great disservice to software engineering, especially with respect to productivity. For a specific example: I use map() frequently with a use() clause or some other means of passing immutable variables to the inner scope. I have done the work of building that dependency graph by hand. But I should be able to use a mundane foreach() or even a dreaded for() loop, have the compiler examine my scope and see that I'm using my variables in an immutable fashion, and generate functional code from my imperative code. What I am getting at is that in the olden days we used synchronous macros do a series of tasks and even though it was mediocre at best, it gave tremendous leverage to the developer. Today the amount of overhead required to map-reduce things or chain promises and carry the mental baggage of every timeout and failure mode is simply untenable for the human brain beyond a certain complexity. What we really need is to be able to read and write code imperatively but have it executed functionally, with every side effect presented for us. I realize there is a lot of contradiction in what I just said but as far as I can tell, complexity has only increased in my lifetime while productivity has largely slipped. Shifting more and more of the burden to developer proficiency is just exactly the wrong thing to do. I want more from a typical computer today that is 1000 times faster than the ones I grew up on.
- swift 10y ago
  I enjoy functional programming because it's easier to reason about the code. Often it's easier to write it, but it's true that sometimes it's harder. I find that when I need to read and understand that code later, though, functional programming is usually a win. The same factors that make it sometimes harder to write - state must be passed around explicitly, idiomatic control flow constructs are less general, mutability is explicit and discouraged - make it much easier to understand later, because the interactions between different parts of the system are very clear. Compilers can certainly transform imperative code into the same form in many cases, but the benefit of functional programming is for my ability to reason, not the compiler's. That said, you can write spaghetti code in any language. =)

dragonwriter 10y ago

> We don't, however, try to understand what "thought" is, and work backwards to form a representation of it. Yes, we do. ML/AI is a moving target that literally represents the current SOTA in doing just that, and even symbolic logic itself is the outcome of an older, a priori, way of doing that. Actually, analytic diagrams are also an outcome of one approach to that. So, all programming methods you mention come from some effort to model thought and make a representation of that model.

dmvaldman 10y ago
Perhaps I spoke too broadly. You're right, many disciplines try to understand thought. From CS to philosophy to neuroscience to psychology etc. My real point is that thought is not visual or textual. Those things are simply ways of transmitting thoughts. When I have a thought, and I write it down, and you read it, I am simply hoping you are now having a thought related to the one I had. Some interaction in your brain is similar to the one in mine, when I had the thought. Civilization has spent a lot of time in mechanisms that correlate thoughts between people. Hence, language. Hence literacy. Etc. Now we are trying to create a shared language between humans and computers, where we both understand each other with minimal effort.
- TheOtherHobbes 10y ago
  Developer tools have always been biased towards text manipulation, and - in a Sapir-Whorf kind of a way - that has influenced which ideas are imaginable in computational languages. Even the word "language" is biased towards text, or at least an atomic symbolic representation which is probably verbal. I agree this is unimaginative, and probably naive. But dataflow/diagramatic systems tend to produce horrible messy graphs that are incredibly unwieldy for non-trivial applications. (My favourite anti-example is Max/MSP which is used for programming sound, music, and visuals. It's popular with visual artists, but its constructs map so poorly to traditional code that using it when you're used to coding with text is a form of torture.) I think it's hard to do better, because human communication tends to be implicit, contextual, somewhat error prone, and signals emotional state, facts, emotional desires, or more abstract goals. Computer communication lacks almost all of the above. Programming is a profoundly unnatural pastime that doesn't come easily to most of the population. The fact that written languages and code both use text is very misleading. They don't use text in anything like the same ways, and code systems are brittle, explicit, and poor cousins of the formal theorem description used in math. So the domains covered have almost no overlap. Coding is machine design, and human thought mostly isn't. It's hard to see how they can work together with minimal effort unless the machines explicitly include a model of human mental, emotional, and social states, in addition to the usual representations of traditional formal logic.

ibgib 10y ago

> We don't, however, try to understand what "thought" is, and work backwards to form a representation of it. I had to laugh here, because that is exactly how I designed ibGib over the past 15 years. It is built conceptually from the ground up, working in conflict (and harmony) with esoteric things like philosophy of mathematics and axiomatic logic systems, information theory, logic of quantum physics, etc. Anyway, like I said...I just had to laugh at this particular statement! :-) > Visual representations like the one in this video also have their shortcomings. The most obvious being, a monitor is 2D. Thought is not 2D. Going to 3D won't help either. Thought also not only spatial and temporal. For example, how would you represent concatenating strings visually? > I think the more interesting question is how we can accurately represent thought? In ibGib, I have created a nodal network that currently can be interacted with via a d3.js force layout. Each node is an ibGib that has four properties (the database has _only_ these four properties): ib, gib, data, and rel8ns (to keep it terse). The ib is like a name/id/quick metadata, the data is for internal data, the rel8ns are named links (think merkle links), and the gib is a hash of the other three. The ib^gib acts as a URL in a SHA^256-sized space. So each "thought" is effectively a Goedelian number that represents that "thought". This is essentially the "state" part of it. The way that you create new ibGib is for any ibGib A to "contact" an ibGib B. Currently the B ibGibs are largely transform ibGibs that contain the state necessary to create a tertiary ibGib C. So each one, being an immutable datum with ib/gib/data/rel8ns, when combined with another immutable ibGib, acts as a pure function given the engine implemented. This pure function is actually encapsulated in the server node that the transformation is happening, so it's conceivable that A + B -> C on my node, where A + B -> D on someone else's node. So the "pure" part is probably an implementation detail for me...but anyway, I'm digressing a little. I'm only starting to introduce behavior to it, but the gist of it is that any behavior, just like any creation of a "new" ibGib, is just sending an immutable ibGib to some other thing that produces a tertiary immutable ibGib. So you could have the engine on some node be in python or R or Bob's Manual ibGib manipulating service where Bob types very slowly random outputs. But in the visual representation of this process, you would do the same thing that you do with all other ibGib. You create a space (the rel8ns also form a dependency graph for intrinsic tree-shaking btw) via querying, forking others' ibGibs, "importing", etc. Then you have commands that act upon the various ibGib, basically like a plugin architecture. The interesting thing though is that since you're black-boxing the plugin transformation (it's an ibGib), you can evolve more and more complex "plugins" that just execute "their" function (just like Bob). Anyway, I wasn't going to write this much...but like I said. I had to laugh.

azeirah 10y ago

There's someone who definitely spent a lot of time on this, definitely check out Ted Nelson's ZigZag structure: http://xanadu.com/zigzag/ http://xanadu.com/zigzag/ It is exactly that, an attempt to structure data in a similar way that our thoughts are formed. I believe it was this video where he shortly explained that concept; https://www.youtube.com/watch?v=Bqx6li5dbEY https://www.youtube.com/watch?v=Bqx6li5dbEY Although it might be a different video since Ted Nelson is all over the place with his documents and videos.