Perhaps Bret Victor's ideas are comparable to something like formal methods: few doubt their enormous power, but the difficulty is in the extreme effort one needs to implement them in a project. It is tempting to believe that the level of instrumentation that Bret proposes could be achieved automatically, just as it was once dreamed that formal methods could be fully automatic. But experience with formal methods has shown us that while some of their promise can be implemented by automatic tools, and this is valuable, to realize their full potential for a complex project requires substantial effort, non-reusable effort.
Bret Victor: Learnable Programming
181–190 of 193 posts
Re: Bret Victor: Learnable Programming
#182Earlier quoted context omitted.
Okay, but what is ellipse(50,25,32,5)? "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!
The comparison is still shallow. It is regrettable that most programming languages don't support named parameters, but it's fairly trivial to imagine a language and api: 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 appreciat…
It'll be interesting to read his subsequent comments on graphics state, as extending this example to draw arbitrary ellipses without coordinate changes could make for a simple visual demonstration of function composition, assuming the goal is not "Learn PostScript in floor(π^e - 1) Days."
Re: Bret Victor: Learnable Programming
#183Earlier quoted context omitted.
> Brett Victor is pointing out what he perceives to be valid flaws 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.
It's amazing how many people have a problem with the idea of testing a solution. I'm simply saying that assumptions need to be challenged and assertions need data to back them up. I'm not saying any of this ideas are inherently wrong, I'm saying they're unproven. 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.
You are not being downvoted because "people have a problem with the idea of testing a solution". You are being downvoted because your tone suggests you categorically dismissed a groundbreaking project because its introductory article wasn't a scholarly work bristling with citations.
"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.
Re: Bret Victor: Learnable Programming
#184Earlier quoted context omitted.
Khan Academy and Bret Victor are apples and oranges -- they're not even playing the same game. In order to make any major strides, we have to reconcile the need for PRODUCTS, NOW! with the conceptual, exploratory approach taken here. 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 d…
I disagree that real-world innovation isn't tested, iterated on, and improved. Look at flight and the Wright Brothers. They didn't just run numbers and present ideas. They built prototypes and tested their assumptions. That's what Bret needs to do. He needs to build, test, iterate, and improve upon his ideas.
You're reading an imagined reply no one is giving. No one is disagreeing that testing ideas is important. Until you test, you never know if there are problems with your ideas that never would have occurred to you no matter hard you thought about them, and that makes testing invaluable.
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.
Re: Bret Victor: Learnable Programming
#185Earlier quoted context omitted.
It's amazing how many people have a problem with the idea of testing a solution. I'm simply saying that assumptions need to be challenged and assertions need data to back them up. I'm not saying any of this ideas are inherently wrong, I'm saying they're unproven. 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.
You are not being downvoted because "people have a problem with the idea of testing a solution". You are being downvoted because your tone suggests you categorically dismissed a groundbreaking project because its introductory article wasn't a scholarly work bristling with citations. "Numbers, proof, evidence" tend to be marks of an excellent article. But an incredible amount of work clearly went into this article, an…
First, this isn't Bret's introductory article on this topic. As far as I know, his first talk about this came in January of this year (watch the Inventing on Principle video on Vimeo). Granted, 7-8 months isn't a super long time, but he has never built/tested his ideas, yet asserts them as if they were proven facts.
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.
Re: Bret Victor: Learnable Programming
#186Earlier quoted context omitted.
I disagree that real-world innovation isn't tested, iterated on, and improved. Look at flight and the Wright Brothers. They didn't just run numbers and present ideas. They built prototypes and tested their assumptions. That's what Bret needs to do. He needs to build, test, iterate, and improve upon his ideas.
I think you're misreading my reply. It's not that real world innovation isn't tested and iterated on, quite the opposite. The Wright Brothers are exactly that model and I don't dispute that at all. 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…
You're right, I did misread your reply - I originally thought you said it was innovation that took laboratory time. Though, now that you've explained it further, I'm still not sure I agree with the concept. Pure research follows a specific method - you form ideas, form a hypothesis, create an experiment, and test your hypothesis, then revise and test again. There is nothing, ever, that is not tested. Though, you can certainly make the argument that a few of Bret's projects (such as Tangle) work as small-scale experiments for testing his larger ideas. I may actually concede that point; though it is not exactly the big picture he's talking about, it does test the tools he suggests using to achieve that big picture.
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?
Re: Bret Victor: Learnable Programming
#187Programmer must be able to think in terms of how a machine works, how data-structures are represented and how system is organized, what other processes are running and what resources they are sharing.
Not thinking about the machine or an underlying OS is a total nonsense and the cause of problems and suffering.
Imagine a doctor who says "Doctors must not think about what is inside the body, they must think in terms of temperature measurements, blood testing and medicine prescriptions.
btw, the SICP book threats the subject exceptionally well, and not mentioning such fundamental work is an example of ignorance.
People understand what they can see - yes, they do. That is why we have box-and-pointer diagrams. That is why we use parenthesis.
In other words, all this was solved long ago in the Lisp world.
Re: Bret Victor: Learnable Programming
#188Earlier quoted context omitted.
Okay, but what is ellipse(50,25,32,5)? "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!
The comparison is still shallow. It is regrettable that most programming languages don't support named parameters, but it's fairly trivial to imagine a language and api: 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 appreciat…
> If someone can't think about their code, no amount of visualizations is going to help.
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.
Re: Bret Victor: Learnable Programming
#189Can I ask a question - why do I have to hear about a new platform or language once a week? Is there some problem existing languages aren't solving? Seriously. It's like this place falls in love with a new platform once a quarter. Before it was Lisp, Python, Ruby, etc. Now it's Clojure and anything else that has less than 1000 people actively using it. Did I somehow wander into the hipster bar of the programmers? I just don't get it. I can't keep floating from language to language leaving a cluster fck of code in my wake because I'm onto the next big thing.
Re: Bret Victor: Learnable Programming
#190Earlier quoted context omitted.
The comparison is still shallow. It is regrettable that most programming languages don't support named parameters, but it's fairly trivial to imagine a language and api: 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 appreciat…
> If someone can't think about their code, no amount of visualizations is going to help. 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.
Exactly! There are several levels of learning. At the master level one does his job using muscle memory. Graphics help at the early levels, but to be proficient one needs to master the domain. At that level graphics are slowing down the process, not helping 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.