UnixReview.com
August 2006

Review: G2 8.2

G2 8.2 is fantastic software.

It's much different from almost any other software you've encountered, though. It's likely to feel very much like a program from a parallel universe.

And it is, after a fashion. G2 is an almost twenty-year-old product, one so far ahead of its time when introduced that it still offers unique development value. In 1986, when Gensym Corporation, the company behind G2, was founded, Lisp Machines were where real programmers camped out, Apple was beginning to sell computers with a megabyte of RAM, and Compaq first brought a 80386-based PC-compatible computer to market. As the '90s began, G2 was recognizably what it is now, a "real-time rule engine platform" (although the marketing slogan has changed through the decades). That means that it is what we now call an integrated development environment (IDE) for a general-purpose language that offers expert systems, natural-language processing, persistence methods, connections to real-world devices, impressive two-dimensional end-user graphics, and enough performance zing to monitor such systems as a NASA launch site, a nuclear power plant, a satellite communications network, a mine, or a continent-scale hydrocarbon pipeline, in real time.

It's not just when connected to "heavy metal" that G2 is useful, of course — the same algorithmic capabilities that supported real-time expert systems running chemical plants or traffic control in the '90s have been recast more recently as "business rules management systems". This decade, applications showcasing G2 and the complementary Gensym products layered over it have been in retail-facing health care, telecomm, and finance. Logistics, compliance, and customer relations are three of the most important themes in enterprise-class development now, and G2's scalability and event orientation make it a great platform for requirements that far exceed the rather wimpy security and dataflow models of conventional desktop computing.

Why haven't you heard of it before? The Gensym business model is to sell what we now call "enterprise software", something like R2, Oracle, or Vignette — programs sold to division managers through a long sales cycle as high-level solutions to expensive problems. Through most of its history, it has cost tens of thousands of U.S. dollars to start to use G2 or the products layered over it. While that's a trivial amount for a large organization making a strategic decision to improve its automation, no individual practitioner casually downloads G2 over a weekend to see how it really compares to the very different but potentially competitive software from QNX, National Instruments, ILOG, Kinesix, Genasys, or Evergreen, or other vendors.

Like all of J2EE, or .NET, or Oracle Business Intelligence Solutions, or other very large and capable systems, G2 is too big to be captured in a single review. For today, though, let's introduce a few of the program's most prominent advantages and disadvantages, and figure out what it means to you. Note this disclaimer — I write about Gensym and its products as a participant as well as an observer. For a few years in the '90s, I was an employee and/or trivially small shareholder, and I consulted with and for Gensym or its products both before and after this time. No current Phaseit contract involves Gensym, though, or any of its products, nor do any members of my family currently own Gensym securities.

Things wrong

G2 is not like other programs. Unlike many of the products UnixReview.com reviews, Gensym doesn't provide evaluation copies that are easy to download, or even publish its documentation online, except to existing customers. There isn't a well-trafficked interactive public site where developers thrash out technical issues of mutual interest, nor a conveniently archived mailing list.

G2 itself doesn't look like other programs, although the latest releases have been converging on common elements of visual display. Except when writing "foreign functions", all G2 development is done inside the G2 IDE, which has funny-looking menus, as seen in Figure 1.

Figure 1: Top menu

Notice that menus, like most G2 widgets, have a little "X" for removal from the main display. Even button clicks seem to be different from other areas of computing; Gensym documentation often writes "click" for what most of us call "right-click".

In some ways, it's just as well that G2 doesn't look like other toolkits; whereas most development environments focus on forms-oriented "office automation", G2's visual elements are much livelier and deserve to look different. By "lively" I mean that G2 visual objects often are mobile — it's easy to move them around the screen, often in coordination with other objects — and also that they pack a lot of intelligence. Visual elements can contain, inherit, or aggregate "agent"-like real-time computational ability. The snapshot in Figure 2 of a demonstration program supplied with G2 illustrates several qualities typical of applications easily built with G2:

• The graphics are sufficiently iconic that most observers immediately grasp their identities;
• The red and blue data-links to the satellite track the satellite in its orbit along the equator; and
• The satellite and ground stations all behave as autonomous actors, updating their internal states in real time.

Figure 2: Satellite

For these kinds of graphics, the usual spreadsheet-wordprocessor-email models have little to offer.

This unique graphical approach has other costs, though. A G2 application is like the "project" another IDE might support; its natural home is the IDE itself, and it doesn't "serialize" well. A G2 application image saves as a "knowledge base"— note the "KB" abbreviations in the menu above. There's no natural representation of a knowledge base as a source file, or collection of source files, in the manner of most languages. An immediate and dramatic consequence of this is that many of our most fundamental software engineering tools, including version control through incremental textual differences, are infeasible. There's no canonical support for such refactoring commonplaces as changing all instances of the name "myObject" to "genericCommunicationConnection", or reporting on all invocations of the "assessHazard" method.

It remains possible to do good software engineering with G2 knowledge bases; organizations need to understand, though, that not everything fits into the Eclipse-Rational-emacs-CVS-Unit-... mold on which they might have standardized.

I have a few other broad technical reservations about G2's support for parallelization, Unicode, and drag-and-drop, along with more arcane coding items and a few annoyances peculiar to its Web site, but the single gravest liability of the product is its vendor's finances. Gensym is in delicate health — the 10-Q it filed with the Securities and Exchange Commission in mid-May described a company with limited liquidity, vulnerable to international upset, with a long sales cycle and inconsequential backlog, and dependent on preservation of its lead both in technology and sales effectiveness. Gensym has accumulated a deficit of more than $20 million since its founding, and total stockholders' equity is evaporating rapidly. Annual revenues have fallen below $10 million.

Keep in mind that Gensym has little debt and a strong client list. G2-based applications in the field are too important to let the company's assets wither. In an extreme case, customers such as NASA, Dow, Ericsson, and so on, would surely find a way to prop up support for the company's products.

With all these problems, why would anyone still care about Gensym products? Well, G2 is not like other programs. Yes, that's the main problem with G2, but it's also its greatest virtue — G2 is highly productive, extraordinarily reliable, high in performance, and "stable". Unlike other development environments, G2 simply doesn't crash or act unreasonable. Large, complex G2-based applications typically run for months at a time, equally responsive throughout that span. As mentioned above, G2 is particularly effective for the GUI development of real-world-oriented applications that go beyond conventional office automation. If its licensing were liberal enough, we'd all be G2 programmers — not for device drivers, cron jobs, or simple CGI, but it's a very attractive platform for any development with complex algorithms or a human-machine interface (HMI).

I'm still trying to figure out how to characterize G2's performance. It's very good, but it's hard to compare to anything else you might know, because G2 does so much. Subjectively, G2 is snappy, even under adverse circumstances; most of my recent development has been on a several-year-old utility host, constantly busy with spam filtering and other backgrounds chores. That machine is a thousand miles distant from the old, under-powered, one-button Macintosh I often use as my desktop for one G2 project. Despite these handicaps, which one could reasonably expect to introduce intolerable latencies, development is comfortable in this configuration.

G2's procedural language looks as conventionally Algol-like as C or Java, despite the Gensym founders' affection for Lisp. A typical procedure has code that looks like:

	  ...
	  repeat
	      excess = remainder(the current time + 60000, 12000);
	      factor = (if h < 4000 then base + excess * 0.01 else base2);
	      f2 = factor ^ n;
	      rate = f2 / (f2 - 1);
	      conclude that xx = rate * z;
	      wait for 2 seconds;
	      for any location L
		  for any connection C
		      whenever C is connected to L ...
       

That's a hard question. Despite the pretension of many universities that "Computer Science" is ready to be taught, we're barely at the alchemical stage in comprehension of our own productivity in development of software. Anecdotally, I can report that I've heard developers say, over and over, "We could never have done this without G2." For the large projects that need the potent graphics, rule-based reasoning, real-time event detection and scheduling, and connections to the outside world in which G2 specializes, an entry price of $30,000 to $50,000 is cheap. Moreover, G2 documentation is right when it counsels,

The normal practice is to develop a design, code the design, test it and deploy. Each step requires a different environment and this lengthens the time-to-results. Integration to accommodate data sources is a show-stopper because problems don't arise until late in this cycle.

On the other hand, if your goal is a program you can imagine doing without G2, or if your GUI needs to look more conventional than G2 programs typically do, money that would otherwise go to G2 licensing fees can pay for months of project-specific development.

My conclusion is this — research whether your organization already has rights to use G2. If it does, get permission to experiment with it. If not, find a way to attend a sales seminar or course. While you might never use the product, it's excellent intellectual exercise to learn even a fraction of what this unique descendant of '80s "artificial intelligence" can do. Just as you might take classes in Lisp or Haskell to expand your computing horizons, without a definite plan to implement in either language, G2 training can at least teach you at modest expense what's possible on common hardware.

Cameron is vice president of the Phaseit, Inc., consultancy, specializing in high-reliability and high-performance applications managed by high-level languages. He co-authors a monthly column on programming called Regular Expressions.