Zielgruppen für Softwaretools

Hersteller von Produkten und insbesondere diejenigen die dafür werben, denken in Zielgruppen. So ist es offensichtlich, daß der typische Leser der ADAC Motorwelt sich für Treppenlifte interessiert. Werbung im Fernsehen muß hingegen die 19- bis 49-jährigen ansprechen, die die Zeit für Medien heutzutage eher im Internet verbringen. Genauso wird kommerzielle Software auch für bestimmte Zielgruppen entwickelt und angepriesen.

Entwickler sind ein zu vermeidendes Übel

Manager mit dieser Einstellung sind immer schon ein beliebtes Ziel von Toolherstellern. Bereits vor 20 Jahren wurden CASE-Tools mit dem Anspruch vertrieben, daß die Fachleute für die Geschäftsprozesse diese direkt eingeben könnten, ohne das ein "Entwickler" von Nöten sei. Bei diesen Tools meine ich immer zu merken, daß das Hauptziel bei der Konzeption war, es dem Vertriebsmitarbeiter zu ermöglichen, innerhalb einer halben Stunde eine Adreßverwaltung zusammenzuklicken, so daß die Manager, den dies vorgeführt wird, den Eindruck haben, sie könnten das auch.

Leider sind all diese Tools nicht annähernd so allgemein einsetzbar, wie die Phantasie der Nutzer potentieller Anwendungen reicht. Sobald aber etwas gefordert wird, daß die Toolentwickler noch nicht berücksichtigt haben, so sind komplizierte und schlecht wartbare Hacks an der Tagesordnung, die die vorgesehene Funktionsweise des Tools umgehen und die erst die vom Kunden gewünschte Funktionalität möglich machen.

Häufig sind derartige Tools auch schlecht in den Entwicklungsprozeß einzubinden. Wiederkehrende Aufgaben lassen sich nicht automatisieren, die Ergebnisse lassen sich schlecht in ein Konfigurationsmanagementsystem speichern und automatisierte Modultests sind auch nicht vorgesehen.

Die Behauptung, daß Programmierung nicht notwendig sei, erweist sich als Taschenspielertrick. Statt in einer Textdatei mit einem in einer Programmiersprache geschriebenen Programm ist dieselbe Information in einer Vielzahl von Menüs verstreut, so daß man rasch die Übersicht verliert, wo man was angepaßt hat. Das kann man schon ausprobieren, wenn man rasch mal eine "einfache" Access-Anwendung zusammenklickt.

Turings Fluch

Eine Programmiersprache nennt sich Turing-vollständig, wenn man damit alle denkbaren Programmieraufgaben lösen kann. Dazu braucht es nicht viel: Logische Verzweigung und Schleife reichen im Prinzip schon. Es gibt daher nur wenige Beispiele für Sprachen, die nicht Turing-vollständig sind. Egal, welches Werkzeug verwendet wird, als Entwickler kann man seinem Manager selten mit gutem Gewissen sagen, daß etwas damit nicht möglich ist. Man kann Texteditoren mit der C++-Template-Sprache schreiben, Datenbanksysteme mit Excel-VBA und Schachprogramme mit XSLT. Diese Sprache sind natürlich alle für etwas anderes gedacht und am Ende werden die Programme weder wartbar noch effizient sein, aber prinzipiell möglich sind sie doch.

Manchmal geht die Sache auch schleichend. BPEL ist dazu gedacht, Webservices zu einem Geschäftsprozeß zusammenzufassen, nicht dazu komplexe Algorithmen zu implementieren. Aber wenn man erst einmal eine Schleife und eine Verzweigung eingebaut hat, so gibt es kein klares Haltesignal, bis man doch den Algorithmus zusammengebastelt hat. Das Ergebnis ist dann sehr unübersichtlich, aber es ist da und läuft und es Bedarf einer mutigen Entscheidung, die Anwendung so umzubauen, daß dieser Algorithmus in einer geeigneteren Sprachen neu implementiert wird und das BPEL-Programm wieder wartbar wird.

Marketing-Nebel

Manchmal werden an sich nützliche Dinge durch das Marketing so verzerrt, daß sie nur noch für das sehr geübte Augen zu erkennen sind. Ein Beispiel ist das bereits letztes Mal erwähnte LINQ von Microsoft. Microsoft hat eine lange Geschichte von vergeblichen Ansätzen, einen eigenen O/R-Mapper herzustellen. Über Risiken und Nebenwirkungen solcher Tools könnte ich gelegentlich mal einen eigenen Beitrag schreiben, aber bei der Java-Konkurrenz haben sich diese Tools spätestens seit Hibernate etabliert. Also wurde LINQ als die ultimative Lösung für die Datenbankeinbindung in C#-Programme verkauft. Realisiert ist das ganze in einem Mix aus Spracherweiterungen und Bibliotheken. Ob der ursprüngliche Zweck wirklich viele überzeugt, wird die Zeit zeigen. Tatsache ist, daß einige nützliche Dinge dabei entstanden sind. Das attraktivste ist wohl die sogenannte "List-Comprehension". Diese ist bei Haskell- und Python-Programmierern seit langem bekannt und beliebt. Hier wurde aber eine Syntax gewählt, die vor allem Datenbankentwickler ansprechen soll, da sie an SQL angelehnt ist. Zum einen paßt diese Syntax recht schlecht in die übrige von C#, das doch eher von dem mathematisch knappen Stil von C beeinflußt ist als von dem an der natürlichen Sprache angelehnten von SQL. Zum anderen werden viele Entwickler übersehen, welche Möglichkeit hier versteckt sind.

Alternative Zielgruppe

Wahrscheinlich würde einiges besser, wenn die Entscheidungen für Softwaretools mehr von denjenigen gemacht würden, die sie auch benutzen müssen. Dies müßte dann aber auch zu den Anbietern durchdringen. Derzeit sieht es so aus, daß ein großer Teil der kommerziellen Softwaretools mit Blick auf Manager als Entscheidungsträger hin entwickelt und vertrieben werden. Besser sieht es manchmal bei Open Source Programmen aus, auch wenn hier immer mehr einen kommerziellen Hintergrund haben, der zu den gleichen Auswüchsen führt.

Eine für Alles, Alles in Einer

Wie regelmäßige Leser meines kleinen Blogs sicher schon festgestellt haben, ist eines der Gebiete, für die ich mich interessiere, das der Programmiersprachen. Welche Möglichkeiten gibt es in den verschiedenen Programmiersprachen und wozu kann man sie sinnvoll einsetzen?

Diesmal geht es mir um das Wachstum von Sprachen. Was man immer wieder sehen kann, ist, daß eine Sprache klein und einfach zu erlernen anfängt und dann immer weitere Bereiche gefunden werden, wo es doch so schön wäre, wenn man die Sprache ein klein wenig erweitern würde, damit dieses oder jenes vereinfacht würde. Es gibt natürlich auch die Sprachen, die gleich ganz groß angefangen haben: ADA und PL/1. Die erste wird von kaum jemandem freiwillig benutzt. Sie ist aber Voraussetzung in Ausschreibungen von militärischen Anwendungen. Wenn man sie mal begriffen hat, soll sie gar nicht so schlecht sein. Die zweite sollte mal Cobol ablösen. Sie hat aber die meisten Entwickler von Anfang an abgeschreckt und ist rasch in einer Nische verschwunden.

Sprachwachstum

Auch Java ist im Laufe der Zeit gewachsen und in den Diskussionsrunden der Gemeinde der Java-Entwickler bemerkt man die Wachstumsschmerzen. Allerdings ist Java im Wachstum gehemmt, da es lange dauert, bis ein JCP sich durchgesetzt hat. Anders ist das bei C#. Hier steht kein kompliziertes Gremium dahinter sondern die Entwickler der Sprache werden nur durch die Marketingabteilung getrieben. Eigentlich mag ich die Sprache. Sie ist zwar Java sehr ähnlich, konnte aber schon zu Beginn von einigen Jahren Erfahrung mit Java profitieren und einiges besser machen. Allerdings sind einige neue Ideen zuerst nur halbherzig implementiert worden und erst im Laufe der Zeit brauchbar geworden. Wie in Java haben es die Entwickler nicht hinbekommen, echte Closures in der ersten Version zu implementieren. Während in Java bis zur jetzigen Version nichts in dieser Richtung da war, hatte C# zu Beginn eine halbherzige Lösung namens delegate. Diese wurde erst in der zweiten Version brauchbar und in der dritten richtig rund.

Daneben gab es in der dritten Auflage der Sprache ein Feature namens LINQ. Dazu wurde die Sprache so verbogen, daß funktionale Konzepte wie Monaden darin untergebracht worden konnten. Die Prototypen wurden in F#, einer funktionalen Sprache für das dotnet Framework, entwickelt und dann zu C# migriert. In meinen Augen hat LINQ bislang nicht viel Gutes gebracht. Es hat die Sprache aufgeblasen, verhindert aber die Portabilität von Lösungen, die darauf aufbauen. Die Datenbankanbindung funktioniert nur für SqlServer. Für Oracle gibt es keinen Support und wohl auch keine wirkliche Nachfrage. Noch schlimmer ist, daß Microsoft wegen LINQ die Unterstützung von XQuery in seinen Produkten nicht weiterentwickelt hat. XPath und XSL sind auf der Version 1 stehengeblieben, während der Rest der Welt beginnt, sich an den neuen Möglichkeiten der Version 2 zu erfreuen. Jetzt droht die vierte Auflage. In seinem Blog zeigt sich der erfahrene C#-Trainer Frank Quednau einerseits erfreut über die neuen Möglichkeiten, andererseits bezweifelt er, daß die Sprache dann noch in einem einwöchigen Kurs unterrichtet werden kann. Das ist für mich aber ein ganz großes Problem. Das bedeutet, daß es dann schwer sein wird, in einem größeren Projekt genügend Leute zu finden, die die Sprache vollständig beherrschen. Dann beginnen wieder die projektinternen Vorschriften, welche Sprachkonstrukte nicht benutzt werden dürfen. Wir kennen das von C++. Dies ist für die fortgeschrittenen Programmierer frustrierend, da sie sich gezwungen sehen, in ihren Augen schlechteren Code zu schreiben, nur damit das durchschnittliche Teammitglied eine Chance hat, diesen zu verstehen. Allerdings wird dieser Code dann auch nicht gerade schöner, denn wie das Gehirn nun mal arbeitet, werden dann nicht Lösungen implementiert, die zu den eingeschränkten Möglichkeiten passen, sondern Rückportierungen der neuen Konstrukte.

Mehrsprachlichkeit

Gerade bei dotnet ist es eigentlich überhaupt nicht notwendig, alles einer Sprache aufzubürden. Die Grundidee war eigentlich, daß sich verschiedene Sprachen eine Umgebung teilen können, in der Komponenten, die in den unterschiedlichen Sprachen geschrieben werden, zusammenarbeiten. Das funktioniert ja auch ziemlich gut, so gut sogar, daß die Java-Welt nach anfänglicher Ablehnung dieses Konzept jetzt begeistert übernommen hat. Warum macht man es sich das nicht zunutze und entwickelt verschiedene kleinere Sprachen, die für den jeweiligen Anwendungsfall optimiert sind? Dies gilt ganz besonders für Sprachkonstrukte, die offensichtlich überwiegend für Codegenerierung entwickelt wurden. Der normale Entwickler braucht doch nicht die Dinge zu kennen, die die diversen Wizzards in VisualStudio verwenden. Schon dadurch hätte die Sprache entschlackt werden können.

Auch wenn man dann mehr Programmiersprachen kennen muß, so hat doch jede ihren Kontext. Mehrere Programmiersprachen sind für heutige Projekte ja sowieso schon die Normalität. SQL, HTML, XSL etc. werden neben der Hauptentwicklungssprache meist noch verwendet.