Warum können wir das Design von Software nicht effektiver erfassen? [geschlossen]

14

Als Ingenieure "entwerfen" wir alle Artefakte (Gebäude, Programme, Schaltkreise, Moleküle ...). Das ist eine Aktivität (design-the-verb), die zu einem Ergebnis führt (design-the-noun).

Ich denke, wir sind uns alle einig, dass design-the-noun eine andere Einheit als das Artefakt selbst ist.

Eine Schlüsselaktivität im Softwaregeschäft (in der Tat in jedem Geschäft, in dem das resultierende Produktartefakt verbessert werden muss) ist das Verstehen des "Designs (das-Nomen)". Dennoch scheinen wir als Community bei der Aufzeichnung so gut wie völlig versagt zu haben, was sich daran zeigt, wie viel Aufwand die Leute betreiben, um Fakten über ihre Codebasis wiederzuentdecken. Bitten Sie jemanden, Ihnen das Design seines Codes zu zeigen und zu sehen, was Sie erhalten.

Ich stelle mir ein Design für Software vor mit:

  • Eine explizite Spezifikation, was die Software tun soll und wie gut sie es tut
  • Eine explizite Version des Codes (dieser Teil ist einfach, jeder hat ihn)
  • Eine Erklärung, wie jeder Teil des Codes dazu dient, die Spezifikation zu erreichen (z. B. eine Beziehung zwischen Spezifikationsfragmenten und Codefragmenten).
  • Eine Begründung , warum der Code so ist, wie er ist (z. B. warum eine bestimmte Wahl statt einer anderen)

Was NICHT ein Design ist, ist eine bestimmte Perspektive auf den Code. Zum Beispiel sind UML-Diagramme keine Entwürfe. Es handelt sich vielmehr um Eigenschaften, die Sie aus dem Code ableiten können, oder möglicherweise um Eigenschaften, die Sie aus dem Code ableiten möchten. In der Regel können Sie den Code jedoch nicht aus UML ableiten.

Warum gibt es nach mehr als 50 Jahren Erfahrung mit der Erstellung von Software keine regelmäßigen Möglichkeiten, dies auszudrücken? (Zögern Sie nicht, mir mit expliziten Beispielen zu widersprechen!)

Selbst wenn wir das tun, scheint der Großteil der Community so darauf ausgerichtet zu sein, "Code" zu erhalten, dass Design-the-Nomen sowieso verloren geht. (IMHO, bis Design zum Zweck der Konstruktion wird und das Artefakt aus dem Design extrahiert wird, werden wir das nicht umgehen.)

Was haben Sie als Mittel zur Aufnahme von Designs gesehen (in dem Sinne, wie ich es beschrieben habe)? Explizite Verweise auf Papiere wären gut. Warum waren Ihrer Meinung nach bestimmte und allgemeine Mittel nicht erfolgreich? Wie können wir das ändern?

[Ich habe meine eigenen Ideen , die den oben genannten Standpunkt mit Aufzählungszeichen verdeutlichen, aber ich bin an den Antworten anderer interessiert ... und es ist schwierig, mein Schema umzusetzen. [[Und vielleicht ist das das eigentliche Problem: -]]

EDIT 2011/1/3: Einer der Antwort-Threads weist darauf hin, dass "Dokumentation" (vermutlich in Textform, insbesondere nicht formal) angemessen sein könnte. Ich sollte wohl klarstellen, dass ich das nicht glaube. CASE-Tools tauchten ab den 80er Jahren auf, aber die frühen Tools haben meist nur Pixel für die Diagramme von allem erfasst, was Sie gezeichnet haben. Die Tools waren zwar wohl kommerziell erfolgreich, aber nicht sehr hilfreich. Eine wichtige Erkenntnis war, dass wenn die zusätzlichen "Design" -Artefakte nicht formal interpretierbar sind, Sie keine ernsthafte Werkzeughilfe erhalten können. Ich glaube, die gleiche Erkenntnis gilt für jede langfristig nützliche Form der Design-Erfassung: Wenn sie keine formale Struktur aufweist, ist sie nicht wirklich nützlich. Textdokumente bestehen diesen Test so gut wie nicht.

Ira Baxter
quelle
1
Einig über UML - bestenfalls ein Kommunikationsinstrument, das zur Beschreibung des Entwurfs beiträgt, aber an sich nicht das Design ist. Im schlimmsten Fall handelt es sich bei UML jedoch um grafischen Quellcode.
Steve314
quantifizieren "wie gut es macht"
Steven A. Lowe
Beim Erstellen von Systemen habe ich viele "nicht funktionierende" Anforderungen erfüllt: In dieser Sprache codiert , verwendet diese Datenbank, verarbeitet 1E10-Datensätze mit einer durchschnittlichen Antwortzeit von 100 ms. (Ohne nicht funktionierende Anforderungen ist eine Endlosschleife ein adäquates Programm für jede Funktionsspezifikation.) Mein ganzer Punkt bei der Erfassung von "Design" ist, eine andere nicht funktionierende Anforderung zu behandeln: "wartbar".
Ira Baxter
Ihre Diskussion sieht interessant aus, aber ich bin mir nicht sicher, worum es genau geht. Glauben Sie, Sie könnten versuchen, ein konkretes Beispiel zu nennen oder etwas zu klären, woran Sie genau interessiert sind? Ich denke an so etwas wie das FFT-Beispiel, in dem Sie ein vollständiges Bild der 4 Aufzählungspunkte in Ihrer Frage geben können, so wie Sie sie sehen, und vielleicht welche Art von Dingen Sie mit den einmal erfassten Ergebnissen tun möchten.
n1ckp
Ich habe keine Ahnung, warum diese Ausgabe so ist, aber es ist das Thema von Fred Brooks '' The Design of Design ' . (Entschuldigung, wenn Sie bereits vertraut sind.) Er bespricht Beispiele aus der Programmierung und Architektur. Er merkt insbesondere an, dass das Erfassen von Begründungen (sowohl für das Design als auch für abgelehnte alternative Designs) wirklich nützlich ist und von aktuellen Tools nicht gut bedient wird.
Paul D. Waite

Antworten:

8

Ich denke, es gibt mehrere Gründe, warum wir das immer noch nicht können.

  1. Menschen waren lange Zeit, obwohl Software wie Häuser war, und verwendeten Prozesse und Ideen aus dem Bau. "Software Architect" war ein Titel, den alle Programmierer wollten. In den letzten zehn Jahren ist der Software-Architekt fast ausgestorben. Die Idee von Wasserfallprozessen, bei denen zuerst ein Architekt sagt, wie die Software funktionieren und aussehen soll, und dann die Leute dazu bringt, Diagramme darüber zu erstellen, wie sie erstellt werden sollen, und zuletzt Code Monkey diese netten Workflows / UML-Diagramme nach Vorgabe implementieren lässt, ist diese Idee jetzt weithin verspottet. Tatsächlich hat die gesamte Branche 40 Jahre lang den falschen Weg eingeschlagen.

  2. Die Werkzeuge, die wir verwenden, ändern und verbessern sich ständig. Das Programmieren ist ein logisches Rätsel, und wir entwickeln bessere Ideen und Techniken, um dieses Rätsel zu abstrahieren und verständlich zu machen. Die Art und Weise, wie wir dies modellieren, muss sich mit der gleichen Geschwindigkeit entwickeln, bleibt jedoch zurück. Die verbesserten Techniken, um das Rätsel der Programmierung zu lösen, bedeuten auch, dass wir die Komplexität erhöhen können. Und so machen wir es. Programmierung liegt immer an den Rändern der Komplexität, mit der wir als Programmierer umgehen können.

  3. Wege zur Beschreibung des Programms zu finden, ist eine Art Abstraktion. Wenn wir einen guten Weg finden, die Software zu abstrahieren, können wir diese Abstraktion auch direkt in die Entwicklungswerkzeuge einfügen und daher der Programmierung eine weitere Abstraktion / Vereinfachung hinzufügen. Das ist schon oft passiert. Beispiele für solche Abstraktionen sind Funktionen, Klassen und Bibliotheken.

  4. Deshalb; Wenn Sie eine haben erfolgreiches und genaues Modell der Software, wird dieses Modell sein äquivalent zu der Software. Das macht die ganze Anstrengung irgendwie sinnlos, was wiederum Punkt 1 oben bestätigt: Die Modellierung der Software ist weitaus weniger nützlich als bisher angenommen. Es ist stattdessen besser, Daten über die Software aus dem Code zu extrahieren. Das Erstellen eines UML-Modells anhand des tatsächlichen Erscheinungsbilds des Codes ist weitaus aufschlussreicher als das Erstellen eines UML-Modells und der Versuch, dieses theoretische Modell zu implementieren.

Lennart Regebro
quelle
2
Stimmen Sie Ihrem letzten Punkt nicht zu. Ja, es wird eher der Software entsprechen, aber es ist immer noch einfacher, ein Modell neu zu zeichnen, als die eigentliche Software umzugestalten, wenn (nicht wenn) Sie herausgefunden haben, dass etwas doch keine so gute Idee war. Ich würde die Wichtigkeit des Designschritts nicht unterschätzen.
Joris Meys
1
@Joris Meys: Das Problem ist, dass Sie nicht wissen, was und was keine gute Idee ist, bis Sie es implementiert haben. (Außer in trivialen Fällen, aber dann werden Sie ein UML-Diagramm sowieso nicht viel gebrauchen können). Sie sollten auch nicht überschätzen, wie schwierig es ist, Code umzugestalten. Ich empfehle Kent Becks Bücher über XP und Test Driven Design zu lesen.
Lennart Regebro
@Lennart: Danke für den Tipp
Joris Meys
2
@Lennart: Der Unterschied zwischen dir und Job besteht darin, dass du scheinbar damit einverstanden bist, dass eine auf irgendeine Weise ausgedrückte Spezifikation notwendig sein könnte, obwohl ich nicht weiß, wie deine derzeit programmierbaren Abstraktionen das tun. Aber stell dir vor, ich brauche ein Signalverarbeitungsprogramm, das die Hauptfrequenzen extrahiert. Beachten Sie, dass ich nicht vorgeschlagen habe, wie. Sie könnten entscheiden , verwenden eine schnelle Fourier - Transformation, und ich werde sicherlich Fußspuren im ganzen Code finden , dass Geräte Bits FFT. Aber wo ist die Tatsache, dass Sie sich entschieden haben, eine explizit aufgezeichnete FFT zu verwenden? Ich glaube, Sie brauchen es, wenn Ihre Leser nicht allwissend sind.
Ira Baxter
1
@Ira Baxter: Wie wäre es mit "Wir haben uns für die Implementierung der Signalverarbeitung mit FFT entschieden"? Der Quellcode enthält Kommentare. Und ich kann es auch in eine README-Datei schreiben. Der explizite Ausdruck der Spezifikation ist der Code. Textzeilen wie "Wir haben uns entschieden, es mit FFT zu implementieren" sind weder explizit noch im Sinne Ihres ursprünglichen Beitrags zu gestalten. Es ist die Dokumentation der Implementierung. Sie scheinen in einem argumentativen Modus gelandet zu sein, aber ich verstehe nicht, gegen was Sie argumentieren wollen.
Lennart Regebro
5

Möglicherweise möchten Sie die Dokumentation zur Software-Rückverfolgbarkeit lesen. In keiner bestimmten Reihenfolge:

  • CUBRANIC, D., MURPHY, GC, SINGER, J. UND BOOTH KELLOGG, S. Hipikat: Ein Projektgedächtnis für die Softwareentwicklung. Transactions on Software Engineering 31, 6 (2005), 446–65.
  • TANG, A., BABAR, MA, GORTON, I. UND HAN, J. Ein Überblick über die Verwendung und Dokumentation von Architekturentwurfsgründen. In Proc der 5. Working IEEE / IFIP Konferenz über Softwarearchitektur (2005).
  • RAMESH, B., POWERS, T., STUBBS, C. UND EDWARDS, M. Rückverfolgbarkeit der Anforderungen implementieren: Eine Fallstudie. In Proc des Internationalen Symposiums für Requirements Engineering (York, 1995).
  • HORNER, J. UND ATWOOD, ICH Design-Begründung: die Begründung und die Barrieren. In Proc der 4. Nordischen Konferenz über Mensch-Computer-Interaktion: Rollenwechsel (Oslo, Norwegen, 2006).
  • CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B. UND CLARK, S. Best Practices für die automatisierte Rückverfolgbarkeit. Computer 40, 6 (Juni 2007), 27–35.
  • ASUNCION, H., FRANÇOIS, F. UND TAYLOR, RN Ein umfassendes Tool für die Rückverfolgbarkeit von Industriesoftware. In Proc der 6. gemeinsamen Sitzung des European Software Eng Conf und des ACM SIGSOFT Int'l Symp über die Grundlagen des Software Engineerings (ESEC / FSE) (Dubrovnik, 2007).

Beachten Sie, dass dies nur die Spitze des Eisbergs ist, und ich bin sicher, dass ich einige Schlüsselpapiere ausgelassen habe.

In einer separaten Anmerkung war meine eigene Arbeit an Arcum ein Mittel für Programmierer, um der IDE die Verwendung von übergreifenden Design-Idiomen auszudrücken. Einmal ausgedrückt, könnten Programmierer ihren Quellcode transformieren, um alternative Implementierungen zu verwenden:

Arcum hat übrigens auch etwas mit Ihrer DMS-Arbeit zu tun.

Macneil
quelle
1
+1 dafür. RT ist nicht alles, aber es ist einer von mehreren positiven Schritten , um das Problem tatsächlich zu lösen , anstatt die gleichen alten Entschuldigungen dafür zu finden.
Aaronaught
2

UML ist nach meiner bescheidenen Ansicht ein Programm, was die Pläne für ein Gebäude sind. Pläne alleine sind natürlich kein Entwurf, Sie benötigen dafür Materialspezifikationen (benutzte Code-Tools), eine allgemeine Ansicht des Gebäudes (eine schematische Darstellung der gesamten Software, einschließlich der GUI-Entwürfe), wie das Gebäude in der Umgebung bepflanzt ist (ein klares Schema, wie die Software mit anderen interagiert / innerhalb des Betriebssystems gepflanzt wird), wie sie dem Klima und dem Boden entspricht (Interaktion mit Hardware), ... Viele Bücher über Design versuchen, es zu definieren, aber so In vielen Bereichen der Wissenschaft hat jeder Wissenschaftler eine eigene Definition.

Jetzt stimme ich Ihrer Beobachtung auch nicht zu, dass Sie den Code nicht von UML ableiten können. Sie können, wenn Sie die genannten zusätzlichen Informationen haben. Aber der wahre Code ist nicht mehr das Design, sondern das Artefakt. Sie können die echten Steine ​​und den Beton auch nicht aus einem Plan extrahieren, aber Sie benötigen den Plan, um die echten Steine ​​und den Beton in die richtige Form und an die richtige Stelle zu bringen.

In diesem Licht fand ich den folgenden Artikel interessant (ich habe ihn in einem anderen Kontext kennengelernt, als ich nach Grafiksoftware suchte, aber trotzdem ...). Der grafische Ansatz zur Beschreibung eines Entwurfs ergab für mich Sinn, obwohl dies meiner Meinung nach nur ein Teil des Entwurfs ist. Das Interessante ist, dass dieser Ansatz einen Rahmen zum Verstehen und Umgestalten von Designs (im Gegensatz zum Umgestalten der Software) bietet, wie in den folgenden Abhandlungen angegeben:

Es gibt eine ganze Reihe anderer Ansätze, um das Design (teilweise) zu beschreiben, wie strukturiertes Design (HIPO-Charts) oder integriertes Programmdesign , Designmuster , ...

Solange es noch keinen Industriestandard gibt, ist es unwahrscheinlich, dass es eine "normale" Art gibt, dies auszudrücken. Auch nach über 50 Jahren. Und seien Sie ehrlich, wenn Ihr Unternehmen einen guten Weg findet, um ein Design auszudrücken, würden Sie es mit der Welt teilen?

Joris Meys
quelle
Wenn Ihre Firma einen guten Weg findet, würden die Programmierer es allen anderen ziemlich schnell sagen. :-)
Lennart Regebro
Ich denke, Sie vermissen meinen Standpunkt zu UML (und jeder anderen "einzelnen" Notation). UML-before-Code ist eine Einschränkung dafür, wie Sie die Software erstellen möchten. So sind auch alle anderen Notationen (ja, ich habe viele davon gesehen, ich bin schon eine Weile hier). Bei einer gegebenen Einschränkung ist es wahrscheinlich möglich, Code zu erstellen, der dieser Einschränkung entspricht (Scherzmethode: Erstellen Sie alle möglichen Programme und überprüfen Sie, welche mit der Einschränkung übereinstimmen. Wählen Sie eines davon aus). In diesem Sinne können Sie "Code aus UML generieren". Aber (wenn wir uns an Klassendiagramme halten) dieser Code wird nicht die gewünschte Funktion implementieren ...
Ira Baxter
... und die meisten anderen Notationsschemata leiden auch darunter, sie erfassen nicht wirklich eine Spezifikation dessen, was das Programm tun soll. Sie liefern auch keine Begründung. Warum hat Ihr UML-Diagramm die Form, die es hat? Welchen Teil des Codes kann ich ändern, ohne das Diagramm zu beschädigen? Kann ich Änderungen vornehmen, die der Absicht hinter dem Diagramm nicht schaden?
Ira Baxter
@Ira: Nach dem Besuch Ihrer Webseite wurde mir klarer. Ich muss jedoch zugeben, dass eine hochrangige semantische Diskussion zu diesen Themen außerhalb meines Fachwissens liegt. Wenn Sie jedoch den tatsächlichen Code als Teil des Entwurfs betrachten, wo befindet sich dann das eigentliche Artefakt? UML - oder jede andere Notation - ist meiner Meinung nach eine Blaupause der Codestruktur, und das nenne ich gerne einen Teil des Designs. Mehr als der eigentliche Code. kümmere dich um den Teil . Es ist nicht das Design, aber dennoch ein wesentlicher Beitrag dazu. Nochmals, meiner bescheidenen Meinung nach. Die Begründung usw. kann wie erläutert hinzugefügt werden.
Joris Meys
@Joris: Die meisten Diagrammnotationen können als Projektionen (abgeleitete Artefakte) aus dem Code betrachtet werden (zumindest nach dessen Fertigstellung) oder als Anleitung zum Erstellen des Codes (Blaupause). Es gibt viele mögliche Diagramme (einige sind in Ihrer Antwort aufgeführt). Welche sind grundlegend für Ihren Code und welche sind nur Unfälle? Flussdiagramme sind Digramme, daher sollten sie qualifiziert sein. Trotzdem bin ich ziemlich zuversichtlich, dass Flussdiagramme einiger Codebausteine nicht als Teil des Entwurfs angesehen werden. Was ist also grundlegend? Was ist zufällig?
Ira Baxter
2

Aus meiner persönlichen Erfahrung würde ich behaupten, dass wir das Design von Software gut erfassen können. Wir verfügen über eine Datenbank mit Anforderungs- und Designdokumenten für jedes einzelne Feature, das wir jemals auf unserer Plattform implementiert haben. Ich nehme an, mein Umstand ist vielleicht einzigartig. Hier sind einige Dinge, über die man nachdenken sollte.

Jede einzelne Person in meinem Team hat einen Ingenieurabschluss ... meistens EE oder CE. Das Ingenieurwesen lehrt Sie das Entwerfen als Teil des Lehrplans.

Ich denke, dass es eine Menge sogenannter Software-Ingenieure gibt, die CS-Hintergründe haben. Software-Design ist kein wesentlicher Bestandteil der meisten CS-Programme. Ich sage nicht, dass alle CS-Majors schlecht im Design sind, aber ich wette, dass die meisten keine formale Ausbildung haben, die es ihnen beigebracht hat. Ich denke, viele Leute gehen davon aus, dass wenn man programmieren kann, man Software entwerfen kann, was nicht stimmt. Angesichts der Tatsache, dass viele Programmierer keinen technischen Hintergrund haben, ist es nicht verwunderlich, dass viele Softwareprojekte kein Team haben, das gut darin ist, Design zu erfassen.

Pemdas
quelle
Welche spezielle Methode zum Schreiben von Anforderungen und Designdokumenten verwenden Sie? (Ich habe mir Ihre Biografie angesehen und erwartet, jemanden aus dem Verteidigungsraum zu sehen, und war überrascht). Ich nehme an, dass Sie mit "Anforderungen" einen natürlichsprachigen Text meinen. ... wenn ja, haben Sie keine Argumente dazu? (Ich unterscheide natürliche Sprachanforderungen von formalen Spezifikationen). Sind sie vollständig? Und die Konstruktionsunterlagen? Sind sie für das derzeitige Versandsystem vollständig auf dem neuesten Stand? Ich bin damit einverstanden, dass es viele sogenannte Programmierer und Software-Ingenieure nicht gibt, also können wir uns auf die Frage beschränken, was zu tun ist.
Ira Baxter
1
Ich bin nicht sicher, ob es einen bestimmten Namen für unsere Methode gibt. Unsere Anforderungen sind, wie ich es nennen würde, eine Mischung aus natürlichen Sprachanforderungen und hochwertigen Designdokumenten. Wir haben normalerweise zwei Bearbeitungsrunden. Zunächst dokumentieren wir im Klartext, was eine Funktion tun muss. Dann legen wir genau fest, wie es aus Sicht des Benutzers funktionieren soll. Das Dokument hat zwei Ziele. Zum einen möchten wir ein Dokument bereitstellen, das von unserem Marketing-Team geprüft werden kann, um sicherzustellen, dass wir unsere geschäftlichen Anforderungen erfüllen. Zweitens möchten wir ein Dokument bereitstellen, anhand dessen unser QA-Team Tests durchführen kann.
Pemdas
1
Unsere Designdokumente sind viel formeller und detaillierter. Dazu gehört immer Folgendes: Eine Art von Use-Case-Analyse, eine Erklärung für Abstriche oder Gründe, die wir für eine bestimmte Vorgehensweise ausgewählt haben, Verweise auf andere Designs, explizite Schnittstellendefinitionen, Datenstrukturen ... ect. Wir haben nicht unbedingt explizite Kommentare dazu, wie spezifischer Code bestimmte Anforderungen erfüllt. Ich bin mir nicht sicher, ob ich das für wichtig halte oder nicht.
Pemdas
1
Ich würde sagen, dass unsere Dokumente zu 95% auf dem neuesten Stand sind. Ein paar Sachen hier und da rutschen durch die Ritzen.
Pemdas
2

Ich sehe zwei Probleme.

Das erste ist, dass es verdammt schwierig ist, Code und Dokumentation synchron zu halten. Wenn sie getrennt sind, weichen sie voneinander ab und die Dokumentation wird unbrauchbar. Programmierer haben versucht, Tools zu verwenden, um sie synchron zu halten (wie z. B. CASE-Tools), aber diese Tools haben sich zwischen den Programmierern und ihrem Code bewegt, was mehr Schaden als Nutzen angerichtet hat. Eine der wichtigsten Erkenntnisse des domänengetriebenen Designs (Evans, 2004) ist, dass gutes Design wirklich schwierig ist. Um also etwas daraus zu machen, müssen Sie:

  • Wählen Sie den kleinstmöglichen Bereich Ihres Programms, in dem gutes Design große Vorteile bringt, die sogenannte Kerndomäne
  • arbeite wirklich hart, um ein gutes Design in Form einer allgegenwärtigen Sprache zu erhalten, die alle Teammitglieder ständig verwenden
  • Machen Sie das Design so weit wie möglich zu einem Teil des Codes

Das andere große Problem bei der Art und Weise, wie wir entwerfen, ist, dass unsere Entwurfsmethoden nicht mathematisch genug sind. Undichte Abstraktionen sind nicht geeignet, solide Schlussfolgerungen daraus zu ziehen, und die Welt der streng angewandten Logik und der klaren Wahrheit wird als Mathematik bezeichnet, wovon Programmierer größtenteils zurückschrecken.

Die wenigen mathematischen Werkzeuge, die wir haben, wie formale Methoden, sind sehr unhandlich.

Map-Reduce ist ein schönes Beispiel für Mathematik in der Programmierung. Die Kernidee ist: Wenn Sie eine assoziative, binäre Operation haben, können Sie ihre Ausführung sehr einfach verteilen. Eine binäre Operation ist eine Funktion mit zwei Parametern. Assoziativität impliziert, dass (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99 ist

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99) wobei die As, Bs und Cs trivial an verschiedenen Orten hinzugefügt werden können, deren Ergebnisse gesammelt werden und in kürzester Zeit zusammengefasst.

Kartenreduzierung ist eine lächerlich einfache Idee. Es kann auf einem Blatt Papier beschrieben werden. Wenn Sie davon ausgehen können, dass der Leser das Konzept der Assoziativität fest im Griff hat, passt es auf ein recht kleines Stück Papier. Versuchen Sie nun, jemandem Map-Reduce zu erklären, ohne den Begriff Assoziativität zu verwenden oder sich indirekt darauf zu beziehen. Du traust dich ja nicht.

Software-Design ohne mathematische Abstraktionen ist wie der Versuch, Architektur zu machen, ohne sich jemals die Mühe zu machen, Geometrie zu lernen.

Vielleicht kann Haskell dies im Laufe der Zeit beheben. Die Verwendung von Konzepten aus der Kategorietheorie zur Beschreibung von Programmen erscheint mir vielversprechend. Die Kategorietheorie ist so abstrakt, dass selbst Mathematiker wenig damit anfangen konnten, aber anscheinend scheinen Kategorien, die bis zur Unkenntlichkeit abstrakt sind, abstrakt genug zu sein, um die Struktur von Software zu beschreiben. Wir werden es rausfinden. Langsam.

Waquo
quelle