I always thought Knuth's solution to typesetting paragraphs was a work 
of sheer beauty.  Although glue is a term unique to TeX, dynamic 
programming is a term of art for the n^3 optimization technique used to 
optimize certain types of objective functions, indeed, the same trick 
used in the original unix "diff" program to compute minimal edits to 
convert one file to another.  Knuth associates a penalty with 
consequences of a particular set of line breaks for a paragraph, and 
then computes the minimal-penalty solution.

I have often thought that combining vertical and horizontal glue with 
fixed size boxes was the single best way to define screen and window 
layouts.

It is completely (and beautifully) documented in source code using 
Tangle, Weave and TeX in Knuth's book: "TeX: the Program."

On Friday, May 18, 2001, at 10:56 AM, Alan Kay wrote:

> While all of you are thinking about this, you should also see what 
> Knuth does in TEX using "glue" which is a kind of spring .... and 
> "dynamic programming" to pull all together .... Ian Piumarta is rumored 
> to have a TEX solver in Smalltalk somewhere ...
>
> Cheers,
>
> Alan
>
> ------
> At 7:52 PM -0700 5/17/01, Ned Konz wrote:
>> On Thursday 17 May 2001 19:47, Mark A. Schwenk wrote:
>>>  At 5/17/2001 07:33 PM, Ned Konz wrote:
>>>  >Can someone suggest where Cassowary might be useful for the kinds of
>>>  > drawings I've been dealing with (i.e. shapes connected with lines)?
>>>
>>>  How about automatically positioning the shapes, using the lines as 
>>> springs.
>>>  You can read an object instance model from the system, generate
>>>  collaboration diagrams showing the object relationships with the 
>>> layout
>>>  done by the constraint engine. And then if you wanted, you could 
>>> turn off
>>>  the constraint engine (at least in localized areas) and tweak the 
>>> diagram a
>>>  bit.
>>>
>>>  It could also be used in laying out network diagrams, organization 
>>> charts,
>>>  parse trees, etc.
>>
>> You know, I've thought about this a bit, and it seems like it could be 
>> done
>> without having to use a constraint system.
>>
>> I imagine a process that can be run on demand to re-position shapes 
>> based on
>> their interconnections. Push a button, and things are rearranged (with,
>> perhaps, a property that could exempt certain shapes from being 
>> rearranged).
>>
>> Attaching a single ConstraintMorph to each of the movable shapes that
>> examines the connections and re-positions its constrained object would 
>> do the
>> trick. You could either leave the CM attached, or delete them after 
>> they've
>> done their job. Every step time the CM would examine the connections 
>> to its
>> constrained shape, and compute a vector that it would use to move its
>> constrained shape.
>>
>> This would occasionally lead to oscillations, but you could manually 
>> move an
>> oscillating shape to fix it.
>>
>> I can't imagine a simultaneous solution for _all_ the shapes in a big
>> drawing; you'd almost have to compute them separately anyway. In which 
>> case
>> you have got the simple case: a bunch of independent variables (the
>> connections looked at as springs) and one dependent variable (the 
>> resultant
>> vector for this step). And this doesn't require (or benefit from) a
>> constraint solver.
>>
>> Unless I'm just not seeing the benefit.
>>
>> --
>> Ned Konz
>> currently: Stanwood, WA
>> email:     ned at bike-nomad.com
>> homepage:  http://bike-nomad.com
>