The Human-Language Interface

The Human-Language Interface

PowerPoint slides from Matthias Felleisen's presentations page. He discusses the HtDP educational philosophy and PLT research experience.

Some of the figures are undecipherable, but there's lots of interesting stuff in there. The pedagogical approach to the human factors issues of programming languages has turned out to be really productive.

(P.S. - Is there anything un-politic about posting references to your own professor's work?)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Politics

(P.S. - Is there anything un-politic about posting references to your own professor's work?)

No! It's encouraged!

())))(())(

Interesting... Despite liking scheme a lot, I really do think that the abundance of parenthesis is not such a great thing. Look at the character from a purely visual point of view: ( look at where it pulls your eye - not straight up, but diagonally. I think that makes lispy languages more difficult to follow for the eye. Maybe it's an insignificant difference, but I don't think it's a line of reasoning entirely without merit. A comment that I recall very clearly from a time I had occassion to chat with Simon Peyton Jones a bit was that "syntax is a language's user interface", and that made a lot of sense to me.

It would certainly be interesting to get some comments on the visual aspects of different programming languages from an unbiased graphical artist.

Yeah

As a lisp fan I'd like to see a lisp editor that removed the parens in favor of some other graphical representation. The key idea is that its syntax is really just trees, so there should be many more natural ways of representing that.

Color

As a lisp fan I'd like to see a lisp editor that removed the parens in favor of some other graphical representation

Given a good editor, simply set the color of the parentheses to something like a light grey, so that they're still visible, but fade into the background and don't dominate the source code. The result is similar to the effect you get with languages that depend purely on indentation for structuring, like Haskell or Python. It's especially effective in combination with good syntax highlighting and automatic indentation. DrScheme does this very well.

In fact, the result is a lot cleaner than most languages, where the bracketing punctuation -- such as parens, braces, square brackets, and angle brackets -- usually carries semantic content other than structuring, so you can't afford to ignore it when reading code.

The key idea is that its syntax is really just trees, so there should be many more natural ways of representing that.
Such as? Diagrams of trees with lines between nodes certainly don't usually help at the level of source code, for example. Perhaps a simple approach is best - for example, you could surround each node with some kind of delimiter - say, parentheses or angle brackets - and use nesting to represent the tree structure... ;)

2D graphics

The key idea is that its syntax is really just trees, so there should be many more natural ways of representing that.
Such as?

One possibility would be nested boxes. Keyboard shortcuts to create, move around in and manipulate this structure could make this very ergonomic.

let
x 12
y 13
 
+ x y

=> 25

What I find very interesting, is that any graphical object can be used as a form, as long as there's a s-expression translation of it. In the next example, there is a special user interface for creating emails in program code. This is a visual macro, that would translate to something like (make-mail address subject body).

let
address "foo@mail.com"
subject "unsubscribe"
 

New Mail

To: address
Subject: subject

Body:

=> #<EMAIL>

Boxes in DrScheme

Interestingly, DrScheme has boxes that does something along these lines - it supports insertion of boxes which can contain a mixture of e.g. HTML and quasiquoted Scheme expresions, with nested boxes representing each level in a tree. In this case, the levels of the tree correspond to quoting levels, e.g. HTML, quoted s-exps, spliced Scheme, etc. However, it's not much of a stretch to get to the above from there. I do think this could be a good idea for graphical layout kinds of tasks - forms etc., especially HTML-like. Not sure that I would want every node in my program to be in a box, though!

Granularity

Not sure that I would want every node in my program to be in a box, though!

But such granular storage of information has big advantages. I am working on a graph-based work environment. Compared to Unix's hierarchical filesystem and files, its structure is a grand graph of small connected nodes (such as integers, strings, or app objects).

In this system a program, or program function would be a graph molecule, in which nodes represent statements, documentation, etc, and every part can be cross-linked to other parts.

Now one big advantage over plain text is reuse of structure. For example, the name of a variable need to be defined only once, and all occurences of the variable simply link to this definition. When the name of the variable is changed, all occurences update automatically. This wouldn't be possible with plain text.

Bad Editors!

The problem isn't good editors. Get one fixed up just right and editing Lisp isn't that bad.

But not everyone starts off using a good editor. Lots of people start coding with whatever crappy tool is at hand, not knowing any better. Even those of us who have a good editor often times open something up with 'less', or maybe have to do a bit of work without the good editor on a remote machine, or at a client's place of business, or on some

Mentioned here before

Why doesn't every language have a DrScheme?

A few cool features of DrScheme that seem like they belong in every language:

  1. Step through the evaluation of a term with an evaluation-by-substitution model (parallel bottom up or "breakpointing" on subterms would be nice). For languages which are not purely functional but modify values, automatic watching of anything that will be used in the future evaluation of the term would be nice (this seems inherently two-pass).

  2. Static analysis and visualization - extracting together an expandable collage (with those cool graphical links) of definitions/uses, along with static assertions on variable/term value in terms of the particular reference you started from. Most languages have some tool that generates a concordance or list of hyperlinks of "used by" "defined in" for names, which you can painstakingly explore, but there's something to be said for collecting (excerpts/digests of) everything onto one screen.
  3. Interactive shell supporting "fun" things like images, vector graphics onto canvasses, such that graphical and text output can be part of the "command line history" rather than something that vanishes as soon as execution completes. Automatic browsable visualization of complex structures like (shared) lists,trees,graphs (even pointer graphs) ... and/or an interface for hierarchical expansion/visualization of data structures that can be overridden for user types.

  4. Interface to editors for complete syntax/scoping understanding/checking (there are 1000 ad-hoc C and Java parsers that do highlighting, indentation, declaration/use concordances)

The "graded levels of progressively more complex language" idea seems good for learning, and probably most valuable for languages that have a lot of context-sensitive overloadings (similar syntax, perhaps one typo away, but different semantics).

I think the answer to "why doesn't my language have all these cool toys?" is that it's a lot of work, and that people designing languages tend not to care for building some ideal usable IDE. Which makes me wonder: why can't most of the concepts of PLs be abstracted to the extent that there exists an interface sufficient for performing and visualizing most of these operations (term evaluation, stepwise reduction, static analysis ...) so that you can plug in any conforming language implementation and use all of the applicable features?

And why is it acceptable to use languages nowadays that don't support dynamic code compilation+linking or interpretation, let alone reflection? That is, except for some half-ass subset-of-language evaluator built into your debugger shell, and some limited "edit and continue" you can't really play around with C++ in your program's current environment, without a complete recompile and restart. That's really a shame.

Eclipse (eclipse.org) is a platform that allows you to plug in a Java-IDE or C++-IDE module and have a Java or C++ IDE ... can't we move the level of reuse to a finer-grained level, so that a generic IDE with DrScheme like abilities could refer to language-specific specifications of syntax/semantics, or implementations of processes like term stepping, static assertion generation, data structure exploration/visualization ...

There are so many lovely programming languages out there, so it seems a shame that someone's great work on the human-PL interface for one of them, will be unavailable useless to all languages but the chosen one (of course, if I am a fan of language Z, I am free to port your interface code for language X, but that's a heroic effort in general).

Also a feature of...

...CLIM, the Common Lisp Interface Manager, descended from the Dynamic Windows systems of the late 1980's, and not coincidentally older than DrScheme. There are some demonstration videos and this Lisp listener app for McCLIM.