telling vs. showing

[Sean McDirmid]

An interesting comment on a hackernews discussion (on Bret’s latest goodness) related to visual programming discussions:

 

Counterpoint: he notes our techniques are based on writing, but it goes deeper: our symbolic writing (including mathematical notation) is based on speech, for which we have dedicated linguistic structures in our brains, much as we have a visual center. It is deep-seated, and many have argued fundamentally entwined with sapience. Thus, even if it's not theoretically the best way, it might be the best way for us. But I'm going to argue it is the theoretically best way: Linguistic descriptions have a key advantage over pictorial in that they represent or reference rather than show. This enables them to be compact, and omit unnecessary detail. (Of course, showing rather than telling is a strength of visual representation).

Yes, you can have a hierarchy of visual systems, and zoom-in or hide. But a fundamental problem here I think is in choosing the hierarchy - that is, the way the system is modularized.

Different modularizations of the same system are often appropriate for different uses of that system, or for considering different aspects of it. For even a slightly complex system, there are a huge number of different modularizations possible, and not all of them are useful. Often, you'll start with a poor one, and eventually have insights moving you towards the ideal one. (Of course, sometimes the "right" modularization is obvious, especially for well-known families of problems).

All this is very difficult. My point is that it is easier to switch modularities linguistically than pictorially, by changing your concepts. Without the right modularity, it's difficult to pictorially show just the aspects of interest instead of the whole picture. In contrast, one can linguistically omit detail by referencing it (implicitly, as a separate module).

Maybe it's possible to do this visually, though I suspect it thereby would have become linguistic!

[Though the above is a counterpoint, I'm very impressed with the talk. He's working both ends of abstraction, with concrete working software demonstrating cool useful practical techniques that, while not universal, would be helpful in many domains; and also framing it within, and using it to illustrate, the deep universal and philosophical idea of unthinkable thoughts. BTW e.g. uncomputable numbers.]

 

 

 

[David Barbour]

I believe this commentator is very confused.

* Regarding "showing detail": as subsequently mentioned, we can use encapsulation and zooming. The role of 'reference' can often be replaced by 'recognition' of higher level patterns.

* Regarding "choosing the hierarchy": textual isn't better than graphical with respect to modifying how code is factored and modularized. A multi-aspect projectional editor would help all kinds of code.

I wonder if the author's concerns are more related to the historically first-order nature of most graphical programming environments. 

Showing doesn't imply providing all the details, at least without somehow zooming in. It only needs to be detailed enough that people can recognize patterns they've already studied.

When code is organized on a compositional aspect (e.g. dataflow or control flow) then we can modularize on that aspect regardless of textual vs. graphical representation. 

It quite is possible to view and manipulate code in multiple ad-hoc ways, e.g. using projectional editors or lenses, but this is difficult to implement regardless of whether the code is textual or graphical. 

I believe

and pictorial representations both enable modularization on that aspect.

It's easy enough to hide unnecessary detail for a pictorial representation of code, i.e. by encapsulating code into components.  The notion of supporting different 'views' of code for different cross-cutting 'aspects'

--
You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
To post to this group, send email to augmented-...@googlegroups.com.
Visit this group at http://groups.google.com/group/augmented-programming.
For more options, visit https://groups.google.com/groups/opt_out.

[David Barbour]

Oops, left some previous drafts there.