Whatever happened to Object-Oriented Programming?

I recently purchased "Advanced Programming Methodologies" © 1989. In the preface it emphasized object-oriented programming. I have been using Smalltalk since 1979. In one company my boss brought a copy of Business Week magazine with a cover on Object-Oriented programming into my office. He said that it sounded like a really good idea. I agreed with him and told him, "That is why we switched to it two years ago".

After the hoopla, what happened?

I know that there are skills and abilities. Typing is a skill. Perfect pitch is an ability. Skills can be taught. In my first programming course, Dr. Allan J. Perlis stressed that programmers need vision, crystal clear thought, and attention to detail. He never mentioned abstraction or creativity.

Abstraction is the key to Object-Oriented Programming. I believe it is an ability, not a skill.

I have read about "object-oriented programming" in Python, but nothing on abstractions such as a Collection in Python. They are still using address calculations to simulate Arrays. They have hacked C structures to simulate some features of Object-Oriented programming such as inheritance. They also simulate some features of Functional Programming. But the underlying paradigm still looks like C programming.

What would Ubuntu look like if it was based on Object-Oriented programming?

Which languages would you consider to be real OO ?
When it comes down to OO I don't care much about polymorphism or inheritance.
On the other hand, I do care more about encapsulation and messagepassing (both synchronous and asynchronous) and parallel processing based on those two properties.

The whole idea is interesting, let's see what we have:
Ubuntu-MATE (mate) /Xubuntu (xfce) -> GTK2/3 (Gobject on C which is a-kind-of-OO-hack )
Lubuntu (lxde)-> Qt ( C++ a bit more OO than C )
Ubuntu (gnome) -> GTK3 + javascript(?)
Kubuntu (kde) -> Qt + kdelibs
Bodhi (e17) - > e17libs ( C )

I think I pretty much summed up what you described.
So, what do you propose ?
Are there any graphic libraries for smalltalk or squeak to interface with X and Wayland ?
Would you rather have OCaml ? Lisp ? Rust ? REBOL ?
Which language would you choose?

If you skip building the graphic libraries for now you could use GTK+ or Qt5
There is a reasonable amount of languagebindings
(including smalltalk but probably only GTK2):

If the language of your choice is in the list it would save you a lot of work.

But then again: Which language would you choose?

My first OO language was Smalltalk ported to an 8085 computer.

Then I started applying OO concepts to C. A Class is a file in C. Hide the data structures by not exporting them. Only allow exported procedures to alter the data structure. Functions returning an "object" actually only return an address which is what C uses. Definitely not safe! You do need routines to allocate an object and to deallocate the object.

I believe that the main reason you do not hear more about OO was that when it was a hot topic for managers they saw that Smalltalk (either VisualWorks or VisualAge) cost over $3500 per programmer. C++ cost about $350 per programmer. They saw the ads claiming C++ was "OO" so they bought C++. Their programmers continued to write C code and compiled it with a C++ compiler. The result was none of the benefits they expected from OO.

I do not believe Java is OO, despite the claims.

To actually learn OO a programmer has to change the way he thinks. A true paradigm shift. Chubb & Sons Insurance did it right. They sent their teams to a two week wonder course. Each developer was given his own set of books on the subject. But even more importantly, they hired mentors to work with the teams and help them change how they think. I was the mentor for the Insurance Underwriter Workbench for South America. We used VisualAge running on OS2 with DB2 as a database. I found it takes about 2½ years for the developers to change how they think.

On a Mac I used Squeak which runs fine on Darwin (highly hacked FreeBSD) with X11. On Sun System 3 running Unix V I used VisualWorks. On HP workstations running Univ V we used Visual Works. VisualWorks from Cincom.com is what I use for day to day tasks on Ubuntu MATE 18.04. Squeak and Pharo are also available on Ubuntu.

Smalltalk requires a virtual machine and three files (an image file, a sources file, and a changes file). The image file contains all the objects in the developers' machine at the time the deployed image was created. In fact, the hardest part when deploying an app is removing all the developer classes and objects not used by the application. The sources file contains the source code for all the methods in the image when it was deployed. As you add/change objects and methods, all the changes are recorded in the changes file. When the image becomes corrupted (and it will), the changes file allows you to create a new image with all your work intact. There is also a Change Set Browser which records all changes in methods, making recovery relatively easy.

The Smalltalk IDE blows away all the others I've looked at. The System Browser shows you all packages, classes, and methods (including source code) for everything in your current image. There is a Package Browser which allows you to view all packages in the community repository and install them in your image.

I recommend installing the Personal Usage License (PUL) version of VisualWorks from Concom.com. They do hide some classes (such as the compiler) and although they are supposed to use OpenSS, you cannot build a bot that uses https:// URLs.
In my opinion their debugger is far superior to Squeak's; and light-years ahead of anything for Python, Haskell, Prolog, Lisp, or APL.

I also recommend installing Squeak. Their tutorials are better and Squeak bots can access https:// URLs.

Try using Smalltalk for a while and see what you can do.

I also believe every developer should be a polymath. They should have experience with an imperative language (C then Python - not C++ or Java), an OO language (Smalltalk), an Functional Programming language (Haskell), a Logic Programming language (Prolog), an array processing language (APL), a Symbolic Processing language (Lisp), and Forth.

Program design is about what is possible. A problem may be difficult using one paradigm and trivial using another. Expanding your vision will also help you see deficiencies in current programs. SPICE is the standard circuit simulation software. Expresso written in APL is 1000 times faster.

Robert Pearson

Thanks for the brief introduction on smalltalk :slight_smile:
Although I never toyed with it, I really do like the idea behind the language.

I do not believe Java is OO, despite the claims.

That makes three of us , if you include Alan Kay.

In my opinion, object oriented programming is rather a way of thinking, a mindset, a way of looking at things than a choice of language. This, regardless of programming language (although the choice of language can make it more or less difficult).

By the way, most of what I do is a variation of partly event based/IPC based, pipelined, multi processing, data oriented programming so it fits none of the classical paradigms (or actually a bit of everything)

It all comes down to compartimentalisation. I, for one, am not really fond of certain aspects of OO: I prefer to keep code and data seperate as much as possible and i dislike state if it's not strictly necessary or primary to the functional means so probably in some situations (or rather parts of my code) I'm more inclined to follow the path of functional programming.

Of course it all depends on the task at hand so i'm not limiting myself on a certain paradigm.
I know that I possibly would start using a good OO capable language if I would program simgames or GUI's or ( [deity] forbid ) enterprise software.
(although using a functional language for building a GUI sounds like pretty interesting idea.)

what do you think of this:
A programming language can not offer you a programming paradigm, it can only offer you the tools.

About VisualWorks from Cincom:

I am afraid this is a definite no
I will not install a non-free developement environment on my rig.
GPL, BSD, Apache or comparable licenses are fine.
Closed source is in my opinion ( security, compatability and privacy wise ) just not such a terribly good idea.


The Cincom Personal Use License is free. However, deploying an app can be a costly process involving licensing fees. I recommend developing in the highest-level language environment. Then you might consider a different environment (like Haskell) to prove program correctness. And finally something like Python or C for the actual deployment. Just make sure that all tools converting languages leave the semantics invariant.

Smalltalk V from DigiTalk had an interesting property; it included both a Smalltalk compiler and virtual machine and a Prolog virtual machine. That allows both paradigms to be used for different parts of the application. I did some work on building Forth and Lisp compilers and editors into Smalltalk.

You might also look at Forth. It is a high-level language that allows embedding assembly code directly into the application. When Dr. Allen Perlis talked in class about high and low level languages he said "Low level languages execute faster than high level languages". He also said "High level language code is bigger than low eleven code". Bliss programs run faster than assembly language programs written by expert programmers. Forth programs are approximately 50% of the size of assembler programs. On the TI 990 computer, the Forth virtual machine is 128 bytes. In the Novix computer, the virtual machine is implemented in hardware, making it a Direct Execution Architecture. The Novix computer outperformed the 68000 and the 8086 even though it had only 5000 gates clocked at only 2 MHz.

The language is highly reflective. The Forth words allow you to change the syntax of the language itself.

When Sun Micro was switching from the 68000 based System 3 to the SPARC based System 4, they built a Forth interpreter into the boot ROM and translated Unix System V and most or the diagnostic programs into Forth. That allowed them to use the same code for both systems except for the diagnostic code for the processor itself.

The Cincom Personal Use License is free.

Yeah, free as in beer, but not free as in freedom.
It's a pity that both meanings in the english language are homonyms.
The freedom part is the most important one for me.

I recommend developing in the highest-level language environment.

For the capabilities I need, that would be 'bash' :laughing:

:innocent: Bash has some OO properties if you consider a running script as an object-instance.
encapsulation (own environment)
message passing ( pipes, files , sockets , dbus , posix ipc )
inheritance ( by sourcing )
late binding

On a more serious note: bash actually has some strong points that you can't find in python or most other languages.
Native automatic multi/parallel processing is one. Very very easy signal handling is another.
I would love to hear about any language that can do it linguistically on such a high level as bash. :wink:

For me that makes it the most attractive 'scratchpad' language. (in the same way that a 'storyboard' is used when producing a movie)

(compulsary unix koan)

What would Ubuntu look like if it was based on Object-Oriented programming?

It would probably look a bit different but it would work a lot like 'lego' I think.

b.t.w. I think I found an interesting and modern smalltalk-IDE (MIT-Licensed) -> https://pharo.org/

Do you theoretically have the skills to build a desktop of your liking in Pharo ?

I just read your post and found it intriguing, as I did the broad range of replies. I'm a fulltime software developer and have been building software for 50 years. I fully agree with your statement, "Abstraction is the key to Object-Oriented Programming. I believe it is an ability, not a skill.".

I am responding at this late date, because I believe that OOP is very much alive and that, if used as Alan Kay and the team at PARC intended, is still one of the best ways to write software that needs to be understood by others, and maintained and modified economically. I also believe that too often OOP is not taught or used well. The concept of abstraction can be taught, but abstract thinking is much harder.

My own opinion is that the ability to reason abstractly comes to some with age. Personally, at around age 35, I ceased to need concrete examples to think about a problem and could build mental models in my head that I could run to see if they'd work or not. It was very liberating. Too bad we seem to replace programmers with younger, less expensive, ones at around that age.

Because OOP is not taught and used well, many people are seeking better ways of writing code. Having been at this as long as I have, I know that many "new" coding paradigms, like "functional programming", are in fact regressions to the way we were forced to write code before OOP, and are popular only because OOP training frequently misses the primary point of OOP.

Properly used, Java is very much an object-oriented language, but it too is taught badly and misused. That is a shame because there are an enormous number of well-written open-source Java libraries just out there for using.

I recently wrote an article on this topic, and would like to share it:


Hi William,

I read your article with much pleasure and I found myself smiling and nodding while reading. :slight_smile:

It also reminded me of a few years of my life (decades ago) when I was programming some software under QNX which was a very small and very fast microkernel OS with native 3 step messaging: send(), receive(), reply(), more or less identical to the messagepassing you described in your article. :slight_smile:
(microkernel indeed: 3kB in size)

About functional programming; the most important takeaway for me is the idea of pure functions and their benefits as described in the paragraph "Pure Functions" in this article. (about 1 page scroll from the top. No direct link unfortunately)

It is, ofcourse, not the 'Be all and end all' of programming. It's just another tool in the toolbox.

You might be interested in some observative comments about programming that John Carmac wrote.


Thanks Thom,

I too like the concept of pure functions. The team I work on has used our message orchestrator implementation to get pretty close. Our message orchestrator guarantees that:

  1. Messages are always passed by value, not by reference.

  2. Our composable services are pure message processors and have no instance variables.

  3. They are thread safe and almost pure actor model classes.

  4. The only public methods they can have are the RESTful message responders in our ComposableService interface. They are permitted to have private methods (subroutines),

Here's a link if you are interested:


Thanks a lot for the the link William :slight_smile:

About Composable services:
Especially point 2, 4 and 5 stood out to me in a oddly familiar way.

Even when writing in bash, I seem to stick to point 4 and 5 naturally, whereas in C it's mostly point 2 that I naturally gravitate to :slight_smile:

I think I would naturally get into the habit of indeed paying attention to all 5 points if I would write medium sized projects or bigger.

I already experienced the benefits of writing a serverapplication as a cluster of communicating cooperative processes. Not only enables it swapping parts in and out at runtime (which is incredibly convenient on a production server (no downtime etc.)), it also proved rock solid and reliable (and unit testing is a breeze).

May I ask what your language of choice is to get the best out of this microservices concept without fighting with the language itself ? I mean, which language would you deem to be the closest natural fit for this concept ?


Thanks Thom,

I hope that you are not too horrified by the fact that we use Java (at this point Java 21). We are currently validating the use of Kotlin with our micro framework. We aren't finished yet, but it is looking good for those who like a more economical syntax than Java.

Java does not constrain what we can do, and we depend upon features of the JVM (JIT compiler and the dynamic class loader). We also exploit the Java and the Jakarta EE ecosystems for things we would otherwise have to write. There is a huge Java and JVM-using corporate market out there and you can find Java libraries for almost any technology you might need to use.

Though I love what I do, it has also been a business for me. I was trained as a biologist and an Army officer. I've read books and articles, and built systems for hire, to learn development and have never had a computer science class. When I was at Brown, there were no computer science courses.

I prefer an expressive programming language to an obsessively concise one. Clarity of expression is important to me. Coding is usually only 10-20% of the cost of building and deploying a software application. A few extra keystrokes do not bother me.

I began my career with COBOL and IBM Basic Assembler Language on mainframes. When the Macintosh came out I taught myself Object Pascal and then THINK-C (which supported the Mac OS Object Pascal system calls).

At the first company I founded (pre-WWW), we implemented a 4GL OOP language called the Class Specification Language (CSL) using YACC and LEX to output C in dialects for a number of platforms (Macintosh, Unix, OS2, Windows, and DEC VAX). We implemented automated memory management and were able to run apps that distributed objects across networks and accessed relational databases.

We built an integrated graphical development and runtime management environment that ran on the Mac OS. We turned a data model into a runnable application and provided the tools to customize it. The chief architect at Apple wanted to buy our technology to move the Macintosh from desktop publishing only to corporate app development.

The architect and I pitched it to Apple corporate marketing in Cupertino. The marketing VP couldn't understand why Apple would want to do that. The architect resigned and I later sold the company to a Singapore-based data modelling company.

That has given me the freedom to pick and choose what I do and whom I work for. It has been a great ride and I'm not done yet.