Ästhetik und Klarheit von Code

[Tim Tepaße]

Hallo zusammen,

es gibt verschiedene Kriterien, um Code zu beurteilen. Zum Beispiel:

• Einhaltung der Styleguides der jeweiligen Sprache, des Projektes, der Firma.
• Ansprechende Formatierung
• Effizienz, sprich bestes O() erreichen. Auch Speichereffizienz.
• Mit der Programmiersprache/API arbeiten, statt gegen sie. D.h. in Javaland objektorientiert, in Haskell funktional. Gerne mal die standard library durchforsten, was es da alles schon gibt und wie es einem helfen kann.
• Design pattern nutzen, weil es dadurch ein gemeinsames Vokabular von häufig genutzten Fällen gibt. Seien es die klassischen design pattern wie MVC, Observer, Singleton, etc., seien es funktionale Konstrukte wie map, reduce, filter, etc.

Mich beschäftigt etwas, was irgendwo dazwischen liegt, wofür ich aber nicht so wirklich ein Vokabular finde. Nicht Microästhetik wie Formatierung sondern mehr eine Ästhetik, die den Quellcode verständlicher macht. Die Absicht hinter dem konkreten Ablauf verständlich macht und gleichzeitig verwirklicht.

Ok, das klingt vielleicht zu abstrakt, deswegen ein Beispiel. Ich bin vor ein paar Tagen über diese Quellcodeschnipsel gestolpert. Dort werden zwei Programmiervarianten für ein Problem verglichen. Zum einen eine recht funktionale Variante, zum anderen eine imperative Variante. Das Problem, kurz erklärt, ist eigentlich ein billiges, sehr übliches, man versucht herauszufinden, ob es in einem bestimmten Abschnitt zwei Knoten gibt, die in einem Wert unterschiedlich sind. D.h. die Knoten aus dem Abschnitt aggregieren, die Werte finden, bei zwei unterschiedlichen Werten dann einen Wahrheitswert zurückliefern. Der funktionale Stil macht genau das, auf sehr abstrakte Art. Wenn man es gewöhnt sich, ist es recht verständlich. Der imperative Stil konzentriert sich mehr auf die einzelnen Schritte und erlangt dabei Vorteile wie short-circuiting.

Ich mochte beide Varianten für den Problemfall nicht und bastelte schnell aus Spaß an der Freud' eine eigene Variante. Die Gedanken dahinter:

• Anonyme Lambdas sind praktisch und ein Grundpfeiler jeglichen funktionalen Stils. Dennoch stellen sie Stolpersteine im Lesen dar. Um die Absicht des Ablaufs zu verdeutlichen, ist es recht praktisch statt reinen Codes einen sprechenden Namen, sprich eine Abstraktion zu verwenden. Ideal wäre eine Macro, selbst wenn es nur einmal genutzt wird, aber Macros sind abseits von Lisp-Dialekten leider Mangelware. Ich finde es in Ordnung, dann eine Funktion zu opfern, auch wenn man sie nicht benötigt, und auf die Kapabilitäten moderner Compiler/Interpreter zu hoffen. Deswegen das Auslagern in kleinere, verdaubarere Abschnitte.

• Imperativer Stil hat den Vorteil, bei frühen Bedingungserfüllungen short-circuiting zu betreiben, ohne groß unnötigerweise Daten zu erzeugen. Das wollte ich beibehalten, das erklärt die if-Klausel, die schon wirksam werden kann, wenn man schon die Anzahl der Knoten weiss, ohne die Einzelwerte der Knoten zu überprüfen. Auch bin ich zunehmend skeptischer gegenüber mehreren Ausstiegspunkten aus einer Funktion. Meine Lösung ist es, anfangs einen Resultatwert mit einem Default zu definieren, für Sonderfälle frühe Ausstiegspunkte beizubehalten, aber letztendlich den Default-Ausstiegspunkt immer ans Ende zu setzen.

• Die else-Klausel hat den Default-Ablauf, was sonst nicht ganz so toll ist, aber in diesem Fall aus anderen Gründen pattern matching/guards aus Haskell und Verwandten simulieren sollte. Die Umwandlung von einer collection von Knoten zu einer collection von Werten halte ich im Gegensatz zur imperativen Variante für besser, um zu verdeutlichen, dass man dann auf einer anderen Ebene operiert. Und der Verzicht aufs anonyme Lambda mit Einsatz eines sprechenderen Namens macht das lesbarer. (Nebenbei: Besser wäre natürlich eine lazy list, oder eines Generators wie Pythons imap(), auch schon vorher. Aber die Infrastruktur für so etwas liefert JS derzeit nicht mit und Nachrüsten ist oft zuviel Aufwand.)

Der konkrete Ablauf ist aber mehr der Logik des imperativen Stils angelehnt. Die Logik lässt sich in einem Satz ausdrücken: „Wenn in der Liste von Werten sich ein Wert vom ersten Wert unterscheidet, dann ist die gesuchte Bedingung erfüllt.“ Nun mixt sich das im imperativen Stil mit zuviel Zeug für Iteration und Aufruf zum konkreten Erlangen von Werten. Für eine Lesbarkeit ist etwas Abstraktion besser. Das bekannte funktionale Konstrukt some (woanders: any) macht im wesentlichen das gleiche wie die imperative Schleife, drückt die Absicht besser aus. Und jede Implementierung von some, die nicht von vollkommen Merkbefreiten programmiert wurde, wird short-circuiting sein, so dass der Effizienz-Vorteil des imperativen Stils erhalten bleibt. Und ich mag die Variablen-Benennung firstpick und nextpick, weil das aufzeigt, was eigentlich verglichen werden soll, ähnlich, wie bei Suchen oft die Namenskombination needle und haystack verwendet wird.

Wenn ich das so aufschreibe, klingt das, als stecke da hinter ein paar Zeilen massive Überlegungen. Dabei ist das mehr das Resultate von Jahren von Lesen und Schreiben von Code und ist mehr intuitiv vorhanden. Ähnlich wie der eigene Stil des Schreibens von Text oftmals aus dem Bauch kommt. Natürlich ist so etwas sowohl im Schreiben als auch im Programmieren ein sehr individueller, sehr subjektiver Stil. Dennoch finde ich, es gibt Kriterien. Oder zumindest Dinge, über die man sich bei Quellcode unterhalten kann. Nur fehlt es oft an Vokabular für diese Ästhetik, deswegen wurde das oben auch so lang. Was der Mensch macht, kann er auch irgendwo anhand möglicher Kriterien beurteilen, eine Schönheit ohne Namen gibt es letztendlich so nicht.

Und das ist letztendlich der Grund für dieses Posting: Ich interessiere mich in letzter Zeit für eine Ästhetik/Lesbarkeit/Intuitive Klarheit von Code. Nicht auf einer Ebene von Microsyntax, auch nicht auf der Ebene von Objekthierarchien, sondern irgendwo dazwischen, bei den Algorithmen. Wie man es schafft, seine abstrakte Vorstellung möglichst gut, tlw. deklarativ zu verdeutlichen. Variablenbenennung. Wann man etwas in Makros oder Funktionen auslagern sollte, nicht wegen DRY, sondern wegen Klarheit. (Siehe z.B. Douglas Crockfords Implementierung eines Top-Down-Parsers und wie er Funktionen wie symbol(), infix(), etc. benutzt. Nicht unbedingt nötig, aber es sorgt für sehr viel mehr Klarheit.) Ich suche also nach schönen Code, Diskussion darüber und den Kriterien dafür.

Dummerweise scheint's dazu wenig Diskussion zu geben, weder im Web, noch in Büchern. Oder ich finde es nur nicht. O'Reillys Beautiful Code geht teilweise in so eine Richtung, ist aber nicht unbedingt das gleiche. Und Ihr, die ihr dieses lange Posting überstanden habt, in dem ich versuche zu erklären, wonach ich eigentlich suche, wisst Ihr da vielleicht etwas interessantes? Bücher, Artikel, Postings, Diskussionen? Ich bin derzeit sehr interessiert und recht polygam in Hinblick auf Programmiersprachen und -paradigma.

Gruß,
Tim

[asdf]

Hallo,

gibts, ist auch schon etwas älter https://www.google.com/cse?q=clean+code.

Guter code zeigt sich vor allen dann, wenn er personen aus folgenden Gruppen standhält (liste nicht vollständig):

http://de.wikipedia.org/wiki/Dunning-Kruger-Effekt davon treiben sich auch viele hier im forum rum.
http://de.wikipedia.org/wiki/Peter-Prinzip man braucht einen moment um solche kollegen zu identifizieren
http://de.wikipedia.org/wiki/Parkinsonsches_Gesetz greift besonders bei kollegen die nicht nein-sagen können, und ergo weniger zeit für mehr aufgaben haben.

hält der code solchen leuten auf dauer und mit ein bisschen pflege stand, dann ist es guter code.

ich verwende immer gerne ein ganz simples beispiel um guten code zu erklären:

  
int sum = 10 * 3 + 1000;  

na? ist der code schlecht?

ja. weil er nicht ausdrückt was der autor vorhatte. jeder mathematiker rollt jetzt schon mit den augen. aber man muss die sachen aus einem anderen sichtwinkel betrachten. wie lange wird der code intakt inkl. kleinen änderungen überleben?

der nächste maintainer wird aus unsäglichen gründen (unkonzentriert, krank, keine zeit, idiot, ...) den code kaputtmachen.

  
int sum = (10 * 3) + 1000;  

ist besser, weil sich der nächste, der den code anfasst nicht fragen muss:

"hat der depp (auch hier gilt der schluss mit den personengruppen) vielleicht doch int sum = 10 * (3 + 1000) gemeint?"

er ist maximal aussagekräftig und zwar nicht minimal kurz, aber minimal kurz, dass er maximale eindeutigkeit enthält.

dann höre ich immer wieder die argumente "wer punkt vor strichrechnung nicht kann ..."

-> DER HAT VIELLEICHT EINFACH EINEN SCHLECHTEN TAG
-> oder liest es im geiste anders
-> oder hat keine zeit ...

guter code lässt sich leicht verstehen. guter code ist so strukturiert, dass man vom groben in die tiefe steigen kann.

guter code erfordert eine menge disziplin, den 98% aller internetbeteiligten, die sich programmierer oder nerd oder geek schimpfen, überhaupt nicht aufbringen können.

und: ein "cleverer" algorithmus führt nicht notwendigerweise zu gutem code.

Hth

[Jeena Paradies]

Hallo,

und: ein "cleverer" algorithmus führt nicht notwendigerweise zu gutem code.

Da kommt natürlich die Folgefrage, muss jeder code so geschrieben sein dass ihn auch der letzte Idiot versteht, oder ist es wichtiger dass der Algoritmus effektiv ist und die software um Magnituden schneller ist und genauso viel weniger Resourcen verbraucht?

Jeena

[asdf]

Hallo,

Da kommt natürlich die Folgefrage, muss jeder code so geschrieben sein dass ihn auch der letzte Idiot versteht, oder ist es wichtiger dass der Algoritmus effektiv ist und die software um Magnituden schneller ist und genauso viel weniger Resourcen verbraucht?

genau die richtige frage, mit der zeit gewinnt man die erfahrung wann welche regeln zu brechen sind!

(und genau diese frage lässt sich auch umgekehrt formulieren)

Hth

[molily]

Da kommt natürlich die Folgefrage, muss jeder code so geschrieben sein dass ihn auch der letzte Idiot versteht, oder ist es wichtiger dass der Algoritmus effektiv ist und die software um Magnituden schneller ist und genauso viel weniger Resourcen verbraucht?

Zumindest im JavaScript-Bereich sind wir so weit, dass wir uns unperformanten Code leisten – und in den häufigsten Fällen auch leisten können. Dass ein unoptimiertes jQuery-Script 20ms läuft, obwohl es hochoptimiert nur 10ms bräuchte, ist i.d.R. egal, wenn das Problem dafür verständlich in drei Codezeilen ausgedrückt wird. Erst wenn ich das Script tausendmal hintereinander ausführen muss, habe ich ein Problem – allerdings wahrscheinlich ein konzeptionelles bei der DOM-Manipulation.

Vor ein paar Jahren war es vielleicht noch so, dass Syntactic Sugar die Performance signifikant gebremst hat. Heute hängt die Performance von JavaScript-Anwendungen von anderen Faktoren ab: Blocking I/O, Reflow/Repaint, Animationen und Effekte, Multimedia-Einbettung, Speicherverbrauch, Flexibilität gegenüber Mobilgeräten und Touch-Interfaces.

Auch im Ruby-Bereich nimmt man extensives Metaprogramming auf sich, um den Programmierern DSLs bereitzustellen, mit denen sie Aufgaben und Sachverhalte konzis notieren können. Performanter ließe sich das sicher lösen, aufs Ganze gesehen geht dabei aber nicht viel Performance verloren. Unperformanten Code zu skalieren ist immer noch weitaus billiger als überbordenden, unlesbaren Code zu entwickeln und zu pflegen.

Mathias

[Jeena Paradies]

Hallo,

Zumindest im JavaScript-Bereich ...
Auch im Ruby-Bereich  ...

Nja mir ist schon klar dass es Bereiche gibt in denen performance gegenüber der Code-Wartbarkeit keine rolle spielt. An anderer Stelle läuft das aber völlig anders, sobald man mit etwas mehr daten als einem Blogeintrag +Kommentare arbeitet muss man sich da doch Gedanken machen.

Ich denke da an sachen wie git, SMS-gateways, Applikationen für mobile Geräte, etc. da kann man sich das (zumindest) noch nicht leisten den code so zu gestalten dass ihn auch jeder PHP-Programmierer verstehen können, da muss man dann bessere Leute einstellen oder zur Verfügung haben.

Jeena

[Stefanie M.]

Da kommt natürlich die Folgefrage, muss jeder code so geschrieben sein dass ihn auch der letzte Idiot versteht, oder ist es wichtiger dass der Algoritmus effektiv ist und die software um Magnituden schneller ist und genauso viel weniger Resourcen verbraucht?

Hi,

fürs erste ist es immer wichtiger, dass der Code gut, sauber, verständlich geschrieben ist. Optimierungen für Laufzeit und Speicherverbrauch sind nachträglich immer möglich, wenn sich herausstellt, dass dies tatsächlich nötig ist. Meist ist es nämlich gar nicht so - nicht mal bei mir im Embedded-Bereich, wo diese Punkte eine recht hohe Bedeutung haben, im Vergleich zu Webanwendungen.

Die Forderung, dass "jeder Idiot den Code versteht" bedingt noch ganz andere Vorteile. Wer sich nämlich im Vorfeld ausreichend Gedanken um die Verständlichkeit macht, wozu nicht zuletzt auch eine gut abgebildete Architektur gehört, der erschafft auch Fehlerresistenteren, besser testbaren, leichter erweiterbaren Code (natürlich gehört dazu noch ein bisschen mehr). Bei den heutigen Umfängen von Projekten ist es ist es zwingend nötig, dass die Kollegen den Code ebenfalls verstehen, und das möglichst schnell.

Außerdem sprechen wir hier nicht von Gegensätzlichkeiten. Wie oft wird z.B.  derselbe Algorithmus mehrfach implementiert, weil die anderen Kollegen gar nicht geschnallt haben, dass es das schon gab.

Mein Lieblingszitat in diesem Zusammenhang: "Jeder Idiot kann Code schreiben, den die Maschine versteht. Die Kunst ist, Code zu schreiben, den ein Mensch versteht."

Ein gutes Schlagwort auch: Refactoring Hier gibt es auch einige Maßstäbe, um die Qualität von Code zu bewerteten.

Grüsse
Stefanie

[Tim Tepaße]

gibts, ist auch schon etwas älter https://www.google.com/cse?q=clean+code.
Guter code zeigt sich vor allen dann, wenn er personen aus folgenden Gruppen standhält (liste nicht vollständig):

Ich such nicht unbedingt nach sauberen Code bzw. Kriterien dafür. Das ist eine notwendige, aber nicht hinreichende Bedingung. Ich such nach etwas darüber, Kriterien für Quellcode die einem sagen lassen, ja, das isses, so funktioniert es.

[dedlfix]

Hi!

gibts, ist auch schon etwas älter https://www.google.com/cse?q=clean+code.
Guter code zeigt sich vor allen dann, wenn er personen aus folgenden Gruppen standhält (liste nicht vollständig):

Ich such nicht unbedingt nach sauberen Code bzw. Kriterien dafür. Das ist eine notwendige, aber nicht hinreichende Bedingung. Ich such nach etwas darüber, Kriterien für Quellcode die einem sagen lassen, ja, das isses, so funktioniert es.

Wenn du sowas allgemeines suchst, kannst du auch versuchen, total idiotensichere Methoden zu finden, um $sachverhalt zu erklären. Manche kommen mit einer bestimmten Erklärung zurecht, andere nicht. Und so wird es mit dem Verständnis eines beliebigen Quelltextes auch sein. Du wirst immer einen finden, der eine bestimmte Notationsweise (noch) nicht vesteht.

Lo!

[Jeena Paradies]

Hallo,

• Anonyme Lambdas sind praktisch und ein Grundpfeiler jeglichen funktionalen Stils. Dennoch stellen sie Stolpersteine im Lesen dar. Um die Absicht des Ablaufs zu verdeutlichen, ist es recht praktisch statt reinen Codes einen sprechenden Namen, sprich eine Abstraktion zu verwenden. Ideal wäre eine Macro, selbst wenn es nur einmal genutzt wird, aber Macros sind abseits von Lisp-Dialekten leider Mangelware.

Naja das stimmt so nicht ganz. In Haskell hast du let und where, in Python generatoren, in Erlang fun und sogar in JavaScript kannst du ja die funktion auch in einer Variable speichern die dann als macro fungiert. Oder missverstehe ich deine Definition von "Macro"?

Wie man es schafft, seine abstrakte Vorstellung möglichst gut, tlw. deklarativ zu verdeutlichen.

Da helfen deklarative Sprachen ungemein, wenn ich da an einfache SQL-Queries denke, die kann eigentlich jeder verstehen der auch ein bisschen Englisch kann.

Variablenbenennung. Wann man etwas in Makros oder Funktionen auslagern sollte, nicht wegen DRY, sondern wegen Klarheit.

Ich habe mal John Huges beim programmieren zugeschaut, und er macht überall Macros (wenn auch mit sehr komischen namen wie ## oder @@ und es wird Abstrachiert bis zum geht nicht mehr. Und wie als Studenten dürfen dann stundenlang zu Hause sitzen und versuchen zu verstehen was denn die zwei Zeilen code eigentlich tun.

Ich linke mal hier die drei Videos von den Vorlesungen über functional programming:

Functional programming I
Functional programming II
Functional programming III

und hier noch etwas begleitender code:

ParserLibrary.hs
Calculator.hs

Ich bin derzeit sehr interessiert und recht polygam in Hinblick auf Programmiersprachen und -paradigma.

Das klingt wirklich danach dass du eigentlich diesen Kurs aus dem die Videos sind besuchen wollen würdest er hieß damals "Programming Paradigms" und hat mit funktionaler Programmierung angefangen ist dann über concurrent zu Imperativ und schließlich zu Objektorientiert und Logischem programmieren.

Hier noch der Link zur Übersicht über die sachen die beim kurs verteilt wurden: https://www.student.chalmers.se/hp/hp/?hp_id=7710&hp_view=handout

Jeena

[Tim Tepaße]

Naja das stimmt so nicht ganz. In Haskell hast du let und where, in Python generatoren, in Erlang fun und sogar in JavaScript kannst du ja die funktion auch in einer Variable speichern die dann als macro fungiert. Oder missverstehe ich deine Definition von "Macro"?

Ja, teilweise. Generatoren würde ich auch nicht ansatzweise als Macro bezeichnen den Rest als Krücken. Meine – und ich glaube die übliche – Definition von Macro ist diese hier: Ein Syntaxkonstrukt, das vor dem Evaluieren zu einer anderen Syntax umgewandelt wird. Und diese wird dann geparst und evaluiert.

Ich sehe Macros also mehr als eine Abstraktion für den Programmierer denn für den Compiler/Interpreter. Man ist nicht mehr an die syntaktischen Konstrukte der Sprache gebunden, sondern kann was eigenes machen. Für sich selbst, für Lesbarkeit und Klarheit. Und damit ist das ein Anwendungsfall immer dann, wenn man für sich und die anderen Leser des Quellcodes Redundanz vermeiden will. Oder wenn man Dinge auslagern will.

Und warum nicht Funktionen? Funktionen haben Overhead. Aufruf, Stack, Scope, Closures, etc. Dafür sind sie ideal, aber dennoch braucht es sie für obige Anwendungsfälle nicht. Macros ziehen nur eine Ebene zwischen dem geschriebenen Quellcode und dem Evaluieren des Parsetrees ein. Und dazu kommt, dass man bei „echten Macros“ sehr viel mehr syntaktische Freiheit hat – kann man auf den Parsetree zugreifen – als bei Funktionsaufrufen, deswegen greift die reine Macros-als-vermeintliche-Funktionsaufrufe-Syntax des C-Preprozessors etwas zu kurz.

Ich hab natürlich für meine „echten Macros“ etwas vor Augen, die Macros aus den LISP-Dialekten. Lisp hat den Vorteil (und Nachteil), dass die syntaktische Struktur letztendlich nur die Text-Variante eines Parsetrees ist. Dadurch kann man diesen in Macros wunderbar manipulieren. Les mal das Macro-Kapitel aus Practical Common Lisp quer. Und staune später, was für Konstruktionen möglich sind, wie das loop-Macro, das so etwas ist, wie Pythons generator expressions oder noch besser C#s LINQ auf Steroiden. Denn wenn man die Möglichkeit hat, für sich komplexe Aktionen syntaktisch wegzuabstrahieren, kann man sehr viel mehr in sehr viel weniger ausdrücken, die Programmiersprache für seinen Problemfall erweitern und damit geeigneter und klarer machen. Von Paul Graham stammt der (sinngemäße) Auspruch, dass Programmieren in Lisp bedeutet, sich eine Sprache für sein Problem zusammenzubauen und dann das Problem geeigneter zu lösen, ich glaube aus seinem Buch On Lisp. Macros sind also eine Möglichkeit, sich DSLs zu basteln.

Und im Vergleich sind dann Funktionen oder Methoden wie in Ruby eher nur Krücken, um Abstraktionen zu erreichen. Gut, in einer massiv funktionalen Sprache wie Haskell gilt das nicht unbedingt, let und where liefern dem Interpreter/Compiler durchaus genug Informationen um Rausabstrahiertes inlinen zu können. Aber dennoch.

Das klingt wirklich danach dass du eigentlich diesen Kurs aus dem die Videos sind besuchen wollen würdest er hieß damals "Programming Paradigms" und hat mit funktionaler Programmierung angefangen ist dann über concurrent zu Imperativ und schließlich zu Objektorientiert und Logischem programmieren.

Ich les ja genügend quer und wild rum, um so ein ähnliches Halbwissen zu erlangen. Aber dennoch, neulich im Query mit CK:

„Warst Du nicht auch die letzten Jahre manchmal neidisch auf Jeenas Studienprogramm? Chalmers scheint mit all den Sprachen das viel interessanter zu machen als die deutsche Durchschnittsuni.“
„grinsendes Bejahen.“

;)

[Jeena Paradies]

Hallo,

Ja, teilweise. Generatoren würde ich auch nicht ansatzweise als Macro bezeichnen den Rest als Krücken. Meine – und ich glaube die übliche – Definition von Macro ist diese hier: Ein Syntaxkonstrukt, das vor dem Evaluieren zu einer anderen Syntax umgewandelt wird. Und diese wird dann geparst und evaluiert.

Ich sehe Macros also mehr als eine Abstraktion für den Programmierer denn für den Compiler/Interpreter. Man ist nicht mehr an die syntaktischen Konstrukte der Sprache gebunden, sondern kann was eigenes machen. Für sich selbst, für Lesbarkeit und Klarheit. Und damit ist das ein Anwendungsfall immer dann, wenn man für sich und die anderen Leser des Quellcodes Redundanz vermeiden will. Oder wenn man Dinge auslagern will.

Aaah ok dann verstehe ich. Allerdings hindert dich keiner daran einen Proprozessor vor den compiler zu spannen der genau das macht. Ich erinnere da gerne an Coffescript das das ganze wohl auf die Spitze treibt ;)

Aber ich bin da skeptisch dass das wirklich die Lesbarkeit erhöhen würde. Für dich selbst ja, für jemanden von außen eher nicht, denn dann muss er nicht nur die syntax der Programmiersprache kennen sondern auch noch die deiner Macrosprache.

Ich hab natürlich für meine „echten Macros“ etwas vor Augen, die Macros aus den LISP-Dialekten. Lisp hat den Vorteil (und Nachteil), dass die syntaktische Struktur letztendlich nur die Text-Variante eines Parsetrees ist.

Hm ok, das ist da schon was völlig anderes als ich irgendwie erwartet hätte. Aber guck dir mal den zweiten von mir verlinkten film an ab minute 25. Da programmiert John schlussendlich in Haskell eine DSL extra für Parser und die sieht, obwohl eigentlich plain Haskell, verblüffend ähnlich der BNF (Context Free Grammar).

Und im Vergleich sind dann Funktionen oder Methoden wie in Ruby eher nur Krücken, um Abstraktionen zu erreichen.

Ja ok von diesem Standpunkt aus gesehen wohl ja, wobei man an Rails ganz gut sehen kann dass wenn man es sinnvoll macht dann geht da auch schon einiges.

Aus Haskell müsstest du auch Currying kennen, ich finde damit lässt sich code viel besser lesbar machen als mit Macros (zumindest solchen wie bei C). Allerdings muss der Programmierer das Konzept auch schon vereinnamt haben, für einen Laien sind das nur unfertige Funktionen.

Es kommt halt wirklich auf die Zielgruppe drauf an. Will man dass es für Leute in diesem Forum lesbar ist, oder für eine Gruppe von Biologie-Informatik-Professoren die den ganzen Tag nichts anderes machen als Simulationen zu basteln um ihre Hypothesen zu testen.

„Warst Du nicht auch die letzten Jahre manchmal neidisch auf Jeenas Studienprogramm? Chalmers scheint mit all den Sprachen das viel interessanter zu machen als die deutsche Durchschnittsuni.“
„grinsendes Bejahen.“

;)

Hehe, ja ich kann wirklich nicht klagen was das angeht, auch wenn mir immer vorgeworfen wird ich hüpfe von einer Sprache zur nächsten nur weil sie gerade Hipp ist ;)

Jeena

[Der Martin]

Hallo,

es gibt verschiedene Kriterien, um Code zu beurteilen. Zum Beispiel:
• Einhaltung der Styleguides der jeweiligen Sprache, des Projektes, der Firma.

die Übereinstimmung mit vorgegebenen Style Guides ist IMO kein Kriterium, um Code zu beurteilen, sondern höchstens, um die Style Guides zu beurteilen.

• Ansprechende Formatierung
• Effizienz, sprich bestes O() erreichen. Auch Speichereffizienz.
• Mit der Programmiersprache/API arbeiten, statt gegen sie. D.h. in Javaland objektorientiert, in Haskell funktional. Gerne mal die standard library durchforsten, was es da alles schon gibt und wie es einem helfen kann.

Alles sinnvolle Kriterien, denke ich.

Mich beschäftigt etwas, was irgendwo dazwischen liegt, wofür ich aber nicht so wirklich ein Vokabular finde. Nicht Microästhetik wie Formatierung sondern mehr eine Ästhetik, die den Quellcode verständlicher macht. Die Absicht hinter dem konkreten Ablauf verständlich macht und gleichzeitig verwirklicht.

Ich glaube zu verstehen, was du meinst - und behaupte mal, dass man das in der Praxis vieler Programmiersprachen und -umgebungen nur durch eine ausgewogene Kombination von eingängigem Code und hilfreichen Kommentaren erreichen kann.

Ok, das klingt vielleicht zu abstrakt, deswegen ein Beispiel. Ich bin vor ein paar Tagen über diese Quellcodeschnipsel gestolpert. Dort werden zwei Programmiervarianten für ein Problem verglichen. Zum einen eine recht funktionale Variante, zum anderen eine imperative Variante.

Ohne jetzt die zugrundeliegende Aufgabe zu kennen: Auf den ersten Blick erscheinen mir beide Varianten ziemlich komplex. Wenn ich mich in die Materie einarbeite, würde ich aber vermutlich die erste Version für "ästhetischer" halten, weil sie alle relevanten Schritte zu einem umfangreichen Ausdruck kombiniert, anstatt sie in mehrere abgehackte Einzelschritte zu zerlegen, deren Zusammenhang man erst mühsam wieder herstellen muss.

Ich mochte beide Varianten für den Problemfall nicht und bastelte schnell aus Spaß an der Freud' eine eigene Variante.

Auf den ersten Blick fällt es mir bei der Variante noch schwerer, mich darin zurechtzufinden. Möglich, dass das nach einer kurzen Einarbeitung anders aussieht.

• Anonyme Lambdas ...

Was soll das sein? Den Begriff habe ich noch nie gehört.

Ideal wäre eine Macro, selbst wenn es nur einmal genutzt wird, aber Macros sind abseits von Lisp-Dialekten leider Mangelware.

In C sind sie durchaus üblich.

• Imperativer Stil hat den Vorteil, bei frühen Bedingungserfüllungen short-circuiting zu betreiben, ohne groß unnötigerweise Daten zu erzeugen.

Das ist sicher ein Vorzug.

Auch bin ich zunehmend skeptischer gegenüber mehreren Ausstiegspunkten aus einer Funktion.

Ich nicht, im Gegenteil: Sobald das Ergebnis einer Funktion feststeht, beende ich sie. Ich finde das übersichtlicher, als "pro forma" das schon feststehende Ergebnis bis zum Ende der Funktion durchzureichen.

pattern matching/guards aus Haskell ... anonyme Lambda ... lazy list

Wenn du nicht so sehr mit extrem spezifischen Buzzwords um dich werfen würdest, könnte man vielleicht sogar verstehen, was du sagen möchtest.

Und das ist letztendlich der Grund für dieses Posting: Ich interessiere mich in letzter Zeit für eine Ästhetik/Lesbarkeit/Intuitive Klarheit von Code. Nicht auf einer Ebene von Microsyntax, auch nicht auf der Ebene von Objekthierarchien, sondern irgendwo dazwischen, bei den Algorithmen. Wie man es schafft, seine abstrakte Vorstellung möglichst gut, tlw. deklarativ zu verdeutlichen.

Meiner Ansicht nach erreicht man das am besten, indem man versucht, den natürlichen Gedankengang so gut wie möglich mit den Strukturen der jeweiligen Programmiersprache abzubilden. Das ist allerdings keine Einbahnstraße: Intensive Beschäftigung mit einer bestimmten Programmiermethode führt dazu, dass man selbst anfängt, so zu denken, und das als "normal und intuitiv" empfindet.

Das finde ich aber gar nicht so schlimm, denn Programmieren ist einerseits eine Art Handwerk, das man erlernen und üben kann, andererseits aber auch eine Art Kunst, für die man eine gewisse Begabung mitbringen sollte. Und so muss "ästhetischer", gut verständlicher Programmcode auch nicht für jeden Laien verständlich sein, sondern für jemanden, der selbst die Grundzüge der Programmierung, der Programmiersprache und des individuellen Problems kennt.

Und Ihr, die ihr dieses lange Posting überstanden habt, in dem ich versuche zu erklären, wonach ich eigentlich suche, wisst Ihr da vielleicht etwas interessantes? Bücher, Artikel, Postings, Diskussionen?

Leider nein, denn ich fürchte, die Ansichten und Meinungen dazu sind sehr zahlreich und kontrovers.

Ciao,
 Martin

[Jeena Paradies]

Hallo,

• Anonyme Lambdas ...
Was soll das sein? Den Begriff habe ich noch nie gehört.

Funktionen ohne namen, die Idee kommt aus dem Lambda Kalkül wurde mitunter von Christian Seiler nicht allzulange her sogar in PHP implementiert http://php.net/manual/en/functions.anonymous.php (wobei nicht wirklich schön aber was ist bei PHP schon schön).

• Imperativer Stil hat den Vorteil, bei frühen Bedingungserfüllungen short-circuiting zu betreiben, ohne groß unnötigerweise Daten zu erzeugen.
Das ist sicher ein Vorzug.

Mir ist gerade eingefallen dass man mit Hilfe von lazy evaluation das ganze bei funktionalen sprachen sogar automatisieren kann, also kein richtiger Vorteil des imperativen Stils.

Auch bin ich zunehmend skeptischer gegenüber mehreren Ausstiegspunkten aus einer Funktion.
Ich nicht, im Gegenteil: Sobald das Ergebnis einer Funktion feststeht, beende ich sie. Ich finde das übersichtlicher, als "pro forma" das schon feststehende Ergebnis bis zum Ende der Funktion durchzureichen.

Hach ja, solche Probleme hat man wirklich nur bei imperativen sprachen ^^.

pattern matching/guards aus Haskell ... anonyme Lambda ... lazy list
Wenn du nicht so sehr mit extrem spezifischen Buzzwords um dich werfen würdest, könnte man vielleicht sogar verstehen, was du sagen möchtest.

Sind Begriffe aus der Informatik, vor allem vorzufinden bei funktionalen und logischen sprachen. Aber du hast wohl recht dass er hätte sie für dieses Forum erst einmal einführen sollen.

Jeena

[Tim Tepaße]

Wenn ich mich in die Materie einarbeite, würde ich aber vermutlich die erste Version für "ästhetischer" halten, weil sie alle relevanten Schritte zu einem umfangreichen Ausdruck kombiniert, anstatt sie in mehrere abgehackte Einzelschritte zu zerlegen, deren Zusammenhang man erst mühsam wieder herstellen muss.

Ich weiß nicht. Ich bin ja durchaus kein Feind von umfangreichen und mächtigen Ausdrucken, schließlich gehe ich immer mehr in die Richtung von higher order functions wie map, reduce, currying und so. Aber dennoch finde ich, dass man versuchen sollte, konzeptionelle Einzeiler zu vermeiden, auch wenn sie wie hier etwas sauberer geschrieben werden. Programmieren ist zu einem Großteil die Kunst, Probleme in Einzelschritte zu überlegen. Aus verschiedenen Gründen, einer ist zum Beispiel Testbarkeit von Einzelschritten. Aber eben auch das, und das ist, was ich in meinem Posting oben ansprach, dass definierte Einzelschritte weniger kognitive Last mit sich bringen und ein Programm somit klarer und verständlicher für den Lesenden und Programmierenden machen.

• Anonyme Lambdas ...
Was soll das sein? Den Begriff habe ich noch nie gehört.

Ein weißer Schimmel. Lambda ist der klassische Ausdruck für on-the-fly definierte Funktionen. Bist Du bestimmt schon tausendmal drüber gestolpert. Vergleiche mal diesen pythonischen Quellcode, der die Zahlen einer Liste verdoppelt:

~~~python def double(number):
      return number*2

a = [1, 2, 4, 5]
  b = map(double, a)

  
  vs.  
  
  ~~~python
a = [1, 2, 4, 5]  
  b = map(lambda x: x*2, a)

Das Konstrukt findet sich überall, in JS als function expressions, Rubys Blocks, etc. Ist ja auch praktisch, nicht nur wegen des on-the-fly-Aspektes, sondern auch dann, wenn man diverse Funktionen (evtl. mit Closure) erzeugt und rumreichen will. Lambda ist nur ein Name dafür, der, wie Jeena schon sagt, aus dem Lambda Kalkül kommt.

pattern matching/guards aus Haskell ... anonyme Lambda ... lazy list
Wenn du nicht so sehr mit extrem spezifischen Buzzwords um dich werfen würdest, könnte man vielleicht sogar verstehen, was du sagen möchtest.

Nun ja, ich fange ja schon relativ früh an, über funktionalen Stil zu reden und denke, die Zielgruppe meines Postings sind Leute, die mit diversen Programmierstilen vertraut sind und auch schon mal in funktionalen Sprachen reingeschnuppert haben. Oder sich schnell bei Wikipedia schlau lesen können.

Pattern matching ist syntaktischer Zucker, um diverse Funktionsvarianeten anhand der übergebenen Daten unterscheiden zu können. Nimm mal diese aus Real World Haskell entnommene Funktionen:

~~~haskell -- Eine Funktion, die die Zahlen einer Liste quadriert
  square :: [Double] -> [Double]   -- Typ-Definition. Ignorier's
  square (x:xs) = x*x : square xs  -- Nimm das erste Element der Liste und
                                   -- quadriere es, bilde mit dem Ergebnis des
                                   -- rekursiven Aufrufs der Funktion auf den
                                   -- Rest der Liste eine neue Liste
  square []     = []               -- Bei der leeren Liste gib eine leere Liste
                                   -- zurück. Abbruch der Rekursion.

  
Guard erweitern diese Möglichkeit um Vorbedingungen:  
  
  ~~~haskell
-- Eine Funktion die eine Liste nur auf ungerade Zahlen filtert.  
  oddList :: [Int] -> [Int]  
  oddList (x:xs) | odd x     = x : oddList xs  -- Hier ist der Guard. Mach dies,  
                                               -- wenn das erste Listenelement  
                                               -- ungerade its.  
                 | otherwise = oddList xs      -- Ansonsten das.  
  oddList _                  = []

Kann man auch alles klassisch machen, mit vielen if-Klauseln und so. Kann man. Aber wenn man so eine schöne deklarative Syntax hat, ist es netter. Und lesbarer, ist man es gewöhnt.

Leider nein, denn ich fürchte, die Ansichten und Meinungen dazu sind sehr zahlreich und kontrovers.

Nun ja, ich will mir ja selber mein Interesse befriedigen und eine fundiertere Meinung bilden. Dafür sind kontroverse Diskussionen nicht schlecht.

[Der Martin]

Hallo,

schließlich gehe ich immer mehr in die Richtung von higher order functions wie map, reduce, currying und so.

... und schon wieder diese Buzzwords, unter denen man sich als traditioneller Softwareentwickler und Programmierer nichts vorstellen kann, auch wenn man die Techniken, die damit gemeint sind, vermutlich kennt - eventuell unter anderem Namen. Oder man kennt das Prinzip, aber überhaupt keinen Namen dafür, weil es etwas Selbstverständliches ist.

Programmieren ist zu einem Großteil die Kunst, Probleme in Einzelschritte zu überlegen.

Du meinst "zerlegen", nicht "überlegen".
Ja, sicher - aber es ist auch die Kunst, diese Zerlegung nicht zu weit zu treiben. Wenn man sie nämlich weiter praktiziert, als man ein Problem im Kopf zerlegt und analysiert, also quasi-atomare Vorgänge noch weiter aufsplittet, dann erreicht man damit das Gegenteil von dem, was man eigentlich anstrebt.

Aus verschiedenen Gründen, einer ist zum Beispiel Testbarkeit von Einzelschritten.

Das ist ein Argument; dafür kann man ja während der Entwicklungsphase diese Schritte isolieren. Im fertigen Code sollte die Granularität aber nicht mehr unbedingt so fein wie möglich sein, sondern nur so fein, wie man das Problem "üblicherweise" auch im Kopf gliedern würde.

[...] dass definierte Einzelschritte weniger kognitive Last mit sich bringen und ein Programm somit klarer und verständlicher für den Lesenden und Programmierenden machen.

Ja, solange man das nicht übertreibt.

• Anonyme Lambdas ...
Was soll das sein? Den Begriff habe ich noch nie gehört.
Ein weißer Schimmel. Lambda ist der klassische Ausdruck für on-the-fly definierte Funktionen.

Ist mir in dem Zusammenhang noch nicht begegnet.

Das Konstrukt findet sich überall, in JS als function expressions, ...

Also anonyme Funktionen. Okay, damit kann ich schon mehr anfangen.

Lambda ist nur ein Name dafür, der, wie Jeena schon sagt, aus dem Lambda Kalkül kommt.

Was für mich, wie gesagt, ein böhmisches Dorf ist.

Mir scheint, du kennst relativ viele, aus meiner Sicht exotische Programmiersprachen (exotisch hier: geringe Verbreitung) wie Haskell, Python oder Erlang, die viele Programmierer nur dem Namen nach kennen. Erwarte also nicht, dass alle verstehen, was du meinst, wenn du spezielle Konzepte aus diesen Sprachen als Beispiele nennst.

So long,
 Martin

[Jeena Paradies]

Hallo,

schließlich gehe ich immer mehr in die Richtung von higher order functions wie map, reduce, currying und so.
... und schon wieder diese Buzzwords, unter denen man sich als traditioneller Softwareentwickler und Programmierer nichts vorstellen kann

Schwierig, ich finde als Programmierer sollte man diese Begriffe zumindest schon mal gehört haben so dass man sie durch kurzes googeln auch nachvollziehen kann, denn das sind Grundbegriffe wenn man sich über funktionales Programmieren unterhalten möchte.

Aus verschiedenen Gründen, einer ist zum Beispiel Testbarkeit von Einzelschritten.
Das ist ein Argument; dafür kann man ja während der Entwicklungsphase diese Schritte isolieren. Im fertigen Code sollte die Granularität aber nicht mehr unbedingt so fein wie möglich sein, sondern nur so fein, wie man das Problem "üblicherweise" auch im Kopf gliedern würde.

Hm moment, wie testest du denn deinen code dass du ihn vor dem ausliefern noch mal umschreiben willst? Natürlich bleiben die Schritte so wie sie sind damit man jeder zeit seine Unittests (oder was man auch immer für ein Testframework benutzt) duchlaufen lassen kann.

Jeena

[Der Martin]

Hi,

schließlich gehe ich immer mehr in die Richtung von higher order functions wie map, reduce, currying und so.
... und schon wieder diese Buzzwords, unter denen man sich als traditioneller Softwareentwickler und Programmierer nichts vorstellen kann
Schwierig, ich finde als Programmierer sollte man diese Begriffe zumindest schon mal gehört haben so dass man sie durch kurzes googeln auch nachvollziehen kann, denn das sind Grundbegriffe wenn man sich über funktionales Programmieren unterhalten möchte.

deswegen sagte ich ja: Die Konzepte, die dahinterstecken, sind vermutlich vielen bekannt. Aber eben nicht unter diesen Modebegriffen.

Aus verschiedenen Gründen, einer ist zum Beispiel Testbarkeit von Einzelschritten.
Das ist ein Argument; dafür kann man ja während der Entwicklungsphase diese Schritte isolieren. Im fertigen Code sollte die Granularität aber nicht mehr unbedingt so fein wie möglich sein, sondern nur so fein, wie man das Problem "üblicherweise" auch im Kopf gliedern würde.
Hm moment, wie testest du denn deinen code dass du ihn vor dem ausliefern noch mal umschreiben willst?

Klar, warum nicht? Wenn ich Einzelschritte mal validiert und hinreichend getestet habe, kann ich sie auch wieder zu sinnvollen Einheiten kombinieren, so dass sie auch einen Sinn ergeben.

Natürlich bleiben die Schritte so wie sie sind damit man jeder zeit seine Unittests (oder was man auch immer für ein Testframework benutzt) duchlaufen lassen kann.

Nö. Das mach ich doch nicht immer wieder und wieder, sondern nur während der Entwicklung eines Moduls oder einer Funktion. Irgendwann gilt das Ding als hinreichend getestet und "okay" innerhalb der Spezifikationen.

Ciao,
 Martin

[DaBear]

Natürlich bleiben die Schritte so wie sie sind damit man jeder zeit seine Unittests (oder was man auch immer für ein Testframework benutzt) duchlaufen lassen kann.

Nö. Das mach ich doch nicht immer wieder und wieder, sondern nur während der Entwicklung eines Moduls oder einer Funktion. Irgendwann gilt das Ding als hinreichend getestet und "okay" innerhalb der Spezifikationen.

Dann hast du entweder noch nicht an wirklich großen und komplexen Projekten gearbeitet oder bist ein Genie und Supercoder. Schreibt man einzelne Funktionen, mag das ja noch gut gehen. Wenn in einem Projekt aber viele viele Komponenten zusammenspielen, von denen du vielleicht 10% kennst, dann ist es unumgänglich immer wieder Unittests zu nutzen. Fehler verstecken sich teilweise sehr lange und kommen dann plötzlich unerwartet zum Vorschein. Besonders wenn gewisse Abläufe zeitabhängig werden und/oder Zufall mit ins Spiel kommt, bist du ohne systematisches Testen ab einer gewissen Größe schlicht und einfach aufgeschmissen.

[Der Martin]

Hallo,

Natürlich bleiben die Schritte so wie sie sind damit man jeder zeit seine Unittests (oder was man auch immer für ein Testframework benutzt) duchlaufen lassen kann.
Nö. Das mach ich doch nicht immer wieder und wieder, sondern nur während der Entwicklung eines Moduls oder einer Funktion. Irgendwann gilt das Ding als hinreichend getestet und "okay" innerhalb der Spezifikationen.
Dann hast du entweder noch nicht an wirklich großen und komplexen Projekten gearbeitet oder bist ein Genie und Supercoder.

vielleicht von allem etwas. ;-)
Nein, im Ernst: Mag sein, dass ich wirklich noch nicht an "großen und komplexen Projekten" nach deinem Maßstab gearbeitet habe. Aber selbst wenn: Jedes Projekt, und sei es noch so umfangreich, lässt sich in Teilprobleme (Module) mit überschaubarer Komplexität zerlegen. Das Wichtigste dabei ist, dass die Schnittstellen dieser Teilprobleme eindeutig definiert sind.

Schreibt man einzelne Funktionen, mag das ja noch gut gehen.

Genau, jede wird zunächst isoliert für sich getestet: Liefert sie für alle erlaubten Argumente das gewünschte Ergebnis? Wenn das einmal sichergestellt ist, kann man sie mit anderen, ebenso getesteten Funktionen zu einer größeren Einheit kombinieren. Theoretisch müsste diese zusammengesetzte Einheit auch einwandfrei funktionieren, wenn alle Schnittstellen korrekt eingehalten werden. Da aber, wie du schon andeutest, oft der Teufel im Detail steckt, wird diese Ebene natürlich auch wieder getestet - aber dabei betrachte ich nur noch die Schnittstellen dieses Moduls nach außen. Erst wenn ich da feststelle, dass etwas nicht stimmt, muss ich wieder ins Eingamachte, und muss jede interne Schnittstelle erneut untersuchen, bis ich die Funktion(en) gefunden habe, wo der Fehler auftritt.

Erweist sich aber das komplette Modul als fehlerfrei im Rahmen der Spezifikation, dann betrachte ich auch die Funktionen, aus denen es aufgebaut ist, als fehlerfrei unter den gleichen Bedingungen. Ich kann sie also fürs nächste Projekt gleich wieder einsetzen und brauche dort nicht wieder auf dem untersten Level zu testen.

Wenn in einem Projekt aber viele viele Komponenten zusammenspielen, von denen du vielleicht 10% kennst, ...

... dann muss ich wohl den Aufwand treiben, diese Komponenten als "Black Box" ausführlich zu testen. Wünschenswert wäre dabei Zugang zum Quellcode; den hat man aber leider nicht immer. Diese Unwägbarkeiten bei der Verwendung von unbekanntem Code sind aber auch *ein* Grund, warum ich von größeren Frameworks normalerweise Abstand halte. Stattdessen implementiere ich lieber den kleinen Bruchteil selbst, den ich davon nutzen würde. Dann kenne ich meinen Code wenigstens genau und weiß, was er kann oder was er nicht kann. Erfahrungsgemäß ist dieses Vorgehen meist schneller, als sich erst in fremde Frameworks (wie etwa Microsofts .NET) einzuarbeiten.

Oder ich lehne so ein Projekt ab, dessen Umfang oder Komplexität ich nicht überblicken kann.

dann ist es unumgänglich immer wieder Unittests zu nutzen.

Ja. Aber nur noch für die Units/Module, die für sich noch nicht getestet sind bzw. modifiziert oder um etwas Neues ergänzt wurden.

So long,
 Martin

[DaBear]

Hallo,

Natürlich bleiben die Schritte so wie sie sind damit man jeder zeit seine Unittests (oder was man auch immer für ein Testframework benutzt) duchlaufen lassen kann.
Nö. Das mach ich doch nicht immer wieder und wieder, sondern nur während der Entwicklung eines Moduls oder einer Funktion. Irgendwann gilt das Ding als hinreichend getestet und "okay" innerhalb der Spezifikationen.
Dann hast du entweder noch nicht an wirklich großen und komplexen Projekten gearbeitet oder bist ein Genie und Supercoder.

vielleicht von allem etwas. ;-)
Nein, im Ernst: Mag sein, dass ich wirklich noch nicht an "großen und komplexen Projekten" nach deinem Maßstab gearbeitet habe. Aber selbst wenn: Jedes Projekt, und sei es noch so umfangreich, lässt sich in Teilprobleme (Module) mit überschaubarer Komplexität zerlegen. Das Wichtigste dabei ist, dass die Schnittstellen dieser Teilprobleme eindeutig definiert sind.

Schreibt man einzelne Funktionen, mag das ja noch gut gehen.

Genau, jede wird zunächst isoliert für sich getestet: Liefert sie für alle erlaubten Argumente das gewünschte Ergebnis?

Da fängt es ja schon an. Manchmal ist das "gewünschte Ergebnis" zwar eben dieses, aber trotzdem logisch falsch. Solche logischen Fehler pflanzen sich oft lange lange fort und tauchen plötzlich irgendwo auf und man fragt sich warum. Syntaktische Fehler lassen sich da vergleichsweise schnell beheben.

Wenn das einmal sichergestellt ist, kann man sie mit anderen, ebenso getesteten Funktionen zu einer größeren Einheit kombinieren. Theoretisch müsste diese zusammengesetzte Einheit auch einwandfrei funktionieren, wenn alle Schnittstellen korrekt eingehalten werden. Da aber, wie du schon andeutest, oft der Teufel im Detail steckt, wird diese Ebene natürlich auch wieder getestet

Und jetzt stell dir vor du hast 100 dieser Ebenen. Und nun stell dir vor, es soll sich grundlegend etwas ändern (Kunden...) und du musst die Struktur und die Zusammensetzung/Kombination der Module ändern. Und jetzt stell dir vor, dass du auf externe Module angewiesen bist, vielleicht sogar auf solche, die du nicht einmal per reverse engineerung analysieren kannst.

Und zu guter letzt ist es viel zu aufwendig wirklich jeden Testfall durchzuspielen. Und mit den bisher vorhandenen Testfällen mögen die bisherigen Module korrekt zu sein scheinen, aber im zusammenspiel wird dann plötzlich ein vorher nicht getester Fall relevant.

In der Theorie mag das, was du sagst, funktionieren. Aber die Realität zeigt, dass dies ab einer gewissen Größe zu aufwendig wird und aufgrund unterschiedlicher Informatiker/Programmierer (die alle unterschiedliche Fehler machen) kaum machbar ist.

Wenn in einem Projekt aber viele viele Komponenten zusammenspielen, von denen du vielleicht 10% kennst, ...

... dann muss ich wohl den Aufwand treiben, diese Komponenten als "Black Box" ausführlich zu testen.

Und wenn sich diese Komponenten verändern (z.B. SaaS o.ä.)? Dann müsstest du bei jeder Änderung (die du meist nicht mitkriegst) erneut manuell testen.

Wünschenswert wäre dabei Zugang zum Quellcode; den hat man aber leider nicht immer. Diese Unwägbarkeiten bei der Verwendung von unbekanntem Code sind aber auch *ein* Grund, warum ich von größeren Frameworks normalerweise Abstand halte. Stattdessen implementiere ich lieber den kleinen Bruchteil selbst, den ich davon nutzen würde. Dann kenne ich meinen Code wenigstens genau und weiß, was er kann oder was er nicht kann. Erfahrungsgemäß ist dieses Vorgehen meist schneller, als sich erst in fremde Frameworks (wie etwa Microsofts .NET) einzuarbeiten.

In einem privaten Projekt geht das wohl. Nicht aber auf geschäftlicher Ebene. Aus vielen Gründen.

[Der Martin]

Hi,

Schreibt man einzelne Funktionen, mag das ja noch gut gehen.
Genau, jede wird zunächst isoliert für sich getestet: Liefert sie für alle erlaubten Argumente das gewünschte Ergebnis?
Da fängt es ja schon an. Manchmal ist das "gewünschte Ergebnis" zwar eben dieses, aber trotzdem logisch falsch.

ähm, nein. Nicht, wenn die Anforderung klar definiert ist.

[...] Da aber, wie du schon andeutest, oft der Teufel im Detail steckt, wird diese Ebene natürlich auch wieder getestet
Und jetzt stell dir vor du hast 100 dieser Ebenen.

Das bedeutet einen Riesenaufwand, den ich aber für unumgänglich halte. Okay, bei umfangreichen Projekten mag es sinnvoll sein, die Tests auf eine Menge von Stichproben zu beschränken, die man vorher sorgfältig auswählt. Aber das bringt natürlich eine gewisse Unsicherheit ins Spiel.

Und nun stell dir vor, es soll sich grundlegend etwas ändern (Kunden...) und du musst die Struktur und die Zusammensetzung/Kombination der Module ändern.

Wenn irgendwo tief im Innern das ausführlich getestete Modul X gegen das ebenfalls ausführlich getestete Modul U getauscht werden soll, ist das IMO ohne großen Aufwand möglich, wenn
 * X und U die gleiche Schnittstelle haben und unter denselben Bedingungen getestet wurden
oder
 * die Schnittstelle(n) von U eine Obermenge von X ist, die sich innerhalb der Grenzen von
   X gleich verhält.
Nur wenn die zusätzlichen Möglichkeiten von U im Gesamtprojekt tatsächlich genutzt werden (wenn nicht, wäre der Austausch ja sinnlos), sind erneute Tests kaum zu vermeiden.

Und jetzt stell dir vor, dass du auf externe Module angewiesen bist, vielleicht sogar auf solche, die du nicht einmal per reverse engineerung analysieren kannst.

Nur unter Zwang oder Gewaltandrohung.

Und zu guter letzt ist es viel zu aufwendig wirklich jeden Testfall durchzuspielen. Und mit den bisher vorhandenen Testfällen mögen die bisherigen Module korrekt zu sein scheinen, aber im zusammenspiel wird dann plötzlich ein vorher nicht getester Fall relevant.

Das kann passieren, wenn man die Tests auf Stichproben reduzieren muss.

Wenn in einem Projekt aber viele viele Komponenten zusammenspielen, von denen du vielleicht 10% kennst, ...
... dann muss ich wohl den Aufwand treiben, diese Komponenten als "Black Box" ausführlich zu testen.
Und wenn sich diese Komponenten verändern (z.B. SaaS o.ä.)? Dann müsstest du bei jeder Änderung (die du meist nicht mitkriegst) erneut manuell testen.

Selbstverständlich. Ein weiterer Grund, Fremdkomponenten zu vermeiden.

In einem privaten Projekt geht das wohl. Nicht aber auf geschäftlicher Ebene. Aus vielen Gründen.

Oh, das geht. Im Prinzip. Nur manche *wollen* sich das Leben unnötig kompliziert machen, indem sie sich auf Fremdleistungen verlassen.

So long,
 Martin

[Jeena Paradies]

Hallo,

ähm, nein. Nicht, wenn die Anforderung klar definiert ist.

Was sie in 75% der fälle nicht ist, da kein Kunde in die Zukunft sehen kann.

Das bedeutet einen Riesenaufwand, den ich aber für unumgänglich halte. Okay, bei umfangreichen Projekten mag es sinnvoll sein, die Tests auf eine Menge von Stichproben zu beschränken, die man vorher sorgfältig auswählt. Aber das bringt natürlich eine gewisse Unsicherheit ins Spiel.

Wie kommst du darauf dass Unit-Tests "Stichprobentests" sind? Einen Unit-Test musst du dir vorstellen dass du jeden manuellen Test den du sonst auch schreibst innerhalb des Testframeworks schreibst und wenn der code funktioniert _nicht_ löschst sondern beibehälst. Das nächste mal wenn du oder ein Kolege an diesem Code arbeitest und sehen willst ob es denn irgendwelche unerwünschten Nebenwirkungen gibt die nicht offensichtlich sind dann rufst du alle Tests die du vorher geschrieben hast noch mal auf und guckst ob immer noch alle bestanden werden.

Du siehst also, es ist die manuelle Methode, die sich auf stichpunktartige tests verläs und mehr Unsicherheit ins Spiel bringt da man bei einer Änderung nie die Lust hat alle alten Tests noch mal zu schreiben und manuell das ganze Modul durchzutesten.

Das kann passieren, wenn man die Tests auf Stichproben reduzieren muss.

Deshalb benutzt man ein Testframework wie Unit-Test oder noch besser QuickCheck (Was übrigens auch vom in meinem andern Post verlinkten John Hughes an meiner Uni entwickelt wurde). Mit Hilfe dessen kann man zu jedem Zeitpunkt alle alten und neuen Tests automatisch durchlaufen lassen und findet Fehler, die sich im Nachhinein eingeschlichen haben viel einfacher und systematischer.

Jeena

[Christian Kruse]

Moin Jeena,

ähm, nein. Nicht, wenn die Anforderung klar definiert ist.
Was sie in 75% der fälle nicht ist, da kein Kunde in die Zukunft sehen kann.

75% ist aber noch großzügig geschätzt ;-)

Das bedeutet einen Riesenaufwand,  den ich aber für unumgänglich halte. Okay, bei umfangreichen Projekten mag es sinnvoll sein, die Tests auf eine Menge von Stichproben zu beschränken, die man vorher sorgfältig auswählt. Aber das bringt natürlich eine gewisse Unsicherheit ins Spiel.
Wie kommst du darauf dass Unit-Tests "Stichprobentests" sind?

Was Jeena sagen will: der Trick bei Unit Tests ist, dass man so viele Testfälle schreibt, dass am besten jede Zeile des Codes getestet wurde und jede Verzweigung abgelaufen wurde. So kann man zwar keine 100% Sicherheit haben, dass es keinen Bug gibt (es ist bewiesen, dass man durch Tests nicht die Abwesenheit von Bugs feststellen kann), aber die Wahrscheinlichkeit sinkt sehr stark.

Um das sicherzustellen, gibt es auch ein paar „Regeln,“ an die man sich halten muss:

• Unit Tests sollten isoliert ablaufen, also ohne Interaktion mit fremden Modulen
• Unit Tests müssen(!) auch den Fehlerfall testen. Es muss ausdrücklich auch mit Fehleingaben, Netzwerkfehlern, etc, pp getestet werden.
• Unit Tests sollten kontinuierlich beim entwickeln immer wieder ausgeführt werden und als Absicherung genutzt werden, dass Änderungen am Code keine unerwünschten Nebenwirkungen haben.
• Die Entwicklung sollte „test driven“ sein: zuerst schreibt man den Test-Fall, dann den Code, aus mehreren Gründen: es hilft einem sich über die Schnittstellen und die Verhaltensweisen klarzuwerden, es verhindert „whitebox testing“ (testen von nur den Positiv-Fällen) und, bei Änderungen bestehender Module, es ist sichergestellt, dass ohne die Änderung der Testfall fehlschlägt.
• Pro Bug ein Test: dadurch wird sichergestellt, dass der Bug wirklich existiert und es wird sichergestellt, dass er wirklich behoben wurde.

[…] Das nächste mal wenn du oder ein Kolege an diesem Code arbeitest und sehen willst ob es denn irgendwelche unerwünschten Nebenwirkungen gibt die nicht offensichtlich sind dann rufst du alle Tests die du vorher geschrieben hast noch mal auf und guckst ob immer noch alle bestanden werden.

Das nennt man übrigens „Regressionstest.“

LG,
 CK

[Christian Seiler]

Hallo Christian,

Dem Rest Deines Postings kann ich uneingeschraenkt zustimmen, aber zu folgemdem nur kurz:

• Die Entwicklung sollte „test driven“ sein: zuerst schreibt man den Test-Fall, dann den Code, aus mehreren Gründen: es hilft einem sich über die Schnittstellen und die Verhaltensweisen klarzuwerden, es verhindert „whitebox testing“ (testen von nur den Positiv-Fällen) und, bei Änderungen bestehender Module, es ist sichergestellt, dass ohne die Änderung der Testfall fehlschlägt.

"Test driven developement" hat auch seine Nachteile, naemlich dass man sich sehr leicht verrennt, alle moeglichen Tests zu schreiben, bis man dann beim Coden merkt, dass das Interface, was man sich so definiert hat, in dieser Form nicht sinnvoll ist. Das muss man in meinen Augen gegen die Vorteile abwaegen, die Du geschildert hast, ich wuerde den Punkt, den Du machst, daher eher so formulieren: Man sollte sich ueber die Methode "test-driven developement" im Klaren sein und deren Vor- und Nachteile fuer jedes Projekt abwaegen und dann entscheiden was man genau macht.

Das aendert natuerlich nichts daran, was Du sonst gesagt hast, d.h. wie Unittests aufgebaut sein sollten und die Tatsasche, dass man diese bei jedem Projekt einsetzen sollte. (Ausnahmen bestaetigen die Regel.)

Viele Gruesse,
Christian

[Christian Kruse]

Moin Christian,

"Test driven developement" hat auch seine Nachteile, naemlich dass man sich sehr leicht verrennt, alle moeglichen Tests zu schreiben, bis man dann beim Coden merkt, dass das Interface, was man sich so definiert hat, in dieser Form nicht sinnvoll ist.

Natürlich gilt auch hier: nicht übertreiben. Ja.

Man sollte sich ueber die Methode "test-driven developement" im Klaren sein und deren Vor- und Nachteile fuer jedes Projekt abwaegen und dann entscheiden was man genau macht.

Das gilt prinzipiell für jede Vorgehensweise.

LG,
 CK

[molily]

"Test driven developement" hat auch seine Nachteile, naemlich dass man sich sehr leicht verrennt, alle moeglichen Tests zu schreiben, bis man dann beim Coden merkt, dass das Interface, was man sich so definiert hat, in dieser Form nicht sinnvoll ist.

TDD hat natürlich viele Methoden und Angriffspunkte, und mit Tests eine komplette Software zu definieren, die sich am Ende als unzweckmäßig erweist, ist nicht der Sinn von TDD. Der Kreislauf von Test und Implementierung sollte überschaubar sein, alles andere wäre nicht agil.

Integrationstests und Akzeptanztests beispielsweise greifen auf einer Ebene, bei der es nicht um das konkrete Testen von APIs in ihrer gegenwärtigen Ausprägung geht, sondern um das Verhalten größerer Software weitesgehend unabhängig von ihrer internen Organisation.

Mathias

[Tom]

Hello,

[...]

Das Wichtigste dabei ist, dass die Schnittstellen dieser Teilprobleme eindeutig definiert sind.

[...]

Das liegt bestimmt auch daran, dass man im Englischen nicht von "cut" spricht, sondern von "interface". Das bedeutet dann aber "cut and later (re)junction".

Wenn eine Schnittstelle also nicht später zur exakten Verbindungsstelle werden kann, ist sie kein Interface :-P

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tim Tepaße]

deswegen sagte ich ja: Die Konzepte, die dahinterstecken, sind vermutlich vielen bekannt. Aber eben nicht unter diesen Modebegriffen.

Ach Martin. Zwei Möglichkeiten: Die Begriffe, die ich seit einem Jahrzehnt höre, hast Du nie gehört, weil die die Konzepte fremd sind. Oder aber die Konzepte sind Dir unter anderem Namen bekannt und ich erscheine Dir wie jemand, der wild mit exotischen Buzzwörtern um sich wirft.

Das glaube ich aber nun nicht. Ich mein, exotisch sind die von mir verwendeten Programmiersprachen vielleicht im Vergleich mit dem Großen und Ganzen und der Java-Industrie, aber im Bereich der an Informatik interessierten, eventuell gar mit Studienerfahrungen ist es doch nicht ganz so exotisch. Das Lambda-Kalkül existiert seit den 30er Jahren. In den 50ern hat McCarthy darauf Lisp aufgebaut. 1977 hat John Backus den sehr relevanten Artikel „Can Programming By Liberated from the Von Neumann Style?“ im ACM veröffentlicht. Funktionale Konstrukte sind letztendlich ewig dabei, nicht nur in funktionalen Programmiersprachen. Man kann auch in klassischen, imperativen Sprachen damit umgehen, wenn man in C z.B. function pointer rumreicht. Und es taucht ja auch andauernd in moderneren multiparadigmellen Sprachen auf. In Perl seit Ewigkeiten. In Python, ebenso. Ruby, Java, PHP, C# ... Exotisch ist was anderes.

Und Du kennst es vermutlich auch. Nur unter einem anderen Namen. Das ist Ok. Aber musst Du wirklich dann aggressiv Buzzwörtertum unterstellen, nur weil Du vielleicht andere Namen kennst? Kannst Du nicht einfach mal annehmen, dass das Kommunikationsproblem auch bei Dir liegen könnte? Und dass es produktiver sei, sich kurz schlau zu lesen und dann meinetwegen so etwas anzumerken wie „Ah, Currying? Ich hab das meinerzeit unter dem Begriff Schönfinkeln gelernt.“ Aber sich so anzustellen ist doch albern.

[Der Martin]

Hallo,

deswegen sagte ich ja: Die Konzepte, die dahinterstecken, sind vermutlich vielen bekannt. Aber eben nicht unter diesen Modebegriffen.
Ach Martin. Zwei Möglichkeiten: Die Begriffe, die ich seit einem Jahrzehnt höre, hast Du nie gehört, weil die die Konzepte fremd sind.

teilweise bestimmt. Currying habe ich zum Beispiel recherchiert und festgestellt, dass es sich dabei im Grunde um etwas Triviales handelt. Einen konkreten Ausdruck dafür kannte ich bisher nicht. Der Begriff Currying ist mir bisher gelegentlich begegnet, wenn molily über seine Kniffe in Javascript berichtet hat, sonst noch nie; es war mir bisher nicht wichtig genug, um nachzuforschen, was er damit meint.

Oder aber die Konzepte sind Dir unter anderem Namen bekannt und ich erscheine Dir wie jemand, der wild mit exotischen Buzzwörtern um sich wirft.

Genau. Zum Beispiel das mit dem Lambda.

Das Lambda-Kalkül existiert seit den 30er Jahren. In den 50ern hat McCarthy darauf Lisp aufgebaut. 1977 hat John Backus den sehr relevanten Artikel „Can Programming By Liberated from the Von Neumann Style?“ im ACM veröffentlicht.

Das mag ja alles sein - mir war es trotz Informatik-Studium fremd. Vielleicht weil ich als Ingenieur unter Informatik vorwiegend nicht die theoretische, sondern die technische oder angewandte Informatik sehe.

Funktionale Konstrukte sind letztendlich ewig dabei, nicht nur in funktionalen Programmiersprachen. Man kann auch in klassischen, imperativen Sprachen damit umgehen, wenn man in C z.B. function pointer rumreicht.

Ich sagte ja schon: Bei dem Begriff "anonyme Funktion" hätte ich sofort gewusst, was du meinst.

Aber musst Du wirklich dann aggressiv Buzzwörtertum unterstellen, nur weil Du vielleicht andere Namen kennst?

Ja - und zwar wegen der Häufung solcher Begriffe hier im Thread.

Kannst Du nicht einfach mal annehmen, dass das Kommunikationsproblem auch bei Dir liegen könnte? Und dass es produktiver sei, sich kurz schlau zu lesen und dann meinetwegen so etwas anzumerken wie „Ah, Currying? Ich hab das meinerzeit unter dem Begriff Schönfinkeln gelernt.“

Dann wüsste ich zwar, was du meinst - aber du wüsstest noch nicht, dass dein Fachjargon nicht ankommt.

Aber sich so anzustellen ist doch albern.

Es ist der verzweifelte Versuch, andere darauf aufmerksam zu machen, dass sie sich deutlich vom gebräuchlichen Wortschatz der technisch orientierten Fraktion entfernen. Und zwar ohne Notwendigkeit. Ich würde es als unentschuldbares Versäumnis sehen, diesen Hinweis zu unterlassen.

Ciao,
 Martin

[dedlfix]

Hi!

Aber sich so anzustellen ist doch albern.
Es ist der verzweifelte Versuch, andere darauf aufmerksam zu machen, dass sie sich deutlich vom gebräuchlichen Wortschatz der technisch orientierten Fraktion entfernen.

Du wolltest wohl sagen: von deinem. Vesuch mal, dich in Python einzuarbeiten, wenn du ein paar einigermaßen aktuelle Begriffe kennenlernen willst.

Und zwar ohne Notwendigkeit. Ich würde es als unentschuldbares Versäumnis sehen, diesen Hinweis zu unterlassen.

Fachbegriffe müssen verwendet werden dürfen. Bei Nichtverstehen sollte man sich informieren oder nachfragen. Müsste man auf jeden Wissensstand Rücksicht nehmen, könnte man gleich zu kommunizieren aufhören - irgendwer versteht immer Bahnhof.

Lo!

[Tom]

Hello,

Fachbegriffe müssen verwendet werden dürfen.

Wenn Flachbegriffe (sic!) die einzige Möglichkeit für einen Vortragenden sind, seine "Kompetenz" zu beweisen und den Vortrag interessant zu machen, dann kann ich auf den Vortrag auch gerne verzichten.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Jeena Paradies]

Hallo,

Wenn Flachbegriffe (sic!) die einzige Möglichkeit für einen Vortragenden sind, seine "Kompetenz" zu beweisen und den Vortrag interessant zu machen, dann kann ich auf den Vortrag auch gerne verzichten.

Ich glaube Tim wird sich nächstes mal einfach ein anderes Diskussionsforum suchen.

Ein Forum in dem es eher darum geht konkrete Sachverhalte auf professionellem Niveau zu diskutieren, anstatt nur Metadiskussionen mit Leuten, die sich offensichtlich noch nie auch nur Ansatzweise mit dem Diskussionsthema beschäftigt haben, darüber zu führen, ob er sich hier nur mit "Buzzwords" profilieren möchte.

Wie man sieht habe ich es anscheinend auch relativ früh aufgegeben und mich in diese Metadiskussion mit reinziehen lassen.

Jeena

[Tom]

Hello,

Ich glaube Tim wird sich nächstes mal einfach ein anderes Diskussionsforum suchen.

Ein Forum in dem es eher darum geht konkrete Sachverhalte auf professionellem Niveau zu diskutieren, anstatt nur Metadiskussionen mit Leuten, die sich offensichtlich noch nie auch nur Ansatzweise mit dem Diskussionsthema beschäftigt haben, darüber zu führen, ob er sich hier nur mit "Buzzwords" profilieren möchte.

Wie man sieht habe ich es anscheinend auch relativ früh aufgegeben und mich in diese Metadiskussion mit reinziehen lassen.

Ach, nun seid doch nicht beleidigtr, nur weil der Wunsch besteht, dass die Bedeutung dieser "Fachbegriffe" wenigstens ansatzweise auch allgemeinverständlich erläutert wird. Es ist nämlich keinesfalls sichergestellt, dass der Benutzer dieser Begriffe sie selber richtig einordnet.

Ich will Tim hier keinesfalls unterstellen, dass er nicht weiß, was er sagt. Aber es wäre für ganz ganz viele Mitlesende bestimmt sehr hilfreich, wenn ein kurzer Kontext gegeben werden würde. Dann weiß der Leser beim Nachgooglen wenigstgens, dass er sich die richtige Bedeutung herausgesucht hat.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Ich will Tim hier keinesfalls unterstellen, dass er nicht weiß, was er sagt. Aber es wäre für ganz ganz viele Mitlesende bestimmt sehr hilfreich, wenn ein kurzer Kontext gegeben werden würde. Dann weiß der Leser beim Nachgooglen wenigstgens, dass er sich die richtige Bedeutung herausgesucht hat.

... so, wie CK es an einigen Stellen in seinem Posting tut ...
https://forum.selfhtml.org/?t=205712&m=1395298

Ich finde, das ist auch nicht zuviel verlangt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Christian Kruse]

Moin Tom,

Ich will Tim hier keinesfalls unterstellen, dass er nicht weiß, was er sagt. Aber es wäre für ganz ganz viele Mitlesende bestimmt sehr hilfreich, wenn ein kurzer Kontext gegeben werden würde. Dann weiß der Leser beim Nachgooglen wenigstgens, dass er sich die richtige Bedeutung herausgesucht hat.

... so, wie CK es an einigen Stellen in seinem Posting tut ...
https://forum.selfhtml.org/?t=205712&m=1395298

Ich habe eine erklärende Antwort gegeben. Das ist etwas völlig anderes.

Ich finde, das ist auch nicht zuviel verlangt.

Ich finde, es ist nicht zuviel verlangt, dass man Fachbegriffe nachschlägt, wenn man sie nicht versteht.

LG,
 CK

[Kai345]

[latex]Mae  govannen![/latex]

Ach, nun seid doch nicht beleidigtr, nur weil der Wunsch besteht, dass die Bedeutung dieser "Fachbegriffe" wenigstens ansatzweise auch allgemeinverständlich erläutert wird. Es ist nämlich keinesfalls sichergestellt, dass der Benutzer dieser Begriffe sie selber richtig einordnet.

Im konkreten Fall: Pech gehabt, nachfragen hätte geholfen. Den Diskutanten Vorwürfe zu machen, weil sie einen anderen/höherwertigen Wortschatz benutzen, ist hingegen kindisch und albern. Alle genannten Begriffe sind, wie schon mehrfach festgestellt wurde, gängige Begriffe der heutigen Programmiertechnik in verschiedensten Sprachen. Und man muß -hier wie anderswo- auch durchaus höherwertige Diskussionen führen können, ohne jedem "Programmier-Hinterwäldler", der auf dem Stand von vor 20 Jahren stehengeblieben ist, auf seinem Niveau abzuholen. Zum einen ist es eine Hol- und keine Bringschuld jedes Einzelnen, sich diesbezüglich weiterzubilden und zum Anderen kann jemand, der einen bestimmten Sachverhalt nicht versteht *und* indifferente Ergebnisse beim suchen erhält, *konkret* nachfragen. Welcher der Begriffe würde überhaupt !eindeutige Ergebnisse beim Sucher erzeugen?

Diskussionen auf kaka-Niveau zu führen oder langwierige Erklärungen zu jedem Begriff angeben zu müssen, nur damit es auch wirklich der Letzte versteht, ohne seinen Arsch selbst hochzubekommen, ist Unsinn und kontraproduktiv.

Stur lächeln und winken, Männer!
Kai

[Christian Seiler]

Hallo Martin,

Aber sich so anzustellen ist doch albern.

Es ist der verzweifelte Versuch, andere darauf aufmerksam zu machen, dass sie sich deutlich vom gebräuchlichen Wortschatz der technisch orientierten Fraktion entfernen. Und zwar ohne Notwendigkeit. Ich würde es als unentschuldbares Versäumnis sehen, diesen Hinweis zu unterlassen.

Ich sehe den Disconnect eher bei Dir als bei Tim. Nichts für ungut, aber Tim hat einen Wortschatz verwendet, der nicht nur irgendwelche "Modeworte" enthält, sondern tatsächlich das Vokabular ist, das man heutzutage beim Programmieren von modernen Sprachen verwendet.

Wenn man die ganze Zeit nur Assembler, C, Fortran oder Basic programmiert, dann mag man ja vielleicht noch irgendwie um diese Worte herumkommen. Aber in so ziemlich allen anderen Sprachen tauchen diese Begriffe auf. In Python gibt es u.a. "list comprehension", "generator expressions" und "lambda" als Stichworte (alle aus der Ecke der funktionalen Programmiersprachen), selbst für die nächste Version Java 7 wird über anonyme Funktionen nachgedacht unter dem Stichwort "Lambda". Im neuen C++-Standard taucht das Stichwort "lambda expressions" auf - und insbesondere aktuelles C++ versteht man nur, wenn man einen ganzen Rattenschwanz an Begriffen kennt, die (als Begriffe) ihren Ursprung in der Theorie gehabt hat, wie zum Beispiel SFINAE, CRTP oder "rvalue references". map/reduce gibt es in so ziemlich jeder modernen Sprache (PHP kennt die z.B. array_map/array_reduce). Currying ist nunmal ein gewisser Fachbegriff im Lambda-Kalkül - und natürlich ist das letztlich irgendwo syntaktischer Zucker, aber sehr praktischer syntaktischer Zucker - der so fast überall auch als Currying bezeichnet wird.

Seit einigen Jahren ist relativ viel in Bewegung bei so ziemlich allen Programmiersprachen bis auf vielleicht reines C oder Fortran, und fast alle bisher imperativen Sprachen borgen sich immer mehr Konzepte von funktionalen Programmiersprachen - eben unter auch Namen, die sich in diesen eingebürgert haben. Das ist mehr als bloß eine Modeerscheinung, Google hat map/reduce in 2004 populär gemacht, die Bezeichnung "lambda" gibt's schon seit Ewigkeiten (> 10 Jahre) in Python, etc.

Wenn Du aus irgend einem Grund noch nie von diesen spezifischen Begriffen gehört hast: Ok, hey, nicht schlimm, es gibt Suchmaschinen. Aber Tim zu kritisieren, dass er ein Vokabular verwendet, das von der Realität ist, ist fehl am Platze. Gewöhne Dich lieber daran; ob es Dir gefällt oder nicht, die Begriffe, die Tim verwendet hat, werden immer mehr in Gebrauch geraten, auch bei "klassischen" Programmiersprachen.

Zudem - selbst wenn es sowas ähnliches bereits gibt und man z.B. Lambdas bsi zu einem gewissen Grad in C durch Funktionspointer emulieren kann - Begriffe kommen oft mit Paradigmenwechseln daher. In den 90er-Jahren - wie oft wurden da anonyme Funktionen eingesetzt in der Form wie das heute passiert? Selten, meist nur in der Theorie. Schau Dir mal Javascript an, wie es Leute vor 12 Jahren oder so geschrieben haben - da wurden selten anonyme Funktionen verwendet, obwohl die Sprache das ja damals bereits konnte. Inzwischen ist das anders, weil Leute eben diese funktionalen Konzepte entdeckt haben. Und inzwischen wirst Du kaum einen guten Javascript-Programmierer antreffen, der nicht weiß, dass der Begriff "lambda expression" für eine anonyme Funktion steht, obwohl das in Javascript nicht einmal ofiziell so heißt. Fachbegriffe sind wichtig, in ihnen steckt mehr, als bloß die Beschreibung des Konzepts an sich, sondern eben auch die Referenz auf das Paradigma, welches dahintersteckt.

Viele Grüße,
Christian

[Tom]

Hello Christian,

Ich sehe den Disconnect eher bei Dir als bei Tim. Nichts für ungut, aber Tim hat einen Wortschatz verwendet, der nicht nur irgendwelche "Modeworte" enthält, sondern tatsächlich das Vokabular ist, das man heutzutage beim Programmieren von modernen Sprachen verwendet.

[...]

Du magst zwar Recht haben, dass es für bestimmte Dinge neue Begriffe gibt, die sich gelegentlich sogar weit verbreiten, also als bekannt gelten können. Aber wie entstehen diese Begriffe?

Da kommen dann auch gelegentlich solche Dinge, wie

DIN -> Din-Norm          Deutsche Indutrie-Norm-Norm
IT -> ITK                Information Technologie und Kommunikation (ITC wäre konsequent,
                         denn "EDV" hat man abgeschafft, weil es international angeblich
                         nicht verständlich war.)
MAP -> Mappen            Media Access Path -> to map (einen Media-Access-Path anlegen)

SFTP -> Simple File Transfer Protocol / Secure File Transfer Protocol
                         Das ist das ganze Gegenteil

usw. heraus.

Irgendwie "morphen" neue Begriffe auch ziemlich leicht und das dient nicht der Klarstellung eines Schverhaltes, sondern der Verwischung von Fachlichkeit.

Mit Kunstwörtern, deren Bedeutung nachträglich an den Haaren herbeigezogen wird (Currying) ist es noch schlimmer.

Und wenn dann mal jemand ganz aus Deiner Nähe (und ohne Doktotitel) als Ulk einen neuen Begriff nach derselben Masche erfindet (Academic Locking), dann bist Du der erste, der sich aufregt darüber ;-P

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Don P]

Hallo,

Mit Kunstwörtern, deren Bedeutung nachträglich an den Haaren herbeigezogen wird (Currying) ist es noch schlimmer.

Was ist das Problem? Was "Currying" ist, weiß man doch an jedem Pommes-Stand.

Gruß, Don P

[Tom]

Hello,

Mit Kunstwörtern, deren Bedeutung nachträglich an den Haaren herbeigezogen wird (Currying) ist es noch schlimmer.

Was ist das Problem? Was "Currying" ist, weiß man doch an jedem Pommes-Stand.

*ROTFL*

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Stefanie M.]

... dass es produktiver sei, sich kurz schlau zu lesen

Mich interessiert, wie das in Euren Betrieben gehandhabt wird. Da hat man ja nun nicht nur mit Leuten zu tun, die in den letzten 10 Jahren studiert haben. Sind die trotzdem auf diesem Level? Bilden die sich diesbezüglich in der Freizeit weiter und/oder gibt es regelmässige Schulungen?

Meiner eigenen Erfahrung nach (in einem Umfeld, dass überwiegend in C programmiert) ist es eher utopisch, zu erwarten, dass die älteren Kollegen sich dieses Wissen freiwillig und nebenbei aneignen. Und somit unerlässlich, sich auch bei Erklärungen auf dieses Niveau "herab-"lassen zukönnen.

Dabei sehe ich einerseits, dass Sachverhalte teilweise eben nur durch die passenden Termini am besten beschrieben werden können, aber andererseits sollte eben nicht nur Software leicht verständlich sein, sondern auch Erklärungen darüber. Bzw. da ein passender Kompromiss gefunden werden. Die Softwareentwickler, die früher unverständlichen Code erzeugt haben, haben sich auch gerne damit raus geredet, dass eben nur die Cracks das verstehen können...

Gruß
Stefanie

[Tom]

Hello Stefanie,

Die Softwareentwickler, die früher unverständlichen Code erzeugt haben, haben sich auch gerne damit raus geredet, dass eben nur die Cracks das verstehen können...

Das sehe ich auch so.

Und wenn du oder ich den Tim nun mal bitten würden, seinen text mal ausnahmsweise zu übersetzen und zu erläutern, dann könnten wir auch Wetten abschließen, ob er das überhaupt kann ;-P

Wenn er ein gutes Beispiel geben will und uns beweisen will, dass er versteht, wovon er redet, dann wird er es tun. Dann müssen wir beide uns aber auch ducken und ihm alle Achtung zollen :-)

Ich lass mich mal überraschen. Ich wette mal, er kann es und tut es ausnahmsweise auch mal.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tim Tepaße]

Ich lass mich mal überraschen. Ich wette mal, er kann es und tut es ausnahmsweise auch mal.

Eher ausnahmsweise nicht. Ich mein ... ich könnte jedes Konzept mit einem erläuternden Satz unterlegen – Currying (Das Vorbelegen von Funktionsparametern allgemein gehaltener Funktionen um dadurch neue, spezialisierte Funktionen zu erzeugen) – aber das wird dann sehr abstrakt. Die andere, eingehendere Richtung wäre ein Tutorial, mit vergleichenden Quelltextbeispielen.

Aber sieh's mal aus meiner Richtung: Ich hatte da eine Frage. Hab ich immer noch. Vielleicht etwas lang ausgedrückt, aber das liegt auch daran, dass das Thema wenig auftaucht, meiner Erfahrung nach, und ich dadurch erklären muss, was ich eigentlich suche. Und ja, natürlich setze ich einen Wissenstand voraus. Ich tue das, weil ich weiß, dass hier im Forum Leute mitlesen, die den haben und Meinungen dazu haben. Und für all die mir unbekannten Leser erwähne ich diesen Wissenstand in der Form von ... Fachwörtern ... damit der Leser das mit seinem eigenen Wissenstand vergleichen kann. Sozusagen etwas Selektion durch Terminologie. Das ist nix ungewöhnliches. Auf tieferer Ebene passiert das hier ständig im Forum, jeder Thread hat einen verschiedenen Wissensstand, auf dem diskutiert wird und viele Neubesucher sind schon von einfachen Programmierkonzepten ... nun, nicht überfordert, aber sie können (noch) nicht mitreden. So ist das Leben. Ich hab auch von vielem keine Ahnung.

Offenbar scheint es hier inakzeptabel zu sein, auf einem bestimmten Wissenstand sich unterhalten zu können. Stattdessen ein beknackter Metathread, nur weil manche Fachwörter als Buzzwörter empfinden. Und das eigentliche Ziel meines Threads, Kriterien zu finden, um anhand von denen Klarheit und Intention von Quellcode beurteilen zu können ist dabei übern Jordan gegangen.

Offenbar ist dies hier wirklich das falsche Forum dafür. Schade. Ich hatte bislang eine bessere Meinung.

[dedlfix]

Hi!

Offenbar scheint es hier inakzeptabel zu sein, auf einem bestimmten Wissenstand sich unterhalten zu können. [...]
Offenbar ist dies hier wirklich das falsche Forum dafür. Schade. Ich hatte bislang eine bessere Meinung.

Du verallgemeinerst. Das passiert leider sehr oft, wenn sich jemand ungerecht behandelt fühlt, dass er dann auf das Forum im Ganzen schießt und nicht nur auf den/die konkreten Verursacher. Auswirkungen hat das auch auf die Motivation derjenigen, die sich redlich bemühen.

Lo!

[Der Martin]

Hallo,

Aber sieh's mal aus meiner Richtung: Ich hatte da eine Frage. Hab ich immer noch.

ja, glaube ich dir.

Sozusagen etwas Selektion durch Terminologie. Das ist nix ungewöhnliches.

Völlig richtig. Nur ist das hier ein Forum, in dem doch der Schwerpunkt eher auf Technik, Praxis und Anwendung liegt.

Offenbar ist dies hier wirklich das falsche Forum dafür.

Für so theoretische, praxisferne, eher ins Philosophische zielende Themen: Ja, das denke ich auch.

So long,
 Martin

[molily]

Offenbar ist dies hier wirklich das falsche Forum dafür.

Für so theoretische, praxisferne, eher ins Philosophische zielende Themen: Ja, das denke ich auch.

Wie bitte? Es gibt doch nichts praxisnäheres als die Frage nach lesbarem und gleichzeitig effizientem Code.

Also meine berufliche Praxis dreht sich täglich 8 Stunden um diese Frage. Wir verwenden viel Ressourcen, um in Erfahrung zu bringen, wie wir intuitiv verständlicheren Code schreiben können.

Mathias

[molily]

Hallo,

Die meisten, mit denen ich zusammenarbeite, haben tatsächlich in den letzten zehn Jahren studiert. Außerdem sind sie breit aufgestellt, was Wissen über Programmiersprachen und -paradigmen angeht. Einerseits ist das persönliches Interesse und Freizeitvergnügen, andererseits wird versucht, das Wissen zu teilen und den Wissenstand anzugleichen. Das ist schlicht nötig, wenn der Stack an Sprachen und Tools alle paar Jahre verändert wird.

In der Webprogrammierung ist viel Bewegung, sodass die meisten in ihrer Laufbahn viele verschiedene Programmiersprachen kennengelernt haben, darunter C++, Java, PHP, Python, Ruby, JavaScript, ActionScript. Diese enorme Bandbreite bringt einen mit sehr verschiedenen Programmierkonzepten in Kontakt.

Eine gewisse Flexibilität ist tatsächlich ein Muss. Natürlich gibt es auch spezialisierte Firmen, die seit Jahrzehnten nur Java, nur C oder nur PHP mit denselben Bibliotheken und Tools schreiben. Aber auch dabei ist es nötig, dass neue Lösungsmöglichkeiten für aufkommenden Probleme evaluiert werden.

Mathias

[molily]

... und schon wieder diese Buzzwords, unter denen man sich als traditioneller Softwareentwickler und Programmierer nichts vorstellen kann
Die Konzepte, die dahinterstecken, sind vermutlich vielen bekannt. Aber eben nicht unter diesen Modebegriffen.

Ein Buch über funktionale Programmierung: ca. 30 Euro.
Einer Informatik-Vorlesung als Gasthörer folgen: ca. 30 Euro.
Ein Wikipedia-Artikel über funktionale Programmierung: Kostenlos.
Merken, dass man im Unrecht ist: Unbezahlbar.

SCNR ;-)

Mathias

[Der Martin]

Hi,

Ein Buch über funktionale Programmierung: ca. 30 Euro.
Einer Informatik-Vorlesung als Gasthörer folgen: ca. 30 Euro.

normalerweise kostenlos.

Ein Wikipedia-Artikel über funktionale Programmierung: Kostenlos.
Merken, dass man im Unrecht ist: Unbezahlbar.

Merken, dass man den Kern der Kritik nicht verstanden hat: Utopisch.

Es geht nicht darum, recht zu haben oder nicht. Es geht darum, anderen klarzumachen, dass sie ebensowenig wie ich der Nabel der Welt sind und ihr Standpunkt auch nur einer von vielen ist.

Ciao,
 Martin

[dedlfix]

Hi!

Merken, dass man den Kern der Kritik nicht verstanden hat: Utopisch.

Der Kern der Kritik war aber nicht richtig. Das sind keine Buzzwörter sondern etabliertes Vokabular bei Leuten, die sich mit aktueller Programmiertechnik befassen.

Es geht nicht darum, recht zu haben oder nicht. Es geht darum, anderen klarzumachen, dass sie ebensowenig wie ich der Nabel der Welt sind und ihr Standpunkt auch nur einer von vielen ist.

Ja, aber mit deinem nicht aktuellen Wisensstand auf diesem Gebiet warst du vielleicht nicht wirklich das beabsichtigte Publikum. Genausowenig wie es Lieschen Müller ist, wenn du auf eine konkrete Frage eines Probleminhabers versuchst auf seinem Niveau zu antworten.

Wie hätte Tim es denn formulieren sollen? So dass ein Programmieranfänger auch über Codequalität und -ästhetik mitphilosophieren kann? Er kann sicher aus seiner Sicht für recht einfache Programme sagen, ob er sie versteht, aber ihm fehlt eine gehörige Portion Wissen und Erfahrung, um einigermaßen umfassend einschätzen zu können, was gut und was verbesserungsfähig ist.

Lo!

[Tom]

Hello,

Der Kern der Kritik war aber nicht richtig. Das sind keine Buzzwörter sondern etabliertes Vokabular bei Leuten, die sich mit aktueller Programmiertechnik befassen.

Die sind aber oft gar nicht notwendig. Das ist genauso, wie in der Betriebswirtchaft oder noch schlimmer, beim Marketing. Da werden diese Begriffe nur verwendet, weil man sich damit von Anderen abheben will. Und oft _verstehen_ die Leute selber nicht, was die da erzählen. Der beste Beweis dafür ist, dass sie nur noch dumm aus der Wäsche gucken, wenn man ihnen denselben Sachverhalt in sauberer deutscher Sprache erläutert. Dann kommen sie intellektuell nicht mehr mit und als Reaktion darauf erklären sie Dich dann für doof.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[molily]

Nach unten tritt man sehr gerne im Forum; jeder Anfänger wird bis zum Erbrechen genervt, wenn er Fachbegriffe nicht oder falsch verwenden oder auch nur Rechtschreibfehler begeht. Antwortende verwenden frei heraus Fachbegriffe, und wenn ein Anfänger diese nicht versteht, wird nur ein schnoddriger »Let me fucking google that for you«-Verweis gepostet. Wenn Anfänger diese Arroganz bemängeln, werden sie umgehend zerfleischt: Es werde eben Eigeninitiative gefordert.

Wenn jemand hingegen eine Diskussion startet, die begrifflich den Horizont einiger Stammposter übersteigt, so sind die Anwesenden nicht gewillt, sich läppische fünf Minuten auf Wikipedia zu informieren. Nein, vielmehr wird man gleich bezichtet, man würde absichtlich unverständlich schreiben, ja, man könne gar nicht verständlich schreiben und wisse gar nicht, wovon man rede. Ferner heißt es, man würde lediglich »Buzzwords« und »Modebegriffe« verwenden. Es wird behauptet, die Begriffe seien nicht gebräuchlich und unnötig. Und das Problem an sich wird als »theoretisch« und »philosophisch« abgetan, die diskutierten Konzepte und Sprachen werden als »exotisch« betitelt.

Selbst wenn all diese Vorwürfe in der Sache widerlegt werden, so hält das die »Kritiker« nicht davon ab, auf ihrem Standpunkt zu beharren: Während es sich nach unten leicht tritt, so will man alles jenseits seines Tellerrandes nicht wahr haben und denunziert es als bloße Überheblichkeit.

Der absurde Vergleich, dass Begriffe nur verwendet werden, um sich von Anderen abheben zu wollen: er ist falsch und richtig zugleich.

Mathias

[Christian Seiler]

Hallo Mathias,

Danke, dass Du das so auf den Punkt bringst. Das Verhalten, was hier im Thread an den Tag gelegt wurde, ist mitunter auch einer der Gründe, warum ich a) keine große Lust mehr habe, im SELFHTML-Forum zu posten und es nur noch *sehr* sporadisch mache und b) auch keine Lust mehr habe, noch irgendwie großartig an der Weiterentwicklung der Software zu arbeiten oder z.B. die kaputte Zitatesammlung zu fixen.

Ich kann mich noch erinnern, dass in den guten alten Zeiten[tm] es hier im Forum problemlös möglich war, eine Diskussion auf technisch Hohem Niveau mit anderen Stammpostern zu führen - das war auch einer der ausschlaggebenden Gründe, warum mir das SELFHTML-Forum so gefallen hat, nämlich dass es nicht nur um Anfängerfragen ging (wobei die auch erhellend sind, weil man hier und da doch wieder etwas lernt), sondern dass eben auch die Stammposter auf höherem Niveau diskutiert haben und man auch als Anfänger/Fortgeschrittener ordentlich was gelernt hat nur durch das Lesen dieser Diskussionen. Und wenn einer mal einen Begriff nicht verstanden hat, dann wurde *nachgefragt*, und die Erklärung kam hinterher - aber so Aussagen wie eure sind von Regulars nie vorgekommen. Es war ein Raum, wo Leute ihre Kreativität eingesetzt haben, um die Technik voranzubringen. Von diesem Denken ist im heutigen SELFHTML-Forum nicht mehr viel zu erkennen. Schade. Sehr schade.

Viele Grüße,
Christian

[Christian Kruse]

Moin Christian,

Danke, dass Du das so auf den Punkt bringst. Das Verhalten, was hier im Thread an den Tag gelegt wurde, ist mitunter auch einer der Gründe, warum ich a) keine große Lust mehr habe, im SELFHTML-Forum zu posten und es nur noch *sehr* sporadisch mache und b) auch keine Lust mehr habe, noch irgendwie großartig an der Weiterentwicklung der Software zu arbeiten oder z.B. die kaputte Zitatesammlung zu fixen.

Geht mir ähnlich.

Früher[tm] war das hier ein aufgeschlossener Ort, wo neue Techniken, neue Bewegungen, neue Projekte diskutiert und behandelt werden konnten. Heute habe ich das Gefühl, dass alles neue von vornherein zum scheitern verurteilt ist.

Jetzt werden sicher wieder andere kommen und sagen „machs besser.“ Nein, danke, ich mag mich nicht mehr aufreiben.

LG,
 CK

[Tom]

Hello lieber Christian,

Geht mir ähnlich.

Früher[tm] war das hier ein aufgeschlossener Ort, wo neue Techniken, neue Bewegungen, neue Projekte diskutiert und behandelt werden konnten. Heute habe ich das Gefühl, dass alles neue von vornherein zum scheitern verurteilt ist.

Das liegt doch aber vermutlich daran, dass auch Du dich enorm weiterentwickelt hast, der Einsteigerpunkt zum Forum aber mit sehr viel Kraftaufwand Vieler möglichst konstant gehalten wurde.

DU gehörst inzwischen zu denjenigen, die mit/während/durch das Forum gewachsen sind. Bitte sei doch so fair, das Gleiche auch nachfolgenden Generationen zu ermöglichen.

Dabei muss doch auch niemand verrenken, sondern nur ein paar erklärende Worte einflechten bei komplizierteren Sachverhalten. Und warum gerade Du dich dann quasi dafür entschuldigst, dass Du es getan hast in deinem "Erklärungsposting", das verstehe ich nun überhaupt nicht. Das war doch gut!

Nur weil ICH geschrieben habe, dass mir das gefallen hat, kann doch kein Grund sein, sich von den Äußerungen distanzieren zu müssen, oder?

Ich mag zwar doof sein, aber ich bin auch doof genug, um mich immer noch an meine eigene Vergangenheit zu erinnern und manchmal extrem darüber zu grinsen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hallo,

Ich kann mich noch erinnern, dass in den guten alten Zeiten[tm] es hier im Forum problemlös möglich war, eine Diskussion auf technisch Hohem Niveau mit anderen Stammpostern zu führen

dieser Satz bringt es schön auf den Punkt: das *technisch* hohe Niveau schätze ich durchaus auch, und das ist nach wie vor gegeben.
Was Tim hier (unfreiwillig) losgetreten hat, ist aber keine technische Diskussion, sondern eine, die sehr auf Theorie und Formalismus ausgerichtet ist - schon durch die Konzepte und Bezeichnungen, die er gewählt hat. Damit spricht er vermutlich nur ein sehr kleines Publikum an.

Es war ein Raum, wo Leute ihre Kreativität eingesetzt haben, um die Technik voranzubringen.

Das ist eigentlich etwas, was ich gerade nicht anstrebe - eher einen Raum, wo Leute sich austauschen, um die Technik bestmöglich zu *nutzen*. Vorankommen tut sie ohnehin viel schneller, als es den meisten lieb ist.

Ciao,
 Martin

[Christian Seiler]

Hi,

dieser Satz bringt es schön auf den Punkt: das *technisch* hohe Niveau schätze ich durchaus auch, und das ist nach wie vor gegeben.
Was Tim hier (unfreiwillig) losgetreten hat, ist aber keine technische Diskussion, sondern eine, die sehr auf Theorie und Formalismus ausgerichtet ist - schon durch die Konzepte und Bezeichnungen, die er gewählt hat. Damit spricht er vermutlich nur ein sehr kleines Publikum an.

Und *DAS* ist genau das, was molily angekreidet hat - dass Du einfach nicht einsehen willst, dass Du falsch lagst. Nur weil die Begriffe nicht in dem Bereich der Technik, in dem Du tätig bist, relevant sind, heißt es nicht, dass das eine rein theoretische Diskussion ist. Wie molily an anderer Stelle schon sagte:

| Wie bitte? Es gibt doch nichts praxisnäheres als die Frage nach lesbarem und gleichzeitig effizientem Code.

Übrigens: Es muss Dich ja auch nicht alles interessieren, was hier besprochen wird, aber dann mache bitte andere Leute blöd nicht von der Seite an, wenn sie andere Interessen als Du haben. (Und ja, das ist genau das, was Du getan hast.) Bsp: Ich mag Perl nicht. Trotzdem hijacke ich nicht jeden Perl-Thread und erkläre den Leuten, wie abgefahren und unpraktisch doch die Konzepte in Perl sind.

Aber ich sehe schon: Hier ist Hopfen und Malz verloren. Genau das ist der Grund, warum ich nur noch sporadisch ins Forum schaue.

Viele Grüße,
Christian

[Der Martin]

Hallo,

Was Tim hier (unfreiwillig) losgetreten hat, ist aber keine technische Diskussion, sondern eine, die sehr auf Theorie und Formalismus ausgerichtet ist - schon durch die Konzepte und Bezeichnungen, die er gewählt hat. Damit spricht er vermutlich nur ein sehr kleines Publikum an.
Und *DAS* ist genau das, was molily angekreidet hat - dass Du einfach nicht einsehen willst, dass Du falsch lagst.

und das sehe ich auch immer noch nicht.

| Wie bitte? Es gibt doch nichts praxisnäheres als die Frage nach lesbarem und gleichzeitig effizientem Code.

Ja, da stimme ich Mathias zu. Das war auch die ursprüngliche Fragestellung. Aber sie war in einer Weise gestellt, die -ob absichtlich oder nicht- nur eine kleine Minderheit von Theoretikern anspricht.

Übrigens: Es muss Dich ja auch nicht alles interessieren, was hier besprochen wird, aber dann mache bitte andere Leute blöd nicht von der Seite an, wenn sie andere Interessen als Du haben. (Und ja, das ist genau das, was Du getan hast.) Bsp: Ich mag Perl nicht. Trotzdem hijacke ich nicht jeden Perl-Thread und erkläre den Leuten, wie abgefahren und unpraktisch doch die Konzepte in Perl sind.

Das mach ich genauso - aus den Themen Perl, Java, teilweise auch Datenbank, halte ich mich auch wegen meiner Unkenntnis heraus. Programmiertechnik ist aber etwas Allgemeines, das man bitte auch so allgemein behandeln und beschreiben sollte. Andernfalls möge man es bitte deutlich auf bestimmte Programmiersprachen oder -konzepte einschränken, so dass sich die Experten für C, Assembler, Fortran, oder was auch immer nicht fälschlicherweise mit angesprochen fühlen.

Ciao,
 Martin

[Tom]

Hello Christian,

Danke, dass Du das so auf den Punkt bringst. Das Verhalten, was hier im Thread an den Tag gelegt wurde, ist mitunter auch einer der Gründe, warum ich a) keine große Lust mehr habe, im SELFHTML-Forum zu posten [...]

Das ist schade.

Du hast dabei vielleicht übersehen und /oder vergessen, dass Du mit und während des Forums gewachsen bist. Du bist dabei sogar so wichtig geworden für das Forum, dass wir auf Dich hier nicht verzichten können.

[Das ist in keiner Weise ironsich gemeint, sondern einfach ehrlich!]

Es ist sehr sehr sehr bedauerlich, dass Du das anders siehst!

Bitte missachte nicht, dass Forumseinsteiger und auch langjährige Hobbymitglieder durchaus an den "Profithemen" interessiert sind. Die Profis müssen ihnen dafür nur eie Chance geben. Findest Du das fair, wenn man als interessierter im-Moment-nicht-IT-Vollberufler jedes Wort nachschalgen muss?

Das kann man auch haben, indem man RFCs liest. Dazu benötige ICH kein Self-HTML-Forum.

Und wenn ich hier "ICH" schreibe, dann deshalb, weil ich damit alle die Kollegen meine, die schon vor 20 Jahren "Currying" gekonnt haben, aber nicht so arrogant waren, diesem simplen Trick einen Namen zu geben und dann auch noch dutzende von Morphismen in WIKIPEDIA unterzubringen, die erklären müssen, warum aus "varianter Argumentanzahl" der Begriff "Schönfinkeln" und daraus "Currying" wird.

[Du wirst jetzt sicher überprüfen, ob diese Argumentationskette überhaupt stimmt. Viel Spaß dabei :-P]

Das war übrigens nur ein Beispiel...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Du hast dabei vielleicht übersehen und /oder vergessen, dass Du mit und während des Forums gewachsen bist. Du bist dabei sogar so wichtig geworden für das Forum, dass wir auf Dich hier nicht verzichten können.

[Das ist in keiner Weise ironsich gemeint, sondern einfach ehrlich!]

ich könnte heulen...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Jeena Paradies]

Hallo,

warum aus "varianter Argumentanzahl" der Begriff "Schönfinkeln" und daraus "Currying" wird.

"Variable Argumentenanzahl" ist aber nicht Currying. Aus der Wikipedia:

"Es sei eine Funktion gegeben, die n Argumente erfordert. Wird diese auf ein Argument angewendet, so konsumiert sie nur genau dieses und liefert als Funktionswert eine weitere Funktion, die noch n-1 Argumente verlangt. Die zurückgegebene Funktion wird anschließend auf alle weiteren Argumente angewendet."

Das ist halt ein mathematisches Konzept mit dem man sich ein bisschen beschäftigen muss um es zu verstehen.

Jeena

[dedlfix]

Hi!

Danke, dass Du das so auf den Punkt bringst. Das Verhalten, was hier im Thread an den Tag gelegt wurde, ist mitunter auch einer der Gründe, warum ich a) keine große Lust mehr habe, [...]
Ich kann mich noch erinnern, dass in den guten alten Zeiten[tm] es hier im Forum problemlös möglich war, eine Diskussion auf technisch Hohem Niveau mit anderen Stammpostern zu führen - das war auch einer der ausschlaggebenden Gründe, warum mir das SELFHTML-Forum so gefallen hat,[...]
Es war ein Raum, wo Leute ihre Kreativität eingesetzt haben, um die Technik voranzubringen. Von diesem Denken ist im heutigen SELFHTML-Forum nicht mehr viel zu erkennen. Schade. Sehr schade.

Wenn ich mir diese Entwicklung, ob gefühlt oder wirklich, so ansehe, so stelle ich gewisse Parallelen zur Besiedlung anderer Räume fest, zum Beispiel bestimmter Stadtteile. Und ich denke, diese Entwicklung wird es so wie bei den Stadtteilen immer wieder geben. Bei letzteren ist es soweit ich weiß auch schon Gegenstand wissenschaftlicher Untersuchungen gewesen. Und da dort genauso wie hier, Menschen beteiligt sind, wird es immer wieder so werden. Zuerst stellen einge wenige etwas Großartiges auf die Beine. Die Ausstrahlung zieht weitere Leute an, zu denen Fachleute, Fachidioten, interessierte Anfänger und Schaulustige gehören. Einige werden sesshaft, andere ziehen weiter. Die Vielfalt menschlicher Charaktereigenschaften findet man dabei mehr oder weniger in allen Wissensständen wieder. Und so kommt es vor, dass einige immer wieder nach Neuem streben - die schaffen es auch, sich schneller was neues zu suchen, wenn das was in der Gegend einmal modern war zum Alten verkommen ist - und andere eine gewisse Zeit der Entwicklung haben und danach sesshaft werden. Außerdem gibt es immer wieder welche, die einfach nicht miteinander können und solche, die überhaupt nicht gruppenkompatibel sind - nebst aller möglichen Schattierungen.

So ist er eben, der (von mir beobachtete) Lauf der Dinge und man entkommt ihm nicht. Es sei denn, man bildet mit einigen wenigen Gleichgesinnten ein elitäres Grüppchen, das strikt darauf achtet, keine Nichtpassenden aufzunehmen. Als Alternativen sehe ich, ständig zu versuchen, Konsens herzustellen, viel Kraft zu investieren, um eine angenehme Umgebung aufzubauen und sie zu halten, oder besser, sie mit interessanten Anregungen weiterzuentwickeln oder einfach abzuhauen, um sich einzuigeln oder um anderswo auf den selben Kreislauf zu stoßen.

Lo!

[Tom]

Hello Mathias,

[...]

es tut mir nun wirklich aufrichtig leid, wenn ich hier füer eine solche Metadisktussion verantwortlich wein sollte, obwohl ich das Thema selber doch sehr interessant finde.

Nur sehe ich dieses Forum immer noch als eines der besten an, in dem sich Fachleute breit erklären, komplizierte Sachverhaltemauch für potentielle zukünftige Fachleute verständlich zu erklären, in dem aber auch Fachleuter untereinander - quasi zum Zugucken - über interessante Theme diskutieren. Das sollten sie dann aber mMn so tun, dass der nachwusch noch mitkommt und nicht jedes Wort nachschlagen muss.

Um das also nochmal auf den Punkt zu bringen:

• ich finde Tims Anliegen sehr interessant
• ich möchte gerne erreichen, dass er die Begriffe _ein__wenig_ mit deutscher Sprache hinterlegt,
    auch wenn es (vermeinlich anerkannte) Fachbegriffe sind

Ich bin mir nämlich sicher, dass ich über viele dieser Dinge bereits vor 19 Jahren heiß diskutiert habe und es auch noch andeere (ältere) Denkansätze dafür gibt. Die haben dann aber bestimmt auch fot andere Begriffe genutzt oder es einfach auch Deutsch, Östgerreichisch oder Schweitzerisch ausgedrückt :-))

Ich stehe immer noch auf dem Standpunkt, dass Tim keinen Nachteil davon hätte, sein OP nochmals  etwas mit Erläuterungen zu versehen, denn es ist ein mMn wirklich wichtiges Posting, dass nicht nur in einem schmalen Sprachkorridor von "Eingeweihten" geführt werden sollte!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tim Tepaße]

Ich stehe immer noch auf dem Standpunkt, dass Tim keinen Nachteil davon hätte, sein OP nochmals  etwas mit Erläuterungen zu versehen …

… was viel leichter fiele, würde jemand konkret sagen, mit welchen Begriffen er welche Verständnisprobleme hat. Martin ist bislang nie dem Begriff Lambda begegnet. Ok. Und Du?

[Der Martin]

Hallo,

Ich stehe immer noch auf dem Standpunkt, dass Tim keinen Nachteil davon hätte, sein OP nochmals  etwas mit Erläuterungen zu versehen …
… was viel leichter fiele, würde jemand konkret sagen, mit welchen Begriffen er welche Verständnisprobleme hat. Martin ist bislang nie dem Begriff Lambda begegnet.

dem Begriff schon - als griechischer Buchstabe, als Symbol für die Wellenlänge und als Symbol für den Sauerstoffgehalt im Abgas. Vielleicht noch als Symbol für die ekliptikale Länge in der Astronomie. Etwas anderes will mir im Moment nicht einfallen.

Ok. Und Du?

Auch die Begriffe Observer, map, reduce, filter oder lazy list sagen mir nicht wirklich was, wenn ich auch -mit Ausnahme von lazy list- mit etwas Überlegung zumindest vermuten kann, was das sein mag.

Closures

Würde ich nicht kennen, wenn ich nicht ab und zu Postings von molily über Javascript gelesen hätte.

Aber auch abseits dieser Fachausdrücke hast du einen sehr elitären Schreibstil. Insofern passt das zusammen und erweckt den Eindruck, als wolltest du dich bewusst von der Masse abheben.

So long,
 Martin

[molily]

Auch die Begriffe Observer, map, reduce, filter oder lazy list sagen mir nicht wirklich was, wenn ich auch -mit Ausnahme von lazy list- mit etwas Überlegung zumindest vermuten kann, was das sein mag.

Observer:
http://de.wikipedia.org/wiki/Observer_(Entwurfsmuster)
http://en.wikipedia.org/wiki/Publish/subscribe

Map/reduce:
http://en.wikipedia.org/wiki/Map_(higher-order_function)
http://en.wikipedia.org/wiki/Fold_(higher-order_function)
http://de.wikipedia.org/wiki/MapReduce
In JavaScript:
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/map
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/Reduce

Filter:
http://en.wikipedia.org/wiki/Filter_(higher-order_function)
In JavaScript:
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/filter

Underscore-Bibliothek mit vielen funktionalen Aspekten:
http://documentcloud.github.com/underscore/

Listenmethoden in Prototype.js:
http://api.prototypejs.org/language/Enumerable/

Bibliothek Functional.js:
http://osteele.com/sources/javascript/functional/

»Eloquent JavaScript« über funktionale Programmierung:
http://eloquentjavascript.net/chapter6.html

Listenmethoden in Ruby:
http://www.ruby-doc.org/core/classes/Enumerable.html

Lazy List (hier in Ruby, gute kompakte Beschreibung):
http://flori.github.com/lazylist/

Closures

http://aktuell.de.selfhtml.org/artikel/javascript/organisation/#closures
http://molily.de/js/organisation-verfuegbarkeit.html#closures
https://developer.mozilla.org/en/JavaScript/Guide/Closures
http://blog.morrisjohns.com/javascript_closures_for_dummies.html

Noch Fragen, Kienzle?

Mathias

[dedlfix]

Hi!

Noch Fragen, Kienzle?

Wie wäre es, wenn wir zur Abwechslung mal versuchen würden, miteinander vorwärts zu kommen, und nicht einerseits vom hohen Ross herab mit Links durch die Gegend werfen und andererseits die noch offenen Fragen konkret benennen würden, die beim sicherlich bereits erfolgtem Versuch, die Bildungslücken selbständig zu schließen, entstanden sind?

Lo!

[molily]

Dieses Forum ist keine technische Dokumentation, keine Referenz und kein Tutorial. Es ist auch kein geeignetes Medium, um allgemeine Erklärungen zu publizieren. Man muss die Grundlagen anderswo lesen, um in Diskussionen hier weiterzukommen. Das gilt für alle Beteiligten und das ist gut so. Dafür sind u.a. Links wunderbar geeignet und haben erst einmal nichts mit »hohem Roß« zu tun. Konkrete Probleme, Detailfragen und Missverständnisse müssen individuell geklärt werden. Dafür gibt es dieses Forum.

Links zu guten Erklärungen sind in diesem Forum Luxus, im doppelten Sinne: Es ist Usus, Anfängern Begriffe ohne Links vorzuwerfen (Bsp.). Wie gesagt ist es absurd, wenn plötzlich Stammposter fordern, was Anfängern systematisch verwehrt wird. Gleichzeitig sind Links auf gute technische Dokumentationen äußerst nützlich und können eine Frage in kurzer Zeit erhellen. Daher habe ich mir die Mühe gemacht, solche zusammenzutragen. Dafür mache ich mir die Mühe, eine Erklärung z.B. von Closures aufzuschreiben. Damit ich den Link dorthin, wie du es nennst, »durch die Gegend werfen« kann, auf dass jemand hingehe und sie lese.

Mathias

[Don P]

Hallo,

Dafür mache ich mir die Mühe, eine Erklärung z.B. von Closures aufzuschreiben. Damit ich den Link dorthin, wie du es nennst, »durch die Gegend werfen« kann, auf dass jemand hingehe und sie lese.

Wenn mich nicht alles täuscht, ist das überhaupt der Sinn von HTML, Hypertext eben. Ich bin jedenfalls dankbar für die Links :).

Gruß, Don P

[Tom]

Hello,

Ich stehe immer noch auf dem Standpunkt, dass Tim keinen Nachteil davon hätte, sein OP nochmals  etwas mit Erläuterungen zu versehen …

… was viel leichter fiele, würde jemand konkret sagen, mit welchen Begriffen er welche Verständnisprobleme hat. Martin ist bislang nie dem Begriff Lambda begegnet. Ok. Und Du?

Doch, Lambda war mir aus Java geläufig, nur bei "anonyme Labdas" habe ich gestutzt, weil ich das als doppelt gemoppelt empfinde...

Den Begriff des "Currying" finde ich dagegen ausgesprochen dämlich. Es gibt bestimmt noch einen anderen Ausdruck dafür, der es besser trifft. Wenn ich einem begegne, werde ich ihn bei Wikipedia unterbringen, wo er dann aber wahrscheinlich mangels meines Doktortitels nicht lange stehen bleiben wird ;-O

Dein Posting und die aufgekommene Diskukussion hat allerdings dazu geführt, dass ich mir nochmals verschiedene Programmiermuster usw. ins Gedächtnis zurückgerufen habe. Könnte ja schließlich sein, dass ich morgen auf der Straße jemanden treffe, der sich mit mir darüber unterhalten will.

[ Einen Kernkraft-Fachmann aus dem Wirtschaftsministerium der Bunten Republik traf ich neulich auch zufällig und hatte ine heiße Diskussion mit ihm über die Regelungsfähigkeit von Kernkraftwerken. Aber ich war gut vorbereitet. Nichts ist also unmöglich ;-) ]

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tim Tepaße]

Den Begriff des "Currying" finde ich dagegen ausgesprochen dämlich. Es gibt bestimmt noch einen anderen Ausdruck dafür, der es besser trifft.

Schönkfinkeln ist meiner Meinung nach auch der schöner funkelndere Ausdruck dafür. Ok. Partielle Funktionsanwendung. Was ganz streng genommen etwas anderes ist als Currying, aber eben das ist, was man gemeinhin so im Programmierbereich nutzt. Aber die Welt sagt nun mal Currying, nicht nur die Inder. Argumentfixierung könnte ich auch eben noch erfinden, aber ... die Welt redet nun mal vom ... ;)

[ ...  Aber ich war gut vorbereitet. Nichts ist also unmöglich ;-) ]

Sobald Obama einen Fachmann braucht, um mit dessen Wissen obskurer Charaktere aus Tolkiens Silmarillion die Welt vor den bösen Aliens zu retten – ich bin perfekt vorbereitet. ;)

[dedlfix]

Hi!

Sobald Obama einen Fachmann braucht, um mit dessen Wissen obskurer Charaktere aus Tolkiens Silmarillion die Welt vor den bösen Aliens zu retten – ich bin perfekt vorbereitet. ;)

Welche silmarillschen Charaktere sind denn obskur?

Lo!

[Christian Seiler]

Hallo Martin,

Mir scheint, du kennst relativ viele, aus meiner Sicht exotische Programmiersprachen (exotisch hier: geringe Verbreitung) wie Haskell, Python oder Erlang, die viele Programmierer nur dem Namen nach kennen.

Naja, Python würde ich keine geringe Verbreitung nachsagen wollen.

Viele Grüße,
Christian

[Don P]

Hallo,

Programmieren ist zu einem Großteil die Kunst, Probleme in Einzelschritte zu überlegen.
Ja, sicher - aber es ist auch die Kunst, diese Zerlegung nicht zu weit zu treiben. [...]

Aus verschiedenen Gründen, einer ist zum Beispiel Testbarkeit von Einzelschritten.
Das ist ein Argument; dafür kann man ja während der Entwicklungsphase diese Schritte isolieren. Im fertigen Code sollte die Granularität aber nicht mehr unbedingt so fein wie möglich sein, sondern nur so fein, wie man das Problem "üblicherweise" auch im Kopf gliedern würde.

Martin, da kann ich nur zustimmen.

Bei meinem eigenen Code, den sonst niemand lesen muss, gehe ich so vor: Entwickelt wird in kleinen Einzelschritten, aber nachdem ein abgeschlossenener Codeabschnitt (Objektmethode bzw. Funktion) ausführlich getestet und für gut befunden wurde, wird er so kompakt wie möglich formuliert und als Enzeiler minifiziert. Wenn ich später auf solche Zeilen stoße, weiß ich sofort: Halt, bloß nicht daran rumpfuschen, ist getestet und ok. Sollte sich doch irgendwann die Notwendigkeit ergeben, solchen Code zu überarbeiten, dann wird er eben zwecks Übersicht zuerst wieder mit einem Beautifier aufgehübscht, auch kein Problem.

Bei Teamarbeit wage ich das aber nicht. Vermutlich würden mir die Kollegen den Vogel zeigen ;) Im Team versuche ich ein gesundes Mittelmaß zwischen Kompaktheit/Ausdruckstärke und hinreichender Formulierung in leicht vertändlichen Einzelschritten.

Gruß, Don P

[Tom]

Hello,

also es ist spannend, das hier zu lesen. Ich muss gestehen, ich muss für mich erstmal übersetzen, was Tim meint.

• Anonyme Lambdas ...

Was soll das sein? Den Begriff habe ich noch nie gehört.

Ist das nicht "doppelt verpackt"?
http://www.straub.as/csharp/anonyme-delegates+lambdas.html

Ideal wäre eine Macro, selbst wenn es nur einmal genutzt wird, aber Macros sind abseits von Lisp-Dialekten leider Mangelware.

In C sind sie durchaus üblich.

Sind die noch aus (Makro-)Assembler übrig geblieben, oder hat man da das Rad neu erfunden?

Auch bin ich zunehmend skeptischer gegenüber mehreren Ausstiegspunkten aus einer Funktion.

Ich nicht, im Gegenteil: Sobald das Ergebnis einer Funktion feststeht, beende ich sie. Ich finde das übersichtlicher, als "pro forma" das schon feststehende Ergebnis bis zum Ende der Funktion durchzureichen.

Das geht aber nur sicher in Sprachen, die selber für das Aufräumen sorgen und keine lost handles oder vagabundierenden Speicher zurücklassen, wenn man den Gültigkeitsbereich der Funktion verlässt.

Wenn du nicht so sehr mit extrem spezifischen Buzzwords um dich werfen würdest, könnte man vielleicht sogar verstehen, was du sagen möchtest.

Oh, jetzt traue ich mich auch mal zuzugeben, dass ich das Wörterbuch dazu benötige.

Meiner Ansicht nach erreicht man das am besten, indem man versucht, den natürlichen Gedankengang so gut wie möglich mit den Strukturen der jeweiligen Programmiersprache abzubilden. Das ist allerdings keine Einbahnstraße: Intensive Beschäftigung mit einer bestimmten Programmiermethode führt dazu, dass man selbst anfängt, so zu denken, und das als "normal und intuitiv" empfindet.

Für mich ist es immer wichtiger, ob auch ANDERE, die die Sprache "nur lesen" können, auch verstehen können, was derjenige erreichen wollte. Denn ob das Wollen mit dem Tun übreinstimmt, ist ja auch nicht immer selbstverständlich und steht selten dabei :-P

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Moin,

also es ist spannend, das hier zu lesen. Ich muss gestehen, ich muss für mich erstmal übersetzen, was Tim meint.

das trifft es ganz gut. :-)

[Macros]
In C sind sie durchaus üblich.
Sind die noch aus (Makro-)Assembler übrig geblieben, oder hat man da das Rad neu erfunden?

Keine Ahnung, wie die Evolution da abgelaufen ist, aber in C gelten sie als fester Bestandteil der Sprache, auch wenn der Macro-Präprozessor mitunter ein eigenständiges Programm ist, das auch als eigenständiger Schritt bei der Übersetzung abläuft (meistens ist das aber schon im Compiler integriert).

Auch bin ich zunehmend skeptischer gegenüber mehreren Ausstiegspunkten aus einer Funktion.
Ich nicht, im Gegenteil: Sobald das Ergebnis einer Funktion feststeht, beende ich sie. Ich finde das übersichtlicher, als "pro forma" das schon feststehende Ergebnis bis zum Ende der Funktion durchzureichen.
Das geht aber nur sicher in Sprachen, die selber für das Aufräumen sorgen und keine lost handles oder vagabundierenden Speicher zurücklassen, wenn man den Gültigkeitsbereich der Funktion verlässt.

Nicht nur, auch wenn es da natürlich am einfachsten ist.
Aber ich hatte es als selbstverständlich vorausgesetzt, dass der Programmierer entweder ganz raffiniert ist und diese "Aufräumarbeiten" (Speicher freigeben, hergestellte Verbindungen trennen etc.) in der aufrufenden Ebene macht (das ist manchmal vorteilhaft, aber im Sinne der Kapselung und Modularität nicht unbedingt der Brüller), oder zumindest sich um diese Dinge explizit kümmert - und sei es, dass er im konkreten Fall feststellt, dass nichts weiter notwendig ist.

Meiner Ansicht nach erreicht man das am besten, indem man versucht, den natürlichen Gedankengang so gut wie möglich mit den Strukturen der jeweiligen Programmiersprache abzubilden. Das ist allerdings keine Einbahnstraße: Intensive Beschäftigung mit einer bestimmten Programmiermethode führt dazu, dass man selbst anfängt, so zu denken, und das als "normal und intuitiv" empfindet.
Für mich ist es immer wichtiger, ob auch ANDERE, die die Sprache "nur lesen" können, auch verstehen können, was derjenige erreichen wollte.

Hmm. Was meinst du mit "nur lesen"? Möchtest du Programmcode wirklich so schreiben, dass ein Laie ihn nachvollziehen kann? Das halte ich für übertrieben. Ich setze schon veraus, dass derjenige, der den Code später liest, auch vom Fach ist.

Denn ob das Wollen mit dem Tun übreinstimmt, ist ja auch nicht immer selbstverständlich und steht selten dabei :-P

Wie wahr ...

Schönes Wochenende,
 Martin

[Don P]

Hallo,

Auch bin ich zunehmend skeptischer gegenüber mehreren Ausstiegspunkten aus einer Funktion.

Ich nicht, im Gegenteil: Sobald das Ergebnis einer Funktion feststeht, beende ich sie. Ich finde das übersichtlicher [...]

Geht mir auch so. Zur Zeit beschäftige ich oft mit dem Umschreiben von altem Code früherer Kollegen, denen anscheinend nicht nur das DRY-Prinzip unbekannt ist bzw. war, sondern die auch *immer* eine Funktion erst am Ende des Funktionscodes verlassen. Das sieht dann so aus:

if (!bli) {  
  if(bla){  
    if(blubb){  
      result = true;  
    }  
    else {  
       result = false;  
    }  
  }  
}  
return result;  

Das führt zu unnötig vielen Einrückungsebenen und ist schon allein dadurch schwerer zu verstehen. Da ich den Code in der Regel von oben nach unten lese, meine ich dann immer, die Funktion seit noch fertig, und scrolle mich weiter durch, nur um dann festzustellen, dass ja gar nichts mehr kommt und die Verabeitung schon lange zu Ende ist. Statt

if (!bli) {  
  /* viele Zeilen Code */  
}  

Schreibt man doch besser

  
if (bli) { return; }  
/* viele Zeilen Code */

und spart sich die vielen Einrückungen sowie die unnötige Scrollerei. Schon in der ersten Zeile wird klar, was im Fall von bli passiert, nämlich nichts.
Damit nicht den Überblick über mehrere Ausstiegspunkte verliert, bieten sich auffällige Kommentare an. In mancher Entwicklungsumgebnug werden sie ohnehin automatisch deutlich herausgehoben.

Gruß, Don P

[Jeena Paradies]

Hallo,

if (bli) { return; }
/* viele Zeilen Code */

  
Ich mag da ja noch viel lieber die ruby variabte:  
  
~~~ruby
  
return if bli  
/* viele Zeilen Code */

Jeena

[Christian Seiler]

Hallo Jeena,

Ich mag da ja noch viel lieber die ruby variabte:

return if bli
/* viele Zeilen Code */

  
Ich mag diese Variante (die es auch in Perl gibt) grundsaetzlich nicht, weil sie den Fokus auf das 'return' legt und nicht auf die Bedingung. Diese Fokusverschiebung obfuskiert in meinen Augen den Programmfluss. Das Problem ist aber auch das Keyword 'if' an dieser Stelle.  
  
Das Perl-Konstrukt 'return unless <unwahrscheinlicher ausdruck>' finde ich dagegen noch in Ordnung, (ich bevorzuge aber auch da die explizite Variante) weil das unless semantisch zusammen mit der Tatsache, dass der Ausdruck unwahrscheinlich ist, ziemlich gut ausdrueckt, wie der Kontrollfluss im Programm ablaeuft (in den meisten Faellen wird hier 'return' gemacht, aber in ganz wenigen Faellen geht es auch mal weiter).  
  
Viele Gruesse,  
Christian  

-- 
[Mein "Weblog"](http://del.icio.us/chris_se/servertipps) [[RSS](http://del.icio.us/rss/chris_se/servertipps)]  
[Using XSLT to create JSON output](http://www.christian-seiler.de/projekte/xslt-json/) (Saxon-B 9.0 for Java)  
  
[How to tell the difference between a science fan and a scientist.](http://www.smbc-comics.com/index.php?db=comics&id=1777#comic)

[Christian Kruse]

Moin Christian,

return if bli
/* viele Zeilen Code */

>   
> Ich mag diese Variante (die es auch in Perl gibt) grundsaetzlich nicht,  
  
Ich mag sie sehr gern. Solcher Syntax sugar vergrößert die Ausdrucksstärke von Code.  
  

> […] weil sie den Fokus auf das 'return' legt und nicht auf die Bedingung.  
  
Genau. Das ist ja das tolle daran. Man ist näher an dem, was man wirklich sagen will.  
  

> Diese Fokusverschiebung obfuskiert in meinen Augen den Programmfluss.  
  
Man muss alles mit Maßen einsetzen. Und maßvoll und gezielt eingesetzt, verstärkt sie m.E.n. die Lesbarkeit des Codes massiv.  
  

> Das Perl-Konstrukt 'return unless <unwahrscheinlicher ausdruck>' […]  
  
Der Vollständigkeit halber: das gibt es durchaus auch in anderen Sprachen, z. B. Ruby.  
  
LG,  
 CK  

-- 
<http://ck.kennt-wayne.de/>  

[molily]

return if bli

Ich mag diese Variante (die es auch in Perl gibt) grundsaetzlich nicht, weil sie den Fokus auf das 'return' legt und nicht auf die Bedingung. …
Das Perl-Konstrukt 'return unless <unwahrscheinlicher ausdruck>' finde ich dagegen noch in Ordnung

Diese Schreibweise nutzt man i.d.R. in einer negativen Bedeutung, also bspw.

return if arr.nil? or arr.empty?

Solange der Ausdruck diese Länge nicht überschreitet, sehe ich nicht, dass er irreführt. Wenn man dieses Pattern zweimal gesehen hat, ist es einem geläufig.

Allgemein ist der Zweck dieser Postfix-Schreibweise die mögliche Ähnlichkeit zu natürlichen Sprachen. Das heißt, diese Ausdrücke sind ähnlich aufgebaut wie ein Satz, der die Funktionalität des Codes beschreibt:
»Breche die Funktion ab, wenn der Array nicht angegeben wurde oder keine Elemente enthält.«

Die Postfix-Schreibweise bereitet Probleme wenn die Zeile nicht sofort überblickbar ist:
mach_was.ganz_langes(und, kompliziertes(mit(siebenundzwanzig).verschachtelten(expressions))) if foo() and bar() and not quux?
wäre insofern schlecht.

Mathias

[molily]

Hallo,

ich halte das Beispiel für problematisch, um daran über sprechenden Code zu diskutieren, schließlich sind schon zwei Funktionen vorgegeben:

collectAllEffectivelyContainedNodes(getActiveRange(), filter)

Ist schon eine imperative API, die ich so nicht entwerfen würde. Das halte ich für wenig »fluent«.

Man kann das durchaus funktional lösen, dann würde ich aber vorne anfangen. Für die schwächste Stelle der funktionalen Lösung halte ich ebenfalls .filter(function(value, i, arr) { return arr.slice(0, i).indexOf(value) == -1; }). Das ist sehr kompliziert zu verstehen und nicht sehr sprechend. Davon abgesehen ist es nicht sehr performant, wie du sagst. Beides hängt natürlich miteinander zu tun: Mehr algorithmischer Aufwand ist meist nicht intuitiv verständlich.

Deine Lösung ist da sicher verständlicher. Ich würde das Pferd aber anders herum aufzäumen: Was ist die Syntax, in der ich das Problem gerne ausdrücken würde, um den Kern des Problemes freizulegen? Mal ein Beispiel für eine Phantasiesyntax:

range = something.getActiveRange
nodes = range.containedNodes.editables.textNodes
return unless nodes.length
nodes.fontnames.unique.length > 2

editables und textNodes wären Filter, fontnames ein Mapper.

Das könnte man jetzt noch realistischer notieren (CoffeeScript-Rubyiesk):

range = something.getActiveRange()
nodes = range.containedNodes.select(:editable, :textNode)
return unless nodes.length
nodes.map(:fontname).unique().length > 2

Hier würde allerdings ein Short-Circuit verunmöglicht. Damit hätte ich erst einmal kein Problem. Erst wenn sich die map- und die unique-Operation als notorisch unperformant für die tatsächlichen Nodes bzw. Fontnamen erwiesen, würde ich optimieren. Etwa so:

nodes.unique?(:fontname, 2)

Wenn man die tatsächlich hässliche imperative Implementierung durch eine Abstraktion verstecken kann, wird der Code, der das Problem auf hoher Ebene formuliert, natürlich umso lesbarer. :)

Konkreter zu deinem Vorschlag: Allgemein tendiere ich auch dazu, mehr Variablen und Funktionen zu deklarieren, als nötig – selbst wenn sie eine Variable nur bis zur nächsten Zeile lebt und eine Funktion nur einmal aufgerufen wird. Ich verzichte darauf, eine möglichst ununterbrochene Kette von Funktionsaufrufen zu notieren. Das kann schließlich der JavaScript-Komprimierer machen, der merkt, dass Variable/Funktion nur einmal verwendet werden und daher weglassbar bzw. integrierbar sind.

Die Information, was eine kurze Funktion macht, muss man aber nicht unbedingt im Namen unterbringen und die Funktion dazu zentral notieren. Das macht deine Lösung eher umfangreicher und m.E. schwerer verständlich.

fontNames = nodes.map(function (node) { return node.fontName });

So etwas halte ich für intuitiv verständlich, wenngleich man natürlich eine bessere Syntax wie z.B. in Ruby haben könnte:

fontNames = nodes.map &:fontName

Allein CoffeeScript verbessert das Signal-Rauschen-Verhältnis schon stark, indem es die meisten Klammern unnötig macht:

fontNames = nodes.map (node) -> node.fontName

Wenn ich allerdings mit einer schlimmen API arbeiten muss, ergibt es vielleicht Sinn, das Implementierungsdetail durch eine ausgelagerte Funktion in der Formulierung des Problems zu verstecken. Ich würde die Information »node2fontname« erst einmal in einem schlichten Kommentar unterbringen:

fontNames = nodes.map(function (node) {
  // Get the node's font name
  return ugly.api.getEffectiveValue(node, "fontname", null, ugly.api.FOO | ugly.api.BAR, -2);
});

Sodass der Leser weiß, was passiert, und die nicht sprechende Implementierung ignoriert.

editableTextNodes = nodes.filter(function (node) { return isEditable(node) && node.nodeType == Node.TEXT_NODE });

Das halte ich auch für verständlich in einer Zeile mit anonymer Funktion. Wenn ich das sprechender gestalten wollte, dann indem ich an 'nodes' bzw. 'node' entsprechende Funktionalität definierte.

Mathias

[Tim Tepaße]

ich halte das Beispiel für problematisch, um daran über sprechenden Code zu diskutieren, schließlich sind schon zwei Funktionen vorgegeben:

Ja. Ich hab das auch nur nebenbei aufgeschnappt und hab das eher genommen, weil es das aktuellste war, wo ich über so etwas nachgedacht habe. Und die API ist doof, aber ich wollte da ja nur ein Gegenbeispiel bringen.

nodes.fontnames.unique.length > 2
nodes.map(:fontname).unique().length > 2
nodes.unique?(:fontname, 2)

Ich vermeide unique, wenn ich keinen Überblick über die ungefähre Datenmenge habe, weil zu viele Vergleiche und zuviel benötigter Zwischenspeicher. Premature, vielleicht, aber irgendwo in mir eingegraben. Und hier weiß ich ja nicht, was der Kerl eigentlich bezwecken will. ;)

(Es gibt irgendwo ein unique, dass so überladen ist? Doch nicht in Ruby, oder? Ich war ja da kurz davor, mir ein Array.prototype.differentValues zu monkeypatchen.)

fontNames = nodes.map(function (node) { return node.fontName });
...
fontNames = nodes.map(function (node) {
  // Get the node's font name
  return ugly.api.getEffectiveValue(node, "fontname", null, ugly.api.FOO | ugly.api.BAR, -2);
});
...
editableTextNodes = nodes.filter(function (node) { return isEditable(node) && node.nodeType == Node.TEXT_NODE });

Das ist eine anderer Programmierstil, den ich mag – die deskriptive Information steckt in der Bezeichnung der Collection, Filtern passiert subsequent. Was auch eine Art deklarativer Stil ist. Ich hab diese Präsentation da als etwas in Erinnerung, was mich mal stark beeinflusst hat. Python, ab Seite 100 oder so wird's aber sehr rocket sciencig.

[reborn]

Hi Tim,

Schönheit liegt bekanntlich im Auge des Betrachters. Wenn es dir um die Bewertung von Code geht, dann wäre Zyklomatische Komplexität vielleicht ein Stichwort. Code sollte nicht nur verständlich sondern auch gut wartbar sein. Bei deinem Codeschnipsel würde ich den ersten Ansatz bevorzugen, weil er allgemeiner das Problem und die Lösung beschreibt (input.where.map.filter.length).

LG

[Buchtipp]

Clean Code von Robert Martin
Refactoring von Fowler
Clean Code Developer

[jobo]

Hallo,

Und das ist letztendlich der Grund für dieses Posting: Ich interessiere mich in letzter Zeit für eine Ästhetik/Lesbarkeit/Intuitive Klarheit von Code. Nicht auf einer Ebene von Microsyntax, auch nicht auf der Ebene von Objekthierarchien, sondern irgendwo dazwischen, bei den Algorithmen. Wie man es schafft, seine abstrakte Vorstellung möglichst gut, tlw. deklarativ zu verdeutlichen. Variablenbenennung. Wann man etwas in Makros oder Funktionen auslagern sollte, nicht wegen DRY, sondern wegen Klarheit. (Siehe z.B. Douglas Crockfords Implementierung eines Top-Down-Parsers und wie er Funktionen wie symbol(), infix(), etc. benutzt. Nicht unbedingt nötig, aber es sorgt für sehr viel mehr Klarheit.) Ich suche also nach schönen Code, Diskussion darüber und den Kriterien dafür.

Also bei Crockford scheints Du aber an der richtigen Adresse zu sein http://forum.de.selfhtml.org/archiv/2011/5/t204924/#m1388501. Die Readability steht bei ihm ganz oben an. Das auch ein Hintergedanke bei seinem JSLint-Experiment. ("I will agree that trivial, contrived examples are free of this sort of confusion. My concern here is with large programs. The biggest criticism of JavaScript by the Java community is that the language lacks the discipline that is required to allow programs to grow large, reliably. Some claim that programming in the large is impossible in JavaScript. I don't believe that, but I do agree with the discipline part, which is why I am doing this experiment.") http://tech.groups.yahoo.com/group/jslint_com/message/2391?var=0

Gruß

jobo

[jobo]

Hallo,

http://www.google.de/search?q=crockford+readability hast du bestimmt schon probiert ...???

Gruß

jobo