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 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.

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.

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.

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.

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…

The Long Slow Decline of App Store Income

I didn’t expect to get rich creating an iOS app. If that were my goal I certainly wouldn’t have create a ‘to do’ list app to compete with the gazillion other ‘to do’ lists apps in the App Store.

But for a very long time I'd been making lists on scraps of paper, so when I first got my iPod Touch in September 2008 and couldn’t find a list app that I liked, I decided to make my own. If I could make a bit of extra money in the process, so much the better.

I released List! Lite in February 2010 and List!, a paid version of the app, in July 2010. Since that time, I’ve released 25 updates including new features and bug fixes. List! has 210 ratings with an average of 4.5 out of 5 stars.

There are many excellent articles worth reading on the challenges of making money on paid apps, but I can nicely summarize them with a single graph showing the monthly income I’ve made on List! between October 2010 and April 2014:



I got a large bump in income shortly after adding support for the larger screen of the iPad in June 2011, but nothing I've done since that time—new features, sales, promotions, and localization—has had any lasting effect on generating sustainable income. At best, all I've done is just slow the decline.

As a hobbyist, I have no regrets on the time I spent developing the app. I learned a number of new things, made enough money to buy some toys, and have an app that I use on a daily basis.

As a developer, I’m glad the only investment I lost was my spare time. There’s all kinds of speculations I could make, but at the end of the day I wrote an app I loved creating that just wasn’t commercially successful. I haven't written my last app, but I now have a more enlightened view of the economic realities of app development.

So if you approach a developer about an app idea that’s sure to make money and they look at you skeptically, now you know why.

Security Theater

There’s this website I have to access occasionally for work, but the account password expires after a fixed period of time (a few months).

Fair enough. For security reasons, passwords should be changed periodically. Having them expire is a straightforward method to force users to comply with this policy. You log in, receive a notification that your password has expired, enter your old password once, your new password twice, and voila, your password is changed. All that's left to do is write it down on a sticky note and affix it to the front of your monitor.

The problem I’ve had with the way passwords expire for this particular account is that there’s no indication that the password has expired. If my password doesn’t work, I have no idea whether I just mistyped my password or it’s actually expired. As a result, if I enter the previously valid password too many times, I’m locked out of the account. Again there's no indication that this has happened. Wrong password. Expired password. Too many attempts. Bzzzzt! Try again. Fail.

What a great idea: a password policy that’s completely opaque to the people forced to use it. To change your password, you actually have to visit a separate website and, of course, none of the websites where you use your password link to it.

If you haven’t figured out yet where I’m heading with this story, it’s that I’ve been locked out of this account more than once. When that happens, I have to call the help desk to have my password reset.

Given the hostile design of the login process, I half expected my reset password to be a long string of Ms and Ns, all recited to me over a bad phone connection. Sorry, for security reasons, we can’t email it to you.

Fortunately it was surprisingly user friendly, but I immediately recognized the new password as one I was given previously: the six character company name plus three sequential digits.

The new password worked on the first try, but I wasn't forced to immediately change it, so it was obviously not temporary. That seems like a big pile of security stupid, but it’s their policy, so whatever. To my credit, I immediately headed over to the site I bookmarked to change it, but that option was nowhere to be found.

So now I have a password that’s easy to remember.

Security theater, adopting an ineffective or poorly implemented policy just to have a policy is worse than no policy at all; it consumes resources that could be more effectively allocated and gives a false belief that risk has been reduced.

Put more succinctly, the only security worse than no security is false security.