The usual HN article that contains criticisms is usually limited to that. Some rant that took 10 minutes to write and contains nothing constructive.
Bret Victor put an insane amount of time into this (I can only assume) and is truly advancing mindsets about programming tools and learning. We should all be thankful that he put this much effort into a "criticism" piece.
Where are the numbers? Where's the testing? Where's the proof that his proposed changes are more effective in teaching a new programmer? Validity comes through numbers, proof, and evidence.
Some times you have to show people what they want. And then when they see, they would know how awesome things are.
Not all projects are started after research and data. That way many projects would never start.
What actually happened? Does anyone know definitively whether or not it was tested by non-Apple employees before launch?
In this case, I believe that a professional/experienced educator who has tried teaching introductory programming can, given their own experiences, relate, understand, and build on the concepts in the article to improve their own teaching and understanding of teaching/learning introductory programming. This is sometimes called communicative generalization (see Smaling: http://www.ualberta.ca/~iiqm/backissues/2_1/html/smaling.htm... ).
For example, to me, as a computer science teacher in high school, I recognize a lot of the issues discussed in the article. Reading the article I am able to link these issues and solutions to my experiences in class and decide to what extent it is credible and trustworthy. Furthermore, and more importantly, I can more easily apply results this kind of research in my daily practice than I can results of (rigorous) quantitative research as that almost always is taken out of context and ' clinically' due to fixing variables that aren't fixed in real life situations (i.e. the classroom, the students (holistic), environment).
If you down-vote simply because I believe a person should offer proof when they make a claim, you're falling victim to your own biases.
I hope you have a study to backup that assertion.. :p
(Hint: not all knowledge is empirical)
"Numbers, proof, evidence" tend to be marks of an excellent article. But an incredible amount of work clearly went into this article, and it presents powerful ideas in a novel and original light; it is highly valuable and fascinating in its own right, even if it is weak in certain areas that academic papers tend to be strong in.
Yes, citations would help tease apart questionable assumptions from reliable ones. Yes, thorough testing would help lend more credence many of the ideas. Yes, the article is imperfect and could be better in a multitude more ways. Still, the article is highly valuable and fascinating.
Have you heard of the term "strawman argument"? That's what you're doing when you say "It's amazing how many people [are completely unreasonable]". Most people are quite reasonable. If a large community is downvoting you, you should strongly consider the possibility that you, in fact, are the one being unreasonable.
Also, I know why I'm being down-voted. Bret is an inspiring person. His Vimeo talk, specifically, is very inspiring. He acts on principle, he believes strongly in his ideals, and there are many people who agree with him. So, the people who like Bret are people who align themselves with his ideals. So, when I challenge his vision by asking for data, people who read it feel like I'm challenging them, personally - like I'm challenging their beliefs (because, well, I am - I'm asking them to prove their beliefs). People respond to that kind of challenge in a negative way. It'd be like if you tried to argue the ideas of Steve Jobs with an Apple fan - they're just not going to listen to you, no matter how solid your arguments are.
I, myself, agree strongly with Bret's principles. He's right that developers need better tools and we need a better way to teach programming to people. However, I try to divorce myself from those emotions and still look for facts and evidence. If someone claims A is better than B, I will look for proof, even if my "gut instinct" tells me that they're right. I very well believe Bret could be right, but that doesn't mean we should all just assume he is without evidence.
My point here is that asking someone to give evidence for their arguments is completely acceptable. But, when you challenge the ideas of someone feel emotionally invested in (because their beliefs and ideals are being challenged), you receive negative feedback. Thus, the down-votes. It's actually a very interesting study in how people can be loyal to someone even without evidence of that person being right.
I don't think you really do grasp the magic of what he has come up with. Yes you saw his video 8 months ago. But if you did truly grok what he is putting forth, you wouldn't make this generic rebuttal about whether its tested or not. That can be applied to anything.
We come to hacker news to get the kernels of the newest innovation that is happening around the world before anyone else. If you require ideas to be tested before you do anything with it, you will be late to the party. Your loss.
Now Russel can you please stop standing up for this point. It's unfortunately the first thread on this awesome piece and a waste of our energies to discuss.
Lets discuss how we are going to implement this watershed idea for innovation!!
Inovative ideas are rare and fragile. We should be thankful someone sharing them.
https://vimeo.com/36579366 http://ejohn.org/blog/introducing-khan-cs/
The current trend in live coding seems to have spawned from a discussion between two computer musicians (Fabrice Mogini and Julian Rohrhuber) in 2001, with masses of related prior art going back to Lisp machines, Self, Smalltalk, corewar etc.
But why do you think liveness requires visual programming? I see them as pretty much orthogonal.
Separately, when I see "visual programming language" I see "unusual programming language". When language features become normal (like 2D syntax in Python/haskell), then we stop calling them visual. A great deal of visual features are just alternative ways of structuring text, ways of constraining syntax, or ways of constructing high dimensional (and therefore non-visual) graphs. To a large extent, all programming languages are visual.
Liveness doesn't require visual, of course, but that's where liveness first shows up in history (SketchPad, along with directness). I go into some of the history in my own paper on the topic (http://lamp.epfl.ch/~mcdirmid/mcdirmid07dead.pdf).
Personally I think all computer languages are textual by definition, and vary in the amount of extra visual support for syntax and more often secondary notation. The Reactable perhaps pushes beyond this limit by making proximity and orientation part of the syntax, but still is basically about composing textual symbols.
If we're doing that thing, I wrote a chapter on this in my thesis :) http://yaxu.org/thesis/
[ For the benefit of any others, here's a link to Sean's preprint: http://lamp.epfl.ch/~mcdirmid/mcdirmid07live.pdf ]
I skimmed your thesis a few months ago; lots of good work there! But I think we are a bit out of whack on our world views (arts vs. PL), which is why we might not be talking on the same page.
Thanks, I forgot about the DigitalLibrary link :p. If someone is just looking for related work, better to try http://lamp.epfl.ch/~mcdirmid/mcdirmid07dead.pdf (smaller download as it doesn't embed quicktime movies).
There clearly is a distinction between textual and visual, but at the same time they support one another: text is made out of pictures, pictures can be described with text (e.g. svg). For me the aim of visual programming language research shouldn't be to disparage or get away from the composition of symbols, but to supplement that with mental imagery. As I see it, mental imagery and language are most valuable in combination.
I'll look into sketchpad and toontalk properly though, "truly" visual language is a fascinating area.
This is where Khan Academy exceeds. They have users. They have real people really trying to learn how to code. This means they can test their assumptions and modify their approach. An imperfect solution delivered today is better than a perfect solution delivered next week.
Real world innovation often makes very small tweaks on proven formulae, whereas bold new ideas can have a long incubation period with seemingly little payoff at first. It's roughly the difference between business and research. While it's not possible to "test" these bare assertions in the sense you imply, they can certainly be argued for and against. And he makes a rather compelling case for it, certainly a more nuanced one than much of the criticism here on HN.
In any event, he's begun sharing some of his code (I believe) and products like Light Table are emerging that appear to draw from very similar inspiration, if not his work directly. It would appear these ideas are gaining some traction.
What I'm drawing a distinction between is this approach to innovation, which is necessarily iterative and based on incremental improvements to prior art, and another approach which makes larger conceptual leaps and may not have obvious initial practicality. I described these two approaches as being roughly comparable to "business and research", although I admit that's a somewhat crude dichotomy. It is the latter camp that I think Victor falls in.
Both are relevant. For every Wright Brothers you also have a Tim Berners Lee, whose invention was developed in an international research laboratory (not a startup) and was largely ingored by the public for several years. It took the perfect storm of the late 90s Internet boom for the web to develop into the thing we recognize today.
In any case, it's not as though Victor has been doing nothing but writing papers and photoshopping mockups. If you look for them, you can find videos of him giving talks where he is demonstrating real, live software that implements his ideas. He has been refining them in practice for several years now, and others (such as Light Table's Chris Granger) are doing the same. The question is whether they will catch on, and the jury is still out as far as that's concerned.
And, I have seen the talks where he demonstrates his software. I just wish he would make it available (open source, sell it, whatever) so that others could use it and test it. Wouldn't you like to try out those tools he shows?
also, the stuff will work. It's dead obvious that it's the future. Take a step back, take a breath, open your mind and stop trying to backup your initial point about "where's the evidence?" and just agree this is magical and some big things will come out of it.
if you can't see that, and can't allow yourself to be wrong for a second, then fine, you're a regular guy--not someone we expect to see making the amazing startups that will put Bret Victor's stuff to use.
But sometimes some of the problems that testing would reveal, would also be revealed if you just thought and discussed your ideas more, and would cost vastly less time and effort (which is a very high bar when what you're testing is the efficacy of pedagogy for teaching people programming for the very first time). So presenting your ideas in a compelling way and opening up discussion can also be extremely valuable, and that's exactly what Bret Victor did.
"ellipse" and numbers are only hints, just as blank buttons and dials are only hints.
Programmers rely a lot on IDE support now to see the parameters...which is exactly what Bret is talking about!
DrawEllipse(x=50, y=25, width=32, height=5)
No real-time rendering and tracing of values required (I hope!). Furthermore, a decent IDE will bring in the method doc blurb, so the programer has a richer context to make an informed decision.
I appreciate the work Brett put into the article and I'm half way pre-convinced myself. At the end I was somewhat disappointed because most of the stuff he talks about is already present in a decent IDE, perhaps in a less polished form, but present nonetheless.
The deeper put-off is that the article seems to advocate not thinking, instead performing random walks using shiny tools. If someone can't think about their code, no amount of visualizations is going to help. That being said, the potential of enhancing one's thinking abilities by properly chosen visualizations is tantalizing, but I don't think the article makes a good case for it and I haven't yet seen a better approach than old school pen and paper.
Most of the article tries to make the point that if someone can't visualize what their code is doing, they can't think; they can't reason about it.
Building the right visualisations that hold at master level as well as at novice level holds the promise to expand one logical abilities far beyond what our current ones.
The thing that you don't know in the programming example is what those numbers do. I've written processing.js code before and I'd be half-guessing if you asked me what each parameter to elipse() does.