Programmierst du noch, oder klickst du schon?


#1

Nachdem die meisten kleineren1 und größeren2 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 letzten3 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 :slight_smile:


1:

2:

3:


Der IntelliJ-Thread
#2

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?


#3

Ohhh neeeiiinn :smiley: 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 :smiley:

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!*” :wink: 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 https://github.com/Dierk/kanbanflow_animation ), 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 … :slight_smile:

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 http://www.jfree.org/jfreechart/ in ein Modul einbindet, so dass in dem Modul (!) dann ein BarChart angezeigt wird.

Nach dem Post hier ist auch noch https://github.com/javagl/Flow/tree/master/flow-samples-weka 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.


#4

Sieht sehr interessant aus :slight_smile:
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.


#5

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

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.1

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.


#6

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.


#7

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


#8

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


#9

Nenne es doch “Flowr”, dann ist es googlebar :sunflower:


#10

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” :wink: ) in einem Projekt namens “JFlow”, aber insgesamt ist “branding” an dieser Stelle vielleicht nicht so wichtig … solange das ganze nicht “größer” wird.