Smalltalk wächst

Smalltalk-Entwickler haben eine schwere Zeit durchgemacht. Jahrelang wurden ihre Projekte als Altlasten gesehen, die schnellstmöglich durch “was vernünftiges” abgelöst werden müssen. In manchenUnternehmen hat das auch geklappt, und man arbeitet inzwischen erfolgreich mit dem Nachfolgesystem.

In der Zwischenzeit sieht die Situation ein bisschen anders aus: das Interesse an dynamisch getypten Sprachen wie Ruby, Python oder Groovy wächst, auch und gerade durch den Drang hin zu Internet-Applikationen. Dadurch ist auch Smalltalk wieder wesentlich interessanter geworden. Schliesslich gibt es wenige Sprachen, die so ausgereift sind (immerhin blickt Smalltalk auf rund 30 Jahre Entwicklungsgeschichte zurück) und zudem eine soumfangreiche Werkzeugumgebung bieten, wie Smalltalk.

Frameworks wie Seaside sind dabei, die Sicht auf Smalltalk nochmals ganz neu zu formen: Ein Smalltalk-basiertes Framework ist es, das in vielerlei Hinsicht den Weg weist, wohin die Reise in der Webentwicklung gehen sollte. Gerade in der Ruby-Welt, wo sich mit Rails ein sehr mächtiger Ansatz für eher einfacher gestrickte Webanwendungen etablieren konnte, wird immer öfter ein Blick auch auf die Kombination Smalltalk/Seaside geworfen. In der Blogosphäre geistert Smalltalk auch immer mehr durch die Gegend.

So verwundert es auch nich, wenn sich auch bei den Anbietern von Smalltalk-Entwicklungsumgebungen ein Aufwärtstrend zeigt.

Bei David Buck findet sich dazu Folgendes

  1.  Last year was the best year yet for Cincom Smalltalk. Their revenues are growing and they have been consistently growing ever since they acquired VisualWorks. They are also seeing some new projects starting up in Smalltalk.
  2.   Last year was GemStone’s best year in their last 26 years in business. They are landing big projects and are seeing lots of interest in Smalltalk.
  3.   Instantiations says “Last year the software industry grew at about an 8% rate while Instantiations grew at substantially more than that rate and our VA Smalltalk at an even better rate than that!”

Auch bei uns stellt sich die Situation so dar: es kommen immer öfter Anfragen von Kunden, die nach Smalltalk-Experten suchen. Die Zahl an Kunden, die teils uralte IBM-Lizenzen erneuern und sich für einen Support-Vertrag mit Instantiations entscheiden, wächst.
Noch sind das überwiegend die oben genannten “Altlasten”, die aus dem reinen Wartungsmodus wieder in den Weiterentwicklungszyklus übergehen, aber das Interesse an den neueren Features von VA Smalltalk ist inzwischen deutlich gewachsen. Die Ankündigung, dass VA Smalltalk Version 8 mit Seaside-Unterstützung daherkommen wird, findet großes Interesse.
Es scheint, als wenn in vielen Unternehmen wieder öfter die Frage gestellt wird, welchen Wert eine Anwendung bzw. die darunter liegende Technologie für das Unternhmen liefert, und immer weniger die Frage im Vordergrund steht, ob es sich dabei um eine “Moderne, Zuklunftsweisende” Technologie handelt. Zukunft weisend ist wieder die Technologie, mit der man die gestellten Aufgaben lösen kann, mit der man wartungsfreundliche Systeme erstellen kann, und nicht, was die Fachpresse gerade am höchsten lobt…

Das Web ist Typenfrei

Eines der ältesten Missverständnisse rund um Internetanwendungen ist, dass man sie am besten in Java schreiben könnte. Mit seiner Typsicherheit und “weil es ja dafür gemacht wurde”, ist Java am besten fürs Web geeignet. Über beides kann man sich trefflich streiten.

Tatsächlich ist das Web ja eigentlich völlig Typfrei. Ein HTTP-Request ist zunächst einmal ein langer String, den es gilt, in Happen zu zerteilen, und aus den einzelnen Bestandteilen etwas zu machen, das für ein Programm verwertbar ist. Und wenn ein Web server etwas daraus gemacht hat, liefert er eine HTTP-Response zurück, die lediglich aus einem langen String besteht.

Mir ist in dieser Sache noch nicht ganz klar, welchen Vorteil vielen Entwickler in einer stark typisierten Sprache für Web-Anwendungen sehen. Klar ist mir aber, warum man in Web Applikationen häufig eine java.lang.NullPointerException zu Gesicht bekommt: Strings sind ihrer Natur nach schwer in ein Typsystem zu pressen. Jede Annahme darüber, was sich in einer Zeichenkette verbirgt, kann falsch sein, und bedarf einer umfangreichen Prüfung. Und genau die Zone, in der diese Prüfungen gemacht werden müssen, ist in einer streng typisierten Umwelt sehr anfällig: bevor ein String in eine Zahl umgewandelt werden kann, müssen umfangreiche Prüfungen gemacht werden, aber dabei kann nur auf Funktionalitäten von Strings zurückgegriffen werden, oder aber man begibt sich in die Gefahrenzone Typecasting: java.lang.NullPointerException.

Die Geschichte des VA Smalltalk Forums (1)

Als IBM 2005 das Thema Smalltalk aus ihrem Produktportfolio strich, waren viele User entsetzt: Jetzt ist es wirklich aus. Wenn IBM Smalltalk aufgibt, geht’s jetzt dem Ende zu. Und wir haben’s ja auch alle schon gewusst.

An schlechten Beispielen, aus denen man das ablesen kann, mangelt es nicht. Das prominenteste ist sicher OS/2, das inzwischen zwar auch von einer anderen Firma weiter gepflegt wird (eCom Station), aber keine wirkliche Bedeutung mehr am Markt hat.

Auch die Vorzeichen waren düster: Als IBM Business Partner und langjährige Berater im Umfeld von VisualAge Smalltalk war es uns teilweise sehr schwer gefallen, bei der IBM in Deutschland jemanden zu finden, der  uns mit dem Bezug von Lizenzen helfen konnte. Ich kann mich an einen Mailverkehr innerhalb der IBM erinnern, in dem eine Anfrage von uns zwischen Berlin, Stuttgart, Raleigh und Hamburg hin und her wanderte, in der es zunächst zu klären galt, welcher Ansprechpartner in der IBM für dieses seltsame VisualAge eigentlich noch existiert. Schliesslich gehörte es weder in die Sparte Tivoli, noch zu Websphere, und schon gar nicht in die Notes- oder DB2-Schiene…

Instantiations war hierzulande bis zur Ankündigung der Übergabe von VA Smalltalk eigentlich eine eher unbekannte Größe. Zwar hatte man von Window Builder und VA Assist schon gehört, aber hier in Deutschland sind diese beiden Produkte nicht sehr verbreitet. Und so galt es, einfach mal Kontakt aufzunehmen, und die Fühler dorthin auszustrecken. Schliesslich hatten wir einige Kunden, die von der ganzen Geschichte ziemlich beunruhigt waren, und die genaueres zu diesem Deal erfahren wollten. Ausserdem gab es ja die Hoffnung, dass Instantiations vielleicht etwas mehr Interesse daran hat, sein Produkt zu verkaufen, als die IBM es einige Jahre lang an den Tag gelegt hatte.

Die ersten Kontakte waren sehr interessant. Instantiations hatte alle Hände damit zu tun, das Produkt in einer neuen Version (6.03 unter IBM-label) fertig zu stellen, und irgendwie war man noch gar nicht recht auf internationale Kontakte eingestellt.

Interessanter Weise hatte es auch schon bei der IBM das Problem gegeben, dass das Entwicklungsteam seine Kunden gar nicht kannte. Wer keine Support-Anfrage gestellt hatte, die bis zum Entwicklungsteam durchgereicht wurde, war ein weisser Fleck auf der Karte. Das Vertriebsmodell über Passport Advantage tat dazu noch seinen Teil: die meisten Kunden hatten Lizenzverträge mit IBM, die so umfangreich waren, dass eine Hand voll VisualAge-Lizenzen praktisch nicht gesondert berechnet wurden, sondern nahezu verschenkt wurden. In Summe war zwar klar, dass VisualAge profitabel war, aber eindeutige Zahlen dazu, wieviele Installationen es gab und wo diese waren, waren nicht bekannt. Genau das war natürlich auch ein Problem für Instantiations: man kannte das Produkt seit langer Zeit und auch viele Kunden vor allem in den USA, aber ausserhalb der Staaten wurde es schon schwieriger.

Wichtigstes Ziel für Instantiations musste also zunächst sein, möglichst viele IBM – Kunden davon zu überzeugen, ihre IBM-Lizenzen in Instantiations-Lizenzen umzutauschen. In den Staaten, wo vor allem Window Builder ein sehr weit verbreitetes Add-on zu VisualAge ist, war das recht gut möglich: die Kunden kannten Eric Clayberg und seine Mannschaft schon lange Zeit, und wussten, dass hier ein kompetentes Team versammelt ist, das wirklich guten Support leisten kann.