From: larix_occidentalis@yahoo.com   
      
   Don Geddis  wrote:   
      
   > To conclude with my original point: if you actually try to write normal code   
   > using a reasoning language (like Prolog), you'll find that it's easy enough   
   to   
   > encode the logical problem specifications, but the resulting program doesn't   
   > run well enough.  You eventually find that 99% of your effort is trying to   
   > shoehorn procedural hints into a declarative language.  And you finally   
   > conclude that it would have been a whole lot easier to encode that procedural   
   > knowledge using a language that is optimized for expressing procedural   
   > knowledge, aka one of the ordinary programming languages (Lisp, C, Java,   
   > Perl, etc.).   
      
   Agreed, but where does that leave us? Where do we go from here?   
      
   If procedural subroutines are called for, I don't see any good   
   reason to try to contort a declarative language to implement them --   
   it seems feasible to combine procedural and declarative languages   
   to get the benefits of either one.   
      
   Actually, that's already very common. Regular expressions and SQL queries   
   are embedded in procedural languages -- concise declarative languages   
   that have a limited domain of application, but which are very powerful   
   within that domain. I would argue that this general recipe can be   
   followed with other kinds of declarative languages, with declarative   
   programs appearing as objects within a procedural program.   
      
   There is another angle which hasn't been raised yet -- in a declarative   
   language, it is sometimes possible to identify the points at which   
   some procedural routine is needed to carry out the implications of   
   a declaration. For example, there are languages to describe minimization   
   problems -- the steps needed to solve a particular problem vary   
   greatly with the details of the problem. Being able to identify the   
   steps for different kinds of problems allows us to build a system   
   that executes the appropriate blocks of code for different problems.   
   This is a big win -- from the declarative point of view, problems   
   are all described in a uniform way, and from a procedural point of   
   view, the steps appropriate to a particular problem are carried out.   
   It seems to me this general approach could be exploited in other   
   kinds of problems.   
      
   L.O.   
      
   [ comp.ai is moderated.  To submit, just post and be patient, or if ]   
   [ that fails mail your article to , and ]   
   [ ask your news administrator to fix the problems with your system. ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)