Ziff Davis Interactive, Liberty BASIC, and Bill Gates

Robert Gerami, a close friend of mine worked for Ziff Davis (the owner of PC Magazine) in Cambridge, Massachusetts.  He was in charge of their free downloadable utilities.  They were particularly well known for their whimsical screensavers, including one where a cartoon of Bill Gates would smash your Windows 3 desktop to reveal a shiny new Windows 95 desktop which would then be eaten by bugs before your eyes.

Robert liked what he saw in Liberty BASIC and decided to offer me a chance to have it featured on their web site as a special edition.  But, before he was willing to do this he want it to support making API calls.

The best part of this arrangement was that Ziff Davis would pay me to do the development, and that the resulting work would still be owned by me.

This is one of the important features of what became Liberty BASIC v2.0.  This was promoted by Ziff Davis Interactive on their website for several years.

DOOM and the raiders of the lost hours

My first PC compatible computer ran DOS and Windows, and OS/2 and... DOOM.

In between rounds of development work on Liberty BASIC I would take breaks playing DOOM.  By today's standards this is a crude looking game, but back then it was really groundbreaking.  Playing it in a dark room was a good way to scare yourself half to death.  Today I would surely consider it rather tame.  The only thing that really compared to it was a game called Ultima Underworld which was actually a smoother and more detailed real-time 3D game.

In the world of PC gaming it really was all DOS.  Running Windows or OS/2 sucked up too many resources from what was typically a 33MHz 80486 computer.  The game would not play well.  Even when running DOS you needed to use HIMEM and play all the tricks in the book for there to be enough memory.

Other games that wasted my time included Falcon 3.0 which is probably the perfect air combat simulator and a cool game called Theatre of War which was sort of a real time version of Chess, kinda.

When a bad sector error is not a drive problem

When I was working on my book for NRI Schools I was having a lot of bad sector errors and cross linked sector errors on my computer.  Stuff like that.  Every day.

I even continued to get these after I upgraded my hard drive so I began to smell a rat.  My 32MB of RAM tested good so it wasn't that.  If the processor cache RAM was bad this should also cause the main RAM test to fail, unless the algorithm for the memory test is too naive.  I decided to replace the cache RAM chips on my motherboard anyways.  I think this was 128K of chips in eight sockets on my motherboard.  I don't remember how much this was, but I don't think it was very expensive.

I'm sure I got the RAM chips from Metrowest Computers in Framingham, Massachusetts because that's where I bought the computer from.  I tore the machine down.  I was very careful not to static out anything.  Inserting those little DIP chips with their little legs requires some care or they get bent!

Got it all back together and crossed my fingers as I booted it up successfully.  :-)

I never got another sector error.  Mission accomplished.

Murphy's Law of book publishing

Once the book was all proofed and the camera ready art produced, and once I had the color separation for the cover all produced I was ready to order the first run of books which was approximately 1000 copies.

NRI Schools sent me a check in advance for these books.  How can you beat that?  So I sent everything off to Whitehall Publishing and waited nervously.

A couple of weeks later several heavy boxes arrived.  So exciting!

I cracked open one of the boxes and grabbed one of the fresh books.  What a neat thing to hold the result of so much work in my hands.  This really looked just like a book that you would buy at the store.

And then... I opened the book to the first page and my heart sank.  The very page had a spelling mistake.  I misspelled the word congratulations.  :-/

It read Congradulations.   What?  How could I miss that?

Ah well, it was still a great day!  :-)

Liberty BASIC book preproduction

In addition to actually writing the Liberty BASIC book which involved developing the tutorial examples and explaining them, creating a quiz for each chapter, developing and proofreading each chapter, etc. There was the matter of producing camera ready pages.  They needed to be a certain size and they wanted crop marks on the pages.

NRI Schools also wanted a full color color, which I really didn't know how to create.  A friend of mine named Robert Gerami actually helped me with the graphic, and he even added a funny cartoon to the back of the book.  The cartoon was of a building with a sign saying "Programming School" and there was a hot dog stand outside the building.  A character with a fishing rod up on the second floor was trying to snatch a hot dog from the vendor's stand with his fish hook!  It was a humorous way to polish off the book's cover design.

There was a local company that created the acetate color separations for the cover, and all this went off to a company called Whitehall Publishing.  They charged me approximately $6 for each copy of the book when ordered in 1,000 or more.

All I needed to do now was write the check and wait...

Writing a book was more than I bargained for

I really had no idea how much work this was going to be.  I had good starting material with the Liberty BASIC tutorial, which had actually been fashioned into a spiral bound book which I produced at the local Staples store, but this had to be more polished.

I had no serious word processing software.  This meant that I needed to use the Write application that came with Microsoft Windows.  The only strengths that this provided was that it was essentially free, it was easy to understand and didn't burden me with any strange gotchas that full blown word processors often do, and it allowed page footers.

This was hard work.  The process was to produce a draft of a chapter, print it out and then I would lay down on the carpet with a pencil and read it, marking it up as I went.  Then I would go back and enter in all my changes and repeat the process several times until that chapter seemed good enough for the book.

This took weeks.  By the time I was done, I was determined to never, ever do it again.  Of course this didn't end up being my last book.  :-/

NRI Schools and my first book

About this time I received a phone call from someone at NRI Schools, McGraw-Hill Continuing Education Center which was a popular adult education company.  They told me that they were developing a new computer programming course and they wanted to base it on Liberty BASIC.  Wow!

Here's what they wanted to do.  They would write their own course, which would be a staple bound series of books that they would distribute to their students.  They also wanted an actual official Liberty BASIC manual from me for which they would prepay me.

This was to be a perfect bound book with a full color cover.  I had never done such a thing before, so I had a lot to learn.  It was very helpful that they were willing to prepay for the first 1000 copies of the book because otherwise I was not going to be able to bankroll this project.

I decided that the book would be based on the tutorial that came with Liberty BASIC.

This was going to be a lot of work, but it was very exciting!

Bugs Bunny and Raytheon

When we were well along in our project for the Defense Nuclear Agency, a couple of developers from our team were chosen to go to Albuquerque, New Mexico to field test the system.  Part of the system was designed to help provide security by means of motion detection in the desert.

To make this happen we needed to build a custom computer that ran OS/2..  This PC included hardware which could interface with motion detection cameras in order to log motion detection events which included video frames showing what the motion was.  So we were all excited to know that our system was going to take pictures of tumbleweeds and Bugs Bunny in the desert wasteland.  ;-)

Most of the assembly of this custom hardware was done at the Wyman Street, Waltham IBM office where we worked, but Raytheon in Burlington, Mass was responsible for the final integration and shipment to the test grounds in Albuquerque.

So, off to Burlington we went with server in tow.  When you visit Raytheon you have to go in the front door and sign in, and you have to have an appointment with someone who will meet you at the door.  So one of my colleagues and I followed this procedure and found one of our other teammates working on the machine, trying to get OS/2 to start up and load all the drivers properly, but he was having some trouble.

Then a couple other members of our team showed up, but they were unescorted.  So they were asked how they got into the building.  They said rather innocently that they parked in back and as they approached the back door someone came out.  That person held the door for them and they got in without signing in at the front desk!  Uh, oh!  Who was it that let them in?  They didn't know this person, and presumably he went for a walk for took off in his car, so it wasn't going to be easy to figure this out.  They didn't know they were breaking security protocol.  Okay so they went to sign in.

Now we turned out attention to the server again.  We were trying to figure out how to get all the drivers working and we were having some trouble.  This fellow with a clipboard came to us and said that he needed to pack up the computer and put it on the truck to ship it to Albuquerque.  We told him that it wasn't ready, and he walked off.  Some time later he came back again and we told him it still wasn't ready.  Finally he returned and said, "Okay let's ship this thing.  I've got to check this off my list!"  We game him a sharp look and told him firmly "Look buddy, this machine isn't going anywhere until it works.  We will tell you when it's ready."  He did not like this at all, but we really couldn't have cared less.

I guess he thought a non-working computer was good enough for government work.

How to make a RAID array failsafe

The computer that we used to manage the source code for our Defense Nuclear Agency prototype was an IBM System 95 server.  One of the nice features of this system was a three hard drive RAID array.  The special property of this system was that if one of the drives failed, the contents of that drive are recomputed on the fly based on the other two good hard drives.  The drives were hot-swappable, so it was possible to eject the bad drive and replace it with a new one while the system was running.  That drive would then be formatted and it contents rebuilt from the other two drives while the system was in use.  Very cool technology!

One day we decided to reboot the server.  When we did the OS/2 operating system produced an error message on startup saying that one of the drives in the RAID array had failed.  We were shocked.  We should have received an indication of this when the drive actually failed.

So what happened?  These special hot swappable hard drives have an error light that turns on, and also a piezo buzzer that sounds when the drive fails.  The trouble is that the drive failed so completely that the piezo buzzer also failed.  We never heard the audible error sound that we were supposed to hear.  This was a vulnerable moment for us.  If one more of the hard drives were to suffer failure we would have lost work.  We did back up our code periodically to an external cartridge, but it had not been done for weeks.

So clearly IBM had some work to do perfecting their RAID products.  For example, if the piezo buzzers on the other hard disks were designed to sound when any of the other drives failed, this might have proven much more effective.

Liberty BASIC at IBM!

While working on our prototype for the Defense Nuclear Agency I discovered that we needed to reset some files repeatedly whenever we tested and demonstrated the functionality of our system.

I was eager to put Liberty BASIC to good use, and since we were running on OS/2 this gave me an opportunity to create a utility that would make things easy.  Liberty BASIC to the rescue!

It was actually easier to create this utility in BASIC than it would have been in Smalltalk.  Smalltalk is very powerful and really is one of the best languages, but BASIC is stronger for banging out small and simple programs.

I took great pride that when were were demonstrating our system to the customer that they also got a demo of Liberty BASIC in action!

The IBM dress code

Our contracting work at IBM in Waltham was back when IBM had a particular dress code.  All the men had to dress like the agents in the Matrix (without sunglasses).  All the women also needed to wear a lady's business suit.

However since we were not employees we could wear whatever we liked.  The fun part of that is that we got to wear IBM badges which gave access in and out of the building, to the cafeteria, etc.  I got the biggest kick out of this because the IBM employees gave us the strangest looks.  They clearly could not figure out who we were and why we were permitted to dress in casual attire.

IBM Smalltalk and team development

One really great thing about getting the job at Gem Consulting was that we were developing in IBM Smalltalk for OS/2, on IBM computers at IBM.  So we had access to quality support.

My experience using Smalltalk up to this point was using Smalltalk/V which was a popular and very good Smalltalk product.  The IBM Smalltalk was fancier and included GUI drawing tools and source code management, and working with a team of developers (there were four of us) gave me important experience that I never had before.  I learned so much by developing software with others and it taught me to break software down into modules even more effectively than I ever had.

The working space was an audio visual presentation room with an LCD projector that dropped down from the ceiling.  Around the outside of the room were tables where we worked.  We were able to communicate effortlessly because we were in the same space, and when we needed to design or make plans we would all turn our chairs around and use tables in the middle of the room.

Our development of this project went swiftly and smoothly.  I really enjoyed this style of work.

Onward and upward!

In my time at CFC Incorporated I had several interviews for work in Smalltalk.  One of them was in Cambridge, Massachusetts.  They focused a lot on Unix in the interview, or at least that's the way I remember it.  I never got a call back from them.

Another interview was with a company in Waltham called Marble Associates where my friend Laird Popkin worked.  This job seemed fantastic, and the interview was going great.  But when they told me that it was a traveling job which required that I fly to the client every Monday through Thursday I regretfully declined because I was unwilling to be away from my wife and children and also my church community in that fashion.

One day in 1995 I was contacted by one Peter Statterman, and he told me that his company GEM Consulting was looking for an experienced Smalltalk developer for a joint IBM and Raytheon project for the Defense Nuclear Agency of the US military.

We met at a coffee shop in Natick, Massachusetts and he interviewed me.  I must have said something right because he hired me!  It was exciting to be working on a project for IBM on the OS/2 operating system platform.  I was already working on Liberty BASIC for OS/2 and so this gave me the experience I needed to jump right into the project.

GEM Consulting hired me as a subcontractor.  The money was really good, but it was only a three month contract to create a prototype.  If that went well they would extend that to another six month phase.

My intention was to focus on Liberty BASIC when the contract ended and try to launch a full time business.

This was the start of a new chapter in my software development career!

I do own a leather jacket!

Sometimes when a computer breaks the cure can be surprising. We purchased a very expensive software solution for one our engineering tasks. It came with an HP Unix workstation. I never really used this machine. It was a single task appliance and I'm not even sure precisely what it was for. One day however it refused to boot, and I guess we must have stopped paying for support because they called me over to have a look.

Turning the machine on yielded the usual power supply fan noise and nothing else. None of the expected hard drive spinning or seeking was heard. This could be a bad power supply, or it could be a failed hard drive controller, or it could be... sticktion! That is pronounced stick-shun. Yes, really. Look it up. This happens on some hard drives when the hard drive sits powered down for hours or days, and the mirror smooth surface of the hard disk platters get stuck to the magnetic heads which have come to rest on the surface. The coating is just soft enough to stick.

The only way to find out if the problem is sticktion is to open the machine and bang on the hard drive casing to see if the heads can be freed. An ideal tool for this is the plastic handle of a screwdriver.

We opened the computer and I rapped on the hard drive a few times with the butt end of a screwdriver. We turned on the computer and waited... success! I felt just like the Fonz! :-)

Power BASIC and the Uncrashable Kingdom

I had it in mind to use Power BASIC as the compiler to implement the new DOS file server for the factory. This was a new, slicker and rebranded version of Turbo BASIC which I had been using for a while. It wasn't cheap. Power BASIC was a nicely polished compiler and had good documentation. I think we paid $300 or so for it.

I wanted to create a nice UI for the file server so I purchased a windowing library for Power BASIC. It made it easy to create text mode windows using graphics characters. The way it worked was very similar to the way that a Windows programmer would do it in C. You called functions which created windows, buttons, etc. These would return a numeric handle.

Your program would intercept messages from the UI library in an event loop and act on them. Each message would include the handle for the window or widget it was about, and also a value for an action such as a click or a key press. This is not an easy way to write windowing code, but the file server would have a simple enough UI. The end result looked nice and was functional.

I learned a lot on this project. This must have been the highest quality BASIC code I had written to this point. It was a multitasking file server using state machine techniques. Unlike its Xenix based predecessor, this file server never crashed once we had it up and running. Never.

Hacking a file server

No, I'm not talking about hacking an Internet file server. At CFC, Inc. we kept the CNC drilling and routing programs on a file server running Xenix which was a Microsoft branded version of Unix. The CNC machines were plugged directly into this file server using RS-232 ports. Until we purchased this server we had been keeping all our programs on punched paper tape and stored on shelves but now we could keep all this stored electronically.

Okay, this new way of doing things would have been great except that the file server cost lots of money and it wasn't reliable. Every so many weeks or months the computer would crash for one reason or another. When this happened it would run fsck on bootup. This would sometimes find some file system records to repair because the machine didn't have a chance to write everything to disk when it crashed. The end result? We would sometimes lose files from the file server. Bad, bad and worse because all our backups were on tape and we had really bad luck restoring from tape.

We didn't want to spend any more money on this file server. I wanted to develop a replacement in house. It would run on DOS which didn't have the bad habit of delaying writes to the file system. Not bulletproof, but bullet resistant and cheap. But, I had a problem. The only documentation I had which explained the communication protocol for the file server was very thin and hard to understand. I was stuck.

Remember the RS-232 monitor that I grabbed at the GTE auction? I knew right away how useful it would be for this project! Back at the factory I installed this monitor between one of the CNC machines and the Xenix file server. With the ability to see data moving back and forth I was able to figure out how the file server worked. It was tricky because data was actually delivered in packets. There was a non-trivial conversation that happened between these machines but it looked like the code for this was going to be fun to write!

I was ready to get started!

An Auction, an RS-232 monitor and an Apple Lisa

My father called and told me that GTE was auctioning off old equipment. Me and my friend Ray took a break from work in the middle of the day to see if there was anything useful we could use at the factory. There was.

A piece of equipment about the size of a small benchtop oscilloscope caught our attention. It had a 5 inch CRT display, a flat panel keyboard on the front next to the screen and a ribbon cable with a pass-through 25-pin D connector. It was an RS-232 monitor! When I realized what it was I had to have it for a project at work. The idea is that you place this device between devices and it allows you to spy on data that goes back and forth over the serial line. It displayed data in both directions, and you could see it as text or hexadecimal. The price? If I remember correctly I paid $35 for it. Amazing!

I also managed to buy an Apple Lisa computer for $25, but it didn't come with a keyboard. Luckily I noticed the keyboard on a palette of keyboards. I talked to the fellow who won that palette and convinced him that the Lisa keyboard wasn't valuable to him without the computer, and he let me have it.

This was a huge win. I still have the Lisa computer.

Poor Big Bird

No, this isn't a Sesame Street reference! ;-)

One day at CFC the power went out, sort of. Some of the offices had power and some didn't. Maybe a circuit breaker tripped? No, that wasn't it. Like most factories we had 3 phase power. Some parts of the building ran off one phase, and some another. One of the phases went out. This was no big deal for office equipment, but on the factory floor some of the motorized equipment required all 3 phases. If a phase dropped out while a motor was running, it could stall and even burn out. Some of the motors did burn out. Even worse, there was a reflow machine with a steel wire conveyor which ran fiberglass circuitboards through an oven to melt the solder plating to give it a nice shiny finish. The conveyor stopped moving, and the boards caught on fire and filling the factory with a nasty odor. Burning epoxy smells really, really bad.

It took a while to get all this repaired.

Outside on the curb was the cause of all this trouble. A very large bird (maybe a stork?) had decided to take a break. It chose a very dangerous place to sit and met an untimely demise. Up on the utility pole there was a large power transformer which had exploded, and on top of that? A large bird, burnt into a very black cinder, the recipient of that day's Darwin Award!

The Expensive Break Clock

One of our Tandy Model 100 computers had become relegated to controlling the buzzer for indicating shift changes, breaks and lunch. We used the signal for controlling the cassette interface to turn the buzzer on and off. A twenty line BASIC program was used to check the time against a schedule that was hard coded into the program.

Invariably for one reason or another this computer would forget the program. Either Bob or I would then run over and type the program in from memory, set the clock and get it running again. I cannot even count the number of times I did this while I worked there, but it was really no big deal because after a few times it only took a minute.

So here was have this computer which was originally purchased for more than $1000 and we were using it to blow a whistle 8 times a day. Nowaways this would be completely appropriate because you can buy a computer on a chip with all the power of the Model 100 for about $30.

101 Stupid LaserJet Tricks

When I was moved into my new office downstairs, it was located in a space behind what used to be the reception area of the building. The front door was locked from the inside, and visitors would enter a door slightly off to the side and climb stairs to a new reception area.

When anyone visiting would come back down those stairs they would sometimes forget that they came through the side door. Instead they would go out the original glass door, which was an inner door and an outer door. The first door had a lever you pushed to unlatch and open the door. This was locked so that if you passed through this door you couldn't come back in. Once through this door there was another door right there. This had a locked bolt, but you could just unlock the bolt and get out, and invariably this is what people did.

Then I had this idea for a prank. Using the LaserJet printer I printed in great big letters READ THIS. Then below in a tiny 4 point font I printed "If you can read this then you are trapped!" I drew an arrow from the large words to the tiny words by hand. I hung this on the wall between the two glass doors.

Weeks later I was in my office working and I heard some banging and the sound of someone calling out. I went out to find out what was going on. Shock and amazement overcame me when I saw this fellow between the glass doors, banging with his fist and calling for help! He had read the sign and believed it! I laughed and opened the inner door for him and explained that he really wasn't trapped at all. So I showed him how to unlock the bolted outer door. Unfortunately he didn't think this was funny at all. He didn't smile or laugh but he just left without saying a word. Perhaps he was humiliated that he had fallen for the trap?

I was very pleased to see that someone had read the sign and believed it. This was absolutely priceless. Looking back at this prank I should count myself lucky that I didn't get in trouble.

Our First Laser Printer

We decided to purchase a laser printer so we could print bill of materials sheets for each job. I managed to find a used HP LaserJet cheap. This was the original LaserJet printer model and had only 128K of RAM. This was fine, except if you wanted to print graphics. You could not even draw a half page of black and white graphics with 128K. This also meant that there was very little room to load fonts into the printer. The saving grace was that there was a font cartridge slot. I bought one of those super font cartridges that had lots of fonts. It turns out that we really only needed one font. I don't remember which one we used, but it was a small monospaced font.

The printer had a serial port, not a Centronics printer port. Normally this would have been considered a limitation, but this was perfect for our shop floor control system which I was building around Arnet multiport RS-232 cards.

I needed to learn just a little bit of Hewlett Packard's PCL (printer control language) to make the LaserJet do its thing. I wrote some code in Smalltalk to drive the printer. Depending on how complex the board design was, these bills of materials sometimes had a lot of information on them. It was somehow very satisfying to produce software that would drive a printer elsewhere in the building. I had never done that before.

The printer was located up in the engineering department, and after they designed a circuitboard for an order they would fill in some fields into the shop floor control system and print out the bill of materials on the LaserJet.

Little Guatemala

Most of the employees at C.F.C. were from below the Texas border. I don't remember ever there being anyone from Mexico, but there probably was. There were people from Nicaragua, El Salvador, Costa Rica, Brazil, Chile, Peru, Ecuador and the Carribean islands like Puerto Rico, the Dominican Republic and Haiti. You name it. There seemed to be more people from Guatemala than from anywhere else. We liked to joke that we were going to fly the flag of Guatemala over the building and declare C.F.C. a sovereign nation, Little Guatemala.

The Fastest Computer in the World - CompuAdd

I invited Bob to my office to show him what I had done with the tracking system idea and I demoed the Smalltalk/V prototype I had written. I showed him what it could do and I explained that we could attach many terminals to it. This went over very well. I told him that in order to do this well we would need a copy of Smalltalk/V 286, which was a more powerful version of Smalltalk/V that could access up to 16MB of RAM. This was $199. We would also need a computer more powerful than anything we had in the factory at that time, and we would need to purchase at least one multiport RS-232 card to get started.

Bob agreed to all this. On top of that he was willing to go all out. The company usually quoted as having the fastest PC clones at that time was Compaq with their DeskPro systems. Bill Machrone from PC Magazine was famous (in my own mind at least) for having said that the DeskPro/20 ran its startup tests so fast that it made him giggle.


But the king of the hill at the time I went looking for a speed demon for our shop floor system was made by CompuAdd. In the reviews I read, the CompuAdd 386/25 was a terrific performer for the budget price of only $6100. Then we needed to add 4MB of RAM for about another $2000, and I'm pretty sure the multiport card was about $900. He agreed to buy this equipment. Wow. Just, wow.

My office wasn't the best place for this machine, so they moved me downstairs into a more central location. The office they gave me was spacious with a very large window. This was great except sometimes the window leaked when it rained. Our facilities manager Joe (yes that was his real name) helped me run some serial cables, and I soldered the 25 pin D connectors onto each end. RS-232 is only designed for 50 foot cable lengths. We needed longer runs than 50 foot. I had to source special low capacitance cable so that we could run cables of 100 foot or more. I needed to short across handshaking lines to make them work, and I made a null modem adapter for each one. I found a supplier in Framingham called Marcus Associates where we bought some used ADM-5 terminals, which were much newer and nicer than the ADM-3A I had prototyped the system on.

Before long we had a working system with terminals in different departments, and a printer for reports. I created a simulated terminal window for the computer itself so I could test the system without consuming a valuable serial port in my office.

This was the beginning of what was an exciting and productive project, even with some very challenging hurdles to overcome.

My Skunk Works Project

What is a skunk works? A definition from Wikipedia: The designation "skunk works", or "skunkworks", is widely used in business, engineering, and technical fields to describe a group within an organization given a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects.

In order to prototype the multiuser shop floor control system, I needed a real video terminal. The idea would be to take a computer and install one or more multiport RS-232 cards and connect terminals to them from all over the building.

The following work was done more or less under the radar. I wasn't trying to get away with anything, but I hoped to surprise Bob with the results I hoped to achieve. I managed to requisition an old Lear Sieglar ADM-3A terminal on the cheap. This was one of those pastel blue terminals with a "space age bubble" look to it. Needham High School had a few of these connected up to their PDP-11.

In order to make this work with Smalltalk/V I needed a tiny machine code routine so I could make calls to the serial port. I was lucky to find someone on a bulletin board who was kind enough to write this for me. I was even luckier that it worked! The machine code file was only 14 bytes long!

It didn't take me very long at all to create a master monitor, a login routine, a simple command parser, a simple job object, departments that could hold jobs, and the ability to move the work from one department to another and list the contents of each department.

What was absolutely most amazing about what Smalltalk/V made possible is that the system was extensible and debuggable... as it ran! If there was a runtime error while executing some command from the terminal, a debugger opened on the computer screen. I could then fix the bug right there, and the terminal could be restarted without bringing the system down for a recompile.

This was very promising to say the least.

Christmas Vacation

I didn't take the plunge into Smalltalk right away. I wasn't completely sure it was the right choice. I was at the SoftPro store in Burlington in late 1988 and I noticed that they had a copy of the Smalltalk/V software from Digitalk. I asked them if they had any brochures, and they did. Three different full color, double sided marketing sheets. Very nicely done. Everything I saw about the language reminded me of Forth, but it had this idea of objects.

I wasn't about to ask my boss to buy yet another programming tool, so in December I bought it myself. I took the Tandy 1000SX home from work over Christmas vacation and dove into the Smalltalk/V manual, following the tutorial.

I was not disappointed. What an amazing language! I had never used anything so dynamic, or so graphical. Almost all the source code for each and every thing in Smalltalk is there. You can see it and you can modify it if you like. This was very compatible with my observation that Smalltalk and Forth were conceptually similar. The one surprise that really topped off this sundae with a cherry? Smalltalk has built-in multiprocessing. This was the ingredient that I sorely needed to produce the multiuser shop floor control system! What luck!