Thinking Objects

12 August, 2007

I Object

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 *

7 Responses to “Thinking Objects”

  1. Joey Says:

    Don’t stop at Smalltalk–there’s much more to be learned! Lisp or Haskell will stretch your brain even farther.

  2. Brett Says:

    Farther? I’m not sure. Perhaps “differently” is a better term. Yes, Lisp (with it’s powerful macro system, allowing one to create DSLs), and Haskell (with it’s pure, side-effect free nature) force one to solve problems in… unusual.. ways, but the same can be said for Smalltalk, with it’s emphasis on software as a living system.

    Personally, I find Haskell and Lisp just *too* alien for my tiny brain (just try to find a comprehensible description of monads *shudder*), but, hey, that’s just me. 🙂

  3. […] Thinking Objects [image] When I was much younger then I am now, before I knew much about computers, except that I didn’t like […] […]

  4. vanjulio Says:

    For many modern programmers (Java C++ etc), objects are a way of expression that is more natural than “codes” and lines of syntax. Your symbols in the preprocessor might be great to some engineers, but to most sane adults it is garbage compared to the reality of the system. A spreadsheet in old times was a useful means of expression, but hopefully that paradigm is becoming obsoleted because we know much better now to manipulate and view data. I think the ability to express relationships and control of the dynamics of the computer are done beautifully in Smalltalk, but I can understand why Lisp or Haskell people would think their mode of expression is more natural.

    You are right though that you could do Smalltalk things even just with a spreadsheet. I spend all my efforts doing this in the C language. And yes, I think it makes me the superstar programmer that is building tomorrow’s systems today!

  5. Hi Vanjulio,

    I hope I was clear that all the hoops I had to jump through were garbage. I wouldn’t suggest them for anyone. They were the only way I could solve the problems I had before learning Smalltalk. Smalltalk, and more, the paradigms of object oriented programming, provide cleaner, easier and much more beautiful solutions to difficult problems.


  6. Fabio Says:

    Smalltalk is like drawing with a pencil, Haskell feels like drawing with a CAD.
    They are good in different occasions.

    Smalltalk has influenced me like nothing else. Even more than LISP. It changed my view on programming. Particularly Blocks and ‘Live’ environment.

    On the other hand Haskell has two MINOR!! problems in my opinion:
    1) it’s model suggests to work using pure functions … but as soon you have to write a ‘print’ you need to rewrite your code in monadic stile which is … well imperative…mmm… so why force a purely functional style ?
    2) Type inference is nice to have, but if you have a type error the most easy way to find it using type tags…. which is putting types…
    so why type inference ?

  7. Hiren Says:

    Q is another very nice language. It is pleasure to code in.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: