A lack of productivity is killing Smalltalk.

Andres Valloud AVALLOUD at roadrunner.com
Mon Aug 13 05:06:10 UTC 2007


Janko Mivšek wrote:
> Another one from blogosfere. For our rethinking ...
>
> http://pinderkent.blogsavy.com/archives/99
>
> A lack of productivity is killing Smalltalk.
>
> I heard today that the development of Dolphin Smalltalk has been 
> discontinued. Although it isn’t a product I used or was familiar with, 
> I have been involved with a number of Smalltalk-based development 
> efforts in the past. While it was somewhat popular in the late 1980s 
> and early 1990s, the commercial usage of Smalltalk has declined 
> significantly since then.
>
> Slava Pestov suggests how poor implementations are leading to the 
> downfall of Smalltalk. I would tend to agree, to some extent. Most 
> Smalltalk implementations really don’t compare to a development 
> platform like Java, or even what Microsoft has put together with C# 
> and .NET.
>
> However, I would tend to think that the main reason why Smalltalk has 
> started to really fall out of favor is that it doesn’t bring the level 
> of productivity that it used to, relative to other technologies. Back 
> in the early 1990s, a lot of enterprise-grade software was written 
> using C or C++. For developing complex business applications, 
> Smalltalk often did offer a very significant productivity boost to 
> developers, even if the runtime performance of the applications 
> suffered somewhat. Being at a higher-level, it allowed business rules 
> and concepts to be more easily and effectively represented in the 
> software itself.
>
> But that started to change by the mid-1990s. Java arose, and offered 
> many of the benefits that Smalltalk had been offering. That’s not to 
> say that Java, as a language, is comparable to Smalltalk. In many ways 
> it’s quite inferior, even over a decade after its initial release. But 
> it was more familiar to those developers who’d come from the world of 
> C and C++, while also offering OO functionality and garbage collection 
> similar enough to that of Smalltalk.
>
> I’ve worked with several excellent Smalltalk developers in the past. A 
> talented, experienced professional can do wonders with Smalltalk. 
> Unfortunately for them, Java and its vast array of classes, class 
> libraries and frameworks have brought a similar level of productivity 
> to only average developers. So if these average developers can churn 
> out an adequate software product at a lower cost than the Smalltalk 
> expert, as has often become the case, then the business will flow 
> towards the Java developers.
>
> Unless the Smalltalk developers bring something to the party that 
> drastically increases their productivity (or their software’s 
> productivity) over that put out by Java developers, they won’t have a 
> real chance at survival.
>

That does not work as soon as changes must be made to the software.  
Which, oh by the way, happens all the time.

Other than that, I find fascinating how easily we put the responsibility 
with the tool instead of ourselves.  To a point, I'd say there's 
something to be said about the overall productivity of diverse languages 
over time.  At the same time, I find it quite frustrating when I go to a 
bookstore to research computer programming books and it turns out that 
the amount of information they have on hash, which we shall call K, is 
inversely proportional to the cube of books that cover the same topic.  
So, for instance, many books on the latest programming trends have no 
index entry for hash.

Since hashing is such a fundamental issue of computer programming, I 
can't just help worrying that the underlying assumption is that the 
average programmer does not even need to know about these things.  Some 
books even explicitly state so, thus there's some justification for that 
assertion.  Thus, if that is the case, then the real issue is that our 
skill set is tiny --- and then how are we going to even begin to have a 
proper discussion on the merits of programming language X vs Y?

Just my 2 cents,
Andres.



More information about the Squeak-dev mailing list