This article only looks at the initial implementation, which is the
smallest part of the software life-cycle.

It is probably true these days that one can use InteliJ or Eclipse to
generate all the verbose code and bring a Java developer on par or
even past a Smalltalk programmer for that initial writing (though even
this doesn't seem to be the case in practice).

Then starts the QA/debugging phase.  Here the advanced IDE's help out
again but Java et al begin to slip behind.  Not as far as they used to
but still losing ground.

And now your software goes into production.  So the support teams need
a way to see what your software is doing so they can support it.  This
means you have to reach into the system and expose parts of it, but
what do we expose?  You will get this question wrong pretty much every
time.  So you have to make the next version just to put in monitoring
code.  And it works beautifully... to demonstrate that they actually
needed to see some other part of the system.  At some point you just
give up and log the entry and exit to every function in the system
with Log4* and let them choose how much information they want.

In Smalltalk you can completely skip this step if you want, the entire
system is *already* exposed [1].

Most of the cost of software comes from the maintenance which is tied
directly to lines of code.  Smalltalk is still way ahead on that score
(against Java and C/C++ at least), and giving people the ability to
generate the 3/5/10/whatever times more code faster doesn't fix that.
It is the equivalent of optimizing a section of code that almost never
gets called.  When you pan out and look at the bigger picture you
don't see any gains at all.

[1] Also talked about at:
http://sixtyk.blogspot.com/2007/02/watching-watchmen.html

On 8/12/07, Janko Mivšek <janko.mivsek at eranova.si> 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.
>
>
>
>
> --
> Janko Mivšek
> AIDA/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
>
>