Rules

Jon Udell highlights a technology lost in the late 1980's "A.I. Winter", but which kind of hung around and is now coming back into its own. I'm a veteran of the A.I. Winter and was disappointed when very practical tools like KnowledgeCraft and GoldWorks were lost in the hype of those days. Looks like GoldWorks is still available.

Some more resources to add to Jon's list...

• CLIPS - the grandparent of almost all current rules engines, public domain, written in C with good integration possibilities to other languages.
• Business Rules Applied - a very good book that covers a wide variety of issues around the management of business rules.

Facility

Phil Windley draws some good points out of the interview with Grady Booch. But, and there's always a 'but' when I read something, my philosophy is there's no point in not being a critical reader. If I end up in the worse case being wrong or mistaken, I've still learned something.

Grady Booch writes just after Phil's last quote... One of the advantages of platforms such as .NET is that they codify a lot of those hard things so that global decisions can be made intelligently, then carried out locally by the individual developers.

I think this is untrue. I don't know if Booch is trying to flatter Microsoft, or the readership of the dotNET magazine, or if he really believes this.

I wish the journalist would have pushed for more detail. Why does Grady believe this to be so? Wouldn't that answer help the readers of the interview with how they use dotNET?

For one thing, I don't believe this is true for any current toolset. I'm not singling out dotNET. There is too much complexity in software development. Yes, we're building more complex systems than in the past, but that's no excuse... we should be taking unnecessary complexity out and putting more facility in. Facile --- most software is not.

Glossy Interviews

From an interview with Grady Booch in dotNET magazine...

Q: What is the future of Web services and GXA in conjunction with traditional development?

Booch: I'm pretty jazzed with the direction of Web services. We look at organizations that are already effective at building component-based systems. Meaning they know how to componentize their stuff and deploy them that way. For them the move to Web services is actually a small step. Plus it's not a difficult step, because it represents a different packaging for the things they're already exposing. But there's value in it because now it allows them to transcend a particular platform.

I'm working with a group I think I can mention publicly: MedBiquitous, a project at Johns Hopkins led by Dr. Peter Green. The essence of the project is to try to tie together the various medical research agencies and data across a variety of different specializations in medicine, so that you break down the barriers of specialization. That's a gross simplification of what they're doing but it's pretty cool stuff. The essence of their architecture is based upon Web services, which enables them to make key architectural decisions that transcend particular platforms and technologies.

How helpful is this for you? As a reader and developer, should you expect more from an interview with an industry leader?

This seems to me to be filler in between the ads. I'm disappointed.

Tons of ideas ripe for the picking

Ray Ozzie writes...

I strongly recommend that people join the ACM and use its Digital Library and read some of the things that influenced all of us in the CSCW discipline, e.g. Turoff's early work in conferencing, Flores' work on speech acts/workflow, etc. It's never been more relevant. Now that people have realized that we need to move beyond the Web, there are tons of ideas ripe for the picking in terms of innovative architectures for interpersonal communications & cooperative work e.g. awareness & event notification architectures, real-time & replicated architectures, etc. Explore SIGGROUP papers; head down to Group '03 this fall, and blog what you hear.

This probably is obvious: I couldn't have said it better myself.

I've been a reviewer for several major conferences over the years. The striking reaction I get over and over is how few connections people make to the work that has taken place in our community. Software is forever changing on the surface, but when you get more than skin deep, there are so many common themes, sources of inspiration, and even words of caution.

Meanwhile, what to do?

Jon Udell writes...

In an earlier posting, I characterized one axis of the debate as robustness versus agility, and wondered how we can have our cake and eat it too. Sam Ruby pointed to WS-Transaction, to which Patrick Logan replied "I think we need a rethinking of databases, messages, and coordination." I'm sure that's true. Meanwhile, what to do?

Exactly the right question to ask. Here is the kernel of my response.

1. Design collaborative business processes with partners (internal or external) for exchanging (secured) XML documents independent of connection technology.
2. Emphasize exception processing and failure recovery in those designs. Again independent of connection technology.
3. Apply the simplest technology that could possibly work for connecting and exchanging those documents. Keep the documents independent of the connection technology.
4. Apply the simples technology, or whatever you have available, for processing those documents internally. Keep this technology independent of the connection technology and keep the documents independent of this internal technology. (i.e. your partner should not know or care that you are using MySQL, J2EE, dotNET, Python, etc.)

Something further. Consider passing documents using the following grammar in an XML namespace as a header to the exchanged document.

• "put document D in shared space S with time to live T"
• "take one document matching pattern P from shared space S or return special document N if no match"
• "peek at shared space S for all documents matching pattern P and return copies of those documents or special document N if no match"
• "put copy of document D in space S1 (local) when D is added to space S2 and D matches pattern P"

Metaphor Computer Systems

Peter Nolan writes about Metaphor Computer Systems from the listserv at datawarehousing.com. If you have information about this company or its products you can add that to a wiki page at MetaphorComputingSystems. Endorsements for simple systems like this should be an inspiration to developers. I'm not sure if Meta5 is all or a subset of the original product.

If I said M3 it was a typo...Metaphor Computer Systems (M4) was founded in the early 80s (might have been 1982) and released a product called Data Interpretation System (DIS) in 1984 if my memory serves correctly. Ralph Kimball was one of the co-founders.

I'm not sure there are many places where 'the history of Metaphor' is documented. I wish there was, it was quite a company. In 1997 I got the opportunity to personally say thanks to Ralph for his part in M4 because it changed the direction I was heading in.

In 1991 I had one of those 'ah-ha' moments when I saw DIS demonstrated to a customer of mine. As I watched it took about 5 minutes to realise that what I was seeing was the way end user computing was 'meant to be'. I was completely 'sold' on DIS as 'the way' data analysis/analytical applications would be built in the future. So was the customer. They bought the product.

In another one of those industry 'if-onlys'. If only IBM knew what they had it could have been the office desktop we all use today. (IBM bought Metaphor in 1988. So in 1988 IBM owned an 'office desktop' far superior to MS Office which would not exist for a few years yet. Instead of pushing DIS they pushed Office Vision, which died.)

The list of features in DIS was endless. The folks at M4 broke so much new ground. They had some 400+ customers by 1993 and their customers were household names.

I wish there were some demos or screen shots still around to explain to people what it could do.

The most important thing about DIS was that the IT staff were no longer required to develop analytical applications. The biggest benefit of this was that the business users did not need to 'externalise' or 'communicate' their requirements to anyone. Working on the DIS desktop they could try out their ideas and if they turned out to be good they could be 'packaged' into an analytical app. Yes, I am talking 1986 here. And, as per my previous comment, the 'intellectual capital' of the analyst to who created the application was captured with the application to a very significant extent because any other business analyst could read it. They barely needed any training to be able to read even a quite complex application.

One time an actuary customer of mine borrowed the manuals and from scratch, with no training and no help from anyone else, wrote a 30 year death experience analysis application in 3 weeks. It was that easy and that good to use DIS.

DIS was 'so cool' you didn't even need a keyboard. We used to put out keyboards on top of the screens and they would stay there for weeks on end. Try writing an analytical app today without a keyboard!!!!

Unfortunately, at the time IBM bought Metaphor the future of the world was PS/2, OS/2, MicroChannel, 8514A graphics adapters and Token Ring (at least according to IBM). When moving the software from proprietary to IBM hardware, IBM specified ONLY IBM hardware. There were a lot of other reasons why Metaphor experienced trouble operating inside IBM. (They were not the only ones, who remembers 'Rolm' telephones today?)

DIS was all 32 bit and it was the first fully 32 bit app that was released on OS/2, but OS/2 was 'doomed' and by the time windows 95 came out the opportunity to get DIS out into the marketplace had pretty much gone away and MS Office had a stranglehold on the windows 3.1 desktop.

Eventually the product was stabilised and then finally withdrawn from marketing. I think that was around 1997/8.

But there are many of us out there who look at what we could do then and what we can do today and wonder how it can be that there is so much that is still so hard to do now that was so easy then. Call me nostaligic!!! ;-)

EJB and CORBA

From Jon Udell's item on J2EE/EJB...

You need your business logic available to multiple applications. What if those other applications aren't Java-based?

EJB is designed for CORBA clients.

The problems include, though, firewalls and interop. Unfortunately just as CORBA was rounding third and heading toward home on those issues as well as the price/performance issue, SOAP became a monkeywrench. Too bad really that CORBA could not have been the foundation of an "Enterprise SOAP" that evolved toward some of the flavor of XML messaging.

Also, CORBA 3.0 incorporates its own "Component Model", an improved EJB model that is language neutral. Maybe too little, too late.

Web Services Architecture Usage Scenarios

I just stumbled upon these WS usage scenarios. I've not seen them before, and have read through only a couple of the discussion messages. (Someone probably pointed me to this list some time ago. I "stumble upon" things this way now and again.)

Apropos to my interests, the latest message in the discussion is "REST, uniformity and semantics". Actually REST shows up about every 10-20 messages. When I am awake tomorrow I'll wonder if the conversation ever goes anywhere, and what else is discussed.

More Inflection Points: RAM-based Databases

From the thoughts of Monty Widenius (MySQL)... What I am looking forward to is diskless computers, a little similar to PDAs today, but with much better capacity. Hard disks will be used more as very large backup devices for things that you don't need regularly.

Gemstone's largest customers usually had their entire OODB running on very large systems with the entire database in RAM via copy-on-write shared pages.

Battery-backed RAM would be an incredible boost to performance and simplification to implementing ACID transactions. The other big win for large memory databases is to distinguish read-only data, where you could get rid of most semaphores as well. That's not done enough today.

For habit's sake we insist on running OLAP from OLTP systems designed 20-30 years ago. Newer designs can fit far more RO data in RAM too.

(This is a good time to be a computer scientist. Lots of change over the next five years.)

Wiki and User Identity

Dave Winer believes...

[U]nless I'm mistaken, [Wikis] don't have a concept of user identity...

Some do. Some don't. Sometimes it's an admin option.

Scaling Tuple Spaces

One of the masters of simplicity in software, Graham Glass, writes...

another awesome bit of software technology is Linda, the tuple spaces architecture by David Gelernter. like Lisp, it provides a simple set of primitives with great expressive power. but i don't think that the Linda approach scales well. the remove() primitive requires some degree of locking that is not suited for distributed environments.

Voyager itself was a simple and awesome software technology. Congratulations to Graham for that as well as Glue and the upcoming Gaia. I'd be interested in his thoughts on Linda-like systems for the Internet.

The most significant adjustment in scaling Linda to the Internet that comes to my mind is to redefine blocking operations to be non-blocking. So 'in' (i.e. remove) would not block until a match is found. Maybe there would be a timeout, but the window would be fairly short and so may just be meaningless at Internet scale.

For these non-blocking polling operations, some rationale has to be assigned to an ethernet-like (but larger distance and time scale) backoff policy. Not unlike the RSS situation with polling. But the surprise with Ethernet is that the pipes continue to get faster and conflicts are not the problem people envisioned.

The alternative is to use a cloud-like mechanism for scalable trigger/notification. Eric Hanson has been designing these for relational databases at UFL.

Another aspect of this is the number of simultaneous users of a single tuple space. Scaling out a tuple space is fairly simple... create more spaces. Work has been done to replicate spaces, but in general I'd look for opportunities to simply partition scenarios and participants across distinct spaces. That must be the 80 percent or greater situation at least.

Reliability of messaging would have to take into account that the connection itself does not (and probably should not) implement guaranteed delivery of just one copy of the message. This is where some wisdom has to go into message design and higher-level domain-specific protocols. Less of an issue as the Internet evolves into its next incarnation, but this is the simplest approach for the next N years.

You can add your thoughts to the TupleSpaceScalability wiki page.

R-E-S-P-E-C-T

Sam Ruby writes, referring to the original Smalltalk refactoring browser...

[The] key question in my mind is not when such things converge in the laboratory, but when will such things converge in the mainstream?

I know it's a relatively small market, but Lisp and Smalltalk have been out of the lab for years. IBM's direction before Sun's introduction of Java was clearly aimed at Smalltalk and they were having a good deal of success with it.

There is no doubt that the Smalltalk refactoring browser was first. (Reading Martin Fowler's book will back the claim.)

But when the RB came out, it was aimed at, used, and ultimately made the de facto choice for commercial Smalltalk development.

One Function to a Function

A great site for Lisp programmers and other sorts. Not just Lisp-specific wisdom, from Chris Riesbeck's programming notes, via Kevin Rosenberg's blog, via Lemonodor.

Smalltalk, Lisp, and syntax extension

From James' Cincom Smalltalk blog...

While Smalltalk doesn't have the macro system Lisp has, generics are a non-issue in ST, as is boxing/unboxing. Ditto the "simplification" things. One could summarize this whole thing as adding complexity to a language to make up for the glaring flaws.

While Smalltalk doesn't have syntax macros like Lisp, Smalltalk *does* have simpler block syntax and keyword arguments.

The effect is that new keyword messages can take block closures, which essentially delay evaluation until the method behind the message decides to evaluate them, and the message send looks an awful lot like new syntax, very clean.

Many uses of macros in Lisp, frankly, are simply created to hide the appearance of the lambda keyword. Of course there are more "legitimate" uses of macros, but these are less common.

So Smalltalk and Lisp are fairly evenly weighted in the syntax category in my book.

Ruby is pretty close, too, but has some wierd quirks where they didn't get closures quite right and very bad silent mistakes can be made. Python is further back in this category.

Straightjackets

Phil Windley on dynamic typing...

A strongly typed language merely creates an environment so that the type-checker can automatically check the type constraints for you at the cost of restricting some genuinely useful things you might want to do.

One thing you want to do that is easier with dynamically type checking is testing. Only time spent developing significant systems in dynamic languages will bear this out. Illustrations don't capture the reality.

People see that static types can catch things early. They don't see that those things aren't important since they get caught early in dynamic tests anyway. Yes, you have to write good tests. Can anyone tell me when that's not the case?

Neither is it apparent on paper that refactoring large systems, or just experimenting with large systems, goes much more quickly when you have to change less code to get a small test to run. You trust that the complete set of tests will catch everything else when the experiment is ready to be integrated back into a complete working system.

But during spike experiments you want to ignore the irrelevent, create mock objects, even entire "mock databases", and play what if on isolated bits of code, even within large currently running systems. Doesn't happen easily in Java-like languages. Compilers that have no clue of what you really care about in the moment. They make you dot that 'i' over there and cross this 't' over here before you can even get to the bits of interest.

Learn from this, like this

However, I think that it makes the student's choice crystal clear: become a computer scientist, not just a programmer, because if the IT locomotive does decide next year that some new thing is better, you'd better be as adaptable or you'll get left in the dust.

You want to learn computer science, or anything really, from people with advice like this. You may end up even contributing to the next new thing.

So what?

Stefan Tilkov writes about me...

Patrick Logan has a blog. So what?

Exactly.

Oh, he continues...

Apart from some very interesting posts, I somehow recall the name, and have positive assocations with it ... digging ... I found a patricklogan@gemstone.com

Well, thanks. Gemstone went through an upheaval at the tail end of the dot com fiasco. I left before the implosion...

"In less than a year, a 20-year-old [sic] company, with revenues and profits, (though not brilliant, it was a going concern), has been destroyed by another company that is itself only a few years old. That is sad."

Industry Standards and Emergence

So I am wondering how much should be put into specifications and what should be left for emergence?

I have had bad experiences participating in the market-driven rush to unproven and premature standardization. So I lean toward the minimal necessary and look for patterns and principles to emerge from experience.

Systems from the future

Giulio Piancastelli is very kind and also on the money speculating...

I quoted Patrick's words because I think they are the most original and interesting from the whole bunch. I see Prolog and tuple centers in them, and I am glad for what I see.

Nice connection and thanks for the references to these projects. Indeed I think the future is bright for logic/constraint languages and coordination through blackboard/tuplespace architectures.

Speculating: the Network is not the Computer

There is nothing like a controversial statement to draw attention to an issue, or at least traffic to a little-known blog.

Apparently, Patrick took a peek at WS-Transaction, didn't get any further than the author list and decided it wasn't any good. I agree that two phase commit is traditional... I hold out more hope for compensating transactions via asynchronous messages.

I did read further than the list of authors. But nothing like a controversial statement to get people interested in a topic.

I do think the compensating approach is better than the atomic approach at the distributed business level of "transaction". But I am not sure either should be a part of the connection architecture. Compensation "meta-data" if you will should be a part of the documents exchanged among business partners, no matter how those documents are exchanged.

A distributed system across trust boundaries is where I believe we are collectively heading. The internet shows us the beginnings of what is possible... for the subset of things that are generally always online and publically accessible. Expanding this to mobile and access controlled is the next big thing.

NeuroTransmitters

I love the NeuroTransmitters story. But Sean McGrath illustrates the problems that emerge when you overload your connection architecture over time.

The network is not the computer. My computer is over here and yours is over there. All we need is a simple way to exchange documents.

The documents are the messages. The computers are the cells. (Fortresses in Roger Session's metaphor.)

The connections should be as simple as possible and get out of the way.