Softwaredesign in funktionalen Sprachen

ipsec

Wenn man in objektorientierten Sprachen Softwaredesign betreibt, läuft das meistens auf ein paar Diagramme hinaus: Analysediagramm, Entwurfsklassendiagramm, evntuell andere, eventuell eigene, mit der Essenz, die Klassen und ihre Beziehungen untereinander sowie möglicherweise auch ihr Verhalten darzustellen. Wenn möglich wird dabei auf bekannte Design-Patterns zurück gegriffen.

Wie sieht der Prozess in funktionalen Sprachen aus? Allgemeine Designpatterns gibt es auch dort (wenn auch etwas andere als in der objektorientierten Programmierung), aber was ist das Pendant zu den Diagrammen? Auf welche Weise kann man die Struktur des Programms darstellen und sich erarbeiten, ohne auf objektorientiertes Denken („Es gibt ein Objekt X, welches Funktionalität Y bereitstellt“) zurückzufallen?

Was ist als Literatur zu funktionalem Softwaredesign zu empfehlen?

Ich weiß zwar nichts über einen funktionalen Entwurfsprozess, aber ich glaube nicht, dass funktionaler Softwareentwurf dem objektorientieren diametral gegenübersteht, zumindest was das Design angeht.
Im Gegenteil, manches, was einem in der Objektorientierung als (Behavioral) Designpattern verkauft wird, geschieht im Funktionalen ganz natürlich (vgl. strategy, null objects, commando, template methods, etc.).
Das Modulsystem von Haskell z.B. kommt dem Klassenbegriff schon recht nahe, und viele Gedanken aus der OOP (information hiding bzw. Kapselung, *Modul*arisierung und separation of concerns, (sehr mächtige) statische wie dynamische Polymorphie, Vererbung u.v.m.) können einfach auf funktionale Programmierung übertragen werden.

Wie sich das auf den gesamten Entwurfsprozess auswirkt, kann ich nicht beurteilen. Spezielle Literatur dazu kenne ich auch nicht, glaube aber, dass es aus den o.g. Gründen auch jedes hinreichend allgemeine Buch zum Softwaredesign tut.

ipsec

Ich habe dabei die Befürchtung, dass man zu sehr auf objektorientierte Aspekte zurückfällt und zu wenig die Möglichkeiten der jeweiligen Sprache nutzt. Das Extrem davon wäre ja, ein Klassendiagramm zu entwerfen und dann zu gucken, wie man diese Klassen am besten in (z.B.) Haskell umsetzt.
Andererseits kann es durchaus sein, dass das globale Design da durchaus Ähnlichkeiten hat. Man müsste mal schauen, wie es bei vorhandenen großen Haskell-Projekten gemacht wird.

knivil

Allgemien: Es geht um Abstraktion. Die Abstraktionsmittel bestimmen auch das Softwaredesign. Im Kleinen ist das foldr und alles was darauf aufbaut: zip, scanl, map, filter, take, ... . Was OOP wohl am naechsten kommt sind Typklassen und Ableitungen (instance) davon. Und die reale Welt ist ueber Monaden angebunden. Um ein besseres Verstaendnis zu bekommen, ist es wohl das beste klein anzufangen, beispielsweise mit Tetris, Pong oder Game of Life.

großen Haskell-Projekten

Klein anfangen!

ipsec

knivil schrieb:

großen Haskell-Projekten

Klein anfangen!

Das hatte ich vor. Ich meinte nur, man könnte bei schon vorhandenen großen Projekten nachsehen, wie dort das Design ablief.

Eigentlich geht es mir ja auch eher um den allgemeinen Fall. Wenn sich Leute mal tatsächlich daran machen, ein größeres Projekt in Haskell umzusetzen, werden sie sich ja nicht als erstes bzw. nicht nur Gedanken machen, wo man ein foldr braucht oder wo man am besten die IO-Monade nimmt. Zumal das ja schon in die Implementierungsdetails geht, die zumindest im ersten Entwurfsschritt normalerweise erstmal außen vorgelassen werden.

knivil

Du kannst ja mal schauen wie es bei Galois ist, sie setzen meist nur funktionale Sprachen in der Entwicklung ein. Hier ein Vid auf Channel 9: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/A-Means-to-Many-Ends-10-Years-of-Haskell-at-Galois . Weiss aber auch nicht mehr ueber die.

Zumal das ja schon in die Implementierungsdetails geht, die zumindest im ersten Entwurfsschritt normalerweise erstmal außen vorgelassen werden.

So wuerde ich das nicht sehen, da die Signaturen oder Typeclasses sehr nah an einer formalen Spezifikation sind.

The seL4 API is represented by an executable specification[9] written in Haskell.

Ich empfehle z.B. mal OnLisp zu lesen. Von wegen Bottom-Up vs. Down usw.
Oder Dive into Python.

Mein heutiger Programmierstil hat sich zum großen Teil daraus entwickelt. Erst die Datenstrukturen vor Augen halten und dann darauf los programmieren.

Geht dann auch in C++ oder Java so.

Sorry, bin spät dran.

ipsec schrieb:

Wie sieht der Prozess in funktionalen Sprachen aus? Allgemeine Designpatterns gibt es auch dort

Welche denn? Sind diese Patterns auf alle Sprachen übertragbar? Oder sind es nur Workarounds für misslungenes Sprachdesign?

Marsi Motolami schrieb:

Mein heutiger Programmierstil hat sich zum großen Teil daraus entwickelt. Erst die Datenstrukturen vor Augen halten und dann darauf los programmieren.

Aber andererseits heisst es auch:

Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process.

µngbd schrieb:

Sorry, bin spät dran.

macht nichts, der Thread ist immer noch weit oben

µngbd schrieb:

Aber andererseits heisst es auch:

Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process.

weiss nicht wie ich das interpretieren soll bzw. auf welchen Teil des "programming process" sich das jetzt bezieht (quelle?).

Bevor ich die erste Zeile Code schreibe, ueberlege ich mir, welche Daten ich wie verarbeiten will.

warum "zurückfallen"?

Haskell hat die ein oder andere (interne) Designmacke, mit denen man sich (notwendigerweise) auseinandersetzten muß - und dann entscheiden, welchem Abstrahierungsprinzip man den Vorzug gibt. Recht gut machen sich Mischvarianten wie Scala.

Bei Haskell könnte man zynischerweise sagen, erstmal Prolog lernen und dann mit den Prologprogrammen die formale Struktur der Haskellprogramme (welche gewissermaßen die UML) erarbeiten

Das typische Profiteam dürfte sich zuallererst auf die Suche nach sinnvollen und funktionellen Bibliotheken machen und finden, dass Scala ein guter/befriedigender Kompromiss ist.

Anfänger brauchen ein paar Anläufe, um größere Hürden wie Dividieren oder andere Grundlagen (Typendefinitonen, Typen generell Accumulatoren usw.) zu überspringen.

Profs aus der Logikecke haben sowieso schon ihren logischen Plan und ihre logische Freude

Was letztlich bei allen an erster Stelle stehen muß, ist Übung, weil die Syntax (selbst einfache) von Haskell oft nicht genau verstanden wird, und so auch typische "Design Pattern" nicht (wirklich). Das Problem hier ist, dass öfter in öffentlichen Texten auf gewisse Muster zurückgefriffen wird, die zwar einleuchten, aber oft auch (maximal) ineffektiv sind (während der Hinweis auf diesen Sachverhalt ausbleibt).

Haskell ist aber selbst so flexibel und schlüpfrig, so (mega-)beastig und so wirklich gut gemacht, dass du sagen kannst, der Algorithmus bzw. die natürliche Struktur des Problems (kann auch objektorientiert sein) ist das Design.
(Auch wenn natürlich die Grundlagen der Sprache viel älter sind, Mengenlehre, Logikidealismus der 50/60 Jahre usw.)
(man könnte noch zynischer meinen, c++ sei schon in der Welt des Chaos (Mandelbrot, 70er (aber GUI!)) angekommen )

(Die Übertragbarkeit von Pattern bei Haskell: kommt drauf an, generell aber leicht, wegen der Mathematiknähe (viele Pattern...) der (abstrakten) Maschinennähe) und der guten Abstrahierfähigkeit der Sprache.

Letztlich: üben, üben, und? -> klein anfangen -> Grundlagenlücken schließen -> die Möglichkeiten verstehen (und die eigene gedankliche Begrenztheit) -> fliegen

Passender Literaturhinweis? siehe konkrete PDFs und vielleicht Barskis "Land of Lisp". Hier gehts aber nicht um Design an sich, sondern um den Spaß am Spielen, am Programmieren und so weiter