BLACKLIQUID –
Visual Programming ohne Blackbox
Viele visuelle Programmiersprachen lösen ein Problem – und erzeugen dabei ein neues: BLACKLIQUID ist mein Versuch, genau diese Lücke zu schließen: eine visuelle Programmiersprache, die Abläufe nicht nur verbindet, sondern lesbar macht.
Der Kern ist eine einfache Idee: Daten verhalten sich wie ein Fluss. Und der Benutzer sollte diesen Fluss sehen können – inklusive Entscheidungspunkten, Zustandswechseln und Nebenwirkungen.
Dieses Projekt ist ein privat initiiertes Forschungsvorhaben und Prototyping-Labor. Es untersucht, wie sich Programmlogik als sichtbare Systemdynamik darstellen lässt – so, dass Anfänger schneller handlungsfähig werden und Fortgeschrittene die Struktur eines Programms klarer erkennen.
BLACKLIQUID richtet sich an Anfänger, die schnell erste eigene Projekte umsetzen möchten. Statt sich durch lange Einstiegshürden textueller Programmierung zu kämpfen, ermöglicht das visuelle System einen direkten Start – mit frühen Erfolgserlebnissen und nachvollziehbarer Logik.
Problem: Warum viele Visual Languages trotz „Einfachheit“ verwirren
Visuelle Programmierung wird oft als „leichter Einstieg“ vermarktet. In der Praxis entstehen aber typische Bruchstellen:
Blackbox-Blöcke: Die entscheidende Logik steckt im Inneren eines Blocks und verschwindet aus dem Blickfeld.
Unsichtbare Dynamik: Man sieht Verbindungen, aber nicht, wann und warum etwas passiert.
Schwieriges Debugging: Fehler wirken „magisch“, weil Zustände und Signale nicht transparent sind.
Geringe Lesbarkeit bei Wachstum: Sobald ein Projekt größer wird, kippt das Diagramm in Unübersichtlichkeit.
BLACKLIQUID adressiert nicht „mehr Features“, sondern eine grundlegende Frage der Darstellung:
Wie muss eine visuelle Sprache aussehen, damit man Programme wie Systeme lesen kann?
Ansatz: Visual Semantics statt Block-Bastelei
BLACKLIQUID setzt auf visuelle Semantik: Die Form eines Elements soll schon erklären, was es tut – und wie es sich im System verhält.
Statt „Block + Parameter“ steht im Mittelpunkt:
Flüsse (Inputs, Transformationen, Outputs)
Entscheidungspunkte (Vergleich, Schwellwert, Bedingung)
Zustände und Signale (HIGH/LOW, aktiv/inaktiv, Trigger)
Wirkung (was am Ende tatsächlich angesteuert wird)
Die Metapher „Liquid“ ist dabei keine Deko, sondern Struktur:
Wenn Daten wie eine Flüssigkeit gedacht werden, wird Logik als Steuerung von Strömen erfahrbar – nicht als abstrakte Zeile Code.
Was der Nutzer sieht: Ein Canvas, der Logik lesbar macht
Ein BLACKLIQUID-Programm ist eine sichtbare Kette aus:
Quelle → Verarbeitung → Entscheidung → Aktion
Die wichtigsten Effekte für den Nutzer:
Man erkennt auf einen Blick, wo Daten herkommen und wo sie hingehen.
Bedingungen wirken nicht wie „If-Statements“, sondern wie sichtbare Weichen im Fluss.
Outputs sind nicht „irgendwo“, sondern als konkrete Aktionen erkennbar (z. B. LED an/aus, Motor, Signal).
Damit wird die Oberfläche zugleich Programmierumgebung und Erklärmodell.
Systemtheoretische Perspektive:
Beobachtbarkeit als Architekturprinzip
BLACKLIQUID ist auch eine Systemtheorie-Fallstudie:
Ein Programm ist kein statisches Objekt, sondern ein System aus Flüssen, Kopplungen und Rückkopplungen.
Der entscheidende Hebel ist Observability – Beobachtbarkeit:
Zustände werden nicht geraten, sondern sichtbar.
Signalwege werden nicht vermutet, sondern nachvollziehbar.
Fehler sind nicht „mystisch“, sondern zeigen sich als Störung im Fluss.
So wird Debugging zu Systemanalyse:
Wo staut es sich? Wo verzögert es sich? Wo wird falsch verzweigt?
Warum das didaktisch stark ist
BLACKLIQUID macht typische Programmierkonzepte unmittelbar erfahrbar:
Kausalität: „Wenn X, dann Y“ wird als sichtbare Verzweigung verständlich.
Abstraktion: Funktionen sind nicht nur Blöcke, sondern klar erkennbare Transformationen.
Systemdenken: Nutzer sehen nicht nur Teile, sondern Zusammenhänge und Nebenwirkungen.
Das Ziel ist nicht, Code „zu ersetzen“.
Das Ziel ist, Verstehen zu beschleunigen – besonders in der Phase, in der viele Lernende aussteigen, weil ihnen das „mentale Modell“ fehlt.
Status des Projekts
BLACKLIQUID befindet sich im Prototyp-Stadium und dient als Experimentierfeld für:
visuelle Grammatik (Wie sieht eine Operation aus, ohne Text zu brauchen?)
Interaktionsprinzipien (Wie baut man schnell, ohne unpräzise zu werden?)
Lesbarkeit bei Wachstum (Wie bleibt ein Canvas skalierbar?)
Debug-Mechanik (Wie zeigt man Zustände, Trigger und Signalpfade sauber?)
Nächste Schritte
Die nächsten Entwicklungsschritte sind bewusst darauf ausgerichtet, die Sprache als System „reif“ zu machen:
Bibliothek zentraler Operatoren (Vergleich, Schwellwert, Filter, Mapping)
Klare Typen-/Signalmodelle (z. B. digital/analog, Ereignis/Status)
Visuelle Debug-Ansicht (Live-Zustände, Pfad-Highlighting, History)
Skalierung (Gruppierung, Module, Wiederverwendung ohne Unlesbarkeit)
Fazit
BLACKLIQUID ist mein Beitrag zu einer Kernfrage in visueller Programmierung:
Wie baut man Interfaces, die Logik nicht verstecken, sondern sichtbar machen?
Der Anspruch ist eine Visual Language, die nicht nur „einfach zu bedienen“ ist, sondern verständlich zu lesen – wie ein Systemdiagramm, das tatsächlich lebt.
Wenn visuelle Programmierung in Bildung, Prototyping und Kreativtechnik wirklich stark sein soll, dann braucht sie nicht mehr Blöcke. Sie braucht bessere Semantik, bessere Beobachtbarkeit – und eine Darstellung, die Denken unterstützt statt es zu ersetzen.
BLACKLIQUID – Beispiel-Canvas: Die Grafik zeigt, wie BLACKLIQUID Datenfluss und Logik visuell abbildet: Ein Eingabewert wird durch Verarbeitungsschritte und Vergleichsbedingungen (z. B. ==, >=) geleitet, die als sichtbare Entscheidungspunkte dargestellt sind. Rechts wird ein digitales Signal (HIGH/LOW) in eine konkrete Aktion übersetzt – eine LED schaltet abhängig vom Zustand. Unten sind weitere Vergleichsoperatoren als Bausteine gezeigt, die sich zu größeren Abläufen kombinieren lassen.