Hacker News Reader

Comment by tsunamifury | Hacker News Reader

I think software engineer and the fundamentals of coding have always had a bias towards those who can conceptualize ideas in the abstract, then build with the assumptions that those concepts are happening regardless of their ability to see them.

This is fine, except that it limits those who need to tinker in order to find out how those concepts work. When the elements are visually recognizable and physically manipulatable, you can tinker without having to hold the entire chain on concepts in your mind. It reduces the load and increases the likelyhood of 'playing around'.

I hope some day more of Victor's ideas can be realized through the understanding that visualizing processes allows us to use more of our brain to design and develop or products -- not to mention stumble upon and explore unexpected outcomes.

View on HN

I can't tell if everyone one is like that (I assume not), but I am extremely reliant on visualization, and I suppose Bret is also. I believe profoundly on it's power partly because it's the only way I can really get things done properly, which is why those tools resonate so much to me. I have a friend however that shudders every time I mention making programming more visual.

I mean, If I'm not visualizing something, I can perhaps find some solution in a logical way following some guidelines -- much like following a recipe to solve a equation or doing trial an error to solve an algebraic problem. But critically, I can't create this way. I may stumble unto something useful, but it's an entirely different process from creativity -- it's efficiency is so much lower that it's qualitatively different.

But my difficulty at that is not fundamental, I think. I believe you can be creative purely 'algebraically', but I have no experience with it -- but I do believe that some people have the same efficiency that I have when I think visually and perhaps stumble a little more when trying to visualize things themselves.

I do think this diversity is quite good, but that's missing the point. My point is that Bret's tools shouldn't be universally essential, but are probably universally beneficial. And for some people, like me, they'd be simply enabling.

To give an exaple: when I see a system of linear equations, I don't think of a bunch of steps to solve them and the number of cases that the solutions may look like in terms of constraints of variables an so on. I think of the Image hyperplane, which can be abstracted as a plane in 3D, and the Kernel, which may be for example a line not on the Image. Then instead I wonder if the Kernel is non-null, what funny things this matrix is doing to the vectors (are they rotating, contracting, and so on), or what are the invariant subspaces. I can answer most questions one could ask about such system, but it's a distinct way, I'm not sure if more efficient or not (and that may be up to the task).

A major problem I can see is that the more interesting a problem becomes, the more impossible to visualize. You might visualize a system of linear equations when it is 3 dimensional. But try visualizing a system with 1000 dimensions. It breaks down very easily. In the end my opinion is that one is simply going to be better off learning to think critically and in the abstract.

Again just my opinion - those who say they are better at visual problems often just need to practice more without the crutch.

A big part of abstraction for me is bringing problems into something I can visualize. This reduction itself works better if I have visual intuition. I suppose linear systems are a simple case, since their functional behavior for finite dimensions can pretty much all be mapped into 3D (I guess 4D would be a little richer with double complex eigenvalue pairs, but that's just 2x 2D rotations). I don't claim to be a great problem solver, but I've gone halfway through college so far with pretty good grades without changing how much visually I think.

Learning how to deal with two dimensions, where visualization a are useful, is the first step to learning how to deal with 100 dimensions. Crutches are useful in getting started.

But maybe our intuition is wrong here:

"Hundhausen and colleagues found that how the visualizations were used matters a lot. For example, using visualizations in lecture demonstration had little impact on student learning. But having students build their own visualizations had significant impact on those students’ learning." p.118

Oram, Andrew, and Greg Wilson. 2011. Making Software: What Really Works, and Why We Believe It. Farnham; Cambridge: O’Reilly.

The Pharo guys are working on that:

https://vimeo.com/channels/ndc2014/97315968

Starts slow, but gets really interesting (disclaimer: I'm a biased interaction designer in this regard, I love this stuff) halfway in.

Pharo might actually become a very good fit for Victor's idea of a big-screen "seeing room" debugging environment, now that I think of it - combine it with some of Victor's idea of drawing dynamic visualisations[1] it would probably be a great environment for creating tools on the fly, and the "everything is an object" model is fitting for the tinkering-mentality of the maker space.

[1] https://vimeo.com/66085662

Does Pharo support anything more than the standard hot code swapping and live object (but not code) manipulation?

If you're familiar with Smalltalk, skip the first twenty minutes of that first video I shared and then stick around for at least fifteen minutes, that's where the customizable views are explained. I think that answers your question - although I don't know how innovative this if you take into account all the alternative UI's that failed. However, the way it is being implemented in Pharo really appeals to me, and I can see it really work well in this "visual debugging seeing room environment thingy" Bret Victor wants us to aim for.

> I have a friend however that shudders every time I mention making programming more visual.

Whenever someone mentions making _programming_ more visual I just get this feeling I don't really understand what they mean. The act of programming is just text to me. Doing simulations, measurements and what not can be visual, but the only way I can see "visual programming" is clunky and cumbersome.

I don't know if I'm just misunderstanding people, but the composition of code doesn't need to be anything else than text-based in my opinion.

Edit: I have seen some of Bret Victor's tools and his tool for visualizing change in game programming is very cool and I'm sure very helpful, but that is a very, very specific thing and whenever you take it out of that context it becomes so much less interesting and helpful.

I'm not advocating just giving up on the whole idea, but I feel like people are trying to generalize things that they've only imagined for very specific purposes.

I think there's an important misconception about Victor's works and ideas. Augmenting human intellect is not only about visualization, it's about gathering and merging symbolic, interactive and visual representations in a single tool. He brought this point in this conference†, quoting research from Jerome Bruner ††. He shows the example of an electric circuit. Increasing some value on a resistance and seeing the change reverberating on all the plots is equally symbolic, interactive and visual.

† http://worrydream.com/#!/MediaForThinkingTheUnthinkable

†† https://en.wikipedia.org/wiki/Jerome_Bruner

This is also a huge concept in Mindstorms, a book sharing many of the same goals as Victor, a stated influence. Here the idea is to expose children to tools for thought ambivalent to their form. Papert's experience is part visual and part formal linguistic—he built LOGO.

That bias came from the necessity that engineering work is mostly invisible and you can't completely generalize every concept to fit every project. You need to put in extra work to visualize a graphic that would respond to the state of the system and the concepts you are visualizing might only be relevant to the project at hand. Despite these challenges, when we can visualize certain general concepts, which apply to a wide group of systems, but engineers do a good enough job and rarely are visual designers or UX experts involved. At that point its a cultural issue and that's why I'm grateful Bret Victor is around to advocate better designed tools for engineers.

There are UX designers that focus on high investment tools....at AutoDesk for example. Also, high investment tools are more difficult to change given...well...the investments made in them by the user base. Also, be careful to distinguish between visual and UX, those aren't often the same people outside of the web world. Heck, data visualization people often aren't visual designers.

Reply on news.ycombinator.com