Vor nunmehr fast fünf Monaten wurde unsere kleine Tochter geboren. Gerade am Anfang war es schwer, ihre Bedürfnisse zu erkennen. Sie hat nicht oft geweint, aber manchmal standen wir vor ihr und wussten nicht: hat sie nun Bauchschmerzen, oder Hunger oder beides? Das Problem war nämlich: sie kann nicht sprechen (und kann es im Übrigen immer noch nicht). Hätte sie sprechen können, hätte sie vielleicht gesagt: „Ihr tragt mich jetzt schon seit drei Stunden in diesem beklopptem Fliegergriff durch die Gegend. Ja, ich hatte Bauchschmerzen aber jetzt will ich einfach nur schlafen und das kann ich nicht, wenn ihr mich hier rumschleppt. Im Übrigen nervt es mich gewaltig, das neunzigste Mal „Guten Abend, gute Nacht zu hören“. Seit wenigstens bitte still. Danke.“
Sprache ist wunderbar, weil uns jemand anderes verständlich machen kann, was er meint. Manchmal ist Sprache aber auch ausgrenzend: wir wohnen in Dänemark und es ist, nicht nur wegen der kühlen, nordischen Mentalität sondern auch wegen der Sprache, schwer Anschluss zu finden.
In der Fahrradstadt Münster wird der durchaus wichtige Hinweis: Vorsicht, Fahrrad! Zu Vorsicht: Leeze! „refactored“. Wenn Sie jetzt kein Masematte kennen, und sich wundernd am „Küls“ kratzen, was denn nun Leeze heißt, kann es sein, dass Sie auf den „Zinken“ fallen. Wenn Sie nun mit blutender Nase dem Münsteraner entgegenhalten, er könne ja schwerlich davon ausgehen, dass alle Masematte sprechen, dann haben Sie Recht und der Münsteraner sollte seine wohl gemeinten Sprachgeflogenheiten kritisch reflektieren.
So ähnlich – nein genauso verhält es sich auch mit Sprachgepflogenheiten bei der Verwendung von Programmiersprachen. Ein wichtiger (wenn nicht gar der wichtigste) Aspekt beim Entwickeln sollte sein, dass das, was da geschrieben wird, für andere auch verständlich ist. Denn schließlich ist das, was da geschrieben ist nicht nur eine Form der Maschine beizubringen, was es zu tun hat, es ist auch Dokumentation dessen was es auszudrücken zu bezwecken sucht. Programmcode ist die beste Dokumentationsform die es gibt, denn sie lügt niemals und sie wird automatisch gepflegt, wenn das Programm geändert wird.
Wenn Sie also Programmcode schreiben, dann behalten Sie im Hinterkopf, dass andere Entwickler dieses irgendwann einmal lesen und verstehen wollen. Ich halte es für guten Stil, den benutzen Sprachumfang auf das Notwendigste und Allgemeingültigste zu reduzieren. Vermeiden Sie es, sprachliche „Geheimkonstrukte“ zu verwenden, nur weil Sie meinen, es sehe geringfügig besser aus oder weil Sie (wie vielleicht unser Münsteraner) es sexy finden.
Ich befinde mich mit meiner Meinung im Gegensatz zu dem hier vorgestelltem: http://ralfw.blogspot.com/2010/04/gemeine-kenntnislucken.html
Lamda Ausdrücke zu verwenden mag sinnvoll sein, aber aus meiner Sicht nur dann, wenn es funktional angezeigt ist oder wenn die einen zu Verfügung stehenden Sprachmittel nicht ausreichen. Andernfalls grenzen Sie per se diejenigen aus, die nicht so firm und virtuos mit den neuen Featuren sind.
Man kann natürlich sagen: Das interessiert mich nicht, sollen die’s doch lernen. Das ist immerhin eine Haltung, nett ist es aber nicht, wenn man ohne Not riskiert, dass sich andere einen blutigen Zinken holen.
Abonnieren
Kommentare zum Post (Atom)
Der Autor des referenzierten Artikels stimmt dir durchaus zu:
AntwortenLöschen"Vermeiden Sie es, sprachliche „Geheimkonstrukte“ zu verwenden, nur weil Sie meinen, es sehe geringfügig besser aus [...]"
Wer wollte da auch etwas dagegen sagen. Aus einem gut gemeinten Eleganzdenken heraus unverständliche C-Ausdrücke haben wir alle schon mal gesehen. Nein, die wollen wir nicht wieder haben in C# Code.
Und so scheint mir dein Argument darum zu kreisen, was denn für wen ein "Geheimkonstrukt" sei. Für meine Mutter ist "i++" ein "Geheimkonstrukt". Für dich und mich mag dieser Ruby Code eines sein: "p b # => [1,2,3]".
Ich paraphrasiere mal Arthur C. Clark: Jedes genügend unbekannte Feature sieht aus wie ein "Geheimkonstrukt". D.h. die schlichte Anwendung ist dann kryptisch.
Dem würde ich aber nochmal die "Eleganz" entgegenhalten. Ich kann auch bekannte Features so anwenden, dass das Ergebnis kryptisch ist. Dagegen bin ich, wie schon gesagt.
Aber aus einer bloßen Anwendung eines unbekannten Features eine "Geheimkonstrukthaftigkeit" zu machen, finde ich unpassend. Dann würden nämlich die mit den wenigsten Kenntnissen bestimmen, welche Konstrukte verwendet werden dürfen. Im Zweifel bleiben wir damit bei der prozeduralen Programmierung hängen.
Es ist also die Aufgabe jedes Einzelnen und der Lehre im Allgemeinen, Kenntnis der verfügbaren Features herzustellen. Auf dass die dann angemessen eingesetzt werden.
-Ralf
@Ralf: Nehmen wir mal an, wie haben ein Abfallbeseitigungsprogramm, das in C# geschrieben wurde. Wir suchen nun jemand, der dieses Programm warten kann.
AntwortenLöschenMeine Mutter scheidet nun schon mal aus und Deine offensichtlich auch. Wir beide wären noch dabei.
Nun bewirbt sich ein Java-Entwickler von der Müllverbrennungsanlage am Volkspark in Hamburg. Der scheint ganz virtuos mit dem Gelben Punkt umgehen zu können, wohingegen wir bekennen müssen, unsere Frauen zu fragen, in welchen Sack das Nuttella Glas gehört.
Das Abfallbeseitigungsgesetzt ist Hölle kompliziert, aber wie schwer ist es für einen Java Entwickler, C# zu lernen? Im Grundsatz ist es nicht so schwer. Java Leute können C# Code lesen und umgekehrt und beide Sprachen orientieren sich an den selben Prinzipien. Lamdad es nun aber ohne Not an allen Ecken, so hat es unser Java-Müllmännchen wesentlich schwerer produktiv zu werden.
Masematte ist eine Geheimsprache. Ihr Zweck ist es, andere auszugrenzen. Als Abfallinspektor wäre mir daran gelegen, dass der C# Code mir die Freiheit lässt, mich für den Java-Entwickler zu entscheiden.
@Carsten: Ahhh, da haben wir eine Anforderung von dir aufgedeckt: Du willst die Freiheit haben, die einen Java-Entwickler zu suchen, der deinen C# Code pflegt.
AntwortenLöschenIch formuliere mal anders: Du willst, dass dein C# Code möglichst plattformneutral ist. Jmd von einer anderen Plattform (Java, C++, C) soll ihn verstehen, gar warten können.
Ok. Kein Problem. Wenn das (!) deine Anforderung ist, dann musst du darauf achten, dass du nur Features benutzt, die der von der anderen Plattform auch versteht, ohne C# zu lernen. Klassen sind ok für Java-Entwickler und C++-Entwickler. Delegaten eher für C++-Entwickler und C-Leute. Für Letztere aber nicht mehr Klassen. Und Attribute? Für Java noch ok, aber nicht C++ oder C. usw.
Wenn du mich nun dafür kritisierst, dass ich nicht nur Kenntnis, sondern auch Anwendung von Lambda Funktionen "fordere", dann lässt du allerdings außer acht, dass deine Anforderung eine sehr, sehr spezielle Carsten-Anforderung ist. Von der habe ich - bitte glaub mir - noch in keinem Projekt gehört, dass ich begleitet habe. Sie würde aus meiner Sicht auch voraussetzen, dass die Teammitglieder die Schnittmenge von Plattformen kennen, also gleichermaßen Java wie C# beherrschen, um dann entscheiden zu können, was sie in ihrem C#-Code benutzen dürfen und was nicht, um morgen einen Java-Entwickler aufnehmen zu können.
Nein, tut mir leid, mit deiner Anforderung, die für jedes Projekt natürlich legitim ist, stehst du ziemlich allein. Frag mal herum.
-Ralf
@Ralf:Vielleicht ist die Diskussion durch die Polemik ein wenig überhitzt.
AntwortenLöschenSoweit liegen wir eigentlich gar nicht auseinander: Die Motivation Deines Artikels war doch wohl anzuprangern, dass die Entwickler heutzutage zu wenig Zeit in ihre Fortbildung investieren und – illustriert am Beispiel der mangelnden Lamda-Kenntnisse – wurde gezeigt, dass offensichtlich in der C#-Entwicklergemeinde arge Defizite in der Kenntnis/Beherrschung dieses Features bestehen.
Daraus kann man folgern, dass die Leute mehr in ihre Ausbildung investieren müssen.
Aus der Erkenntnis, dass die Menge derjenigen, die das Feature beherrschen gering ist, scheint es mir doch aber auch vernünftig zu sein, darauf soweit es geht in einem Projekt zu verzichten. Ansonsten limitiere ich die Anzahl der potentiellen Kandidaten auf diejenigen, die das Feature beherrschen. Und, dass sind Deiner Aussage nach immer noch zu wenige.
@Carsten: Ah, das ist eine interessante Frage: Ist es sinnvoll, ein Feature, dass ich kenne einzusetzen, wenn es viele andere nicht kennen? (Voraussetzung es hat aus meiner Sicht irgendeinen Vorteil gegenüber dem Nichteinsatz.)
AntwortenLöschenHm... Ich würde sagen, ja, man sollte es einsetzen. Erstens habe ich unmittelbar einen Vorteil. Zweitens ist nicht abzusehen, wann jemand es nicht versteht. Drittens kann ich es dem, der es nicht versteht, erklären, damit er es versteht. (Wäre zwar schöner, wenn er es schon kennen würde, aber wenn das halt nicht ist...)
Wenn ich umgekehrt immer wieder Features nicht einsetze, die Vorteile bringen, weil ich unsicher bin, wer sie denn kennt, dann orientiere ich mich immer am Mittelmaß oder sogar darunter. So entsteht kein Fortschritt. Das ist eine Negativspirale. Denn der, der das Feature nicht kennt, denkt ja womöglich genauso. Für den sind dann Lambda Funktionen nicht "bleeding edge", sondern Interfaces. Die möchte er keinem zumuten, weil er nicht weiß, wer sie außer ihm noch versteht. Also Verzicht auf Feature und Vorteil. Dann kommt einer, der tatsächlich Interfaces nicht kennt. Für den sind Klassen "bleeding edge". Die möchte er keinem zumuten, weil er nicht weiß, wie weit verbreitet deren Kenntnis ist. Also programmiert er defensiv prozedural... usw.
Nein, dem Gedanken kann ich mich nicht anschließen. Wenn du das für deine Projekte tun magst, steht dir das ja frei. Wie gesagt: Ich kenne keine solchen Projekte. Niemand hält sich mit Features zurück, die er kennt, weil er nicht weiß, wer sie sonst noch kennt. Features werden nicht eingesetzt, weil man sie nicht kennt, nicht entgegen der eigenen Kenntnis.
Denk mal, wie deine Einstellung da für die Schule wäre: Stoff soll nicht vermittelt werden, weil nicht sichergestellt ist, dass ihn alle verstehen? Besser, die Latte tiefer hängen, damit alle mitkommen? Ne, das kann es nicht sein.
Die Herausforderung ist klar und sollte angenommen werden. Nicht herausreden, sondern Problem lösen: Wie kann Fortbildung systematisch stattfinden?
Das ist keine Frage von Features bei C#. Das ist eine Frage der persönlichen Haltung und der Haltung eines Managers. Die Lösung ist am Ende einfach und hat vor allem mit Willen zu tun. Wenn der da ist - aus Einsicht oder aus welchem Grund auch immer -, dann kann auch der quängeligste König Kunde da keinen Einfluss mehr üben. Dann wird gelernt, weil es eben richtig und wichtig ist.
-Ralf
Ein Freund, der bei dem NDR arbeitet, erzählte mir vor einigen Jahren, dass dort die Grundregeln zur Verwendung der deutschen Sprache gelockert worden sein und in einigen Fällen sogar die Anweisung bestünde, in Zweifelsfalle so zu sprechen, wie das gemeine Volk.
AntwortenLöschenDemzufolge werden Redakteure nicht mehr geteert und gefedert durch die Sendeanstalt getrieben, wenn Sie etwas sagen wie: „die beiderseitige Vereinbarung kam wegen dem Einspruch vom französischen Präsidenten nicht zustande“ (vormals: die bilateralen Vereinbarungen scheiterten am Veto des französischen Permiers“)
Warum? Nun, wohl aus der Erkenntnis, dass die Nachrichten von einem Grossteil der Bevölkerung nicht verstanden werden. Ich bin ein großer Fan des Konjunktiv 1. Ich kann Dich zitieren und gleichzeitig verdeutlichen, dass es sich hierbei um Deine Meinung handelt. Das ist elegant und verschafft sprachlich Klarheit.
Du wirst jetzt sagen, dass der Konjunktiv 1 mindestens so elegant sei, wie Delegaten und dass die, die es nicht kennen, es dann doch gefälligst lernen sollen. Dies ist die Arroganz von Sprachgelehrten, die die Bodenhaftung verloren haben.
Zudem nervt mich Dein Argumentationsstil: wenn ich sage, ich kenne ganz hervorragende katholische Priester, dann wirst Du das solange verwursten, dass ich am Ende Kindesmissbrauch gutheiße.
Also leite bitte nicht aus der Tatsache, dass ich Verständnis für sprachliche Beschränkungen der öffentlich-rechtlichen Anstallten habe ab, dass ich es super fände, dass die Tageschau zukünftig gegrunzt wird.
Ist es gut, was der NDR da macht?
AntwortenLöschenGuter Journalismus hatte von jeher den Anspruch, verständlich für möglichst viele zu sein. (Ob er diesen Anspruch erfüllt hat, sei dahin gestellt. Der Anspruch ist jedoch da bzw. da gewesen.)
In dem Anspruch steckt natürlich nicht drin, wie man das macht. Der NDR versucht da einen Weg. Wolf Schneider steht für einen anderen.
Sprache ist lebendig. Klar. Dem soll sich auch ein NDR oder Duden nicht widersetzen.
Wenn jedoch Ausdrucksmöglichkeiten verloren gehen, dann halte ich es für sehr, sehr bedenkenswert, sich dem "einfach so" anzupassen.
Sebastian Sick & Co machen auch deutlich, dass solche Anpassung oder gar Anbiederung nicht unbedingt auf die Resonanz stoßen, die man sich erhofft.
Gestelzt muss es nicht sein im NDR. Aber die von dir beschriebene Reduktion ist keine Alternative.
Wo liegen die Gründe? Ist der Anspruch gesunken? Nein, das glaube ich nicht. Es haben nur andere das Sagen bekommen. Und es ist ein Wettbewerb entstanden, dem man glaubt besser standhalten zu können, wenn man den Genitiv vernachlässigt oder Ähnliches. Und die Ausbildung der Journalisten ist wahrscheinlich schlechter geworden.
Was sagt uns das? Nun, am Ende gilt: Jeder wie er will. Wenn der NDR am Ende auf Radio Hamburg Niveau angekommen ist und immer noch Geld verdient, dann mag das manchem gefallen. Ob er damit allerdings seinen Auftrag erfüllt? Ich jedenfalls bin nicht bereit, für schlechte Qualität, die ich auch ohne GEZ hören kann, noch Geld zu bezahlen. Und so dreht sich die Abwärtsspirale weiter. Ein Phyrrussieg, würde ich sagen.
Die Masterfrage ist immer: Was will ich eigentlich?
Und wenn die Antwort ein "irgend(wie)" enthält, dann gibt es kein Halten. "Irgendwie Geld verdienen" oder "Irgendwie den Code zum Laufen bringen" oder "Irgendwen einstellen können" usw.
Aber wie gesagt: Das kann jeder halten, wie er will. Wenn du damit glücklich wirst, Lambdas und Co bewusst auszuschließen, weil du ja nie weißt, wen du einstellen musst, dann tu das. Ich will dich da nicht bekehren. Aber ich wehre mich dagegen, das zu einer Maxime für die Branche zu erheben.
-Ralf
Ich habe gerade ein Beispiel:
AntwortenLöschenvar rate = Money.Zero;
foreach (var component in ServiceComponents)
{
rate += component.Price;
}
Finde ich wesentlich einfacher zu lesen als:
var rate = ServiceComponents.Aggregate(Money.Zero, (current, component) => current + component.Price);