CLIPS Year In Review: 2019

This felt like a year of slow progress. I spent some time on the release of version 6.31 of CLIPS, but otherwise I spent my time slowly but steadily honing Adventures in Rule-Based Programming.

Plans in 2020 are the same as plans from 2019: release version 6.4 of CLIPS and publish Adventures in Rule-Based Programming.

CLIPS Year In Review: 2018

Beta Releases 2 and 3 of CLIPS were released this year. Due to the amount of interest in using the NRC's FuzzyCLIPS (which was based on version 6.1 of CLIPS) with newer versions of CLIPS, I updated the FuzzyCLIPS source code available on GitHub to be compatible with versions 6.24, 6.3, and 6.4 of CLIPS. I also made substantial progress in writing the new CLIPS tutorial: Adventures in Rule-Based Programming.

Plans are 2019 are to complete the final release of 6.4 and publish Adventures in Rule-Based Programming.

Stowaway to Oblivion

During college in the early 1980s I wrote a never published text adventure called Stowaway to Oblivion. It was written in BASIC on the Apple II and had a very simple verb-noun parser. It was a fun little program, but I've always wanted to revisit that code and do something a little more sophisticated á la Zork.

Sadly I no longer have the source for Stowaway, but when I decided to write a new tutorial for CLIPS I came back to the idea of revisiting text adventures. Although the commercial market collapsed several decades ago, I discovered there's still an active community writing text adventures.

In writing the tutorial, I've been happy with how well suited CLIPS has been for this type of application, but as it turns out there's another declarative programming language called Inform 7 that's specifically designed for writing text adventures. It's pretty cool.

CLIPS Logo 2018

FuzzyCLIPS 6.31

Updated the FuzzyCLIPS source code to be compatible with CLIPS 6.31 and placed the updates on GitHub.

FuzzyCLIPS 6.24

Updated the FuzzyCLIPS source code to be compatible with CLIPS 6.24 and placed the updates on GitHub.

CLIPS Year In Review: 2017

The API updates for version 6.4 of CLIPS, as well as the release versions of CLIPS JNI 1.0 and CLIPS.NET 1.0, were completed this year. I also found a "good enough" solution for the lack of support for MDI applications in .NET, so CLIPS .NET now includes a CLIPS IDE with support for debugging windows. The makefiles got some attention and I also completed a number of user requests for additional functionality. Finally, the tedious process of updating the Basic, Advanced, and Interfaces Guides were completed allowing the first beta release of CLIPS 6.4 in December.

Plans for 2018 are to complete the release of CLIPS 6.4 so that I can move on to writing CLIPS textbooks. My stretch goal for 2018 will be to include a formal C++ with the 6.4 release.

CLIPS 6.4 Beta Release 1

Finally!

Trying Out Fiverr

Thought I'd give fiverr a try, so I ordered a gig to convert the CLIPS application icon to a vector drawing. This was the original icon at full scale:



And the vector drawings received from the gig at various scales:





Pretty good and affordably priced.

CLIPS Year in Review: 2016

A great deal of work this year on version 6.4 focused on redesigning the APIs that have accumulated decades of cruft. I think the simplification and streamlining will make embedding CLIPS much easier.

Version 0.2 of CLIPS iOS was released. It included the Wine Recommendation example program. Significant progress was made on version 0.6 of CLIPS JNI. Support for I/O routers and user functions were added and an IDE for development was created. For version 0.2 of CLIPS .NET, a console application supporting UTF-8 was created.

Plans for 2017 are to complete release versions of CLIPS 6.4, CLIPS JNI 1.0, and CLIPS .NET 1.0. Working on updating the Advanced Programming Guide is already under way, and the Basic Programming Guide and Interfaces Guide will also contain some major updates. My stretch goal for the year will be to develop an IDE using the QT cross-platform application framework. Microsoft dropped support for MDI applications, so creating a .NET IDE would be much more difficult than it was for MacOS or Java/Swing. Using QT looks like a much better alternative than using expensive third party extensions for .NET.

Bug Hunt

Is this going to be a stand-up fight, sir, or another bug hunt?

PFC Hudson, Aliens

If the bugs are seven feet tall, then a bug hunt is a stand-up fight.

Thirteen days. That's how long it took me to hunt and kill this one. A WPF GUI on top of a .NET wrapper on top of a C++ wrapper for CLIPS.

After overhauling the internal representation of the primitive data types in CLIPS, successfully passing the regression tests, and successfully upgrading the CLIPSJNI demo examples, I thought upgrading the .NET examples would be fairly straightforward. But two of the examples were periodically crashing.

So I went back through past revisions trying to find the point at which the code stopped working. I finally got to the point where the removal of a single unused slot from a struct caused the crashing behavior. Not good at all since this was now likely a corruption issue.

As I delved further into the issue, it became clear that this was a problem related to both running CLIPS in an embedded mode and the CLIPS garbage collection routines. Debugging the issue in Visual Studio was also a huge PITA for a variety of issues, so when I reached the point at which it was clear that the issue was unrelated to the WPF and .NET code, I created a C++ example that produced the same behavior running with MacOS.

That was day thirteen. Once I had the program in Xcode, that's when the magic happened thanks to these diagnostic tools:



With the Address Sanitizer enabled, I was able to immediately determine where the initial issue started and based on thirteen days of scouring the code, quickly implement a fix for it with a half dozen lines of code. So thanks to the fellow who originally told me about these Xcode diagnostic tools. It looks like there's some similar functionality for Visual Studio, just not as easy to use as checking a box.

The Silliest CLIPS Feature Ever

Professor Joe Warnings from the CLIPS Windows IDE circa 1997.

CLIPS Year in Review: 2015

Since my consulting gig with IBM ended in 2014, this was the first year in a long while I was able to devote most of my time to CLIPS development.

The major accomplishment this year was the release of version 6.3, which included significant performance improvements for some types of problems. The microEMACS editor, X Window interface, and help functions were put out to pasture with this release.

The first beta releases of CLIPS iOS, CLIPS .NET, and CLIPS CGI also occurred in 2015. CLIPS JNI also had two updates.

Finally, work on CLIPS 6.4 (code name Cypher) started in 2015. This release will include IDEs for .NET, MacOS, and Java Swing with unicode support and similar functionality; completed versions of CLIPS JNI, CLIPS .NET, CLIPS iOS, and CLIPS CGI; Adventures in CLIPS Programming (a replacement for the CLIPS User's Guide); and major usability enhancements for deftemplates/facts.

Esoteric Language Resources

The internet is an amazing resource for programmers. This is particularly true for programming languages in widespread use. The following graph shows the number of questions on Stack Overflow with a tag for some well-known languages.



There's a huge disparity between mainstream programming languages such as Java and C# and languages associated with artificial intelligence such as LISP and Prolog.

An even greater disparity exists between mainstream languages and expert system languages (that aren't even perceptible on the prior graph unless one zooms in on the far right):



I think this is one of the tallest hurdles to jump for users of esoteric languages. The presence of resources on the internet (discussion forums, documentation, tutorials, examples, etc.) have not reached the critical mass needed for widespread use.

{} vs. ()

People who like C dislike CLIPS because it looks like LISP.

People who like LISP dislike CLIPS because it's not LISP.

Wailing and Gnashing of Teeth

There’s a reason you should take information found on the internet with a grain of salt. While researching citations for the CLIPS wikipedia article, I came across this post on the comp.lang.lisp group:

Look around on the net for CLIPS. I think it ports to Common Lisp fairly easily, but I could be wrong about that.

CLIPS is basically a free version of ART*Inference, which was the Automated Reasoning Tool developed by Inference Corporation. Inference, however, did some things that seem, in hindsight, to indicate terminal stupidity. They had NASA as a client, and NASA developed mission-critical software using ART (IIRC it had something to do with the shuttle’s landing gear deployment system). But Inference formed a partnership with Sun and quit providing DOS/Windows versions of their software. Meanwhile NASA had a budget office to satisfy and had to buy all their computers from the same low-bid source, which meant they could only get Intel-compatible machines.

This resulted in NASA having mission-critical software written in a language that was only available on the computers they weren't allowed to buy. After a certain amount of wailing and gnashing of teeth, what it boiled down to was that they were legally able to hire programmers to implement the language on “standard” hardware, but they weren't legally able to buy the “nonstandard” hardware. Within a few months they had enough of the language running to handle their mission-critical software, and as a taxpayer-sponsored effort, it was released to the public.

This put Inference between a rock and a hard place, since a free version of their main product, which ran on much cheaper hardware than their partner would allow theirs to, was now available.

I love this post. It’s more fiction than fact, yet the manner in which it’s stated and specific details give it an air of credibility. The part about the shuttle landing gear deployment system is implausible for a number of reasons, but certainly makes the origin story so much more dramatic. Oh my, if we can’t deploy our landing gear expert system, the shuttle pilot will never know when to flip the landing gear switch. Wailing and gnashing of teeth, indeed!

A subsequent post in the thread corrects many of the inaccuracies relating to ART, but echoes a similar explanation for the origin of CLIPS:

In the mid-80's, NASA decided to fly expert systems, particularly on the space shuttle, and required a system that would run on PC's or some other kind of tiny embedded machines, which had memory limitations at the point that were fairly tough for a lisp-based system (remember 640K limits?). 

The actual origin of CLIPS is disappointingly mundane. There was no directive from the highest echelons of NASA management to create a tool for deploying mission critical shuttle software. CLIPS started as a small internal project at the Johnson Space Center in just one of several groups working with artificial intelligence. It was originally conceived as an intermediate step between the existing commercial tools and a low cost replacement tool that could promote widespread use of expert system technology. As events transpired, in addition to being an intermediate step, CLIPS ended up being the replacement tool as well.

ART was a powerful tool, but it was also expensive, costing tens of thousands of dollars. You could buy a copy of CLIPS for $250 and install it on every computer in your organization. Placing expert system technology on as many computers as possible was the real motivation behind the development of CLIPS.

“Official” Production System

Charles Forgy on the origin of Official in Official Production System (OPS):

People often ask me if the name “OPS” really stands for “Official Production System.” In fact it does, but the name doesn’t mean what most people think.

In 1975, Carnegie-Mellon University professor Allen Newell started the Instructable Production System Project, or IPS as it immediately came to be called. Project members included John McDermott, Michael Rychener, and myself. While we all had implemented and used our own production systems prior to joining IPS, the goals of the IPS project required that we work in the same language.

Accordingly, in a series of meetings in the fall of 1975 we jointly designed a language with which we all felt comfortable. This language was to be the official production system of the IPS project. The intent behind the name was no more sinister than that. We certainly weren’t trying to tell people outside the IPS group that they should consider OPS an official anything!

Forgy, C. L. “The OPS Languages An Historical Overview,” PC AI, Sep/Oct 1995, pp. 16-21.

The CLIPS Team 1987

NASA Tech Briefs, Nov/Dec 1987

CLIPS 30th Anniversary

This year is the 30th anniversary of the creation of CLIPS. Its wikipedia entry contains enough factoids to have earned it this banner:

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.

Since I’ve been involved with the software longer than anyone else, I’ll add my recollections on the veracity of each of the sentences in the wikipedia summary starting with the first:

CLIPS is a public domain software tool for building expert systems.

True. The versions of CLIPS developed while I was at NASA were distributed through COSMIC, but the versions I’ve developed after leaving NASA have been released as public domain software.

The name is an acronym for “C Language Integrated Production System.”

True. The I in CLIPS was sometimes erroneously stated to stand for Inference or Intelligent.

The syntax and name was inspired by Charles Forgy’s OPS (“Official Production System,” although there was nothing really official about it).

With regards to syntax, this is completely false. The only inspiration involved in the early syntax of CLIPS was to avoid reinventing the wheel. At the time, we were using ART for developing expert systems, so CLIPS replicated the ART syntax supporting the primary set of features we used. So credit for the core syntax used by CLIPS goes to ART, not OPS.

As for the name, there’s a definite truthiness to CLIPS being inspired by OPS (since both contain Production System in their acronym), but I think this misses the mark on the significance of CLIPS. The real impetus behind CLIPS was having a tool written in a conventional programming language that could be more easily integrated into operational environments. So the “C Language Integrated” portion of the acronym is more important than the “Production System” portion. Naming it CLIRL (C Language Integrated Rule Language) would have been as appropriately descriptive as CLIPS, but just wouldn’t roll off the tongue as easily. I don’t recall being involved in any discussions about the name, however, so the only person who can definitively answer questions about its inspiration is Robert Savely, my boss at NASA who conceived the project. Next time I see him, I’ll have to ask how he decided on the name.

Oddly, the most important legacy handed down to CLIPS from the OPS languages developed by Dr. Forgy, the Rete algorithm, is not even mentioned in the article.

The first versions of CLIPS were developed starting in 1985 at NASA-Johnson Space Center (as an alternative for existing system ART*Inference) until the mid-1990s when the development group's responsibilities ceased to focus on expert system technology.

Mostly true. The first version of CLIPS was developed in Spring of 1985 by Frank Lopez, but it wasn’t originally developed as an alternative to ART. Initially, it was developed to gain insight into the development of rule-based languages. After additional development it became apparent that CLIPS could be used as a training tool, and then later as an alternative to languages such as ART. Development on CLIPS at NASA did end in the mid-1990s, which is one of the reasons I ended up leaving NASA in 1996.

The original name of the project was NASA’s AI Language (NAIL).

Possibly or somewhat true, but also an example of why specific words need to be chosen to convey precise meaning. The source for this statement may be Frank’s website that uses the words “first proposed name” rather than “original name.” I have no doubt that NAIL was proposed as a name for the project as Frank states, but to be the original name of the project as the wikipedia article claims implies that at some point NAIL was selected, but then subsequently changed to CLIPS. Yes, this is splitting hairs, but I’m not the one who flagged the article for lack of citation.

On a different note, this is an odd bit of information to include as part of a brief description of a programming language.

CLIPS is probably the most widely used expert system tool.

Fifteen to twenty-five years ago I think you could make a reasonable argument for this claim, but today I think you could only claim that CLIPS is widely used.

On SourceForge CLIPS had around 30,000 downloads in 2014 (which could roughly be split to around half for executables and half for source code, documentation, and example programs). That places it in the top ten downloads on SourceForge for artificial intelligence software.

On the Stack Overflow question forum, there are 165 questions with the clips tags, 101 with the jess tag, and 80 with the jrules tag. On the other hand, the drools tag is associated with 1,546 questions. That makes a pretty strong argument that Drools is now more widely used than CLIPS.

CLIPS incorporates a complete object-oriented language (hence the acronym COOL) for writing expert systems.

True, although this sentence might lead one to believe that the acronym COOL stands for Complete Object-Oriented Language rather than CLIPS Object-Oriented Language.

CLIPS itself is written in C, extensions can be written in C, and CLIPS can be called from C.

True. CLIPS has also been integrated with many other languages including C++, .NET, Java, Perl, and Python.

Its user interface closely resembles that of the programming language Lisp.

True, but it could be more precisely stated that the CLIPS user interface is a read-eval-print loop.

COOL combines the programming paradigms of procedural, object oriented and logical (theorem proving) languages.

False. This sentence ignores the terminology used in the CLIPS Reference Manuals. I suppose this would be OK if you were comparing two or more languages that used different terminology for similar features, but that’s not the case here. CLIPS supports three programming paradigms: rule-based, object-oriented, and procedural. The documentation never refers to the procedural paradigm as being part of COOL and there’s no mention at all of a logical (theorem proving) paradigm.

A language with a similar approach is Planner, which also combines traits of logical languages like Prolog with the capabilities of procedural and OO-languages like C++.

Huh? How is Planner a good example of a language that takes a similar approach? Jess, JRules, and Drools are far better examples since they combine a forward chaining rule engine (much more similar to CLIPS than Prolog) with an object-oriented language.

And that’s it. No more sentences left for a thumbs up or thumbs down.

Stick a Fork in It

Longest... Beta release... Ever.

After seven long years of limbo, I finally managed to work my way through the bazillion small things that needed to be completed before officially releasing version 6.30 of CLIPS.

Whew!

The major new feature in 6.30 is performance improvements, but this marks the first release where the distribution CLIPS executables—both Windows and Mac OS X—are code signed. The warnings you get when attempting to download and run unsigned executables from the Internet are pretty intimidating, so while the signing may go unnoticed by many, I’m glad I took the time and effort to get it done.

The CLIPS documentation has gotten a facelift as well. The box headers that for some reason we thought looked good twenty years ago are gone; spacing has been adjusted to improved readability; and the diagrams and tables have been updated with a modern look.

Now to decide what’s next for CLIPS…