COMPUTER BB
TOPIC:   PROGRAMMING
TO:      <xxxxx>   (<xxxxxxx>)
FROM:    BILL HOGAN   (TWDX23A)
SUBJECT: PROGRAM NEEDED
DATE:    07/13/93
 
<xxxxx>- I am pressed for time at the moment, but I do not   
want to let this opportunity pass, so I hope you will not   
mind too much if I import an excerpt from something I       
recently wrote to someone else (on Compuserve), to whit:    

 Setting aside the question of the existence or
non-existence of (affordable) canned software that might be 
adapted to your particular scheduling problem, the most     
important part of any scheduling problem consists of        
_describing_ the problem.                                   
                                                            
 Scheduling problems that involve _people_ are notoriously  
hard to define: it is very easy to get trapped on a         
merry-go-round whereby every time you think you have        
captured "the" problem, someone who does not like one of    
the consequences of your definition turns around and says   
"Oh, but that's not what we meant! We didn't want THAT      
consequence so you will have to reformulate your definition 
of the problem!"                                            
                                                            
 Unfortunately, if your specification of the problem has    
been "adsorbed" into, say, a C++ program, then even a       
seemingly tiny change in the set of propositions that       
describe the problem can play havoc with the "code" you     
wrote on the basis of the original set of assumptions.      
                                                            
 But if your specification of the scheduling problem has    
been written out in an executable language (properly        
speaking) like PDC Prolog, the job of reformulating the     
problem and the job of "reprogramming" the scheduler are    
one and the same thing.                                     
                                                            
 I heartily recommend that you write out your definition of 
your scheduling problem in PDC Prolog; properly done,       
everyone involved will be able to understand what you have  
written and, once they agree that you what you have         
written is in fact a description of the problem that        
exists, they will have to accept the consequences of your   
description because those consequences will be logical      
consequences of that description.                           

 That's how it works with PDC Prolog: the description of
the problem and the program that generates the solutions to 
the problem are one and the same thing.                     
                                                            
 As you know, people problems tend to be logic-intensive    
and highly situation-specific, which is just a way of       
saying that you have to be close to them in order to        
understand them; to people who care only about fashioning   
computer programs that sell in the millions, like pop music 
albums, the notion of writing programs that are essentially 
"single copies" is, I think, understandably unappealing.    
                                                            
 But for people who _have_ to deal with people problems one 
day at a time, the availability of a computing formalism    
that is at once a _language_ (in the sense of being         
thinkable-in-terms-of) _and_ a programming language (in     
the sense that with it you can make computers do things) is 
very good news.                                             
                                                            
 If you are interested, or would like to see an example of  
what this approach looks like, please let me know.          
                                                     Bill