W

ARPSTOCK --- I'm in the Barrington Room at the Warpstock '98 Convention, where Greg Bourassa is discussing his favorite "power tools" for developing OS/2 software.  Greg knows several computer languages, and I skipped the sessions on "Extending The Operating System" and "How To Deal Effectively With The Computer Press" to sit in and listen and swipe a few ideas.

           Greg is a freelance engineering consultant and has been an OS/2 developer since version 1.2.  His worldwide customers use several operating systems, and I'm impressed to learn that he does all of his development on OS/2 and then ports when necessary to Solaris, Windows or whatever.

           Mr. Bourassa is discussing his favorite development language, the one he now uses the most after years of work with all the mainstream languages, the one he feels is the most powerful and yet has the shortest learning curve of any language he's ever learned.  He points out that there are plenty of companies supplying the compilers and there's lots of existing code.  He's used this language to write word processors, spread sheets, transportation and scheduling problem solvers, and even augments his programs occasionally with a tiny assembler stub if he needs to speed up some matrix calculation.

           He's found that he's reduced his lines of source code by a factor between three and ten with Prolog, his language of choice.  Because of the way Prolog source code is written, he finds it often executes faster than C.  It's built-in memory management is faster than C because the program knows up front where the allocations will take place (no need to keep track of your memalloc's).  He's giving solutions to his customers faster, and making more money, with this very-high-level language.

           You engineering guys will understand this the fastest.  Up front, where you declare things and before you start writing executable code, you also add some logic tables.  It's sort of like defining all of your logic tests beforehand, so your "if . . . then" statements are already defined.  Then, as your program compiles, the compiler uses the logic where appropriate.

           Remember this:  classic C programs are pretty straightforward.  Do all the processing that you can, then execute an if/else to break it into subparts.  Now repeat this on the subparts, ad infinitum.  By putting the logic up front, your logic structure is concise and readable.  No more pressing PgDn ten times to find the "else" section of your code.

           We've been classically trained.  Fortran, Cobol, Basic, Ada, Pascal, C and C++, we put the fundamental logical thinking of our code down in the mud with our assignment statements and function calls.  Programmers, first and foremost, are supposed to be problem solvers.  We shouldn't have to be code-tuners.  Code-tuning can be automated.  Problem solving cannot.

           QuickSort in Prolog is 12 lines.  In Pascal it's 92 lines.  That's a big difference, and it's a lot more likely that some typo bug will drive you nuts for a day when you've got 92 source lines instead of 12.

           Again, Gregory is a top-notch C, Pascal and you-name-it programmer (I looked at some of his code, and I'm not so shaky myself).  He's also a well-known consultant.  And his job is to solve his clients' problems.  If you're thinking that writing less lines of code makes for a less powerful program, then go back to Assembler.  Prolog is a programming tool, and you should be using it.  Do you know and use REXX?  Sure you do.  You should also know Prolog.

           I was impressed with the readability of Prolog source code.  That makes maintenance a breeze.

           Now, suppose you're managing a project.  You've got a couple of big potentially-spaghetti code blocks to write and you know from experience that most of the project problems are going to crop up there.  Throw them at Prolog.  Prolog will flesh out the logic, find your trouble spots and show you what part of the analysis is missing.  C compilers won't do that.  And, if you don't want your final product in Prolog, you can then recode it in C.  Or do a Prolog subsystem that links to your C frontend.  If nothing else, do the design work in Prolog.

           Prolog forces programmers to think about solving the big problem, not the little bugs that shouldn't have crept into the code to begin with.  Prolog has a specific execution model, so the compiler generates code that typically has stack-oriented memory management, built-in recursion optimizations, and nary a memory overrun or underrun.  And the logic, declared up front, keeps you from getting into trouble.

           Prolog has an ISO standard.  Prolog-in-C and C-in-Prolog are quite common.  Porting Prolog between platforms ("syntax tweaking") is fast, and Greg says 5,000 lines per day is typical (GUIs and operating system calls are where your port may take some time).

           Prolog used to be interpreted and was slow like early Java.  No longer.  Prolog compilers are sophisticated and mature, and are on a par with C.  My suggestion:  use both an interpreter and a compiler.  Use an interpreter for code development, so your errors are instantly visible.  Then compile the final code so it's fast and optimized.

           Greg has found that Prolog is faster than C for complex data structures, and slower than C for number crunching.  His solution?  He embeds a C calculation function when necessary.

           Japan adopted Prolog early on for their 5th Generation Project.  We don't see a lot of the results of that project because it's in Kanjii, but Japan is technically proficient and they wouldn't be using Prolog if it wasn't a top contender.

           Your Prolog programs consist of Terms (constants, variables, and compound terms which are structures) and Statements (facts, rules which are logic clauses, and queries).  It's a way of organizing the code you're used to writing so it's more logical, more concise, and easier to maintain.  It still compiles to the same .EXE binary executable you've always had.  You get the same results as from a classic C program.

           There are tutorials available.  Plan on two days --- a weekend --- to learn the language.  The Prolog Development Center (PDC) product, free at Warpstock '98, includes a nice tutorial.

           For other Warpstock '98 articles see the Warpstock '98 Article Index.

Visual Prolog from PDC, see Prolog Development Center