Re: [Gnu-arch-users] "semantic" diff/merge tools

[Thomas Lord]

  Tomas> Quite an interesting discussion. One point I'm missing though
  Tomas> (it *is* implicit in what Tom says, as far as I can read
  Tomas> between the lines, but my eyes are getting worse with time
  Tomas> ;-) is that -as far as the ``programmer'' manually hacks the
  Tomas> source (or Tom's proposed wiki-like syntax), she conveys some
  Tomas> meaning in the otherwise irrelevant line structure. A covert
  Tomas> channel of sorts for some soft semantics.

  Tomas> I think this is part of the success story of diff/merge wrt
  Tomas> to thesources we are accustomed to.


So in a fugue you have a melody that "makes sense" from multiple
perspectives.  It puns and fits together with itself like a little
puzzle.  The melody stands independently and follows a certain
convention of composition.  Shifted in time and juxtoposed to itself,
it also makes sense according to a convention of harmony.  It puns a
third, fourth, and fifth way: it fits the instruments on which it is
designed to be played, the gestures required for a human to play it
fit the range of achievable human skill, and beyond just the
conventions of composition -- it sounds good and evokes a coherent
emotional and intellectual response from many listeners.

A lot of good programming is sort of like that.  For example: A syntax
has to fit how people edit source texts and how people read them.  It
has to fit efficient parsing technology.  It has to fit the space of
data structures it is supposed to be used to express.  It has to
interact nicely with generic diff/merge tools.  And all these fits
have to be simple enough that an author, writing in the syntax, can
keep all of those considerations in mind at once, even if only through
heuristics like formatting conventions.

Schools of programming that focus on scratching itches and putting out
the fire of the day, usually by adding yet more code, completely
forsake the art of the fugue and too often tend towards cacophony.
Rube Goldberg was a comic artist rather than a mechanical engineer for
a reason: "difficult ways to achieve easy results"[1] is supposed to be
parody, not standard operating procedure.
                [1](http://www.rube-goldberg.com/html/bio.htm)



  > I banged my head on this while trying to reconcile Mozilla config
  > files for several users. When I realized that the content of some
  > tags was e.g. order-independent (and the application chose a
  > seemingly random order of the sub-tags) I more or less gave up on
  > a general solution of the problem.

That sounds like an example of what I call a "treed" (as in, "cat
stuck up a tree") or "dead-ended" or "intractable" architecture.  At 
some point, the cost of throwing more code at the latest itch/fire
starts climbing exponentially.


  > You'd need a description of this file format at a higher level. It'd
  > probably have to be a bit more than grammar (``the sub-elements of
this
  > element are order-independent'' sounds more like semantics already).

  > I have no idea whether a good DTD or XSchema could help here (in the
XML
  > case, that is). As to the Scheme/Lisp case -- I don't know.

A bottom line is that generic diff/merge tools are always operating
with the handicap of semantic disconnect.  They are operating on the
data expressed by a syntax (trees, lines, whatever) at a low level and
applications and users assign these structures far higher-level
meanings.

That suggests to me that it is a mistake to build things like
config-file syntaxes that average people can't learn to wrap their
heads around and edit directly in order to fill the gap between
what generic tools can do to them and what needs to be done.

Part of the problem here is what I call "designs that lie".  A file
that records user settings is *literally* a text file declaring 
various values for variables in the running program and so forth.
But that isn't how some designers approach the problem.

Designers fantasize, inheriting third-hand wisdom from usability
experts of the eighties, about discoverable interfaces to achieve
each use-case anyone will ask about.  They want magic.

What these designers neglect to do is to concentrate hard on creating
applications whose operation has a clear conceptual model -- that 
does something fundamentally simple and that, in its interface, simply
explains what it does to users in terms they can seize control of.


  > To put all my babbling in a short and blunt hypothesis::
  > programmers do arrange the lines of their code in a way that diff
  > and merge work well.

Yet most don't do that by explicit choice -- they are just enjoying 
a fugue (partly accidental, partly intentional) from the past.

Line-orientation is natural from many perspectives: human readers,
text editor implementation, text file representation, etc.  It is
one of the simplest ways to do things and so there is a natural
harmony among tools sensitive to it.

SEXPs aren't all that far behind once you have full-screen display
editors.

-t

p.s.: this is one thing that makes me sad about the failure of
  the original project to produce a "complete GNU system".
  Back in the day the intention was to build an improved unix
  that combined the best lessons from that system with the best
  from the lisp-machine world in fugue-like fashion.  It withered
  and died with the explosion of Linux.