knowledge representation and reasoning

The world needs that in every aspect of the day to day.

WIth the three tech deaths within weeks of each other (Jobs, Ritchie, this dude) we should start a tech pool of who’s gonna be next. I’ll go with Steve Ballmer, going either of a heart attack while yelling “Developers developers developers developers developers developers” at WinHEC, or by assassination (probably by a MS share holder, or Bill Gates).

I had a little story to go with this item: I really didn’t think you folks would know or care much about basically just another geek. But every time I came to the end of my rant, I’d fu--mess things up by hitting the wrong key somehow, and no matter what browser gymnastics I tried could I get it back. Following is a very bad, clumsy version of that which I wrote with style, panache and humor.

-
Why post this? Well, AI was one of my main interests in computing—it seemed the most open to creative thinking and problem solving than other areas. Anyone can write a payroll system in COBOL, so when that’s your assignment it’s damn dull. (See footnote one.)

Remember we are going back 20+ years now, when I was a teenager, filled with spunk (See footnote two.) and vinegar; liberally smeared with acne and had most of my brain cells intact.

So on my little Apricot computer, I was playing with, in particular, Expert Systems. In articular, bit-mapped data stores for these. In a bit mapped store, there are only two states: yes and no. While much of AI work was based around fuzzies, I found this to be cleaner. [cont.]

For example, the results of any query were always definitive: so you could be a having a problem logging in or not: there is no grey area and you can immediately discard the relative data set based on that one item and continue with questions about logging in (if that were the issue), or not. Taken further, this idea allowed the system to pick the next best question to ask (as in, the question which would most delineate the data set)—the algorithm I came up with for this was pretty cool: given answer A, run through the data and see what next question would be most effective in refining the data set. Rinse and repeat until you have an answer (if one exists) or at least a recommendation (go ask a human).

As an interesting (maybe) side note, I also tried just using a random number generator to pick subsequent questions: it’s results came very close to my method, which kinda surprised me.

All of this was written in GW-BASIC (Gee Whiz BASIC), because that was the only language available, (See footnote three.) and the code was pretty messy.

Anyway, I’ve done three years of computer science at this point, so I can do COBOL, ForTran and Pascal with relative ease. The first two bored the living shit out of me, but at least were better than the calculus lessons where we were dealing with all that i and j stuff that only exists in the imagination.

After surviving my third year of hard math (including my lowest ever exam score: 3%—I guess I wrote my name correctly) we were placed in industry for a year. As no would be employer wanted a guy who looked like his head would explode from pus at any second, I was one of the runts who the placement teacher had to beg the University’s last hope to take: IBM, Greenock Facility.

By sheer luck, I was assigned to the “Information Center”—basically help desk, software testing, a little coding, and odd visits from an old guy who was always smoking a stogie and putting ash in my keyboard. Asshole.

(We’ll get to the part about LISP soon, promise.)

The IBM set-up was old skool: two mainframes (3080’s?) serving around 3,000 users; one miniframe for development, and semi-smart terminals (3270’s). PC’s were rare: an odd thing to my mind as the production line at the site was spitting out PS/2’s en mass. (Personal System/2, not PlayStation 2’s.) And most of the PC’s just had an emulation card that turned them into the same semi-smart terminals. Kinda bizarre.

Everyone in the Information Center had one topic they were supposed to know in depth: for the intern (me) this was REXX - (REstructured eXtended eXecutor) and XEDIT. It took me a while to understand these two languages/applications and how to use them well. REXX can be compared to Perl, for any web-heads out there.

Being interpreted (the computer reads your code and executes it) rather than compiled (your code is translated into static machine code for execution) plus the ability to work through all the layers (XEDIT, REXX, VM/CMS, machine code) within one program made for some fun.

For example, you could write a program that, as it ran, created it’s own new code, This capability was used either when it was a really smart thing to do, or if you wanted to show off and/or obfuscate your code. Within six months, I could make that shit sing and dance, and I loved it.

Around the six month mark, we were approached by an employee from another department who needed assistance with a new software product: Application System/Expert System. As everyone else was “too busy” (yeah, sure) I was the fresh meat thrown into this project—the goal being an Expert System which would be able to answer 50% of Help Desk calls.

(Taking a break to breath and eat, will continue later, LISP will be brought up, promise.)

Ever get into a flow then get interrupted and have a hard time getting back into it?

Finish tomorrow.

It’s this type of meandering bullshit that no-one cares about that blogs are made for, no?

Or I could tweet it, sentence by sentence…

(Back from break.)

At this point in time AS/ES (or “asses” as I liked to say) was still being built, and we were working with beta versions that rolled and shambled like a sailor leaving a bar. AS/ES didn’t use any of the existing AI languages, because this was IBM damn-it, and if we didn’t invent it it wasn’t worth shit.

The breakdown of tasks was supposed to be other guy (whose name I forget) would do the programming, I’d be the “Expert”. I was to allocate a couple of days per week working with OG. I think it was week three before he stopped showing up.

Despite not having a final, stable product IBM did have a mass of documentation on AS/ES: six to eight big ring-bound binders of stuff that had “Finish later.” or “NER” (needs editorial review) or “This page intentionally left blank” pages with text on them…

AS/ES was based pretty much directly opposite to my bitmap systems: everything had a variability or fuzzyness to it. The basic idea seemed to be collect lots of fuzz, squeeze together and you get something solid. Of course all you got (with a probability of 95%) was just a compressed ball of useless fuzz.

I took to working on AS/ES just as time allowed between help desk calls. One US guy (probably another student) was working on a similar system, with such great routines as “Can you see anything on the screen?”, “Are the keys you are pressing showing up on screen?”. I contacted him and yes, he was taking the piss.

One of my better decisions was to cut the brief drastically: since any human help desk person could answer 70 to 80% of common calls effortlessly, I decided to target the more exotic things that came up—like linking a visitor from some other country through the spiderweb of communications hubs to get to their home page; or solving issues with printer spools that had gone tits-up. So instead of replacing a help desk person, this would be a tool for them to answer the kinda common but kinda complex questions that came up.

The end result? Not really something I was proud of. AS/ES was super-slow, and couldn’t run from a “standard” user account (needed 4MB of VM to itself!), and the underlying goal had changed so much over time it was impossible to define what the underlying engine was trying to do. But it did work. For the two scenarios above, it became the tool of choice: I made changes to make it faster to get to the guts of the thing based on an Expert User rather than an idiot user.

Anyhoo: back to college, and in our fourth year we learn about Databases and AI! Wow! The AI lectures take place in a church across the street from the campus for space reasons. The lecturer is a long stream piss of as guy with a whisper for a voice: even from the pulpit he couldn’t make himself heard.

And he wanted to teach us ProLog. More specifically, he wanted to teach us how to write natural language parsers in ProLog. Anyone who has played an old adventure game knows what this is like: user types a sentence in English, you figure out the objects, verbs, etc. and act upon them or report back that “I can’t !@#$ so-and-so in the !@# with the lead pipe!”

There’s nothing wrong with parsers. And they do get complex. But in AI terms it was like looking at a leaf to see what a forest looked like. I made a good enemy out of the lecturer by pointing this out to him (usually after a few tequilas at the student union).

One day though he excites us with something new! Not ProLog! LISP! We were going to spend exactly 4 hours looking at this language (we devoted the same amount of time to this language called “C” that no-one ever uses).

It’s difficult to convey just how messed up LISP is, but for any programmer types here are some snippets from Wikipedia:

Evaluate a number’s factorial:
(defun factorial (n)
(if (<= n 1)
1
(* n (factorial (- n 1)))))

An alternative implementation, often faster than the previous version if the Lisp system has tail recursion optimization:
(defun factorial (n &optional (acc 1))
(if (<= n 1)
acc
(factorial (- n 1) (* acc n))))

Contrast with an iterative version which uses Common Lisp’s loop macro:
(defun factorial (n)
(loop for i from 1 to n
for fac = 1 then (* fac i)
finally (return fac)))

The following function reverses a list. (Lisp’s built-in reverse function does the same thing.)
(defun -reverse (list)
(let ((return-value ‘()))
(dolist (e list) (push e return-value))
return-value))

I mean, WTF is that bullshit? How do you debug it? How do you even know what’s supposed to be going on? And look at all those fucking (((((( )))) )) ) things. Miss one of those and you are screwed, and yes, it may be many pages of code between the opening ( and the closing one.

I looked at LISP and saw what seemed to be the AI world’s equivalent of “C”: human unreadable, clearly designed for a machine to understand, not a programmer, and not at all self documenting. In effect it was Write Only Code: only the original author could understand it, and maintaining was possible but really, really painful. But I couldn’t quite figure out why LISP was so bad: “C” has the excuse that it’s just warmed over PDP-11 assembly code; LISP had no similar hardware-made-just-for-it equivalent. The best result I could find was that LISP was written to be totally abstract and was designed to be run on a LISP machine.

Madness.

Thankfully we were not tested on LISP, just writing parsers in ProLog. So I got by.

Years later, a visitor introduced me to a new computer language which would make all others obsolete: DyLan (Dynamic Language). Dylan (see whatever footnote is next) made sense: it was interpreted, fully object oriented, modular, extensible and human readable. The one part that initially bugged me was the scripting framework it was based on: Macintosh Common Lisp. And BTW putting “Macintosh” in front of “LISP” did nothing to make LISP better: but at least now it was just a traffic director, moving data between procedures. Nothing wild-ass-crazy.

Dylan, like REXX, was really cool to write with. It took some figuring out, but once it clicked it clicked. It was perfect for the new paradigm of event loop programming (PC’s running Windows or Mac OS where the execution is user controlled, not linear.)

And then the web came along, and suddenly everything was changed. Dylan’s major backer was having financial issues and wondering why they were spending R&D money to develop a new computer language…

And that’s why I posted about that old guy who invented LISP dying. Thank you for your time and attention!