4 ms·

Its a smartly written piece, but to me this just scratches the surface. A couple of issues: 1. If you are making the conceptual jump from 'text' to 'dynamicall

Its a smartly written piece, but to me this just scratches the surface. A couple of issues: 1. If you are making the conceptual jump from 'text' to 'dynamically annotated text', why not go a step further and just let people draw a rectangle with visual tools entirely (like in Illustrator,Inkscape,etc.) and forget the textual representation? 2. The real difficulty comes with representing things as they may arise through a dynamic program, not with just the 'initialization' stage as this shows. This is where code really really gets complex, and also is much harder to add to with these visual systems. [EDIT] To clarify further, relating to comments below - The OP's main intent is "how do we redesign programming?" [for all programmers] and my comments relate to this, not just to the use of such techniques for students as a step towards learning traditional code.

jfarmer 14y ago
1. Because a big part -- perhaps the biggest part -- of "learning to program" is understanding how to move between the picture in your head and the text that makes it real. From both directions: "What does this code do?" and "What code do I need to write to make this happen?" Purely visual programming are, IMO, noble lies.* You want to start with an environment that echoes the final state, not one that's totally dissimilar. e.g., training wheels vs. computer bicycle simulator. *: The exception to this is when you're teaching children ~13 or younger, in my experience. It's always a question of what mental models a student has at their disposal. 2. By the time a student is at this stage, they have more sophisticated, general models the teacher can rely on. In this essay Brett is working in a world where someone might not have the right mental model for assignment, variables, looping, etc.
DigitalJack 14y ago
1)Because that is not learning programming, which is entirely what this essay is about. 1.b) Learning programming is about learning to reason about problems. Not about learning to use different tools. 2) I think I agree that dynamic programs would be more challenging to do this with. On the flip side, this demonstration is so far beyond my reasoning that it doesn't mean much to me. It's all stunning.
- judofyr 14y ago
  1: That is not entirely what he's saying though: A frequent question about the sort of techniques presented here is, "How does this scale to real-world programming?" This is somewhat like asking how the internal combustion engine will benefit horses. The question assumes the wrong kind of change. Here is a more useful attitude: Programming has to work like this. Programmers must be able to read the vocabulary, follow the flow, and see the state. Programmers have to create by reacting and create by abstracting. Assume that these are requirements. Given these requirements, how do we redesign programming?
  - DigitalJack 14y ago
    True. I mistakenly thought I had reached the bottom of his essay when I hadn't.
  - twelvechairs 14y ago
    Thanks. This was my reading of the OP also and what I was responding to (its about changing programming paradigms for everyone, not just about learning for beginners). I've edited my above post to reflect this.
croddin 14y ago
1)He shows an example of this. The last one in http://worrydream.com/LearnableProgramming/#react http://worrydream.com/LearnableProgramming/#react 2)I think the examples with the various timelines, wrapping code in functions or for loops, and replacing constants with variables came a long way in that direction
- twelvechairs 14y ago
  Thanks. I'd missed the first one. The timelines are good, but what I mean by 'dynamic' is something with user input that affects objects. Its easy to show how a loop can draw the same shape in lots of different ways, but what happens if the loop might draw different things depending on what the user inputs while the program is running? This gets tricky.

jfarmer 14y ago

1. Because a big part -- perhaps the biggest part -- of "learning to program" is understanding how to move between the picture in your head and the text that makes it real. From both directions: "What does this code do?" and "What code do I need to write to make this happen?" Purely visual programming are, IMO, noble lies.* You want to start with an environment that echoes the final state, not one that's totally dissimilar. e.g., training wheels vs. computer bicycle simulator. *: The exception to this is when you're teaching children ~13 or younger, in my experience. It's always a question of what mental models a student has at their disposal. 2. By the time a student is at this stage, they have more sophisticated, general models the teacher can rely on. In this essay Brett is working in a world where someone might not have the right mental model for assignment, variables, looping, etc.

DigitalJack 14y ago

1)Because that is not learning programming, which is entirely what this essay is about. 1.b) Learning programming is about learning to reason about problems. Not about learning to use different tools. 2) I think I agree that dynamic programs would be more challenging to do this with. On the flip side, this demonstration is so far beyond my reasoning that it doesn't mean much to me. It's all stunning.

judofyr 14y ago
1: That is not entirely what he's saying though: A frequent question about the sort of techniques presented here is, "How does this scale to real-world programming?" This is somewhat like asking how the internal combustion engine will benefit horses. The question assumes the wrong kind of change. Here is a more useful attitude: Programming has to work like this. Programmers must be able to read the vocabulary, follow the flow, and see the state. Programmers have to create by reacting and create by abstracting. Assume that these are requirements. Given these requirements, how do we redesign programming?
- DigitalJack 14y ago
  True. I mistakenly thought I had reached the bottom of his essay when I hadn't.
- twelvechairs 14y ago
  Thanks. This was my reading of the OP also and what I was responding to (its about changing programming paradigms for everyone, not just about learning for beginners). I've edited my above post to reflect this.

croddin 14y ago

1)He shows an example of this. The last one in http://worrydream.com/LearnableProgramming/#react http://worrydream.com/LearnableProgramming/#react 2)I think the examples with the various timelines, wrapping code in functions or for loops, and replacing constants with variables came a long way in that direction

twelvechairs 14y ago
Thanks. I'd missed the first one. The timelines are good, but what I mean by 'dynamic' is something with user input that affects objects. Its easy to show how a loop can draw the same shape in lots of different ways, but what happens if the loop might draw different things depending on what the user inputs while the program is running? This gets tricky.