Smalltalk ist zu teuer! …. ist es doch?


In einem Kommentar zu meinem letzten Posting über den Vortrag von Robert Martin auf der RailsConf ’09 schreibt jemand:

2. Smalltalk ist leider zu teuer.
Ich bin ehemaliger Smalltalker (so richtig beruflich mit Geld verdienen damit) und würde in meinem jetzigen Umfeld auch gerne wieder Smalltalk verwenden, aber die Kosten für z.B. VA Smalltalk (wäre mein Favorit, als ehemaliger VS(E) Entwickler) kann ich niemals rechtfertigen (wenn man Java umsonst bekommt). Bei mehreren tausend Euro pro Lizenz kann ich gerne um 20% produktiver sein, das rechnet sich nicht.

Hier stecken gleich mehrere Punkte drin, über die man trefflich streiten kann.

Gegen Umsonst hat Smalltalk keine Chance

Das wichtigste und immer wieder auftauchende Argument ist, dass Java und Ruby ja schliesslich umsonst seien.
Wie umsonst ist Java eigentlich? Wer bezahlt Java oder Eclipse? Als IBM-Kunde ist die Frage schnell beantwortet: ich und die vielen anderen IBM-Kunden.
Nicht, dass ich das für schlecht halte. Eclipse ist eine tolle Sache, und dass IBM soviel Geld da rein pumpt ist auch gut für uns alle. Auch die vielen anderen Firmen, die Geld in Eclipse stecken, tun damit etwas, worüber wir uns freuen können. Aber warum tun die das? Weil sie uns Java-Entwicklern einen Gefallen tun wollen? Weil sie uns für ihre kostenpflichtigen Zusatzprodukte gewinnen wollen? Weil sie ein umfassendes Angebot an passenden Dienstleistungen anzubieten haben?

Mal abgesehen von den indirekten Kosten, die eine Entwicklung wie Eclipse, OpenOffice oder MySQL oder auch Ruby für alle IT-Anwender haben, ist ein Eclipse nicht wirklich kostenlos. Wenn man Support benötigt, weil man ein hohes Mass an Betriebssicherheit gewährleisten muss, kann man welchen kaufen (hier schliesst sich der Kreis zum eben Geschriebenen). Eclipse ist ein tolles Werkzeug, und ich wünsche mir vieles aus der Umgebung auch für VA Smalltalk oder VisualWorks. Aber manches ist einfach sehr rudimentär oder gar nicht vorhanden. Wieviele wirklich gute GUI-Editoren für Eclipse gibt es? Und wieviele davon sind kostenfrei und gut supported? Ich arbeite unheimlich gerne mit dem SWT Designer, nicht nur, weil wir ohnehin ein Instantiations Business Partner sind, sondern auch, weil er sich sehr vertraut anfühlt, wenn man VA Smalltalk kennt. Der kostet aber ein paar Euros.

Ich bin der festen Überzeugung, dass die Kostenunterschiede zwischen einem “voll ausgestatteten” Eclipse und einer Smalltalk-Entwicklungsumgebung nicht mehr allzu groß sind. Nimmt man dann noch die Supportfrage mit in die Kalkulation auf, dürfte das ein Va Banque-Spiel werden. Entweder hält man sich einen absoluten Eclipse-Spezialisten im Haus oder kauft Support ein. Beides ist nicht billig. Oder man riskiert es einfach, dass man mal tagelang im Internet forscht, um ein wirklich hartnäckiges Problem zu lösen. Kann die billigere Variante sein, muss aber nicht.

Ich will meinem ungeneigten Gegner gleich ein Argument noch in den Mund legen: selbst wenn wir dann den Support für Smalltalk zahlen, kosten DB2 und Oracle trotzdem mehr, weil die Jungs dennoch Eclipse sponsern. Dieses Argument kann ich nicht entkräften…😉

Mit x% mehr Produktivität lohnt es sich dann doch …oder?

Die Frage, wieviel zusätzliche Produktivität müsste Smalltalk bieten, damit unter Ignoranz des zuvor Geschriebenen auch einem Manager klar wird, dass es sich lohnt, in Smalltalk zu investieren, ist natürlich eine super schwierige.

Gehen wir mal von einem Unternehmen aus, das keine Smalltalk-Kenntnisse besitzt. Hier wage ich zu behaupten, dass die Kalkulation ohnehin wertlos ist. Die Lizenzkosten sind da kein Argument mehr, wenn man Schulungs- und Einarbeitungskosten daneben hält. Da liegt sogar der Schluss nahe, man könne sich stattdessen die teuerste und luxuriöseste Toolsammlung in der im hause bekannten Technologie leisten, und immer noch sparen.

Ich glaube, Produktivität ist nicht das alleinige Argument. Mit anderen Tools lässt sich eine Menge Code so schnell generieren, da kann kein Smalltalker mehr ähnlich viel Masse liefern, ausser er hat 8 Hände und 3 Gehirne.

Der Schlüssel zur Frage liegt doch eigentlich eher in der Frage der langfristigen Tragbarkeit einer Lösung. Wie gut ist guter Smalltalk-Code wartbar, verglichen mit ähnlich gutem Java-Code (gibt es den?)? Wie schnell lässt sich ein Problem in bestehendem Smalltalk-Code auffinden und beseitigen? Wie schnell kann man fremden Smalltalk-Code begreifen und sich im Umgang damit so sicher fühlen, dass man ihn mit gutem Gewissen ändern kann?

Ich meine, diese letzten Fragen sind die wirklich wichtigen in einem Projekt, das auf viele Jahre Lebensdauer ausgelegt ist. Das ist übrigens ein Feld, in dem ich allem, was Code generiert, mit großer Skepsis entgegenstehe. Ein Rails Scaffolding ist beeindruckend, und im Grunde ist eine typische Datenpflegeanwendung in Rails mit ein paar Kommandos fertig. Mit Rational Application Developer ist eine EJB-Anwendung mit ein paar Wizards schnell zusammengeklickt und generiert. Aber wie gut trägt dieser Code auf 5 oder 10 Generationen eines Produkts gesehen? Wie gut lässt sich ein System aus 500 generierten EJB-Klassen und 180 generierten XML-Dateien an neue Gegebenheiten anpassen? Lassen sich die Änderungen und Bugfixes genauso einfach generieren? Oder habe ich enormen Aufwand, mich in die Denke des Wizards hineinzufinden?

Smalltalks Stärke ist neben der dynamischen Sprache die Tool-Umgebung, angefangen beim Klassenbrowser über Inspektoren bis hin zum Debugger. Die Tatsache, dass man ein System während des Laufens am offenen Herzen operieren kann, und rückwärts gehen, neu probieren und die Ergebnisse sofort sehen und ggf. weiter verbessern kann, macht Smalltalk vor allem in der Wartung eines Systems bisher unerreicht produktiv. Leider kann man das sehr schwer vermitteln, man muss es erlebt und ausprobiert haben.

Diese Vorteile in der Wartung  sind auf10 Jahre Projektlaufzeit sehr viel schwerwiegender, als ein paar tausend Euro Lizenz- oder Supportkosten auffressen könnten.

Und hier schliesst sich auch wieder der Kreis zu Robert Martins Zitat von Ward Cunningham. Martin gibt nur einen Teil wieder: It’s easy to make a mess in Smalltalk. Der zweite Satz ist aber viel wichtiger und kam in Martins Vortrag leider nicht vor: but it’s also easier to get out of the mess than in other languages (hier nur sinngemäss wiedergegeben).

Zu allerletzt noch ein paar Tipps zum Thema Smalltalk und Investitionen:

  • Es gibt kostenlose Smalltalk-Umgebungen, wie Squeak, Pharo, Smalltalk/X und GNU Smalltalk
  • Es gibt kostengünstige Smalltalk-Umgebungen wie Dolphin oder Smalltalk MT
  • Gemstone hat eine sehr interessante Option für kleinere Web-Applikationen, die kostenfrei ist (bis 4GB Speicherplatz, nur 1 CPU), und das sogar für den kommerziellen Einsatz (kein garantierter Support)
  • VA Smalltalk und VisualWorks können kostenlos (aber auch ohne garantierten Support) genutzt werden, solange kein Geld damit verdient wird. Man kann also seine Web 2.0 – Startup -Entwicklung zunächst kostenlos starten, und erst, wenn der Versuch einer Gewinnerzielung unternommen wird, müssen Lizenzgebühren entrichtet werden
  • Open Source gibt es auch im Smalltalk-Umfeld, und z.B. Instantiations und Cincom unterstützen open-source-Entwickler sogar mit kostenlosen Lizenzen – einfach mal anfragen

Nicht zuletzt scheint mir auch folgendes Offensichtlich: “Kommentare nach dem Muster: ich würde wirklich gerne Smalltalk nutzen, aber …” zeigen doch, dass an dem einen oder anderen Argument pro Smalltalk was dran ist, sonst wäre die Diskussion gar nie aufgekommen…😉

4 thoughts on “Smalltalk ist zu teuer! …. ist es doch?

  1. Marten,

    gut, dass wir uns einig sind😉
    Schliesslich bin ich auch der Überzeugung, es kommt nicht auf Produktivität bei der Erstellung neuen Codes an. Hier sind andere Tools inzwischen häufig um Welten besser.

    Wichtig ist die Frage, wie gut man seinen Code später verstehen und verändern kann. Hier ist Smalltalk nach wie vor ziemlich unerreicht.

    Die Frage der Schnittstellen und Add-Ons ist eine weitere, aber ganz andere: kann ich mich mit Smalltalk an ein SAP, Archivierungssystem oder Sharepoint problemlos anflanschen? Wie gut ist die Integration? Hier ist vieles noch unmbekanntes Terrain, da hast Du leider Recht. Aber das sind natürlich auch sehr projekt-individuelle Fragestellungen (Naja, bei SAP muss ich vielleicht einschränken…), und nicht jedes Projekt muss in diese Systeme integriert werden.

    Allerdings würde ich auch da ein Stück weit in Widerrede zu Dir treten wollen: Technologien wie Web Services (man mag sie mögen oder nicht), halten hier zunehmend Einzug und öffnen die Produkte für eine Programmiersprachen-neutrale Welt. Natürlich wird ein Sharepoint immer leichter per C# oder VisualBasic anzubinden sein, als in Ruby oder Smalltalk. Aber das ist ja nicht direkt diesen Sprachen anzulasten😉

    Und wie Du schon sagst, solche Add-Ons können den Kostenvorteil einer Sprache ganz enorm beschränken…

  2. Ich glaube, dass man die Produktivität immer wieder überbewertet – auch wenn das keiner öffentlich sagen würde.

    Es sind andere Faktoren, die die Entscheidungen beeinflussen.

    a) Darunter fallen unter anderem Investitionssicherheit. Den Mainstream-Weg zu gehen bedeutet groessere Investitionssicherheit. Aus der Sicht des Kunden und auch des Softwareanbieters.

    b) aus der Sicherheit von Kunden/Softwareanbieter bedeutet eine Nähe zu wesentlichen Betriebssystemanbieter eine bessere Integration.

    Wenn der Punkt b) nicht so wichtig ist, dann kann a) den Ausschlag geben und Java kommt ins Gespräch. Wenn b) überwiegt, dann ist .NET für die Zukunft Pflicht.

    Bei Standardsoftware kann Smalltalk seine bessere Produktivität überhaupt nicht mehr ausspielen, weil man die gewonnene Produktivität in zahllosen Anbindungen wieder verliert – die nun einmal nicht vorhanden sind.

    Es ist aber nicht so, dass z.B. VS2008 alles für das fertige Produkt anbietet – es sind eher sehr rudimentäre Basislösungen, die MS hier mitliefert. Es sind die kostenlosen/kostenpflichtigen AddOns, die das ganze sehr charmant machen.

    Die Kosten ? Na ja, .NET Entwicklung ist auf höheren Niveau nicht billig und Smalltalk steht nicht unbedingt schlechter da (sieht man vom Lizenzmodell von Cincom ab).

    In einer von der Umgebung relativ losgelösten Suche nach einer Lösung kann Smalltalk mithalten – aber ansonsten hat es Schwierigkeiten.

  3. <p>Hmm, ja ein bisschen viel Geheimnistuerei ist da um Dolphin NG herum schon im Spiel, und ich habe auch manchmal das Gefühl, dass es sehr vollmundig zugeht bei all den Ankündigungen.<br />
    Smalltalk MT wird noch entwickelt. Zitat von der Website http://www.objectconnect.com: Version 5.5 supports Microsoft Windows 2000, Windows Xp, Windows Vista and Windows Server 2003. It includes foundation classes for DirectX 9 development and supports DirectX 10 development. </p>
    <p>Smalltalk/X ( http://www.exept.de ) ist defintiv interessant und gemeinhin unterschätzt. Sehr mächtig und gut gepflegt. Leider sind die Oberflächen nicht sehr Plattformnah, aber das gilt ja auch für andere Vertreter der Zunft…</p>

  4. Dolphin ist halt quasi-tot und das Drumherum um Dolphin NG klingt ein wenig merkwürdig.

    Smalltalk MT – wird das eigentlich noch wirklich entwickelt?

    Smalltalk/X dagegen sieht sehr interessant aus …

Comments are closed.