Thinking Objects

When I was much younger then I am now, before I knew much about computers, except that I didn’t like them, I was given a copy of Symphony. The original owner didn’t really have much use for the spread sheet / database programming language. It was the first program that I’d ever seen.

At the time I owned a business and was doing data processing by hand. The program was a miracle. I started by writing a full reporting engine. It calculated the size of the header and footer, the size of the begin and end groups and then it figured out how much data and padding would fit in between so I could print pages. Ok I know, this was overkill for a spread sheet, but at the time I had no idea other languages existed.

I moved from reporting into invoicing. I had to bill my customers for number of different workers unions. Most of the basic rules were the same, but each union had their own payment rules. What I needed was to specialize pieces of the program but leave most of the code alone. I programmed my spread sheet to reference a cell that said what union it was, then read the union from the data and off I went programming my specialized components.

Once I had a major bug in the program I just couldn’t figure out. So I printed my spread sheet code. I taped them all together, cleared room and spread the whole thing out on my office floor. I found the code after hours of walking on my spread sheet from place to place until it clicked.

Later as I discovered other languages, I had another problem. I was building an application that was very dynamic. We had a group of nurses that were building a risk assessment program for pregnant women. I wanted to build a program that would allow the users to define not only what the program did but how it flowed. They entered the specs in data and the system read that data to produce the code. I was using a database program that really didn’t support what I needed to do. What I wanted to do was create a system that could flow down from higher components to more specialized components. A change in the base component would effect everything below it.

I was talking with one of my programmers and he said, “I know how you can do that”. He knew of a pre-compiler. We could identify and replace code with symbols. Then when we were generating the code we just ran the code through the pre-compiler to replace the pieces we needed. It was wonderful!

I was hired for a Smalltalk Job by my old boss after an ugly merger. I had never seen smalltalk before. The language was VisualWorks and all I had was a book that had the checkbook example. In 2 days I had learned smalltalk and was writing production code. Within a week I was designing and delivering huge modules.

I know this is not normal for learning Smalltalk. My reaction to Smalltalk was like someone removing handcuffs. I could accomplish anything. I thought wow I can do that without having to jump through all these hoops first! I don’t need a pre-compiler to do inheritance. I can program a concept and use it somewhere else. I really don’t need a reference cell and an if-statement to control flow I can just subclass and specialize my objects instead. The best part was I didn’t need a bigger and bigger floor because browsers could bring the components to me! It was a terrific experience.

Now I look at everything through the eyes of Smalltalk. It’s really hard not too. When I learned Java the first thing I did was write the collection methods I knew so well and depended on. “What you can’t do that, your kidding!”, I thought and so I wrote it.

There is nothing that Smalltalk can do that other languages can not copy. You can accomplish everything that Smalltalk does in a SPREAD SHEET! (believe it or not) But Smalltalk does it in a natural way. The concepts you need are built right into the language and into Objects!! As the world changes, computing changes, what we can accomplish electronically changes, it is becoming more and more clear, that the concepts of Smalltalk were right all along. If you want to understand other languages, and be extremly productive in todays computing environment, consider studying Smalltalk. Everything you need to know is right there.

Anyone that believes that Smalltalk is dead or dying really doesn’t understand Smalltalk. You can see its influence everywhere. The requirements for todays systems, dynamic computing, distributed processing, are all in there. Smalltalk clears away all the clutter so that you can build tomorrows systems today. Actually you could have built tomorrows system yesterday!!

I’m sorry to hear about Dolphin, but Smalltalk and Squeak are alive and well. If anyone says anything to the contrary, I object!

Ron Teitelbaum * President / Principal Software Engineer * US Medical Record Specialists * www.USMedRec.com