[pjc50]

> I was a smalltalk programmer back in the 1990s

Smalltalk (and languages in the same academic orbit, like LISP derivatives) seems to be a tool that fits a few people's hands very well, but there are no large smalltalk projects for two reasons:

- that doesn't actually suit most people, so it's harder to find developers

- the language maps well to one (1) human brain that keeps a model of what's happening, but that breaks down when larger teams of developers are involved.

I guess that keeps the "small" in smalltalk.

[igouy]

How do you know whether or not "there are no large smalltalk projects" (whether or not there have been large Smalltalk projects)?

Seems like we need do no more than assert: Yes there are!

~

But it's more interesting to look at how a real Smalltalk project worked:

"A very large Smalltalk application was developed at Cargill to support the operation of grain elevators and the associated commodity trading activities. The Smalltalk client application has 385 windows and over 5,000 classes. About 2,000 classes in this application interacted with an early (circa 1993) data access framework. The framework dynamically performed a mapping of object attributes to data table columns.

Analysis showed that although dynamic look up consumed 40% of the client execution time, it was unnecessary.

A new data layer interface was developed that required the business class to provide the object attribute to column mapping in an explicitly coded method. Testing showed that this interface was orders of magnitude faster. The issue was how to change the 2,100 business class users of the data layer.

A large application under development cannot freeze code while a transformation of an interface is constructed and tested. We had to construct and test the transformations in a parallel branch of the code repository from the main development stream. When the transformation was fully tested, then it was applied to the main code stream in a single operation.

Less than 35 bugs were found in the 17,100 changes. All of the bugs were quickly resolved in a three-week period.

If the changes were done manually we estimate that it would have taken 8,500 hours, compared with 235 hours to develop the transformation rules.

The task was completed in 3% of the expected time by using Rewrite Rules. This is an improvement by a factor of 36."

from “Transformation of an application data layer” Will Loew-Blosser OOPSLA 2002

http://portal.acm.org/citation.cfm?id=604258

[randomdata]

> but there are no large smalltalk projects for two reasons:

But mostly because it was expensive. Objective-C and Ruby got you halfway there for free, and there is nothing developers love more than something that is free.

[igouy]

(Elephant in the room) Free-as-in-beer Java!

[ReflectedImage]

Well it's a lack of training problem.

Someone properly trained with something like Smalltalk will on average output 3x the amount of software as someone trained on something like Java.

There are big advantages to doing it.

[EMM_386]

> Well it's a lack of training problem.

The industry spends billions of dollars on developers writing Java. If they could spend 3 times less by simply training developers to use Smalltalk instead, they'd be doing it.

They're not, because that's not the problem.

[randomdata]

> If they could spend 3 times less by simply training developers to use Smalltalk instead, they'd be doing it.

No they wouldn't. While not bad long-term thinking, by the time developers are up to speed with Smalltalk and realizing three times the output, the competition using the ecosystem its developers already knew will have launched something and won over the customers. It doesn't matter how much software you can crank out after you've already lost.