8 ms·

Haha it sucks actually - I love talking about this stuff, but I know I really need to save it for my talk so I'm tearing myself to pieces trying to keep quiet.

by ibdknox 13y ago

Haha it sucks actually - I love talking about this stuff, but I know I really need to save it for my talk so I'm tearing myself to pieces trying to keep quiet. I guess one thing I will say is that our definition of programming is all over the place right now and that in order for us to get anywhere we need to scale it back to something that simplifies what it means to program. We're bogged down in so much incidental complexity that the definitions I hear from people are convoluted messes that have literally nothing to do with solving problems. That's a bad sign. My thesis is that given the right definition all of the sudden things magically "just work" and you can use it to start cleaning up the mess. Without giving too much away I'll say that it has to do with focusing on data. :)

groby_b 13y ago
This reminds me of the "data-oriented design" debate that's been raging in game programming for a while. I assume you've seen e.g. http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal... (or similar papers)
- ibdknox 13y ago
  I actually have a post about data-centricity in games, though from a very different angle. http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/ http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockou...
  - johnrob 13y ago
    It seems like one large breakthrough in programming could simply be using the features of a language in a manner that best suits the problem. That's what I get from your blog post: design for what makes sense - not for what looks normal during a review. One thing I envy from LISP is that there seem to be few 'best practices' that ultimately make our applications harder to modify.
    - taeric 13y ago
      That should have a nice catch phrase "solidified into disaster by 'best practices'"?
stelonix 13y ago
I'm working on a system based on Bret Victor's "Programming in Principle" talk. I believe to achieve such a system, you need to find a way to add semantics to code, as well as the utilization of proofs in order to have enough constraints that your environment is seamlessly self-aware while at the same time extensible. I'm curious what you mean by data though. Is it data in the "big data" sense? What I mean is, are we talking about gathering a lot of data on coding? My approach is based on that, anyway: lots of data on code with a number of different analyzers (static and dynamic) that allows for extraction of common idioms and constraints, while allowing for the system to more easily help the user. Of course, there's no magic and a lot of times I reach dead-ends, and while I'm eager to have enough to show the world, progress has been kinda slow lately. Looking forward for your talk, be sure to link here on HN.
tiglionabbit 13y ago
I feel the same way. As a programmer, I feel like there are tons of irrelevant details I have to deal with every day that really have nothing to do with the exercise of giving instructions to a computer. That's what inspired me to work on my [nameless graph language](http://nickretallack.com/visual_language/#/ace0c51e4ee3f9d7483ec10780d1ed43 http://nickretallack.com/visual_language/#/ace0c51e4ee3f9d74...). I thought it would be simpler to express a program by connecting information sinks to information sources, instead of ordering things procedurally. By using a graph, I could create richer expressions than I could in text, which allowed me to remove temporary variables entirely. By making names irrelevant, using UUIDs instead, I no longer had to think about shadowing or namespacing. Also, by avoiding text and names, I avoid many arguments about "coding style", which I find extremely stupid. I find that people often argue about programming methodologies that are largely equivalent and interchangeable. For example, for every Object Oriented program, there is an equivalent non-object-oriented program that uses conditional logic in place of inheritance. For every curried program, there is an equivalent un-curried program that explicitly names its function arguments. In fact, it wouldn't even be that hard to write a program to convert from one to the other. I'm pretty excited about the array of parallel processors in the presentation though. If we had that, with package-on-package memory for each one, message passing would be the obvious way to do everything. Not sure how to apply this to my own language yet, but I'll think of something.
- morpher 13y ago
  Your visual language looks a lot like labview. I'm on a phone on a bus and haven't dug in too far, but have you used labview before?
  - tiglionabbit 13y ago
    I'd like to try labview, but doesn't it cost lots of money? I guess I'll sign up for an evaluation copy. The closest things to my language that I have seen are Kismet and UScript. Mine is different though because it is lazily evaluated and uses recursion as the only method of looping. Some other things that look superficially similar such as Quartz Composer, ThreeNode, PureData, etc. are actually totally different animals. They are more like circuit boards, and my language is a lot more like JavaScript.
psgibbs 13y ago
I don't get it, why are you afraid of scooping yourself? In the same way that HN frowns upon stealth startups, shouldn't we frown upon 'stealth theories'? If your thoughts are novel and deep enough, revealing something about them will only increase interest in your future talks, since you are definitionally the foremost thinker in your unique worldview. If the idea fails scrutiny in some way, you should want to hear about it now so you can strengthen your position. What's the downside, outside of using mystery to create artificial hype?
- jpadkins 13y ago
  can't speak for the thread starter, but one downside to prematurely talking about something is confusion. Half formed thoughts, rambling imprecise language, etc can create confusion for his audience. The process of editing and preparing for a talk makes it more clear and concise. Maybe he is not ready yet to clearly communicate his concepts yet.
ericHosick 13y ago
> definition of programming is all over the place I agree. For example, people do seem to assume that programming must involve, in some way, coding. Do we really need to code in some programming-language to be programming? Changing security settings, for example, in a browser lead to quite different behaviors of the program. Isn't the user of the browser programming because they change the behavior of the program? And this leads to.... > with focusing on data If we focus on data, and hopefully better abstractions on how to manipulate that data, then wouldn't any user able to alter a program because they can adjust "settings" at almost any point within the program: in real time. Wouldn't this then enable a lot more people to become programmers? Anyway, just some thoughts.
- astrobe_ 13y ago
  The difference between setting parameters and programming is obviously that programming allows the creation of new functions. "Coding" is literally the act of translating a more-or-less formally specified program (that is, a set of planned actions) into a particular computer language. However, if being a programmer was only like being a translator, programming wouldn't be too hard for mere mortals. That's on the other part - the one that involves methods, logic, knowledge like the CAP theorem - they have problems with. The fact is, not every one can re-discover the bubble sort algorithm like we all here did when we were 8 or so. That's why we are programmers, and that's why they are not (and don't even want to be -- but they are nonetheless nice people and have other qualities, like having money). And these problems don't vanish if you switch from control-flow to data-flow or some bastardized-flow; they just change shape.
  - ericHosick 13y ago
    As some people have mentioned in this HN post, it is hard to define what programming means. A program is the result of the automation of some process (system) that people have thought up (even things that couldn't exist before computers). Programming is the act of taking that process (system) and describing it in a computing device of some kind. Programming currently requires some kind of mapping from the "real world" to the "computer world". The current mapping is done primarily with source code. So, it currently seems that people who are good at programming are good at mapping from the "real world" into the "computer world" via coding. You seem to be making the point that some people are just good at programming because they can do things like "re-discover the bubble sort algorithm" or understand CAP theorem. These are very domain specific problems. For people who are able to "re-discover inventory control management" they would do a great job of automating it (programming) if they had an easier way to map that process (system) to a computing device. The ultimate goal (other than maybe AI) is a 1-to-1 mapping between a "real world" process (system) and a computing device that automates it.
casual_slacker 13y ago
I've been thinking a lot about such issues too; particularly the pain points I have when ramping up against new systems. What information is missing that leaves me with questions? Can code deliver something thorough enough to be maintainable as a single source of truth? I think, the differences between reading and writing code are as big as sending and receiving packets. It's difficult to write code that extrapolates the base information in your head driving the decisions. Not only that, but you also have to juggle logic puzzles as you're doing it. And on the other side, you have to learn new domain languages (or type hierarchies), as well as what the program is supposed to do in the first place. I think the idea of interacting with code as you build it is great, but how can we do that AND fix the information gap at the same time?

by ibdknox 13y ago

groby_b 13y ago

This reminds me of the "data-oriented design" debate that's been raging in game programming for a while. I assume you've seen e.g. http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal... (or similar papers)

ibdknox 13y ago
I actually have a post about data-centricity in games, though from a very different angle. http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/ http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockou...
- johnrob 13y ago
  It seems like one large breakthrough in programming could simply be using the features of a language in a manner that best suits the problem. That's what I get from your blog post: design for what makes sense - not for what looks normal during a review. One thing I envy from LISP is that there seem to be few 'best practices' that ultimately make our applications harder to modify.
  - taeric 13y ago
    That should have a nice catch phrase "solidified into disaster by 'best practices'"?

stelonix 13y ago

I'm working on a system based on Bret Victor's "Programming in Principle" talk. I believe to achieve such a system, you need to find a way to add semantics to code, as well as the utilization of proofs in order to have enough constraints that your environment is seamlessly self-aware while at the same time extensible. I'm curious what you mean by data though. Is it data in the "big data" sense? What I mean is, are we talking about gathering a lot of data on coding? My approach is based on that, anyway: lots of data on code with a number of different analyzers (static and dynamic) that allows for extraction of common idioms and constraints, while allowing for the system to more easily help the user. Of course, there's no magic and a lot of times I reach dead-ends, and while I'm eager to have enough to show the world, progress has been kinda slow lately. Looking forward for your talk, be sure to link here on HN.

tiglionabbit 13y ago

I feel the same way. As a programmer, I feel like there are tons of irrelevant details I have to deal with every day that really have nothing to do with the exercise of giving instructions to a computer. That's what inspired me to work on my [nameless graph language](http://nickretallack.com/visual_language/#/ace0c51e4ee3f9d7483ec10780d1ed43 http://nickretallack.com/visual_language/#/ace0c51e4ee3f9d74...). I thought it would be simpler to express a program by connecting information sinks to information sources, instead of ordering things procedurally. By using a graph, I could create richer expressions than I could in text, which allowed me to remove temporary variables entirely. By making names irrelevant, using UUIDs instead, I no longer had to think about shadowing or namespacing. Also, by avoiding text and names, I avoid many arguments about "coding style", which I find extremely stupid. I find that people often argue about programming methodologies that are largely equivalent and interchangeable. For example, for every Object Oriented program, there is an equivalent non-object-oriented program that uses conditional logic in place of inheritance. For every curried program, there is an equivalent un-curried program that explicitly names its function arguments. In fact, it wouldn't even be that hard to write a program to convert from one to the other. I'm pretty excited about the array of parallel processors in the presentation though. If we had that, with package-on-package memory for each one, message passing would be the obvious way to do everything. Not sure how to apply this to my own language yet, but I'll think of something.

morpher 13y ago
Your visual language looks a lot like labview. I'm on a phone on a bus and haven't dug in too far, but have you used labview before?
- tiglionabbit 13y ago
  I'd like to try labview, but doesn't it cost lots of money? I guess I'll sign up for an evaluation copy. The closest things to my language that I have seen are Kismet and UScript. Mine is different though because it is lazily evaluated and uses recursion as the only method of looping. Some other things that look superficially similar such as Quartz Composer, ThreeNode, PureData, etc. are actually totally different animals. They are more like circuit boards, and my language is a lot more like JavaScript.

psgibbs 13y ago

I don't get it, why are you afraid of scooping yourself? In the same way that HN frowns upon stealth startups, shouldn't we frown upon 'stealth theories'? If your thoughts are novel and deep enough, revealing something about them will only increase interest in your future talks, since you are definitionally the foremost thinker in your unique worldview. If the idea fails scrutiny in some way, you should want to hear about it now so you can strengthen your position. What's the downside, outside of using mystery to create artificial hype?

jpadkins 13y ago
can't speak for the thread starter, but one downside to prematurely talking about something is confusion. Half formed thoughts, rambling imprecise language, etc can create confusion for his audience. The process of editing and preparing for a talk makes it more clear and concise. Maybe he is not ready yet to clearly communicate his concepts yet.

ericHosick 13y ago

> definition of programming is all over the place I agree. For example, people do seem to assume that programming must involve, in some way, coding. Do we really need to code in some programming-language to be programming? Changing security settings, for example, in a browser lead to quite different behaviors of the program. Isn't the user of the browser programming because they change the behavior of the program? And this leads to.... > with focusing on data If we focus on data, and hopefully better abstractions on how to manipulate that data, then wouldn't any user able to alter a program because they can adjust "settings" at almost any point within the program: in real time. Wouldn't this then enable a lot more people to become programmers? Anyway, just some thoughts.

astrobe_ 13y ago
The difference between setting parameters and programming is obviously that programming allows the creation of new functions. "Coding" is literally the act of translating a more-or-less formally specified program (that is, a set of planned actions) into a particular computer language. However, if being a programmer was only like being a translator, programming wouldn't be too hard for mere mortals. That's on the other part - the one that involves methods, logic, knowledge like the CAP theorem - they have problems with. The fact is, not every one can re-discover the bubble sort algorithm like we all here did when we were 8 or so. That's why we are programmers, and that's why they are not (and don't even want to be -- but they are nonetheless nice people and have other qualities, like having money). And these problems don't vanish if you switch from control-flow to data-flow or some bastardized-flow; they just change shape.
- ericHosick 13y ago
  As some people have mentioned in this HN post, it is hard to define what programming means. A program is the result of the automation of some process (system) that people have thought up (even things that couldn't exist before computers). Programming is the act of taking that process (system) and describing it in a computing device of some kind. Programming currently requires some kind of mapping from the "real world" to the "computer world". The current mapping is done primarily with source code. So, it currently seems that people who are good at programming are good at mapping from the "real world" into the "computer world" via coding. You seem to be making the point that some people are just good at programming because they can do things like "re-discover the bubble sort algorithm" or understand CAP theorem. These are very domain specific problems. For people who are able to "re-discover inventory control management" they would do a great job of automating it (programming) if they had an easier way to map that process (system) to a computing device. The ultimate goal (other than maybe AI) is a 1-to-1 mapping between a "real world" process (system) and a computing device that automates it.

casual_slacker 13y ago

I've been thinking a lot about such issues too; particularly the pain points I have when ramping up against new systems. What information is missing that leaves me with questions? Can code deliver something thorough enough to be maintainable as a single source of truth? I think, the differences between reading and writing code are as big as sending and receiving packets. It's difficult to write code that extrapolates the base information in your head driving the decisions. Not only that, but you also have to juggle logic puzzles as you're doing it. And on the other side, you have to learn new domain languages (or type hierarchies), as well as what the program is supposed to do in the first place. I think the idea of interacting with code as you build it is great, but how can we do that AND fix the information gap at the same time?