Smallworld

My profession is building GIS systems (Geographic Information Systems).
For this we use Smallworld, a tool containing a language (Magik) and a database.
Smallworld is one of the market leaders in the GIS world for utilities and communications, it is of a different breed from competitors because it is a proprietary solution. Often we have to defend ourselves why we are different. Of course we are working with other solutions, but for the large scale solutions (in utilities and telecommunications) they do not impress.
Even the latest solutions of competititors of Smallworld do not impress, while being written in the hottest languages using modern spatial databases, the new solutions do not impress.

Why does Smallworld impress: It is dynamic, It is Smalltalk under the hood.
The system has deep reflection and can be modified at almost every level. The agile character of the language (modifying the system while running) makes working together with the customer pleasant. Often a new feature is developed with the customer sitting aside. There is almost no specialization in developers, software engineers do the database administration. So we can develop rapidly and with great ease in small teams.

Most of the competitors are using static languages, one would expect that these languages would excel in performance over Smallworld. Performance is a big issue in the utilities and telecommunication because the system should cope with large amounts (millions) of geographical objects. But even there Smallworld impress. Recently a project with one of the main competitors of Smallworld has been stopped; one of the reasons: the system did not perform.

Why does Smallworld even impress in performance? Dynamic languages are considered to be slower. But the reason is because Smallworld is build in a dynamic language. Gilad Bracha (who was responsible for the Java Language and Virtual Machine Specifications) has said something about this: "For optimisation, more is known about a program written in a dynamically typed language at runtime than is known about programs in statically typed languages at compile time". In static GIS systems it is often very hard to find out what is the behavior of the application. It is very time consuming; people can spend days to find out the cause of an error. The opposite is true in Smallworld, we likely solve the problem fast and often in the situation (the image) where the problem occurred. And as you can inspect and change the system while it is running, you are able to change the design, improve it in short (interactable) interations. This is the reason why Smallworld has an elegant design. Again a reason for good performance: Efficiency stems from good design, not good coding (Robert Glass, Facts and Falacies of Software Engineering).

Because most of the( GIS) world is not dynamic we have to defend why we are different. Too less is known in de Smallworld world about the successes of the dynamic applications, this was even true when Smallworld was a just startup.
Gartner recently has changed mind about Smalltalk, the comeback they predict can be positive for Smallworld as well. We need to follow the other dynamic languages (Smalltalk being the first and prominent one). We can learn from them and keep confident about our future and our strengths.