I think this article raises some brilliant points, and is very well written, but I also feel that it falls short of the mark Bret was aiming for.
As he himself alludes to, most of what he is teach is not programming - it is individual actions. Just as being taught the meaning of individual words does not teach you to write, being taught what certain functions or statements do does not teach you to program.
What is important is not spelling, but grammar - the shape of a program. His parts on Loops and Functions are better on this - the timeline showing loop instruction order is pretty awesome. However, it's still not perfect. At no point is the user instructed what a 'function' is, and how to use it. How do they know that they should be using it? I agree with other commentators who have suggested that it looks too much like he knows what he is aiming for, and the tool is designed to aid that.
In fact, my strongest criticism is in regards to his rebuttal to Alan Perlis:
> Alan Perlis wrote, "To understand a program, you must become both the machine and the program." This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.
I'm sorry Bret, but Alan is right. You do need to be able to think like a machine. Not necessarily an x86 machine, but an abstract turing machine, or a state machine, or a lambda calculus machine. If you cannot think like the machine, you cannot outwit the machine. This is incredible important if you are relying on the machine to give you feedback on what the system is doing.
In all his examples, very simple things happen, and never go wrong more than drawing in the wrong place. What happens if he starts causing an infinite loop? Or creates cycles in a linked list (and remember, sometimes he may in fact want cycles).
In "Godel, Escher, Bach", Douglas Hofstadter suggests that one of the key ingredients for intelligence is being able to go 'up' a level of abstraction. Bret's comment about a circle being made up of small steps, and hence integrating over a differential function, is part of it. A human can recognise that sequential steps with a consistently changing angle can be viewed as a circle. A human can realise that certain relationships are iterative, recursive, self-referential, in a way that (currently) a computer cannot. This is what needs to be taught, and I fear that what Bret has shown here would not help in that element.
However, it's still going to be a better intro than anything we have currently, so I think that in regards to getting people to dip in and try, it will be a vast help. I just hope that Bret keeps thinking about bridging the chasm between setting down series' of instructions, and programming.
> I'm sorry Bret, but Alan is right. You do need to be able to think like a machine.
I would like to bring in another Alan Perlis quote: "You cannot move from the informal to the formal by formal means."
Programming is the art of formalizing things to a point where they are executable. Executable by what is the point of contention here. I think you are saying (and I somewhat agree) that ultimately your programs and ideas have to execute on a real machine, and as a programmer you need to understand and model that machine.
OTOH, perhaps what Bret is arguing is that we should make better machines and software abstractions.
I dont think it needs to be a real machine in the sense of a physical one, just in the sense of an execution environment.
What worries me about Bret's tools is that it looks like they make it easier for someone to produce something without knowing why. When you learn maths at school, you're normally taught to show your working - getting the answer isn't enough, you need to understand the process. Having so many sliders and timelines to pull around is fine, but at the end of the day we need to teach people functions and variables and recursion and combinators and so forth, and I'm not sure how one does that in this system. In a sense, it is skipping the architecture stage - working not just how to build, but what to build in the first place.
As he himself alludes to, most of what he is teach is not programming - it is individual actions. Just as being taught the meaning of individual words does not teach you to write, being taught what certain functions or statements do does not teach you to program.
What is important is not spelling, but grammar - the shape of a program. His parts on Loops and Functions are better on this - the timeline showing loop instruction order is pretty awesome. However, it's still not perfect. At no point is the user instructed what a 'function' is, and how to use it. How do they know that they should be using it? I agree with other commentators who have suggested that it looks too much like he knows what he is aiming for, and the tool is designed to aid that.
In fact, my strongest criticism is in regards to his rebuttal to Alan Perlis:
> Alan Perlis wrote, "To understand a program, you must become both the machine and the program." This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.
I'm sorry Bret, but Alan is right. You do need to be able to think like a machine. Not necessarily an x86 machine, but an abstract turing machine, or a state machine, or a lambda calculus machine. If you cannot think like the machine, you cannot outwit the machine. This is incredible important if you are relying on the machine to give you feedback on what the system is doing.
In all his examples, very simple things happen, and never go wrong more than drawing in the wrong place. What happens if he starts causing an infinite loop? Or creates cycles in a linked list (and remember, sometimes he may in fact want cycles).
In "Godel, Escher, Bach", Douglas Hofstadter suggests that one of the key ingredients for intelligence is being able to go 'up' a level of abstraction. Bret's comment about a circle being made up of small steps, and hence integrating over a differential function, is part of it. A human can recognise that sequential steps with a consistently changing angle can be viewed as a circle. A human can realise that certain relationships are iterative, recursive, self-referential, in a way that (currently) a computer cannot. This is what needs to be taught, and I fear that what Bret has shown here would not help in that element.
However, it's still going to be a better intro than anything we have currently, so I think that in regards to getting people to dip in and try, it will be a vast help. I just hope that Bret keeps thinking about bridging the chasm between setting down series' of instructions, and programming.