Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
Just another Flow-enabled Language ... oder doch mehr?
35 views
Skip to first unread message
Denis
Jun 5, 2014, 4:48:28 PM6/5/14
to event-based...@googlegroups.com
Auf der Suche nach einer Umsetzung für Flow-Design auf der JVM bin ich auf Xtend gestoßen.
Xtend ist eine coole Sprache aus dem Java-Eclipse-Universum, die viele moderne Sprachfeature hat, die wir in Java so vermissen/vermissten und die sich doch völlig nahtlos in das Java-Universum integriert - Xtend- und Java-Code kann nebeneinander im selben Eclipse-Projekt existieren und sich gegenseitig problemlos referenzieren.
Die Sprache sei jedem ans Herz gelegt, der sowieso unter Eclipse programmiert.
... Mit Flow-Design macht's noch mehr Spaß. Deshalb habe ich die Sprache per interner DSL und Annotationen für Flow-Design optimiert. Wer Interesse hat, dem sei mein Artikel empfohlen: http://blog.grammarcraft.de/2014/06/05/extend-your-flow-horizon-flow-design-mit-xtend/
Denis
Xtend ist eine coole Sprache aus dem Java-Eclipse-Universum, die viele moderne Sprachfeature hat, die wir in Java so vermissen/vermissten und die sich doch völlig nahtlos in das Java-Universum integriert - Xtend- und Java-Code kann nebeneinander im selben Eclipse-Projekt existieren und sich gegenseitig problemlos referenzieren.
Die Sprache sei jedem ans Herz gelegt, der sowieso unter Eclipse programmiert.
... Mit Flow-Design macht's noch mehr Spaß. Deshalb habe ich die Sprache per interner DSL und Annotationen für Flow-Design optimiert. Wer Interesse hat, dem sei mein Artikel empfohlen: http://blog.grammarcraft.de/2014/06/05/extend-your-flow-horizon-flow-design-mit-xtend/
Denis
Ralf Westphal
Jun 5, 2014, 5:03:04 PM6/5/14
to event-based...@googlegroups.com
Coole Sache! Sollte Teams helfen, die noch in Java 7 und früher stecken.
Allerdings: Es geht hier um Flow-Design mit EBC. Das ist aber nur ein Teil von Flow-Design. Flow-Design braucht nicht zwangsläufig Klassen zur Implementation von Funktionseinheiten.
--
Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "Event based Components" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an event-based-compo...@googlegroups.com.
Weitere Optionen finden Sie unter https://groups.google.com/d/optout.
Ralf Westphal - One Man Think Tank
Hans-Henny-Jahnn-Weg 44D-22085 Hamburg
Germany
Tel 0170-3200458
Email in...@ralfw.de
Denis
Jun 11, 2014, 4:37:22 AM6/11/14
to event-based...@googlegroups.com
Ja klar, Flow-Design ist mehr. XtendFlow und ScalaFlow sind ja auch nur Werkzeuge, um Flow-Design Konzepte prägnant und kurz ausdrücken zu können. In der Kürze liegt eben auch Würze, wie Du in einem Deiner letzten Artikel festgestellt hast. Ich versuche ja gerade mich über eine interne DSL von den Sprachkonzepten der Host-Sprache zu lösen und damit eine adäquate Abstraktion von Funktionseinheiten zu schaffen.
Ich bin jetzt noch dabei eine externe DSL zu implementieren, die ähnlich der Flow-Runtime, die Verknüpfung der Funktionseinheiten zu Funktions-Boards erlaubt und damit die händische Implementierung derselben überflüssig macht.In Kombination von interner und externer DSL kämen dann dieser Ansatzder Spezifikationmächtigkeit des Flow-Runtime-Ansatzes sehr nahe. "Flow-Design" ist am Ende in meinen Artikeln eben auch nur ein Schlagwort, unter dem sich alles gut zusammenfassen lässt - besser als "EBC", wie ich denke. Was das als Design-Paradigma bedeutet, beschreibst du am Ende eh am besten. ;-)
Gruß, Denis
Ich bin jetzt noch dabei eine externe DSL zu implementieren, die ähnlich der Flow-Runtime, die Verknüpfung der Funktionseinheiten zu Funktions-Boards erlaubt und damit die händische Implementierung derselben überflüssig macht.In Kombination von interner und externer DSL kämen dann dieser Ansatzder Spezifikationmächtigkeit des Flow-Runtime-Ansatzes sehr nahe. "Flow-Design" ist am Ende in meinen Artikeln eben auch nur ein Schlagwort, unter dem sich alles gut zusammenfassen lässt - besser als "EBC", wie ich denke. Was das als Design-Paradigma bedeutet, beschreibst du am Ende eh am besten. ;-)
Gruß, Denis
Ralf Westphal
Jun 11, 2014, 4:56:59 AM6/11/14
to event-based...@googlegroups.com
Wenn du eine DSL machst und dann Implementationen autom. verdrahtest, dann versuche doch aber, das nicht nur auf EBCs auszulegen. Ganz normale Funktionen oder eben welche mit Continuations sind auch Flow-Funktionseinheiten.
--
Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "Event based Components" sind.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an event-based-compo...@googlegroups.com.
Weitere Optionen: https://groups.google.com/d/optout
Denis
Jun 16, 2014, 6:02:06 PM6/16/14
to event-based...@googlegroups.com
Ja, stimmt. Manchmal sind EBC-assoziierte Klassen zu schwergewichtige und Funktionen oder Methoden mit Continuations die bessere, weil leichtgewichtigere Wahl.
Wenn man Code generiert, sollte Wrapper-Code drumherum wie in der Flow-Runtime machbar sein.
Danke für den Hinweis. Ich werde das in einer zweiten Iteration versuchen.
Denis
P.S. Genrell würde mich mal interessieren, wie viele hier in der Gruppe noch auf der JVM-Plattform unterwegs sind und für wen der XtendFlow-Ansatz hilfreich wäre?
Wenn man Code generiert, sollte Wrapper-Code drumherum wie in der Flow-Runtime machbar sein.
Danke für den Hinweis. Ich werde das in einer zweiten Iteration versuchen.
Denis
P.S. Genrell würde mich mal interessieren, wie viele hier in der Gruppe noch auf der JVM-Plattform unterwegs sind und für wen der XtendFlow-Ansatz hilfreich wäre?
Am Mittwoch, 11. Juni 2014 10:56:59 UTC+2 schrieb Ralf Westphal:
Wenn du eine DSL machst und dann Implementationen autom. verdrahtest, dann versuche doch aber, das nicht nur auf EBCs auszulegen. Ganz normale Funktionen oder eben welche mit Continuations sind auch Flow-Funktionseinheiten.
Am 11. Juni 2014 10:37 schrieb Denis <kun...@grammarcraft.de>:
Ja klar, Flow-Design ist mehr. XtendFlow und ScalaFlow sind ja auch nur Werkzeuge, um Flow-Design Konzepte prägnant und kurz ausdrücken zu können. In der Kürze liegt eben auch Würze, wie Du in einem Deiner letzten Artikel festgestellt hast. Ich versuche ja gerade mich über eine interne DSL von den Sprachkonzepten der Host-Sprache zu lösen und damit eine adäquate Abstraktion von Funktionseinheiten zu schaffen.
Ich bin jetzt noch dabei eine externe DSL zu implementieren, die ähnlich der Flow-Runtime, die Verknüpfung der Funktionseinheiten zu Funktions-Boards erlaubt und damit die händische Implementierung derselben überflüssig macht.In Kombination von interner und externer DSL kämen dann dieser Ansatzder Spezifikationmächtigkeit des Flow-Runtime-Ansatzes sehr nahe. "Flow-Design" ist am Ende in meinen Artikeln eben auch nur ein Schlagwort, unter dem sich alles gut zusammenfassen lässt - besser als "EBC", wie ich denke. Was das als Design-Paradigma bedeutet, beschreibst du am Ende eh am besten. ;-)
Gruß, Denis
--
Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "Event based Components" sind.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an event-based-components+unsub...@googlegroups.com.
Weitere Optionen: https://groups.google.com/d/optout
wp11033256-ole wp11033256-ole
Jun 20, 2014, 5:29:42 AM6/20/14
to event-based-components
Hallo Denis,
P.S. Genrell würde mich mal interessieren, wie viele hier in der Gruppe noch auf der JVM-Plattform unterwegs sind und für wen der XtendFlow-Ansatz hilfreich wäre?
Ich bin auf der JVM mit Java unterwegs.
Ich habe mich auch durchaus mit alternativen JVM-Sprachen beschäftigt.
Allerdings können die Entwickler anderer JVM-Sprachen fast immer Java gut lesen, aber Java-Entwickler selten die andere JVM-Sprache. Einzig Groovy scheint sich zumindest in einigen Nischen neben Java zu etablieren.
Das Rennen um eine potentielle Java-Nachfolge hat allerdings gerade erst angefangen... :-)
Meinen Code findest Du hier:
Es fehlt allerdings noch ein gutes Beispiel und viel Dokumentation. Deshalb habe ich hier auch noch nix gepostet.
Viele Grüße
Ole
--
Trettlachstr. 34
91301 Forchheim
Tel.: 09191/79 40 838
Mobil: 0171/10 7 90 23
Denis
Jun 23, 2014, 5:26:52 PM6/23/14
to event-based...@googlegroups.com, o...@bulbuk.de
Hallo Ole,
Interessant!
Ich sehe, Du hast Dich an einer Flow-Sprache versucht, die Du mit einer Parsing-Expression-Grammatik spezifizierst.
Ich kenne den Parsergenerator nicht, mit dem Du arbeitest. Aber wenn Du auch auf Eclipse unterwegs bist und Dich mit Grammatiken auskennst, lohnt es sich für Dich vielleicht auch, das DSL-Framework Xtext (https://www.eclipse.org/Xtext/) anzusehen. Im Kontext von Eclipse läßt es sich wirklich sehr gut benutzen und man bekommt viel integrative Funktionalität geschenkt. Vielleicht ergibt sich darüber auch eine Zusammenarbeit?
Gruß, Denis
Interessant!
Ich sehe, Du hast Dich an einer Flow-Sprache versucht, die Du mit einer Parsing-Expression-Grammatik spezifizierst.
Ich kenne den Parsergenerator nicht, mit dem Du arbeitest. Aber wenn Du auch auf Eclipse unterwegs bist und Dich mit Grammatiken auskennst, lohnt es sich für Dich vielleicht auch, das DSL-Framework Xtext (https://www.eclipse.org/Xtext/) anzusehen. Im Kontext von Eclipse läßt es sich wirklich sehr gut benutzen und man bekommt viel integrative Funktionalität geschenkt. Vielleicht ergibt sich darüber auch eine Zusammenarbeit?
Gruß, Denis
Rainer Schuster
Jun 29, 2014, 1:53:47 PM6/29/14
to event-based...@googlegroups.com, o...@bulbuk.de
Also ich bin ja eher nicht auf der JVM unterwegs, und Clojure hat hier doch eine sehr hohe Verbreitung... (ich würde sogar meinen noch mehr als groovy, zumindest ist das meine subjektive Wahrnehmung) Das liegt aber wohl eher an dem Bereich in dem entwickelt wird. Und um beim Thema zu bleiben und die Brücke zu schlagen. Wem EBC zusagt, sollte sich mal die Quellen von LightTable ansehen, das in ClojureScript geschrieben ist. Die darunterlegende Architektur BOT http://www.chris-granger.com/2013/01/24/the-ide-as-data/ ist ähnlich dem FRP (http://en.wikipedia.org/wiki/Functional_reactive_programming)
Objekte werden über ein Makro erzeugt und sind intern nichts anderes als eine hashtable/map, wobei die Schlüssel meist Symbole sind :symoble_name. Wer Ruby oder Clojure kennt, dem sind diese Konstrukte geläufig.
Ein Objekt definiert hier wie in der oop auch attribute (das sind die Schlüssel der Maps). Es hat direkt keine Funktionen, sondern definiert nur events, (was nichts weiteres ist als ein Schlüssel innerhalb der Map). Verhalten kann auf diese Objekte über Tags dynamisch hinzugefügt werden und das zur Laufzeit. Alles in allem entspricht das einer FBC Architektur ausser: Daten sind nur Daten (und zwar global) Pfui, pfui, pfui. Nein, das ist wirklich in Ordnung in dem Fall. Und über behaviors triggers und tags wird das ganze verdrahtet und mit Funktionalität verknüpft. Um ein Event auszulösen wird die Funktion raise aufgerufen. Wie gesagt, zu den Daten kann BOT zur Laufzeit Verhalten hinzufügen oder wegnehmen. Ohne etwas neustarren zu müssen. Verkabeln von Inputs und Outputs nach belieben.
Am Freitag, 20. Juni 2014 11:29:42 UTC+2 schrieb OleB:
Reply all
Reply to author
Forward
0 new messages