Smalltalk’s Proven Productivity

by Richard Kenneth Eng

You often hear about Smalltalk’s productivity advantage over other languages such as Java, JavaScript, and Python. Depending on who you talk to, this advantage ranges from 1.5X to 2-5X. In my own experience, for smaller projects, it’s around 3X. This is all anecdotal, of course, but is there actual scientific evidence to back it up? In fact, there is.

In the seminal 2013 paper published by Namcook Analytics, Capers Jones discusses the use of function points for analyzing software productivity, quality, costs, risks, and economic value. Note that Jones studies productivity over all aspects of a software project, not just the coding or programming phase. So this is fairly representative of the real world.

CEO’s and other C-level executives want to know much more than just the coding part of software applications. They want to know the full cost of applications and their complete schedules from requirements through delivery. They also want to know multi-year maintenance and enhancement costs plus total cost of ownership (TCO).

On page 42, Jones deals with “Function Points versus Lines of Code (LOC) for Software Economic Analysis.” Having established the approximate number of logical source code statements per function point for a wide variety of languages, he then presents a hypothetical software application to compare the development effort among these languages. (Non-code months include things like requirements, design, documentation, management, etc.)

Language Coding months Non-code months Total months
C  128  50  178
FORTRAN  107  50  157
JavaScript  71  50  121
Lisp  64  50  114
C++  53  50  103
Java  53  50  103
Python  53  50  103
C#  51  50  101
Ruby  46  50  96
Haskell  38  50  88
Delphi  29  50  79
Objective-C  27  50  77
Visual Basic  27  50  77
Smalltalk  21  50  71

As you can see, Smalltalk easily trumps JavaScript, Java, Python, C#, and Ruby. Now, this result is not definitive since it makes a number of assumptions, and one has to be somewhat wary of statistics. Nevertheless, the numbers are consistent with anecdotal evidence which constitutes proof within the statistical error. The interesting thing about this study is that it goes beyond simple coding and programming; it takes the entire software project into consideration, which is what business executives care most about.


16 thoughts on “Smalltalk’s Proven Productivity

  1. A reader asked what makes Smalltalk more productive than other languages. The best response I could give was:

    I can explain it to you in words, but you may not appreciate it conceptually. The only way to really understand is to try it, use it in a sample project, and get the actual feel of the Smalltalk environment.

    Nevertheless, I’ll try to explain it. The Smalltalk environment consists entirely of a system of “live” objects, the actual runtime objects of your running application. This includes the “core” of Smalltalk, as well.

    In real time, you can examine these objects, as well as change them, change the code and proceed with execution! This is a very powerful methodology. It allows you to build your prototype application quickly, eliminating any cognitive interruption that you typically experience in traditional file-based tooling and static execution. Smalltalk helps you to fully develop your application concept in a natural uninterrupted flow.

    This, in combination with Smalltalk’s extremely simple and elegant syntax, which minimizes the cognitive load on your mind during development (think C++, C# or Java), provides the one-two punch of greatly amplified productivity. Smalltalk’s language feature set is very modest but powerful in its expressiveness.


  2. PeterO says:

    I use Smalltalk, Javascript and C# mostly. My own metaphor for explaining how Smalltalk is 2x to 4x more productive than C# or Javascript compares a word-processor (Smalltalk) to a typewriter (C# or JavaScript).

    The “live object” development environment of Smalltalk is interactive, rich, flexible, quick-to-use and lets me pay attention to the domain model or solution I want to build. The more static languages and development environments (e.g C#) make me expend more brain cycles and time thinking about computer science. The static software technologies, like a typewriter, get in the way of my productivity, flexibility and creativity.

    Not only is Smalltalk more productive, but the quality of systems built with Smalltalk are better in terms object orientation (code that is more polymorphic, encapsulated and uses inheritance more optimally). The benefits are code-reuse at high levels down to fine grained methods, ability to more easily extend and maintain systems, code that can double as documentation, ease of getting new developers up-and-running, and much more.

    You have to use Smalltalk or watch a competent Smalltalker in action to get it. If world is of the typewriter paradigm, then you take a few hours to learn the word-processor paradigm, you’ll understand the leap Smalltalkers are excited about. Smalltalk is often described as a joy to use.

    Using the word-processor / typewriter analogy, resulting documents are better quality and more efficiently produced by the word-processor enabled writer. Similarly, software built by experienced Smalltalkers can be better quality and completed in a more efficient manner. This is a generalization and there are exceptions. It comes down to using the best tools for each project. For low-level operating system development, C or C++ might be the best tool. Smalltalk is an excellent technology for a broad range of applications in business, science, and other domains.

    I always look for ways to use Smalltalk over the more static technologies. I’ll use C# or Javascript if I must. These days, there are systems that enable me to write Smalltalk and compile to Javascript or code that executes on .NET. But these are topics for another post.


  3. Jack Trainor says:

    I’ve programmed professionally in C, C++, Java and Python. I understand the table above somehow correlates function points vs months of coding, but the notion that a serious programming task could be accomplished in the same number of months using C++, Java and Python strikes me as flat wrong and makes the rest of the table’s numbers dubious..

    Does anyone here believe C++, Java and Python are equally productive in development time?

    I’m also surprised Lisp would be so much worse than C++. I’ve no experience with Lisp aside from some hacking with Clojure, but I thought one of its claims to fame was its speed in development. At least that’s what Paul Graham wrote in his influential “Beating the Averages” essay. I suspect the problems with Lisp lie more with back-end maintenance but that’s not what.the table covers.


  4. “Does anyone here believe C++, Java and Python are equally productive in development time?”

    I can imagine it. “Coding” is more than just translating an algorithm into the programming language of your choice. It also includes testing and debugging which arguably are much more work. Python code may be easier to write than C++ code, but is it easier to debug? Smalltalk makes debugging much more pleasant.

    Of course, we’re just speculating. The data behind the Namcook study may cover a lot of issues that we’re not aware of. Analyzing software projects is a very complex undertaking, which is probably why it’s not done very well by many organizations.


  5. Jack Trainor says:

    Anything that requires 53 man-months of programming is more than translating an algorithm. And of course that includes testing and debugging.

    Based on my experience, yes, one can achieve results faster with Python, including testing and debugging, than C++. I don’t think there is any doubt about that among professionals — unless the Python programmer is far junior to the C++ programmer. The trade-offs are that the Python application will be much slower, occupy more memory and be more difficult to distribute than the same in C++.

    It’s just plain harder to work in C++ than Python. Debugging memory errors alone kill your development time in C++ but are almost never an issue with Python.

    If the development time for C++, Java and Python were the same, there would a whole lot more C++ code being written.


    • What about maintenance? Garry Taylor, a prominent answer participant on Quora, has had extensive experience with Python and now Java. He absolutely hates Python. He says that maintaining a large Python code base is a nightmare. He’d rather chew off his own arm than go through that again. He much prefers Java.

      53 months of coding are more than 4 years. That’s a lot of code maintenance. That could severely impact the software project. Like I said, we don’t know what Namcook looked at in detail, but I believe in their results.


  6. Jack Trainor says:

    Here is a small project for parsing basic XML I wrote first in Python, then in C++ (as well as Java and C#).



    Given the choice, I like to work out the details of a program in Python first, then translate into C++ or Java. That works for my own projects, but on a job, that’s usually not an option.


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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s