General Problem Solver

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)
It's like XML, but you can store source code in it.
If you review the initial source-code offering (a cleaned up version of the 2007 prototype) or try the current runnable demonstrations, you may either conclude that HLL does simple things in an overly complicated manner or that it represents a good start on a grander design. It's the latter, and one of the reasons I'm writing this post is to assure you that it's not the former. But this post will end with a comment on "high level" support for a general problem solving method.

HLL has been developed in a way that makes it "open." By that I mean, you can do things with it - lots of things - even things I haven't thought of yet. That's the point. It's supposed to provide support for a broad range of applications, making them easier to build, and once the grander design level is reached in reality, more powerful than you thought your time and budget allowed. Expanding the application with increased complexity or even using your earlier work as "experts" in a larger system is going to be all the easier.

Here are some examples, and remember, you don't need to write all the code for this stuff. That's why there's HLL.

The use of an agent approach to pass messages may seem overly complicated if you're only sending "Hello World!" to another part of your application. You may wonder if you really need sockets to pass the message. If you are building to run on a local machine (Is that a lost art?), then you can set the host to "localhost" and you're fine. If you have reason to make use of more than one machine on a LAN, that works too - just set the host to a local IP address. Communicate with machines around the world - HLL is "open" to that as well - just use an IP address or host name recognizable to the outside world.

Although you can pass messages in other ways within your application code, what about the complexity of an agent's message? If you're passing messages between agent layers (actors), but your needs are simple, you can set messages up to have defaults. Your application code then only needs to specify what it needs to specify. Within the application code, it's still simple. If your need becomes more complex, the agent message standard that will be supported is "open" to allowing you to do that.

And of course, you can write as many "experts" as you wish and make them as complicated as you need - from simply command responses, to complete external systems. HLL is easy to extend into your application world.

The "Hello World!" example is a perfect case for making agent "layers" (actors) look a little silly. All three layers do something unique, but in the end, you've just typed "run" in the console (or used the browser-based GUI), to get "Hello World!" printed out. Well - if you've done much Java programming, your used to that. "Hello World!" is part of the culture - a very simple way of showing the details of how something works. Each of the agent "layers" (actors) is designed to provide a set of support functions - and (eventually) application programmers will be able to define their own actors. The basic three - executive, manager, and expert will always be supported as part of the HLL Core system (with increasing power and grace as time goes by). These three will support things that tons and tons of applications need to do and will also form the initial structure of a larger "organization." (HLL was designed by taking something from nature so to speak - then nature of human work organizations.)

The latter may not immediately seem interesting to general purpose Java programmers who tend to move around a lot. (Or maybe it does if you're entrepreneurial - read on.) Consider the fact that many companies provide software with a specialty area. I've spent enough time in more than one such company to know that various software functionality related to the company's area of specialization is sometimes repeatedly redesigned and rebuilt; something that's not supposed to happen in the age of object oriented reusable software components. Instead, you can define actors with basic capabilities commonly needed in software in that specialty area. Various products can be defined with different sets of "experts" (supported by the same actors). If you're a specialized consultant, you can do the same thing - licensing your software for resale or being paid to write new experts. If you're building something to support a company's internal operations, you can build "actors" to reflect the company organization itself. (Start by thinking about departments of operation).

Best of all - you don't need to maintain the HLL Core software yourself. Somebody else is doing that for you - keeping the technology up-to-date and making it ever more perfect. :)

There is another use of the "sufficient complexity" of HLL that I would like to mention. It's related to XML plans (on the issues list). If you've read though the old ppt presentation (available for download on the right side of this page) this should be familiar. The original HLL concept includes the idea of providing general "high level" support for problem solving. There are five steps involved:

1. Define the Problem
2. Collect Information
3. Perform Analysis
4. Identify Alternative Solutions
5. Recommend a Solution

I'm looking forward to getting the core software to the point that I can concentrate effort directly on providing "high level" support that will make it very easy for application developers to apply this particular problem solving approach.

Follow up, see blog entry: The Ghosts in My Machine: Chapter 2

.