The “feels like dynamic” trend

I found an interesting tweet by Gilad Bracha through pharoproject:

Mainstream programming language syntax is like human sacrifice: evil, yet once entrenched, difficult to get rid of.

But one answer to it is even nicer:

Every new typed programming language says it “feels like a dynamic language”. What does this tell us about how typed languages feel?

Indeed there is so much going on in order to make Java or C# more and more “like” dynamically typed languages by introducing more and more complex language features and disabling type checking (by using Reflection for example). More and more languages try to achieve the flexibiliy and effectivity of dynamically typed languages (most of the times only getting close with some tricky side effects). Now that even Objective-C gets Blocks for Grand Central Dispatch, shouldn’t people just try and see if the real thing is even better? Why not try Ruby or  – even better – Smalltalk?

ESE 2009: Don Syme über F# und Funktionale Programmierung

Hier in Ludwigsburg findet aktuell ja das Eclipse Summit Europe statt. Es sind rund 400 Leute dabei, und es gibt eine Menge zu lernen über Eclipse, einige der wichtigsten Eclipse-Projekte und die neuesten Entwicklungen zu Eclipse4 (kurz e4), dem noch etwas vagen und für manch einen auch sehr esoterischen nächsten großen Meilenstein in Eclipse.

Zwar ist mir noch niemand über den Weg gelaufen, der mir mit meinem DataBinding-Problem weiterhelfen kann, aber dafür gibt es eine Menge an Informationen und Eindrücke zu bewältigen.

Als Business Partner von Instantiations sind wir natürlich auch dam um Dan, Jaime und Nick zu unterstützen und Interessenten über die Neuerungen der Instantiations-Tools zu informieren. Aber das ist eine andere Geschichte…

Die heutige Keynote war bemerkenswert. Nicht nur, weil Don Syme für Microsoft arbeitet, sondern auch, weil er nicht über Java, sondern über F#, eine funktionale Programmiersprache von MS, und dabei für seine Demo nicht Eclipse, sondern VisualStudio benutzt hat. Und trotzdem wurde den ganzen Tag über an den Tischen und in den Kaffeegrüppchen darüber gesprochen, und nicht etwa, um ein Urteil über seinen dreifachen Frevel zu fällen, sondern um über funktionale Programmiersprachen, Type Inferencing und Scala zu diskutieren.

Und in der Tat war seine Keynote ein Highlight. Er zeigte einige sehr eindrucksvolle Beispiele, wieviel kompakter und verständlicher F# Code sein kann, verglichen etwa mit C#. Neben einem kurzen Schweinsgalopp durch die wichtigsten Sprachkonstrukte von F# und die Kernkonzepte funktionaler Programmierung brachte er auch einige gewichtige Argumente für funktionaler Programmierung zur Sprache:

  • Die Lästigkeit des vielen Syntax-Rauschens in Java oder C# verglichen mit FP
  • Die ökonomischen Effekte durch wesentlich niedrigere Fehlerraten (bekannter Weise sind die Codezeilen, die nie geschrieben wurden, die am wenigsten fehleranfälligen)
  • Den Spass am Programmieren, der in C# oder Java leider allzu oft verloren geht

Als Smalltalker fühlte man sich immer wieder an die eigene Umgebung erinnert, nicht zuletzt, als er in F#interactive in der Manier eines Workspaces Code-Schnipsel für Codeschnipsel mit der Maus selektierte und per “Execute”-Menü bzw. Tastenkürzel ausführte.

Die ersten Code-Beispiele waren dann auch noch sehr “normal” und da man in F# (wie übrigens auch in Scala) keine Typeninformationen eintippen muss, fühlt sich das ganze für einen Smalltalker sehr vertraut an.

Aber FP ist noch deutlich mehr: die FP ermöglicht es, Funktionen zu definieren und praktisch als Objekte immer wieder zu verwenden. Ähnlich vielleicht wie Smalltalk-Blocks, aber eben irgendwie auch anders. Durch Definition einer Funktion kann Code extrem kompakt gehalten werden (man ist ab und an im Hinterkopf den Begriff Makro zu bemühen, aber ein Makro ist ja nur ein Precompiler-Trick um Schreibarbeit zu sparen, und ist nicht der richtige Vergleich).

Die Trends, die aktuell in OO-Sprachen zu beobachten sind, so Syme, sind genau die Stärken der FP:

  • Immutable Data
  • Abfragesprachen in der Programmiersprache eingebettet
  • Lambda-Funktionen
  • Pattern Matching als Sprachelement
  • Einfache Syntax
  • Reduktion von Seiteneffekten

Genau diese sieht Syme in F# realisiert. Die Funktionale Programmierung wird aktuell ja als einer der vielversprechendsten Ansätze gesehen, um die Umsetzung von Programmen für Multiprozessor- und Multi-Core-Architekturen zu schreiben. Eine Funktion ist in sich abgeschlossen, operiert auf isolierten, unveränderlichen Daten und erzeugt neue, und kann daher isoliert auf einem Prozessor oder Core parallel ausgeführt werden.

Die Sprache F# hat zwei wesentliche Urpsünge: OCaml als Ideenlieferant für die Syntax und C# wegen des gemeinsamen Objektmodells.

Ein sehr wichtiger Aspekt, den Syme anspricht, ist die Tatsache, dass ein F#-Programm nahtlos in ein .Net-Umfeld eingebettet werden kann. Jede andere .Net-Sprache kann auf F#-Komponenten zugreifen, und umgekehrt natürlich auch. Dasselbe gikt für Scala, das ja nahtlos mit Java interoperieren kann.

So macht es möglicherweise Sinn, den GUI-Code in C# (Im Sinn: Java/Eclipse) zu schreiben, und die Business-Logik in F# (behalte Scala) umzusetzen.

FP hat das Zeug dazu, die Objekttechnologie abzulösen bzw. einen Schritt weiter zu bringen. Java, C# etc. sind Sprachen, in denen sehr viel technisch motivierter Krimskrams programmiert werden muss, den man sich in der FP sparen kann. Die Ansätze in JavaScript, Scala und F# dazu sind vielversprechend. Vielleicht ist Jave wirklich bald mehr eine Plattform als eine Programmiersprache, und vielleicht bewegen wir uns bald wieder auf einem neuen Terrain, der funktionalen Programmierung.

Ich wäre dabei. Die ganze Umgebung und die Denkweise in Scala oder meinetwegen F# ist einem Smalltalk-Entwickler sehr vertraut. Und doch gibt es einige neue Ideen und Konzepte zu entdecken und zu nutzen.

Achja: F# hat auch etwas, das mich doch sehr verwundert hat: Whitespace matters. Das heisst, es ist für Zeilen in einer Funktionsdefinition zwingend erforderlich, dass sie mit einem Tab eingerückt sind. Ich musste unweigerlich an Cobol und PL/1 denken, und habe innerlich den Kopf geschüttelt. Aber vielleicht gibt es ja eine gute Erklärung für diese Design-Entscheidung… Zumindest gibt es so keine Glaubenskriege über Einrückungen oder den richtigen Platz für schliessende Klammern… ;-)

SWT auf Cocoa 64 bit mit Galileo

So, nun ist es wieder mal soweit. Ich weiss nicht weiter.

Inzwischen läuft mein Eclipse Galileo ziemlich rund. Alles ist JVM 1.6 und 64 Bit. Auch der WindowBuilder läuft rund, und ich kann die meisten meiner SWT-Dialoge nutzen. Klar, das übliche “Mac-Buttons sind aber ein bisschen höher als die von Windows” und “Labels sind ein bisschen breiter auf dem Mac”, aber es hat mich ja auch keiner gezwungen, ausgerechnet ein GridLayout zu nutzen…

So ganz habe ich den richtigen Weg für wirklich portable SWT-Oberflächen noch nicht gefunden.

Also eigentlich alles toll und großartig, wäre da nicht noch eine Kleinigkeit:

java.lang.ClassDefNotFoundError: org/eclipse/core/databinding/property/value/IValueProperty

beim Start einer Shell mit DataBindings aus SWT 3.4 (übernommen vom JDK 1.4). Der Allmächtige G konnte mir auch nicht weiterhelfen. Imports sind soweit okay, denke ich, ein Package mit dem Namen

org.eclipse.core.databinding.property

gibt es nicht, weder auf meinem Mac, noch sonstwo, sagt G. Und irgendwie scheint das alte DataBinding-Zeugs auch nicht deprecated zu sein.

Wer weiss Rat? Wahrscheinlich wieder irgend so ein kleines “Achja, stimmt, wenn Du auf orgMyMac64.galileo.org/swt/cocoa diese 24 dingers da nach Dropins legst, dann geht’s. Steht übrgens schon seit April auf TheUltimateEclipseGuru.org”

Naja, vielleicht finde ich morgen auf dem Eclipse Summit jemanden von UltimateEclipseGuru ;-)

IntelliJ wird open source oder: was vom Java-IDE-Markt übrig bleibt

Auf  heise ist es nachzulesen: JetBrains gibt IntelliJ IDEA in Zukunft als open source frei und bietet neben einer kostenlosen “Community edition” eine kommerzielle “Ultimate edition” an.

Das jagt einem (also zumindest mir) einen Anflug von “das musste ja kommen” durch den Kopf. Die Macht, mit der Eclipse den Markt von Java- Entwicklungstools überrollt hat, hinterlässt ihre Spuren. JetBrains steht zu wünschen, dass das Kalkül aufgeht, eine freie Edition wird zumindest einige Leute dazu animieren, die Ultimate edition zu kaufen. Aber ich hege da so meine Zweifel: was, wenn sich nach und nach zeigt, dass es zunehmend Erweiterungen für IDEA gibt, die aus der open source-community kommen? Wieviele Entwickler werden wohl mit IDEA in seiner community edition zufrieden sein?

Natürlich ist es für eine kleine Softwareschmiede auch sehr schwer, gegen viele hundert Millionen Dollar schwere Gorillas wie IBM und die später hinzugekommenen Eclipse-Financiers zu halten: wie schnell kann man neue Features einbauen, wie lange kann man sich gegen den bestechend günstigen Preis einer Plattform ankämpfen, die rasant schnell voran schreitet und mit enorm vielen Plugins erweiterbar ist, die aus allen Richtungen auf den Markt kommen, in unterschiedlichster Qualität und mit Preisen von kostenlos bis zu einigen tausend Euro?

Vieles spricht dafür, sich einfach in diesen Sog hin zum Mainstream zu begeben, im Eclipse-Strom mitzuschwimmen, und sich darauf zu verlassen, dass die große Zahl der Nutzer und Geldgeber schon dafür sorgen werden, dass man es mit einem erstklassigen Werkzeug zu tun hat, und sich für jedes Problem jemand finden wird, der es schon gelöst hat, oder der sich helfend auf den Plan werfen wird, um es zu lösen, und das ganz sicher genauso kostenlos.

Leider ist das ein Trugschluss. Es ist nicht nur naiv, sondern geradezu fatal, zu glauben, dass, was kostenlos herunterzuladen ist, auch kostengünstig einzusetzen ist. Ich versuche seit geraumer Zeit, Mit Eclipse Galileo einen Workspace aufzusetzen, indem ich SWT-Anwendungen für Mac OS X unter Java 1.6, also 64-bittig, entwickeln kann. Kann alles nicht so schwer sein, alles auf der Eclipse-Seite herunterladbar.

Pustekuchen. Es kompiliert nicht, man findet keine Dokumentation dazu, und selbst die Download-Links sind teuilweise falsch. Plötzlich bekommt man was kompiliert, aber beim Start der Anwendung heisst es, man habe ja die 32-Bit-Variante von SWT, und die laufe nicht auf der JVM 1.6 (die auf dem Mac eben ausschliesslich in 64 bit verfügbar ist). Ganz sicher gibt es mein Stück Dokumentation irgendwo, und gantz sicher haben schon zig Leute das Ding am Laufen, und es ist auch alles ganz einfach, wenn man die 3 wichtigsten Tipps zum Thema mal gefunden hat.

Und genau da haben wir’s: wo sind sie? Auf Eclipse.org sind sie nicht, oder sie verstecken sich noch vor mir. Auf diversen Usenet-Foren habe ich nichts gefunden, und auch eine Google-Suche habe ich noch nicht formulieren können, die mir weitergeholfen hätte.

Kostenlos und open source kann eben auch bedeuten, dass man schlichtweg verloren hat, wenn’s nicht klappt. Von wegen “Ruf mich an!” wenn’s Probleme gibt. Ich kann ja mal bei IBM anrufen, die helfen mir sicher gern. Tagessatz sicher oberhalb dessen, was IDEA an Lizenzkosten inklusive Support gekostet hätte.

Im kommerziellen Umfeld ist es nur bedingt förderlich, wenn ein vermeintlich kleines Konfigurationsproblem ein paar Tage Projektverzögerung bedeutet, die man mit Google und verzweifeltem Selbstversuch verbringt. Man ist nachher ein Projektmitglied mit extrem angesehenem Spezialwissen, das steht ausser Frage. Es ist gut, solche Spezialisten im Hause zu haben, vor allem, wenn man weiterhin mit solchen Werkzeugen arbeitet. Aber es ist auch teuer. Nicht unbedingt, weil solche Spezialisten hoch bezahlt wären, sondern vor allem, weil sie sehr viel Zeit unproduktiv vergeuden, um Probleme zu lösen, für die man bei einem Hersteller wahrscheinlich wesentlich weniger bezahlt hätte.  Hinzu kommt, dass ein verzweifelt Suchender möglicherweise nicht nur Kosten durch seine eigene Ablenkung vom Wesentlichen verursacht, sondern möglicherweise ein paar Dutzend Kollegen in ihrem Projektfortschritt bremst. Da sind die Kosten für Support oder Lizenzen mit Support sehr schnell amortisiert, man kann sowas manchmal in Stunden zählen…

So hat eben alles seine Vor- und Nachteile. Wir können uns als Entwickler nun über eine weitere hervorragende und kostenlose Entwicklungsumgebung freuen, und glücklicherweise können wir uns für die ultimate edition entscheiden, um o.g. Szenario weitestgehend zu vermeiden. Solange sich das Modell trägt.

Eins ist und bleibt klar: Irgendjemand muss jedoch die Zeche zahlen. Wenn das Modell aufgeht und funktioniert, sind es die, die den Support brauchen.

Wenn nicht, verschwindet eine tolle IDE sehr schnell vom Markt.

Jetzt sind die User dran.

Studie beweist: Java führt ins Chaos

Nein, langsam, nicht gleich drüberblättern, es gibt sie wirklich, die Studie, sogar Heise hat darüber berichtet…

Also, mal ganz langsam, und von vorne. Da gibt es eine Firma, die hat eine Studie mit dem Titel “Java Trendbarometer” durchgeführt.

Zitat heise:

An der Studie, die im Mai 2009 durchgeführt wurde, beteiligten sich 82 deutschsprachige Java-Fachleute, von denen die meisten regelmäßig als Externe in Kundenprojekten arbeiten.

Immerhin hat niemand behauptet, die Studie sei repräsentativ ;-)

Was also sagen die 82 Spezialisten? Ihr Java-Projekt ist unter dem deckmantel der Agilität eine ziemlich chaotische Veranstaltung. Noch ein Zitat aus dem Heise-Artikel:

So empfinden 75 Prozent der Teilnehmer die Bedeutung der Qualitätssicherung in ihren Projekten als “zu gering”.

Der mitdenkende Leser hat nun sicher schon bemerkt, dass diese Feststellung an sich einen eher zufälligen Zusammenhang mit der eingesetzten Methodik oder gar Programmiersprache aufweist.
Wenn man also mal die Fakten sortiert, kann man diese Aussage der Studie zumindest auf folgende Kernaussage reduzieren:

In Deutschland existieren mindestens 61,5 Java-Fachleute, die meist als externe regelmässig in Java-Projekten arbeiten und mit der Qualitätssicherung im Projekt eher nicht zufrieden sind.

Hmm.
Bedenkliche Zustände am deutschen Java-Markt.
Wenn man das mal global hochrechnet auf alle Java-Projekte weltweit….

Java ist offenbar der direkte Weg ins Chaos.
Ich hab’s ja immer gesagt.
Vielleicht sollte ich mir ein Schild vor die Brust hängen und in der Fussgängerzone Javageddon verkünden und der Welt einen Dienst erweisen.

Noch eines muss zitiert werden:

Die Qualität leide unter der häufig sehr stark termingetriebenen Entwicklung.

Ein Glück, dass das in Projekten in anderen Programmiersprachen nicht passieren kann…

Galileo / SWT jetzt auch Cocoa-fähig

Es gibt ein Leben ausserhalb des Smalltalk-Image. Auf dem Mac gibt es das sogar recht oft, denn ein Smalltalk mit nativer Oberfläche gibt es leider noch nicht, seit der Status von Ambrai ja ein sehr fragwürdiger ist.

Darum, und weil man einfach ab und an auch mal was in Java machen muss oder möchte, ist Eclipse immer mit an Bord.

Heute ist ja Galileo-Tag, d.h. die neuste Version von Eclipse wird heute als offizieller Download freigegeben. Neben vielen Verbesserungen in einigen Projekten, die man vielleicht auch nicht unbedingt braucht, gibt es aber insbesondere für Macies gute Nachrichten: SWT unterstützt nun Cocoa. Bisher wurde nur Carbon unterstützt, was nur unter 32 Bit und damit nicht mit Java 1.6 lief.

Ab sofort können also mit Eclipse und SWT echte Cocoa-Oberflächen gebaut werden, und das auch in 64 bit.

Damit ist meine spärliche Freizeit für die nächsten Tage also verplant, denn es warten ein paar kleinere Projekte auf ihre Cocoaisierung…

IBM will SUN kaufen?

Laut Spiegel und heise (die sich wiederum auf das Wall Street Journal berufen) laufen derzeit Gespräche zu einer Übernahmen von Sun durch IBM. Uff. 6,5 Milliarden sollen da über den Tisch gehen, wenn’s denn klappt.

Nun, wie sinnvoll könnte dieser Deal sein?

Solaris. Als Konkurrent zu AIX sicher halbwegs ernst zu nehmen. Gerade im Finanzumfeld hat sich Solaris eine Nische aufgebaut, in der diese Solaris-Dinger nicht mehr so leicht wegzudenken sind. Da könnte man sicher was verdienen, und einen Konkurrenten ausschalten. Bliebe dann noch Hewlett Packard ;-))))

Sun hatte ja vor einiger Zeit MySQL für eine Milliarde gekauft. Das dürfte einer der weniger intelligenten Deals von Sun gewesen sein. Die MySQL-Gemeinde war hier nicht sonderlich begeistert, und viel verdient hat Sun da sicher auch nicht. IBM hat bereits mehr als genug Datenbanken im Portfolio, und so ganz klar, wo die Reise mit Informix hingehen soll, ist es wohl noch nicht.

Sun hat die Rechte an Java. IBM verdient hervorragend an Java und hat wie kein anderer dafür gesorgt, dass Java sich im Business-Umfeld etablieren kann. IBM investiert höllisch viel Geld in Java und Eclipse. IBM hat eine eigene Java-VM im Portfolio und bietet sicherlich die umfangreichste Sammlung an Infrastruktur, Entwicklungswerkzeugen und vor allem Dienstleistungen rund um Java am Markt. Sun hat hier nicht viel dagegenzuhalten. Kauft IBM Sun um die Rechte an Java zu bekommen? Wozu?

Sparc-Prozessoren? Die sind sicher nicht schlecht, aber PowerPCs und Cells sind noch immer recht viel versprechend. Ich als Laie würde vermuten, ausser ein paar netten Ideen für die IBM-Prozessorarchitekturen dürfte von Sparc nicht viel übrig bleiben. Ich könnte mir vorstellen, Solaris lebt länger als Sparc, wenn Sun eine IBM-Brand wird. Solaris läuft auf x86, warum nicht auch auf POWER oder Cell?

So ganz einleuchten mag mir der Deal nicht. Aber spektakulär ist die Sache…

Gartner sieht wachsende Bedeutung dynamisch getypter Sprachen

Mark Driver, ein Analyst bei Gartner (eben der, der erst im Oktober schrieb: “I said it. Smalltalk is making a comeback.“) verweist in seinem neuesten Blog-Beitrag auf eine (nur für zahlende Kunden herunterladbare) “research note”, und gibt eine kurze Zusammenfassung davon zum Besten:

Dynamic programming languages, such as PHP, Python and Ruby, are making their way into mainstream IT efforts

Zwar nennt er Smalltalk nicht explizit, aber im Verlauf des Postings wird klar, dass Smalltalk neben JavaScript und Ruby sicherlich einer der interessantesten Kandidaten aus dem Umfeld der dynamischen Sprachen ist (Interessanter Weise nennt er auch JavaScript nicht).
Ein Schlüsselsatz seiner “Key Findings” ist sicher:

Dynamic programming languages offer a number of unique capabilities that cannot be duplicated with established market-leading technologies.

In der Tat sind dynamische Sprachen wie eben gerade Smalltalk sehr mächtig und erlauben ein Verhältnis zwischen “technischem” Code und “fachlichem” Code zu erreichen, das in Sprachen wie C#, Java oder C++ völlig undenkbar ist. So ist es schon lange kein Geheimnis mehr, dass ein erfahrener Smalltalk-Entwickler eine deutlich höhere Produktivität und gleichzeitig eine wesentlich geringere Fehlerquote hat, als ein gleichsam erfahrener C++- oder Java-Programmierer. James Robertson schrieb dazu schon 2001:

Research studies comparing different programming languages indicates
that Smalltalk is more efficient. This enables programmers to solve a given problem
quicker and with less code — typically 1/2 to 1/3 of the code required of a C++/Java programmer. Independent studies also show that Smalltalk has fewer defects.

Ein weiterer wichtiger Punkt ist die Möglichkeit der Meta-Programmierung, mit der sich Probleme auf abstrakter Ebene sehr einfach lösen lassen. Ein Feature, das einigen der von Driver genannten Sprachen übrigens fehlt.

Driver gibt zu bedenken, dass die Arbeit mit dynamischen Sprachen anders ist, und weist darauf hin, dass die Entwicklung in z.B. Ruby (oder eben Smalltalk) neue “best practices” erfordert. Dem ist sicher nichts hinzuzufügen. Leider schweigt er sich (zumindest im Blogpost) darüber aus, welche Bereiche er hier identifiziert hat.

Einige der Best Practices, die sich auch in der Welt statisch getypter Sprachen zunehmend durchsetzen, sind der Smalltalk-Welt entliehen und zählen zu den anerkannt wichtigesten Methodiken, um qualitativ hochwertigen Code mit einem hohen fachlichen Deckungsgrad herzustellen. Beispiele? Gerne:

Driver sollte also sicher ergänzen, dass es diese Best Practices gibt, und vor allem sehr ausgereifte Werkzeuge zu deren Einsatz, die in der “etablierten Welt” teilweise noch nicht in voller Pracht angekommen sind. Die gesamte “Pragmatic Programmer“-Bewegung zielt auf den Einsatz von dynamischen Sprachen hin und arbeitet Practices aus, die vor allem die Achsen Geschwindigkeit und Qualität der Softwareentwicklung im Focus haben. Interessanter Weise wird in dieser Szene sehr viel über Ruby und Rail, aber nicht über die meisten anderen dynamischen Sprachen geredet und geschrieben.

Als Fazit lässt sich festhalten: Man kann über Analysten denken, was man will, aber hier trifft Driver voll ins Schwarze. Dynamische Sprachen sollte man in den kommenden Jahren im Auge behalten.

… Und doch daneben: ich hätte anstatt Python und PHP hier sicher eher JavaScript, Groovy und Smalltalk gesehen, denen eine interessante Zukunft zuzutrauen ist. Smalltalk nicht zuletzt deshalb, weil hier die ausgereiftetsten Werkzeuge zur Verfügung stehen.

Zum Abschluss möge sich  der geneigte Leser folgende Empfehlung von Gartner ans Herz legen lassen:

Consider dynamic programming languages for projects where .NET and Java are overly complex for project design goals

Mehr ist dem nicht hinzuzufügen.

Wie typfrei ist die Welt?

In einem Kommentar zu meinem gestrigen Post “Refactoring und der Aberglaube” schreibt Thomas Holzer einen Satz, der mich zum Nachdenken gebracht hat:

Denn die reale Welt (Und jedes Programm bildet immer Teile der realen Welt nach) ist auch typenlos.

Zuerst dachte ich mir, ganz so sei die Welt ja nicht. Schliesslich kann ich es an meinen Kindern sehr gut beobachten: wir nehmen die Welt wahr, indem wir sie kategorisieren, Dinge, Gefühle, Eindrücke in Schubladen stecken, Gemeinsamkeiten suchen und identifizieren. Eigentlich ist unser Bild der Welt doch sehr stark von Mustern, Schablonen und Klassifizierungen geprägt.
Irgendwie ist unsere Wahrnehung der Welt doch statisch typisiert. Ein Kirschbaum ist eine Pflanze und lässt sich ganz eindeutig in eine Klasse, Sorte, Art, Familie und was weiss ich noch für botanische Kategorien einsortieren. Dort gehört ein Kirschbaum unverrückbar hinein und hat klare Unterscheidungsmerkmale zu jedem anderen Ding auf der Welt.
Manchmal ist es aber wunderlich, wie man seine Zeit vor dem Einschlafen so nutzen kann. Anstatt über wirklich wichtiges nachzudenken, sinnierte ich dann doch ein wenig über das Thema. Und heute früh bin ich ein wenig anderer Ansicht. Continue reading

Refactoring und der Aberglaube..

Nein, hier geht es nicht darum, Refactoring als Aberglaube abzutun und alle Welt zur Nutzung silberner Pflöcke oder Knoblauch gegen jeden Nutzer von Refactorings aufzurufen.

Stattdessen geht es darum, ein paar Fetzen Fehlglaube zu identifizieren und anzuprangern, die sich um das Thema Refactoring und Typsicherheuit ranken.

Anlass dazu lieferte mir folgendes Zitat aus einem Blogpost von Travis Griggs , der auf seine Eindrücke von einem Refactoring-Workshop auf der OOPSLA eingeht:

One of the things that struck me in this workshop as well as some other presentations, is how valuable having a simple syntax is. The guys working on the Eclipse refactorings for Java have an object model of the AST that has 100+ node types. Having been working on the RB formatter lately, with its AST object model which has 11 concrete node types, I can see how fortunate I am. Continue reading