From: brianbec@microsoft.COM (Brian Beckman, ATBD)
Newsgroups: comp.lang.scheme
Subject: Abstraction versus Concretization (was Case...)
Date: 7 Nov 92 19:30:42 GMT
Organization: The Internet

Ian Joyner writes:

|Date: 2 Nov 92 08:35:54 GMT
|From: Ian Joyner <ian@syacus.acus.oz.au>
|Organization: ACUS Australian Centre for Unisys Software, Sydney
|Subject: Case sensitivity
|Message-Id: <1992Nov2.083554.1548@syacus.acus.oz.au>
|In-Reply-To: <OZ.92Nov1005201@ursa.sis.yorku.ca>
|To: scheme@mc.lcs.mit.edu
|
|barmar@think.com (Barry Margolin) writes:
|
[...]
|
|This is quite often what makes mathematics difficult to read.  I
|recently review quite a good paper, and the recommendation I made to the
|authors was in one the the mathematical sections to cut out all the
|subscripts, etc.  It made it so much more readable.  So if these devices
|are not needed don't use them.
[...]

Ian is on to something interesting.
It seems to me to be canonical in mathematics to write in a highly 
abstract and stylized way.  Computer programs, perforce, are also 
written in this way.  The concrete realizations are usually packaged in 
input data.  To understand highly abstract papers, readers must 
construct their own examples, then generalize back to the abstraction 
in the paper and check for a match.  If match then enlightenment, else 
try to cook up more examples, i.e., try to concretize the abstractions. 
 This process explains to me why reading some mathematical papers, and, 
likewise, READING OTHER PEOPLE'S PROGRAMS, takes so long.
	I think everybody's mental abstraction engine works better than 
his/her concretization engine because abstraction is a straight and 
narrow path whereas concretization is an open door to a Universal 
search space.  It requires insight and hard work.  When I have a 
difficult program to read, I need to execute it on examples, 
single-step it, trace it, watch it in action, to achieve enlightenment. 
 If I'm lucky or smart, I can come up with example inputs myself.  
Often I have to pester the author for input data.  I claim this 
activity is just computer-aided mathematics.
	There seems to be a kind of unwritten understanding in mathematics.  
When one joins the club, one understands that writers and editors prune 
papers so that just the abstract essence remains, and it is supposed to 
be a fun puzzle or a nasty IQ test, depending on your point of view, to 
figure out what a paper means.  Many people just use papers to decide 
what conferences and talks to go to: that's where a lot of mathamatics 
is done.  Very few authors have achieved the stature to be allowed to 
publish lavish examples, because they take up a lot of space.  The 
papers of these authors are often a joy to read, not least because of 
the presence of examples.  Publishing enjoyable papers just increases 
one's stature, naturally.
	Of course, textbooks is where examples and puzzles-with-answers, aka 
exercises, get published.  That's why Abelson & Sussman's "Structure 
and Interpretation of Computer Programs" and Graham, Knuth, & 
Patashnik's "Concrete Mathematics", etc. are so good.  They show you 
how to play the level-lowering and level-raising game yourself.

[...]

|Ian Joyner  ACUS (Australian Centre for Unisys Software)    ian@syacus.acus.oz
|"Where is the man with all the great directions?...You can't imagine it,
| how hard it is to grow, Can you imagine the order of the universe?" ABWH
|Disclaimer:Opinions and comments are personal.