Those were the days – part 8

So far, this blog post series was mainly focused on IBM products for IBM PC. We covered Macro Assembler, Pascal, Fortran, COBOL, APL, Logo and BASIC. I’ve tried to cover them in chronological order, and my initial intention was to write next about IBM C Compiler 1.00 released in 1985. However, I changed my plan and decided to skip it. While Fortran, COBOL and APL were fun and new to me, and I love Logo and I always will, the rest of the gang are mildly boring. I’m trying to get a glimpse of what was considered professional programming in the early 1980s, share my experience working with those products, and perhaps revisit a few old memories. And in case of (any) C compiler I don’t think there something to write about. I’ve worked with some more “exotic” C compilers like Fujitsu C compiler for embedded/telecommunications/etc. and they all feel dull and ordinary. As they should be.

So, I’ve decided to explore some OPS5 language implementations for IBM PC. I knew about OPS5 the same way I knew about albino deer. Let’s read the first sentence from Wikipedia

OPS5 is a rule-based or production system computer language, notable as the first such language to be used in a successful expert system, the R1/XCON system used to configure VAX computers.

The OPS (Official Production System) family was developed in the late 1970s by Charles Forgy when AI was all the rage. Let’s talk about the elephant in the room – expert systems. Nowadays, those words often have negative connotations. While I think the bad reputation is over exaggerated, I tend to agree with the following pain points.

The “Knowledge Acquisition Bottleneck”

Building an expert system in OPS5 required human engineers to interview industry specialists and manually translate their thoughts into rigorous “if-then” rules. This process proved incredibly slow, expensive, and fragile. Human experts often struggle to articulate their subconscious intuition into exact code, creating a major obstacle to developing and expanding these systems.

High Maintenance and System “Brittleness”

As an OPS5 codebase grew to thousands of rules, it became unmanageable. Because rules in a production system interact globally through Working Memory rather than structured functions, adding a single new rule could trigger unexpected, seemingly chaotic chain reactions across the entire system. Testing and debugging these hidden interactions made updating old software a logistical nightmare.

These two problems are not specific to expert systems but are more pronounced in them. OPS5 is just a tool used to solve problems. Lately, I have been observing these two problems in the project I work on, and that project has nothing to do with OPS5. All I’m saying is A) human experts still struggle to pass their knowledge and B) having a large global state is as problematic now as before.

But let’s step back and have a broader view. Also, some historical context will help us to understand the roots of the above-mentioned problems. Also, note that I am not a historian, neither I can describe in full and correctness that part of computing history. I will present my angle of it and I will try not to digress (too much) from the topic of this post. In the early years of the 20th century some people thought that the world can be described mathematically. Every change in it can be described as symbolic transformation/calculation. Nowadays, many consider that the first (rule-based) production system was proposed by Emil Leon Post. The current world state is symbolically described, and there is a set of rules that describe how symbols may be transformed into symbols. This formed some of the early understandings about human problem-solving behavior and artificial intelligence.

So, OPS5 is based on these concepts.

• a collection of facts about the world, stored in Working Memory
• a set of rules, stored in Production Memory. Each rule has a left-hand side (LHS) and a right-hand side (RHS). The LHS describes the conditions that trigger the RHS, which describes the actions (symbolic transformations) applied on the Working Memory Elements.
• Inference Engine that runs in recognise-act cycle (match, resolve, act, repeat)

Let’s read again the OPS5 description from Wikipedia and focus our attention on the word successful. Obviously, we’ve found that production systems are a good solution for some class of problems. Also, we’ve found the challenges and limitations of production systems. The world is messy and chaotic. Often, we don’t have the skills and the capabilities to capture its state and to express it symbolically or the rules by which the world moves. Hence, the shift from symbolic AI to machine learning, deep learning, etc. Today, most of rule-based management systems (RBMS) morphed in business rule management system (BRMS) and the core of this is the emphasis on the “high-level” business rules and decision logic. They are often represented as decision tables, decision models, decision trees, etc. rather than “low-level” fact rules. When it comes to domains like regulations, policies, etc., the legacy of RBMS is irreplaceable. You don’t want different outcomes (statistical approach) when you fill your tax form or follow medical/security protocol.

So, with that being said let’s get into our, somewhat contrived, OPS5 example. Let’s pretend you work for a small financial company that provides loans in 1980s. AI and RBMS are all the rage. You have to optimize the profits and want to know/predict, within some acceptable error, if an applicant will repay the loan or will default. So, you ask a domain expert and they, being an expert, have access to statistical data. The expert, being a human, will probably not use all data attributes, like marital status, education, etc. and will likely focus on age, income, loan amount, interest rate, etc. This is their expertise. At the end the expert comes with a set of handfuls “if-then” rules and you translate them into 100 lines OPS5 program. Nowadays, every junior ML developer will use XGBoost algorithm and they will be (generally) right. In the beginning of the paragraph, I’ve stated that this is somewhat contrived example. Well, yes and no. Yes, because if you compare (default, naive scikit-learn) ROC AUC for XGBoost 0.757 and ROC AUC for 4-levels decision tree 0.709, you will get ~5% difference which many consider good. No, because it is only a 4-levels decision tree which is exactly where human expertise comes.

This was a small, contained problem which required a very small set of rules. Depending on your business needs, this problem may not grow and become more complex with time. Then a RBMS like OPS5 seems justified. On the other hand, if you are in a competing business environment, those 5% “loss” may be critical.

Anyway, even though RBMS fell out of fashion for good reasons, they were an important step towards modern AI understanding. Sometimes they were successful solutions, but more often they were not. In the end, OPS5 and its peers didn’t truly disappear; their DNA simply evolved to help us build better tools.