Lambda the Ultimate

inactiveTopic The myth of code-centricity
started 8/26/2001; 11:10:38 AM - last post 8/30/2001; 10:40:25 AM
Chris Rathman - The myth of code-centricity  blueArrow
8/26/2001; 11:10:38 AM (reads: 1422, responses: 7)
The myth of code-centricity
The article basically says we need to get away from coding in a text sense and lean towards a more graphic/visually oriented approach.

While I agree that our tools ought to free us from some of the more monotonous and mundane aspects of commanding our machines, I think many tool pushers miss one important aspect. Just because the tool automates the coding process, it does not mean that I am never interested in the implementation details. What I want from my tools is the ability to be as abstract or as detailed as the process requires.

The jump from machine language to assembly language was an easy one - the mapping from assembly instructions to machine instructions is very exact. The jump to languages like C was also not very difficult because the compilers were essentially compiling down to assembly which could be used to diagnose the behavior of the code - important for many of the real time projects that I was involved with. However, when you jump to visual programming, it seems that many want to promote the compilation process to a state of magic.

The author gives the example of using visual tools for database programming - as opposed to SQL. I've personally had to clean up a lot of bad designs that were made through QBE because the users were not aware of the underlying issues - just because it looks ok visually does not mean that it is valid or efficient. Along these lines, I like SQL tools that generate the SQL for me, but I want the ability to look at the results and proceed from that basis.

The best visual tools don't attempt to supplant the coding process, so much as be a tool to help generate and maintain code.
Posted to Software-Eng by Chris Rathman on 8/26/01; 11:12:15 AM

Ehud Lamm - Re: The myth of code-centricity  blueArrow
8/27/2001; 5:47:19 AM (reads: 878, responses: 0)
I agree.

I want the code to be available, if I want it.

It seems like thinking about textual code helps clarify and fix language designs. You must direct your attentions to things like scope, interfaces, sperate compilation, reusability etc.

All this does not mean that tools can't be helpful. We hard some discussion recently on XSLT tools. These can help you concentrate on the lok&feel of your otuput, but the end-result is an XSLT file you can continue to work on.

jon fernquest - Re: The myth of code-centricity  blueArrow
8/28/2001; 3:50:29 AM (reads: 858, responses: 0)

>However, when you jump to visual programming, it
>seems that many want to promote the compilation
>process to a state of magic.

Wouldn't tieing the semantics of the visual programming model tightly to an underlying functional programming language solve this problem?

This seems to be the idea behind "events" and "behaviors" in Fran (Haskell). Haskell's Fudgets uses similar declarative functional ideas to tie GUI widgets to the underlying functional language.

I don't know of any visual languages built on top of these GUI systems though.

graydon hoare - Re: The myth of code-centricity  blueArrow
8/28/2001; 5:11:44 PM (reads: 839, responses: 2)
I find this suggestion, that "visual" things are more expressive than "languagey" things, frustrating.

the assertion seems to rest on the understanding that humans can take in an awful lot of information in parallel, visually, in the form of a full field-of-view, whereas taking in a stream of text requires scanning it serially, across the page.

unfortunately, most of what I see people doing with computers is not reading one another's code (much as we might like this) but writing their own, and when writing I hate to say we have no particularly good bulk parallel interface for dumping our ideas into pictures. we cannot "project" what we're thinking into a picture, or any form really other than gesture or vocalization, which is implicitly serialized.

it's sad, but all I can see in these "visual" programming systems is a failure to realize that a mouse, light pen, or similar "drawing" sort of interface is exactly as serial, and often significantly slower and clunkier, than a keyboard or a voice-input system.

Ehud Lamm - Re: The myth of code-centricity  blueArrow
8/29/2001; 5:46:17 AM (reads: 890, responses: 1)
I find this suggestion, that "visual" things are more expressive than "languagey" things, frustrating.

I don't think anybody around here is making this claim

graydon hoare - Re: The myth of code-centricity  blueArrow
8/29/2001; 10:13:40 AM (reads: 957, responses: 0)
perhaps nobody here is, but the article's gushing about moving programming into a "totally different, higher-level way to work compared to coding" leads me to believe the author has swallowed the common, and imho wrong assumption that character streams are an inferior, lower-level medium of expression than GUIs.

some of what he's talking about is valid, albeit presented in an unorthodox manner. e.g. his enthusiasm for "declarative knowledge" closely matches the taste of many programmers to make their work largely side-effect-free and evaluation-order-independent, or at very least to program in a "data-driven" fashion. likewise his interest in "system imagery" closely matches the good programmer's taste for a few well-thought common module interfaces in a system, to make it amenable to quick reconfiguration and aggregation.

but that's all the substance I can see in his article. people have been pushing mouse-driven "visual object" editors as replacements for keyboard-driven languages for a long time, and the unfortunate fact that keeps surfacing is that language is the domain of most human expression, and keys offer better language input than mice.

jon fernquest - Re: The myth of code-centricity  blueArrow
8/30/2001; 8:47:52 AM (reads: 818, responses: 0)
>I find this suggestion, that "visual" things are more expressive >than "languagey" things, frustrating.

>the assertion seems to rest on the understanding that humans can >take in an awful lot of information in parallel, visually, in the >form of a full field-of-view, whereas taking in a stream of text >requires scanning it serially, across the page.

I would question the value of rendering the *procedural* visually, but *complex declarative structures* as found in Prolog, or the *complex feature structures* of unification-based programming languages like HPSG (computational linguistics) or LIFE (Ait-Kaci) or PROFIT almost *have to be rendered visually to be comprehensible*.

Here's some 2D diagrams of feature structures:

The Lingo grammar of English (Stanford HPSG) which attempts to cover a significant fraction of English has a very complex declarative structure. It has a small set of grammatical rules and a very large lexicon of feature structures:

Feature structures are difficult to read in horizontal streams of text across the page because you can embed feature structures in feature structures to an arbitrary depth. Although pretty-printed s-expressions might just get you there, the extra dimension you get in a 2D diagram makes the inclusion relation between feature structures much clearer.

Sometimes you literally need a "big picture" to get a handle on how a large complex system is put together (cf UML, linked list data structure diagrams in any textbook, finite state diagrams).

Jon Fernquest

graydon hoare - Re: The myth of code-centricity  blueArrow
8/30/2001; 10:40:25 AM (reads: 814, responses: 0)
oh, yes, I'm all for visualization. I regularly pass confusing parts of programs into visualization tools. understanding data structures and relationships, plotting grammars, proofs, control graphs, interpreting profiles, bug detection.. all this stuff definitely requires extensive visualization.

I'm just questioning the need to input anything "visually"; where "visual input" oddly always seems to mean "with a mouse". I consider text the superior "visual input tool" for most tasks; only things with an obvious spatial metaphor (such as adjusting one's field of view, making a drawing, "feeling around" an undocumented tool, or arbitrarily selecting a piece of information from within a window) seem to benefit much from mice.

the author of this article, for instance, is advocating a form of component system assembly based on connecting boxes together with lines, in a freeform canvas widget (a la DX or PD). My experiences with this sort of programming is that it's often significantly more work than learning a (small) connection language (say TCL or bourne shell) and typing in the connections you want: you spend all your time shifting the "objects" around, to present a comfortable arrangement on the canvas, and dragging your mouse back and forth, hovering over "connection points" on the objects, etc. moreover, the spatial metaphor has the potential to break down entirely if you ever want to do higher order assembly tasks; it has to be very carefully designed to maintain expressiveness in the face of nested structures.

the upside is that you are, in some sense, forcing yourself to produce an "intuitive" visualization of your program while you're editing it; but I'm not convinced that visualization isn't best done retroactively, or at least offline from the editing process.