Programmierst du noch, oder klickst du schon?

Marco13 · 27. Mai 2017 um 05:35

Nachdem die meisten kleineren¹ und größeren² Projektchen, die ich hier erwähnt habe, bisher wenig Resonanz verursacht haben, dachte ich, dass ich es mal mit einem reißerischeren Titel versuche (das nennt sich dann wohl „Click-Baiting“), um mal zu zeigen, worin einige der letzten³ Projektchen zusammenfließen.

Fließen ist auch schon das Stichwort: Es geht, im weitesten Sinne, um Flow-Based-Programming:

und das ganze liegt unter

Das ganze hatte ich ~2012 angefangen (inspiriert durch einen Vortrag… ich meine, auf der JAX … zum „Kanban-Flow-Pattern“ - aber damit hat es jetzt nicht mehr viel zu tun). Zwischenzeitlich war es recht weit in verschiedene Bereiche abgedriftet (Typinferenz…). Zuletzt lag es lange brach, aber jetzt habe ich mal versucht, es auf einen Stand zu bringen, wo man es sich mal ansehen kann. Es liegen vermutlich noch einige Leichen im Code, und es gibt viele mögliche Erweiterungen, aber zumindest die Demo sollte man starten und ein bißchen drin rumklicken können.

Ansonsten könnte ich vieeeel dazu schreiben, aber … das passiert wohl erstmal eher auf Englisch, um die ganzen TODOs in den READMEs zu füllen… oder als Antworten auf Fragen hier

1:

2:

3:

cmrudolph · 27. Mai 2017 um 11:41

Erst einmal: Hut ab, dass du da was lauffähiges hinbekommen hast!

Im Studium habe ich eine Vorlesung “Graphische Sprachen” (oder so ähnlich) besucht. Neben den theoretischen Grundlagen, die einer graphischen Sprache zu Grunde liegen, wurde dort auch auf die praktische Relevanz eingegangen. Quintessenz war, dass graphische Sprachen für größere Projekte tendenziell eher ungeeignet sind, weil die Informationen sich nicht kompakt genug darstellen lassen. Das sieht man denke ich schon an deinem Screenshot.
Ein Vorteil ist, dass die Programmierung nicht unbedingt linear erfolgt. Für Steuerlogik, wie in eingebetteten Systemen, haben derartige Sprachen den Vorteil, dass sie auch für “Laien” schnell verständlich sind.

Deine Sprache sieht nach einem graphischen Wrapper um Java aus. Abgesehen davon, dass du wohl probiert hast, ob sowas für Java umsetzbar ist: was ist dein Ziel bei der Sprache?

Marco13 · 27. Mai 2017 um 14:55

Ohhh neeeiiinn Ich hatte schon den Satz im ersten Beitrag eingefügt:

Und um die Frage vorwegzunehmen: „Wozu soll das ganze denn gut sein?“ : Das weiß ich doch nicht…

aber ihn dann wieder rausgenommen

Die Antwort ist tatsächlich schwierig. Zumindest, wenn man nicht antworten will mit „Andere machen auch so einen nutzlosen Kram, da darf ich das ja wohl auch machen!*“ und dabei verweisen auf

(wobei hinter einigen dieser Dingen große Teams bzw. eines der größten Unternehmen der Welt stehen). Ein Vergleich meines handgeklöppelten, technisch fragwürdigen Klick-Tools (in einer Sprache, die heute kaum noch verwendet wird) mit diesen Dingen wäre unangebracht.

Das ganze wurde ohne konkretes Ziel entwickelt. Wie gesagt: Ursprünglich hatte ich ein bißchen was zu „Kanban Flow“ runterimplementiert (siehe GitHub - Dierk/kanbanflow_animation: Animation of the KanbanFlow Pattern ), aber das ist inzwischen nur noch eine theoretisch mögliche Implementierung für das FlowExecutor-interface.

Als Swing-Fan dachte ich mir dann: Hey, irgendein GUI dafür wäre cool. Also los …

Ein Abstecher in die dunklen Tiefen der Typinferenz ergab sich dann aus dem abstrakten Zwischen-Ziel:

„Ich habe etwas, was eine List<T> und einen Consumer<T> als Eingabe bekommt. Wenn man dort eine List<Number> anschließt, soll erkannt werden, dass an den anderen Eingang nur noch ein Consumer<Number> angeschlossen werden kann.“

Das ist ein Trivialbeispiel. Man kann sich vorstellen, dass das ganze bei Map<K extends Number, V extends Serializable> und Consumer<K extends Serializable> etwas fummeliger wird. Das ganze hatte ich im Zuge der letzten Aufräumaktion komplett rausgezogen, bzw. versucht, es in einem vorläufigen, experimentellen TypeContext interface zu verstecken. Kleine Überreste wie der TypeVariableInstantiator sind nach außen nicht sichtbar.

Aber ein Teil-Ziel hatte ich die ganze Zeit: Wenn man ein Modul auswählt, sollten bei „Sources“ bzw. „Targets“ nur die Module angezeigt werden, die dazu passen.

Irgendwann kam ich auf die absurde Idee, dass man Module ja direkt aus Methoden erstellen könnte. Allgemein: Wenn man ein Modul auswählt, kann man automatisch Module erstellen, die irgendeine Methode auf dem Ausgabe-Objekt ausführen. Das ist dann tatsächlich fancy, und vielleicht auch bis zu einem gewissen Grad „praktisch“.

Parallelisierung ist noch ein Punkt. Eines der ersten Mini-Beispiele für den „core“-Teil zeigt, wie man

Eine Liste von Strings in zwei Hälften teilen
Beide Hälften getrennt voneinander verarbeiten
Die Hälften wieder zusammenfügen kann

Die Verarbeitung der beiden Hälften erfolgt dabei („natürlich“) parallel zu einander. Das schwierige Problem der Data Dependencies wird „automatisch“ gelöst, da man ja mit dem Flow schon die Ausführungsreihenfolge vorgibt.

Und natürlich: Visualisierung. Das zweite GUI-Beispiel zeigt, wie man JFreeChart in ein Modul einbindet, so dass in dem Modul (!) dann ein BarChart angezeigt wird.

Nach dem Post hier ist auch noch Flow/flow-samples-weka at master · javagl/Flow · GitHub dazugekommen. Das ist zwar noch sehr rudimentär, aber wird sicher bald verallgemeinert. Und wer Data Mining (oder „Data Science“) in Java macht, weiß, dass man um http://www.cs.waikato.ac.nz/~ml/weka/ nicht drumrumkommt, und kann sich vielleicht vorstellen, was man damit alles anstellen könnte.

iFelixxxx · 28. Mai 2017 um 12:24

Sieht sehr interessant aus
Mit den passenden Modulen kann man damit sicherlich kleinere Programmieraufgaben vereinfachen und behält auch leichter den Überblick, als bei rein textbasiertem Code. Gerade für Laien oder Nicht-Programmierer ist das sinnvoll.

Das ganze System erinnert mich etwas an Node-RED, eine Webanwendung, bei welcher per Drag and Drop verschiedene APIS (z.B. für Twitter/Raspberry Pi/Sensor/etc.) und diversen Aktionen verknüpft werden können. Damit habe ich bei meinem Unternehmen im Rahmen eines Messdaten-basierten Projektes gearbeitet und das Prinzip hat Potential: Es ist nicht nur sehr leicht und intuitiv damit zu Arbeiten, sondern bei kleinen Projekten ist die visuelle Darstellung auch hilfreich bei der Vorstellung des Projektes bzw. um Außenstehenden die Funktionsweise zu erklären.

Respekt wie weit du bisher schon gekommen bist! Bin auf jeden Fall gespannt auf Updates.

Marco13 · 28. Mai 2017 um 13:46

Node-RED hatte ich nicht konkret auf dem Schirm, aber indirekt: Es ist recht weit oben bei den Ergebnissen der Google-Bildersuche

Allgemein stimmt es natürlich: Man würde nicht ein System „mit 1000 Zeilen (spezifischem) Code“ mit so einem System programmieren. Das ist klar, und dafür ist es auch nicht gedacht.¹

Sowas ist eben eher für den Fall gedacht, dass man irgendwelche „Black Boxes“ hat, die eine komplexe Funktionalität wegkapseln aber eine einfache Schnittstelle haben. Speziell natürlich für den Fall, wo man viele Black Boxes hat, die alle die gleiche Schnittstelle haben, aber verschiedene (komplizierte) Funktionalitäten oder Implementierungen.

Weka ist da ein gutes Beispiel: Es gibt das Interface Classifier. Aus einem gegebenen Instances-Objekt wird ein Classifier erstellt, der jede Instance einer Klasse zuordnet. Und davon gibt es … ca. 30 oder 40 verschiedene Implementierungen. Die sollten (oder könnten) natürlich im Baum der verfügbaren Module auftauchen.

Oder auch nicht. Damit hadere ich im Moment noch: Sollte es ein Classifier-Modul geben, wo der Typ des Classifiers ein „Konfigurationsparameter“ ist, oder sollte es die 40 Classifier als getrennte Module geben? Entscheidungen, Entscheidungen…

1: Es könnte der Eindruck entstehen, dass das System wirklich als „Alternative zu Code“ gedacht ist, dadurch, dass Module direkt aus Methoden erstellt werden können (und Methoden auch automatisch als Module angeboten werden). Das ist aber eher „Convenience“. Ansonsten müßte man in vielen Fällen händisch Module zusammenklöppeln, die nur eine Methode anbieten. Wieder Weka als Beispiel: Es gibt z.B. ein Evaluation-Objekt, das irgendwo ausgespuckt werden kann. Dieses Objekt hat eine Methode toMatrixString, um das Ergebnis der Evaluation schön formatiert auszugeben. Sollte ich jetzt händisch ein EvaluationToMatrixStringModule erstellen müssen? Neeeein. Einfach das passende Methoden-Modul verwenden.

Nichtsdestotrotz hatte ich auch schon überlegt, die Möglichkeit zu bieten, einen Flow, der nur aus Methoden-Modulen besteht, direkt als ausführbaren Code exportieren zu können. Aber IO ist sowieso so eine Sache. Im Moment gibt es nur XML. Wir hatten ja nix, damals. Heute würde man eher JSON verwenden. Aber in allen Fällen stellen sich viele Fragen zum Dateiformat im allgemeinsten Sinne.

Marco13 · 30. Mai 2017 um 16:10

Ein erster, erweiterter Weka-Support ist jetzt auch dabei. Damit kann man z.B. die Ergebnisse eines “Farthest First” und eines “K-Means”-Clusterers vergleichen:

Aber das ist nur ein erster Test.

Marco13 · 31. Mai 2017 um 12:26

Vielleicht möchte ja jemand zu den ersten issues (hier oder dort) etwas sagen:

Marco13 · 20. Juli 2017 um 23:57

Ja, der Name war dann vielleicht doch zu generisch. In Java 9 wird es diese Klasse geben: http://download.java.net/java/jdk9/docs/api/java/util/concurrent/Flow.html

Landei · 21. Juli 2017 um 07:45

Nenne es doch „Flowr“, dann ist es googlebar

Marco13 · 21. Juli 2017 um 15:19

_{Jetzt habe ich gerade kurz überlegt, was die Sonnenblume bedeutet, oder warum „Flowr“ und nicht „Flowm“ oder „Flowq“, aber das war wohl nicht der Punkt}

Suchen nach "javagl flow" hilft schon. Einige Codezeilen entstanden („natürlich“ ) in einem Projekt namens „JFlow“, aber insgesamt ist „branding“ an dieser Stelle vielleicht nicht so wichtig … solange das ganze nicht „größer“ wird.

Marco13 · 28. November 2018 um 20:03

Es gibt ein Update. Jetzt habe ich endlich (!) das “Lokale Maven Repo” gekickt, indem alle benötigten Libs in die Central gewandert sind. Ansonsten nichts substantielles. Schade.