Follow my new blog

Donnerstag, 31. Dezember 2009

Linksammlung zum Thema Monads [OOP 2010]

image Bei der Beschäftigung mit Funktionaler Programmierung stoße ich immer wieder auf den Begriff Monad. Leider bringt mich jedoch der zugehörige Wikipedia-Artikel bei dessen Verständnis nicht weiter. Deshalb habe ich jetzt ein wenig gegooglet. Für mich als Entwickler, der bisher (vor allem) mit imperativen Programmiersprachen zu tun hatte, sind dabei die folgenden Beiträge herausgekommen, die ich als verständnisfördernd empfinde.
So ganz bin ich mit diesen Beiträgen allerdings immer noch nicht zufrieden. Ich finde die Erklärungen für Monads immer noch recht theoretisch und fern der imperativen objektorientierten Programmierpraxis.

Wie würde ich nun Monads erklären? Hm... mal sehen. In einem zukünftigen Beitrag versuche ich das mal.

Samstag, 26. Dezember 2009

Neues Format für längere Blogartikel? [OOP 2010]

Es gibt keine formale Beschränkung für die Länge von Blogartikeln. Und so habe ich bisher kürzere wie längere unterschiedslos hier gepostet. Nun mir jedoch Zweifel gekommen, ob ich das auch weiterhin tun soll.

Online Zeitungen verfahren ja schon lange so, dass sie längere Beiträge splitten. Beispiel www.zeit.de: Artikel werden zunächst häppchenweise gezeigt, wie Sie hier sehen können; erst wenn Sie “Auf einer Seite lesen” anklicken, bekommen Sie alles auf einer Seite. Die Zeit hat für solche verschiedenen “Views” natürlich ein hübsches Redaktionssystem, bei dem auch noch ein PDF rausfällt. Das kann ich mir natürlich nicht leisten. Was also tun?

Wie wäre es denn, wenn ich längere Beiträge nicht mehr direkt ins Blog schriebe, sondern wie folgt veröffentlichen würde:

Zustand als Abhängigkeit - IoC konsequent gedacht

Wenn Sie mögen, können Sie diese Ansicht auf den ganzen Bildschirm vergrößern. Oder Sie stellen vom “Book View” um auf den “Scroll View”, um quasi wieder alles auf einer langen Seite zu haben. Oder Sie drucken den Inhalt aus. Oder Sie exportieren ihn als PDF, um ihn auf Ihrem favorisierten ebook-Reader zu lesen.

Was meinen Sie? Wäre solche Differenzierung in der Publikation nicht eine gute Sache? Blogartikel, die ca. eine Bildschirmseite lang sind, veröffentliche ich weiterhin direkt im Blog. Aber Artikel von mehreren Bildschirmseiten oder gar mehreren Druckseiten biete ich Ihnen im obigen Format.

Denn seien wir ehrlich: Längere Texte am Bildschirm zu lesen, ist immer unschön. Es macht wenig Unterschied, ob sie häppchenweise präsentiert werden oder in einem Stück. Längere Inhalte brauchen Überblick. Den bietet nur ein Ausdruck – wofür ein Blog keine wirklich gute Grundlage ist – oder eine Ganzseitendarstellung im Hochformat auf einem speziellen Reader.

Vergleichen Sie einmal den Text im obigen Viewer bzw. nach Ausdruck mit der ursprünglichen Veröffentlichung. Welche Präsentation finden Sie lese- bzw. verständnisfreundlicher?

Nachtrag: In einigen Kommentaren zu diesem Posting wurde gegen solche Flash-Darstellung eingewandt, dass der Content dann nicht von Suchmaschinen indiziert würde. Das ist jedoch falsch wie diese Suche beweist: http://www.google.de/search?q="zustand+als+abhängigkeit"+site:scribd.com (die Einschränkung mit site:scribd.com habe ich nur gemacht, um den Link zum Dokument auf die erste Ergebnisseite zu bringen). Das erste Ergebnis ist ein Link auf das obige Dokument: http://www.scribd.com/doc/24512457/Zustand-als-Abhangigkeit-IoC-konsequent-gedacht.

Objektorientierung als Behaviorismus der Softwareentwicklung [OOP 2010]

Die Objektorientierung steht uns im Weg zu evolvierbareren Programmen. Ja, das glaube ich immer mehr. Nicht, dass ich Objekte missen möchte – sie sind nützliche und wichtige Strukturierungsmittel für Software.  Ich will natürlich Funktionseinheiten mit eigenem Zustand definieren können. Aber die Sprache der Objektorientierung wie sie C++, Java, C# und auch VB vorgeben, ist einfach nicht für Flexibilität und Evolvierbarkeit gedacht gewesen. Und da Sprache unser Denken bestimmt, kommen bei der Benutzung objektorientierter Sprachen eben nicht einfach flexible und evolvierbare Programme heraus.

Objektorientierung ist sozusagen die Brille der Programmier-Behavioristen. Wer durch sie blickt, vereinfacht die Welt extrem – manchmal bis zur Unkenntlichkeit. Wo die Welt der Behavioristen durch Reiz-Reaktion determiniert ist, da ist sie für “die Objektorientierten” durch Zustand und Synchronizität geprägt.

image Und so wie Behaviorismus bei der Dressur eines Tanzbären funktionieren mag, so funktioniert Objektorientierung auch bei einem simplen Malprogramm. Ok, sie “funktioniert” auch bei viel größeren Anwendungen – doch ich meine mit “funktionieren” nicht, dass objektorientierter Code am Ende läuft, sondern ob mit den Mitteln der Objektorientierung etwas heraus kommt, was sich auch weiterentwickeln lässt. Denn das ist ein wesentliches und trotzdem oft unterschätztes Qualitätsmerkmal von Software. Beim Tanzbären ist das hingegen nicht wichtig. Wenn der keine neuen Tricks mehr lernt, nimmt man einen neuen.

Wer hingegen mehr als einen Tanzbären dirigieren will, z.B. ein ganzes Unternehmen, der ist mit Behaviorismus schlecht bedient. Unternehmensführung funktioniert schlecht mit Zuckerbrot und Peitsche als Mittel, um Reize auszulösen und Reaktionen zu provozieren, die eine vielköpfige Belegschaft verlässlich zum Erfolg führen.

Dito die Objektorientierung in nicht mehr einfach überschaubaren Szenarien. Direkte, streng typisierte und synchrone Kopplung ist das falsche Denkmuster für evolvierbare Software. Solche Kopplung ist aber der Default der Objektorientierung. Nur mit Mühe und Disziplin kann man sich von ihm lösen. Das mag dann zwar das Expertentum von Softwareentwicklern ausmachen – doch wie in Panik die Moral schnell verdampft, so verflüchtigen sich unter Projektdruck auch solche programmierzivilisatorischen Errungenschaften. Was dann nicht durch die Sprache quasi erzwungen wird, das findet nicht statt.

Deshalb bin ich für möglichst hart verdrahtete neue Defaults – wenn schon nicht neue Sprachen, die die Evolvierbarkeit begünstigen. Ein solcher Default ist die echte Komponentenorientierung, bei der Komponentenimplementationen physisch alleingestellt in Komponentenwerkbänken stattfinden und Komponenten einander nicht mehr direkt referenzieren. Deshalb bin ich für Flows als ersten groben Implementationsansatz für jede Realisierung eines Features; denn in Flows gibt es keine Kopplung mehr zwischen den Schritten, so dass die Evolvierbarkeit sehr hoch ist. Deshalb bin ich für die Nutzung eines in-proc Bussystems, d.h. selbst wenn die Kommunikation noch lokal und synchron ist. Ein solcher Bus entkoppelt noch mehr als ein DI Container.

Komponentenorientierung begrenzt die OO-Defaults lokal auf die Implementation einer überschaubaren Komponente. Und DI Container, Flows sowie Busse sind neue Defaults für die Kopplung von Strukturen, wenn es unüberschaubar wird – was immer schneller passiert, als wir uns vorstellen.

Wie wäre es, damit einmal im neuen Jahr zu experimentieren? Der überkommene Programmierbehaviorismus würde einem differenzierteren Verständnis von Software weichen.