Category Archives: Smalltalk

Why GemStone/S

Most business software systems are built using the object oriented paradigm, one of the key concepts of OO is encapsulation and that the data and behavior be packaged together and the distinction between the two be hidden within the object. In every company and client i have worked for one of the biggest assumptions made is the idea that programs and data should be stored separately, storing data separately violates encapsulation at the most fundamental level and it greatly limits the adaptivity of a system. we aren’t able to completely leverage all the benefits of Object Orientation.

“However, doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.” – Alan Kay

Now to eliminate the distinction between databases and programs, we need a technology that seamlessly integrates the capabilities of the programs and storage and multi user capabilities of databases. This is exactly what GemStone/S is, its a Smalltalk dialect, that has object persistance and transactional capabilities baked into the Virtual Machine !. A GemStone/S repository has living objects (there is no seperation between code and data, Code are objects too). GemStone/S is not simply an object oriented database because it not only can stores objects but also can execute them in a muti-user environment. What GemStone/S is, is its a true object server.

So what does this buy us ?

  • No more object-relational mapping (no need for ActiveRecord, Hibernate, GLORP like ORM’s)
  • Makes the software incredibly adaptable, normally if we change the structure of the data defined in a class, we would also need to modify the structure of the database, mapping files etc to reflect the change, so GemStone/S Eliminates need for the synchronization of code and data, because there is no distinction between the two.
  • Objects can evolve as the business needs change, Its quite simply to change the shape of a class in a GemStone/s repository.
  • Allows us the ability to create executable business models and objects that cross cut applications, so pure objects can be shared across mutiple applications. The object can expose a specific interface with a set of messages to each application. This way there is a single point of reference for a particular object and also a single point chage for a particular object. (note none of the data is ever exposed to the app, every thing is done through the object interface by sending messages)
  • Check out this case study where a large shipping company used GemStone/Smalltalk to create a pure OO solution.

Smalltalk a world of living Objects

When I first discovered Smalltalk, it took me a while to get my head around the fact that in image based Smalltalk systems, source code is not written in flat files. Source code in files was so ingrained into my thinking, I had to unlearn and leave a lot of assumptions I have made. In most programming languages programs are written and defined using text files, typically source code is written in text files, using a text editor or an IDE such as Eclipse, IntelliJ or Visual Studio. At this point it just “dead code” in text files, there are no running objects, this is often referred to as compile time. Before a program runs, the runtime environment is created, the program’s source code is parsed, compiled and executed, and when the program finishes the runtime environment is destroyed, so in essence every time a change is made to source code the entire program is created from scratch. Smalltalk is pure object oriented and everything is an object and everything is achieved by sending messages to objects. In Smalltalk we dont use source code in text files to define programs (classes methods etc) instead objects are used to define Smalltalk programs, objects themselves are used to define new classes method etc. Now an object can exist only at runtime, and in Smalltalk everything happens on the fly, there is no such thing as compile time, Smalltalk is a runtime, it is not just a programming language, its a living system, it is a world of “living objects”. This requires a paradigm shift and it often is one of the biggest barriers I find people face when entering into the Smalltalk world. Smalltalk pushes “Object thinking” to another level, but once you push past that barrier you enjoy all the benefits of working with living objects, you can interact with objects, inspect them modify, extended and change them on the fly. This is the main reason why Smalltalk environment have such powerful IDE’s.

So what happens when the smalltalk VM is shut down or not running ? Do the objects then die ?

No. The objects are in a suspended state or go into hibernation and are stored in an image. This is analogous to a VMware image, when you close a vmware image the operating system goes into a suspended state, so the next time the vmware image is loaded to exactly the same state it was before. In Smalltalk objects essentially never die (note objects without any references will be garbage collected), they simply go into a suspended state in the image, in a Squeak Smalltalk image it is very likely some objects are probably 30 years old !

In Smalltalk everything is an object, classes are first class object too, so they can respond to messages just like any other object, so it trivial to create new classes on the fly. The image based system of the Smalltalk might be a stumbling block for people entering into the Smalltalk world but I think this is one of the main things that gives Smalltalk its power, its awesome IDE and the ability to work with live objects makes development so much more productive.

So Smalltalk code doesnt live in files so what happens to version control systems then ?

I do most of my Smalltalk development in Squeak and I use Monticello as the versioning system, in Smalltalk source code itself are represented as objects and are basically modelled as a collection of packages, classes, and methods. Code changes then simply become addition/removal or update of these elements. Since the entire source code are modelled in objects, Smalltalk version control systems have very powerful merge and diff algorithms. The version control systems are language aware and source code changes and history can be tracked down to individual method.

Smalltalk is an amazingly powerful environment, developing in a Smalltalk made me see what incremental development is really about. I guess with GemStone now working on a Ruby VM which is primarily based on the GemStone/S Smalltalk VM, folks from the Ruby world can also experience developing with living objects

My journey to Smalltalk

Ever since I started my professional career as a software developer back in 2002, nearly all of my development was done using C sharp and .NET framework with a bit of Java here and there. However while studying software engineering at University of Sydney 90% of my work was done on unix machines, I was taught object oriented programming in my first year, and thankfully we didn’t get introduced to OO by learning C++ or Java but a language called Blue (it was first developed by the Basser Computer Science department at the University of Sydney to teach students OO concepts) . Blue was not just a programming language but was a programming environment, which allowed interactive manipulation of classes and their relationship to each other graphically or textually. This allowed me to visualize a group of instantiated objects whose state was encapsulated and only way the objects performed anything was by collaborating with each other sending messages to each other to perform a task.

As I learned mainstream languages like C++ and Java. The idea of objects sending messages was blurred by multiple inheritance, classes and types. Throughout the years as I read books, researched and experimented with different ideas, I noticed Smalltalk being reference numerous times in every book OO book and every time Objects, XP and TDD were discussed. Xp and TDD were all conceived in the Smalltalk community and some of my favorite authors like Kent Beck, Rebecca Wriffs-Brock and the numerous speakers at OOPSLA every year all had a Smalltalk background. So about a year ago I decided to check out and learn this Smalltalk thing. It was a steep learning curve in the beginning (especially getting used to the idea of not working with source files) it was a big paradigm shift but it the best thing I did, there such a long history and wealth of experience in the Smalltalk community. Just browsing through code base in the standard squeak Smalltalk image, studying the wonderfully crafted code which was refined and polished by master Smalltalk craftsman over the last 25 years has improved my understanding of good OO design and also increased my productivity in my day job using C sharp and .NET. After experiencing Smalltalk and programming with “live objects”, going back to C sharp or java seems a little dull at times they are not nearly as expressive as Smalltalk. While learning squeak Smalltalk and as I immersed myself into the Smalltalk culture, I stumbled across Seaside a framework to create web based applications entirely in Smalltalk. Seaside kind of blew my mind, I have dabbled with Rails a bit and it is very clean and can be very productive, but Seaside takes web based development to a whole new level I never seen highly complex web based applications developed this way. Well it wasn’t long before I discovered GemStone/S which is not just an OO database but a powerful object server based on Smalltalk (more on this in another post). Through Smalltalk I rediscovered just how powerful it is to think in terms of objects not classes and just be able to send any message to *any* object that can understand that message. Now I realize that OO is more about message passing and actually very little to do with classes, inheritance or types. I found this quote by Allan Kay where he states what OO is all about.

“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.” – Alan Kay creator of Smalltalk