Robert Martin auf der RailsConf 09: “What killed Smalltalk Could kill Ruby too”


Robert Martin von Object Mentor hat auf der RailsConf einen hervorragenden Vortrag gehalten. Der Titel ist vielleicht ein wenig sensationslüstern, aber ich denke, das passt zum Anlass.

Der Vortrag ist wirklich wert, angesehen zu werden. Sehr amüsant und vollgestopft mit ironisch servierten Wahrheiten. Das Video ist z.B. hier zu finden.

Martin hat weder Recht mit der Aussage, dass Smalltalk tot sei, noch glaube ich, dass er es so gemeint hat. Aber in vielem hat er  Recht: Smalltalk ist nicht so verbreite, wie es sein sollte, und es hat nicht die Bedeutung erlangt, die es verdient hätte. Die meisten Gründe, die er dafür nennt, sind richtig: selbst die Sache mit der Arroganz ist so, wie er sie darstellt, leider absolut wahr, zumindest für die Vergangenheit.

Interessant sind aber auch die Kommentare im Web zum Thema, so z.B. auf Robertsons Blog Post zu Martins Vortrag oder bei Giles Bowkett, der auf seine ganz eigene Art darüber schreibt😉. Einige Smalltalker haben den Titel wohl tatsächlich ernst genommen, und versuchen mt aller Gewalt, zu beweisen, dass Smalltalk nicht tot ist…. Das spricht für sich und ist wohl völlig unnötig😉

Für Smalltalk-Enthusiasten und Leute, die  sich gerne mal von einem der “alten Herren” inspirieren lassen, ist das Video ein echter fünf-Sterne – Tipp. Amüsant und lehrreich, was will man mehr?

6 thoughts on “Robert Martin auf der RailsConf 09: “What killed Smalltalk Could kill Ruby too”

  1. Claus,

    ich denke, ich habe das mit der Rechnung schon verstanden. Ist ja nicht wirklich ein neues Argument. Diese Argumente schlagen ja immer wieder entgegen, und das schon seit ich mit Smalltalk zu tun habe (auch schon rund 13 Jahre, Mann, wie schnell man altert…). Aber es ist halt kurz gedacht – manageral eben😉

    Die redundanten Implementierungen werden immer weniger. Je mehr Open Source Einzug in die Smalltalk-Welt hält, also je verbreiteter GLORP, Seaside, Pier, AIDA, sUnit, der Refactoring Browser oder SmallLint werden, desto mehr werden die Hügel abgetragen. Die Anbieter selbst bauen natürlich noch ein Stück weit ihre eigenen Kisten, aber das ist woanders nicht wirklich anders.

    Für ein Projekt stellt sich m.E. die Problematik nur dann, wenn eine open-source-Komponente noch nicht auf den eigenen Lieblingsdialekt portiert wurde😉
    Ansonsten ist es eher selten so, dass man wirklich code für verschiedene Smalltalk-Plattformen baut.
    Man sei denn, man wäre selbst ein Tool-Anbieter…

    ZU Deinen letzten beiden Argumenten:
    Strategische Partner: Diesen Unfug treiben fast alle große Unternehmen und machen sich selbst das Leben schwer. Man baut extra große Hürden auf, die ständig mit den raffiniertesten Tricks und besonders hohen Eskalatonsstufen umgehen muss. Mit Smalltalk hat dieses Problem allerdings nur insofern zu tun, als vielleicht weder Cincom noch Instantiations bisher auf der Liste stehen. Für einen Tool-Anbieter ist es nach meiner Erfahrung relativ leicht, auf die Liste uz kommen. Als Beratungshaus hat man es da schon sehr viel schwerer…

    Ablehung weil nicht bekannt: auch hier wird immer mit mindestens zwei Massen gemessen. Wenn diese Regel nämlich immer gälte, würden wir weder Java noch Ruby in irgendeinem Unternehmen wiederfinden, denn sie wären nie hineingekommen.
    Ich gebe nun schon seit einiger Zeit Smalltalk-Schulungen und coache Smalltalker (aber auch Javajaner) und muss sagen, es ist lernbar. Klar kostet es Geld, aber es bringt vielleicht mehr, als Mainstream-Leute mit mittelmässigem Wissen und mässiger Erfahrung in einer Mainstream-Technologie einzukaufen.

    Man kann, nebenbei bemerkt, auch wirklich üblen Smalltalk-Code erben. Da wurden auch Leute nach einer Woche Schulung als Smalltalk-Spezialisten verkauft. Das ist natürlich kein Privileg von Java. Aber die Überlegung, es gibt da draussen milliarden Java-Spezialisten zum kleinen Preis und nur eine handvoll sauteurer Smalltalk-Gurus da draussen, ist leider auch sehr verbreitet. Dabei gibt es heute sicher mehr Leute mit Smalltalk-Kenntnissen, als noch vor 8 oder 10 Jahren. Und Ruby-Entwickler können Smalltalk sicher auch sehr schnell lernen. Auch gute JavaScript oder Perl-Leute sind sicher schnell in Smalltalk zuhause. Vielleicht schneller als ein Java-Entwickler, der bisher nur mit Framework X gearbeitet hat, aber nun in Tool y arbeiten soll…

    Achja: Dolphin ist nicht tot. Es wird wieder daran gearbeitet und es wird wohl noch dieses Jahr eine Beta-Version einer ganz neuen Implementierung auf Basis der VM von LSW Vision Smalltalk geben. Eine deutsch-britische Kooperation also …

  2. Lieber Joachim,

    nur um Missverständnisse zu vermeiden – ich stelle als Entwickler nicht diese Rechnung auf, sondern mein Upper Management, ich bin eigentlich ziemlich ganz Deiner Meinung.

    Ein paar Kommentare:
    Die Dialektbezogenheit stört mich nicht weiter, das Problem ist und bleibt die Notwändigkeit der redundanten Implementierungen, das kostet meiner Meinung nach einen HAUFEN Geld, der jedem Hersteller für Weiterentwicklung fehlt.

    Eclipse vs. Smalltalk IDE:
    Ich finde, in dem Vergleich kommen die Smalltalk IDEs noch gut weg. Wenn Du allerdings IntelliJ kennst, das ist schon etwas anderes als Eclipse. Gut, es kostet Geld, aber halt €528 (http://www.jetbrains.com/idea/buy/index.jsp) ist halt etwas weniger, so auf dem Niveau war Dolphin Smalltalk.

    Wenn man bedenkt, dass IntelliJ gerade beim J2EE einen wahnsinnigen Integrationslevel erreicht hat, für diesen Preis.

    Der GUI Builder von Netbeans ist übrigens auch nicht schlecht, kann zwar nur AWT und Swing, aber das ziemlich gut.

    GUI-Builder als Kriterium ist ziemlich problematisch, da man bei nicht-statischen GUIs sowieso selbst Hand anlegen muss.

    Aber das nur nebenbei.

    Es gibt noch zwei weitere Probleme:

    1. Strategische Partner

    Bei meinem Arbeitgeber gibt es strategische Partner. Deren Produkte sind bevorzugt zu verwenden, da ist sogar Java auf dem absteigenden Ast.

    2. Smalltalk wird abgelehnt, da man es nicht kennt, dann gibt es keine Leute, welche das übernehmen können … usw.
    Ich weiss zwar auch, dass man Java-Code erben kann, den man nicht mehr versteht und stattdessen neu schreiben muss.
    Management weiss das nicht. Da steht dort, Java-Projekt, dann sagt Management, “da finde ich schon jemanden, der das kann”. Um es mal kurz zusammenzufassen.

  3. Hallo Claus,

    einige der von Dir angesprochenen Probleme sind in Arbeit. So wird zunehmend der ANSI-Standard in die Umgebungen eingebaut, und Projekte wie Seaside, die auf vielen Smalltalk-Umgebungen portiert werden, zeigen zunehmend die Notwendigkeit dazu auf.

    Auch der ANSI-Standard soll ja überarbeitet werden.

    Die Dialektbezogenheit der Communities weicht auch zunehmend auf. Gerade open source-Projekte wie der Refactoring Browser, sUnit, Seaside, AIDA, SWiki und noch einige mehr sind auf praktisch allen Umgebungen vorhanden und portierbar.

    Die Dialektbezogenheit der Hersteller ist systembedingt und wird nicht zu überwinden sein, schliesslich will man Marktanteile gewinnen, und braucht dazu Alleinstellungsmerkmale. Aber auch hier ist ein Umdenken zu spüren.

    Ist Dialektbezogenheit für ein Projekt wirklich relevant? Für Frameworks und Tools wie die vorgenannten ganz sicher, aber wie steht es um ein In-House Projekt einer Bank oder Versicherung? Wird da häufig zwischen Smalltalk-Umgebungen hin und her migriert? Muss ein Oracle und ein DB2 wirklich 100% kompatibel sein? Ich glaube, hier werden öfters mal Argumente konstruiert, die seltsamerweise in anderen Umfeldern nicht bemüht werden.

    Das ewige Preisargument… Tja, schauen wir doch mal genauer hin. Eclipse ist toll und hat in einigen Bereichen wirklich auch einem VisualWorks oder VA Smalltalk noch viel Voraus.
    Dafür versagt es bei Dingen fulminant, die VA Smalltalk oder VisualWorks seit 15 Jahren brillant beherrschen. Was ist ein Eclipse ohne GUI-Builder? Wenn man Web-Anwendungen baut, sehr gut. Wenn man Rich Clients baut, sieht es schon anders aus…. Dafür gibt es dann kommerzielle Plugins, die Eclipse enorm aufwerten. SWT Designer oder RCP Developer sind hier sicher gute Kandidaten.

    So kauft man sich mal hier ein Plugin für 300 Euro, dort ein Plugin für 80 und hier wieder eins für 39 US-Dollar. Unterm Strich kämpft man dann mit Inkompatibilitäten und sonstigen Problemen, und gibt auch 500 oder 1000 Euro pro Arbeitsplatz aus.

    Und steht mit Problemen oft ziemlich alleine da, weil kein Support. Da gibts natürlich auch Lösungen für, die aber auch einen kleinen Obulus kosten.

    Von IBM’s RAD wollen wir nun bei der Preisdiskussion mal gar nicht sprechen, da sieht ein VA Smalltalk wirklich nicht schlecht aus.

    20% Produktivitätsvorteil klingt wenig, ist aber bei einem Projekt mit 10 Entwicklern und einer Projektlaufzeit von 8 Jahren inklusive Wartungsphase eine Stange Geld.

    Ich möchte eigentlich nicht unhöflich gegenüber netten Kommentarschreibern sein, aber der Begriff Milchmädchenrechnung muss einfach raus😉

  4. Smalltalk hat finde ich zwei grosse Probleme:

    1. Die verschiedenen Dialekte, es gibt keine einheitliche Standard-Klassen (siehe String & Symbol), kein sauberes Import/Export-Format.

    Das führt dazu, dass viele Sachen eben für jeden Dialekt implementiert werden müssen, anstelle ein echtes “write once, run everywhere” zu haben.

    Die kommerziellen Anbieter sind auch nicht gross genug um wirklich alles selbst machen zu können und die Communities sind Dialekt-bezogen.

    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.

    Das Beste wäre, wenn Oracle anfinge, für Java Geld zu verlangen. Dann wäre Smalltalk wieder echte Konkurrenz.

  5. Hallo Mouse,

    Ich fand den Vortrag ganz gut, und habe mich nicht wirklich genötigt gesehen, Smalltalk zu verteidigen. Aus meiner Sicht will er den Ruby-Youngstern (und die meisten Zuhörer scheinen sehr junge Leute zu sein) einfach klar machen, was man nicht tun sollte, um eine ähnliche Schattenexistenz führen zu müssen, wie Smalltalk. Für mich ist Smalltalk auch nicht tot, aber eben nach wie vor nicht mainstream genug, um die Annahme, es sei tot, wirksam wiederlegen zu können. Ob man unbedingt im Mainstream sein muss, um eine gute Basis zur Entwicklung von Softwaresystemen zu sein, steht auf einem völlig anderen Blatt😉

    Smalltalk ist ganz und gar nicht irrelevant und auch weit davon entfernt, nur noch Geschichte zu sein. Es beeinflusst noch immer viele neue Entwicklungen, und in Sachen Produktivität und Entwicklungsgeschwindigkeit ist es nach wie vor erste Sahne. Aber es gibt inzwischen auch vieles, was man von neueren Sprachen und Systemen lernen und übernehmen kann. Und in diesen Punkten muss ich Martin recht geben: Smalltalk hat hier lange Zeit keine Entwicklung mehr mitgemacht, und hat nun einiges aufzuholen. Die Jagd ist allerdings eröffnet, und es tun sich viele Interessante Dinge und Entwicklungen auf. Seaside ist da nur ein Vertreter einiger interessanter Themen, ich denke, auch AIDA ist sehr interessant.
    Squeak ist da sicher der Hauptschauplatz, auch was etwa das iPhone angeht.
    Unterhaltsam ist der Vortrag auf jeden Fall…

  6. Nun – der Vortrag von Mr. Martin versucht eher zu provizieren, als mit komplette Wahrheiten zu glänzen.
    Dem geneigten Leser/Hörer Deines Blogs empfehle ich hier die Episode 81 der Industry Misinterpretations mit dem von Herrn Martin oft zitierten Ward Cunningham (Erfinder des WikiWiki) höchstpersönlich als Gast
    (http://www.cincomsmalltalk.com/blog/blogView?entry=3384371378)

    Smalltalk ist durchaus nicht tot – vor allem im nichtkommerziellen Umfeld wurde mit Squeak, Pharo, Seaside, OpenCroquet, EToys usw völliges Neuland betreten und eine ganze Menge junge Leute angezogen. Die führen auch nicht den Glaubenskrieg der Sprachen, sondern finden es einfach nur toll in einer interaktiven dynamischen Umgebung zu arbeiten. Herr Martin als alter C++’ler glaubt offensichtlich schon noch daran, nun endlich den Smalltalkern eins auswischen zu können😉

    Smalltalk is dead – long live Smalltalk!

Comments are closed.