Comment by gojomo | Hacker News Reader

Comment by gojomo | Hacker News Reader

Beautiful and inspirational, and yet...

Sometimes becoming able to hold the 'invisible state' in memory is the skill to learn.

Consider the 'dual N-back' drilling which seems to improve working memory, and then also (by some studies) other testable fluid intelligence. The whole point is holding more and more hidden state in your mind. (To 'show the state' would defeat the purpose of the game.)

Similarly, sometimes struggling with the material is the best way to internalize it.

Consider some studies that show noisy, hard-to-read text (as on a poorly-printed copy) is better remembered by readers than clean typography. Apparently, the effort of making out messy printing also strengthens the recall.

So I'd be interested in seeing comparative testing of the vivid 'Victor' style, and other styles that are more flawed in his analysis, to see which results in the most competence at various followup dates.

We might see that the best approach is some mix: sometimes super-vivid interactivity, for initial explanation or helping students over certain humps, but other times intentionally-obscurantist presentations, to test/emphasize recall and the ability to intuit/impute patterns from minimal (rather than maximal) clues.

Having an environment such as one Victor styled for big systems (big as in millions of lines of code), would prove unfeasible (hell auto-complete has a hiccup when lines start getting into hundreds of thousands).

Those tools he proposes seem to be very beginner and RAD oriented (even if he claims otherwise). I've seen IDE's choke on smaller code bases and this not only has auto-complete, auto-update but also state/frame/time tracking built into. There is no way in hell it can work for existing languages. Maybe some kind of VM that remembers all it's previous states, all function call times, orders and then updates them as programmer changes them.

Yes, in a large system, many of Victor's techniques might only be usable in isolatable areas, like well-mocked unit-tests.

Regarding "some kind of VM that remembers all its previous states", check out 'Omniscient Debugging': http://www.lambdacs.com/debugger/

We just need to design better IDEs and languages. Ya, large code bases suck but not that much. We can actually compile code pretty quickly, and we are only just beginning to study memoization techniques (which you are alluding to at the end of your post). Also, language is a very big deal: you can't really expect as much from the IDE on C++ as you can from C#.

It can scale, we have plenty of smart people to make it scale. The important problem here is "scale what?" I think that is the genius of Bret Victor's innovations.

Why do systems need millions of lines of code?

If you can build a complete operating system + major programs in 20,000 lines of code, what system should need a million?

http://www.vpri.org/pdf/tr2008004_steps08.pdf

(They're not quite down to 20,000 yet, but they're getting there)

No one said they need millions lines of code. However a large "enterprise" application have a way of growing like cancer. This tool won't be particularly useful for such codebases.

if you had this tool, maybe you wouldn't built applications that way anymore. it's at least a possible outcome.

"Consider some studies that show noisy, hard-to-read text (as on a poorly-printed copy) is better remembered by readers than clean typography. Apparently, the effort of making out messy printing also strengthens the recall."

In the book 'Thinking, Fast and Slow' studies are presented, that the number of right answers increases if the question is harder to read.

The conclusion is, that if you need more effort and consciousness to comprehend a question, than you are already in a mode of thinking which makes it easier to reach the right answer.

Thanks for your post. I was about to write something similar. While it is surely very impressive (the post), I am not sure if I learn better when I click on things. The visualizations make it nice to see what is going on, but making code that does not work error free is always (and was) the most effective way to learn.

The ability of holding an invisible state is important, but at the same time you are mixing things in the learning process, and that makes learning hard. Try learning to speak a new language while learning juggling ... this is definitely difficult. By taking smaller steps, the learner is able to make better progress. First the tools... then the imagination.

Reply on news.ycombinator.com