Robert_Mini hat geschrieben: ↑Di Aug 11, 2020 9:18 pm
Also ich verstehe euch alle 3 nicht.
Ihr seid alle sehr IT affin und erfahren mit Logik, Programmierung etc.
Ich bin Werkstoffwissenschafter...
Ich habe gelernt - sowohl durch Ausbildung als auch öfters durch (leidvolle) eigene Erfahrung - dass das Schreiben von Code ganz einfach ist, die Schwierigkeit liegt im Lesen von Code, gerne mal einige Jahre später wenn alles aus dem Gedächtnis wieder raus ist! Dazu kommt das Problem, dass der Code nur 1x geschrieben wird, aber unzählige Male gelesen werden wird.
D.h. es kommt einzig und alleine auf die Wartbarkeit vom Code an.
Das ist genau der Grund warum bei Programmiersprachen von den einfacheren auf die höheren gewechselt wurde. Von direktem Maschinen-Code zu Assembler, von dort zu C, von C zu C++. Und von dort zu Skript-Sprachen oder grafischen Programmiersprachen.
Für mich ist das Optimum, was ich in der Regelungs- und Steuerungstechnik kenne, immer noch Simulink. Vermutlich dürften alle "großen" Steuerungen wie Fahrwerkregelsysteme und Motorsteuerung in Autos, Triebwerkssteuerungen in Flugzeugen, ... alle in Simulink programmiert - oder zumindest per Prototyping entwickelt - worden sein.
Dazu kommt dann noch mit Modelica (z.B. in der Implementierung von Dymola) eine ganze Sprachfamilie die zur Modellierung physikalischer Vorgänge dienen kann und zumindest optisch (also von der Lesbarkeit) sehr vergleichbar ist. (Die mathematischen Unterschiede und daraus folgenden Probleme erspare ich Euch hier, da die zum Thema an dieser Stelle nichts beitragen).
Vergleichbare grafische Programmierung im Gebäude-Automatisierungsumfeld dürfte eben auch der Home-Server, Node-Red, ... haben. (Hinweis: die kenne ich alle nur von Screenshots, wie praktisch und lesbar die wirklich sind kann ich nicht aus der Praxis heraus beurteilen; auch nicht ob beim Nutzen etwas hakelt und nervt).
Es gibt natürlich auch Problemstellungen die grafisch nicht gut greifbar sind. Hier bieten sich dann klassischere Formen der Programmierung (Text-Dateien) an. (Bei Simulink sind dass dann "S-Function"-Blöcke im Modell die sowohl normale Matlab-Skripte sein können als auch in C geschriebene Programme, womit dann wirklich alles möglich ist was ein Computer auch nur machen kann)
StefanW hat geschrieben: ↑Di Aug 11, 2020 9:52 pm
Weil große Logiken auf ein Blatt malen kann jeder selbst. Aber diejenigen die eine Mal-Engine haben, können dafür alle die anderen Spezialitäten sich nicht selbst machen. Da ist ein bisschen auf ein Blatt malen womöglich gar nicht so schlecht im Tausch. Und es mag helfen, sich auf das Vorhaben zu konzentrieren.
Nein! Das ist nicht lesbar und wartbar!
Wenn ich in 5 Jahren einen Fehler suche muss ich mir erst wieder das Blatt suchen - nur habe ich das zwischenzeitlich sicher schon verloren, weil ich beim Schreiben dachte(!), dass das so trivial ist, dass ich das nicht wirklich aufheben muss.
Wie oft habe ich schon über meinem eigenen Code gegrübelt und mich gefragt was ich mir da nur gedacht habe? Und beim Schreiben war alles noch so klar und logisch...
Gute Kommentare im Code helfen auch nicht weiter - denn es sind meist keine guten Kommentare da. Kommentiert wird der Code vom Programmierer zum Zeitpunkt des Programmierens. Wenn noch alles logisch und klar ist. Der Programmierer kann kaum den Standpunkt wechseln und sich überlegen was denn ein Leser des Codes für Kommentare benötigt um diesen zu verstehen. (Vergleichbares Problem: Der Entwickler kann kaum das Handbuch schreiben, denn er kann sich kaum vorstellen was ein Handbuch-Leser alles (nicht) weiß). Nicht umsonst gilt das Schreiben von gute Kommentaren als eine sehr hohe Kunst, die nur die wenigsten jemals meistern können.
Warum werden die selben Dinge immer und immer wieder neu programmiert? Warum gibt es für die gleichen Dinge immer wieder neue Bibliotheken?
Genau aus diesem Grund - und nicht wegen "Not invented here" was des programmierens unwissende Manager gerne ihren Programmierern vorwerfen.
Code schreiben geht wesentlich schneller und ist einfacher als Code lesen.
Logik-Blöcke auf ein Papier malen geht schnell. Das in JSON schreiben dauert auch nicht viel länger.
Das entstandene JSON in 5 Jahren zu verstehen und nach zu vollziehen ist praktisch unmöglich - da ist es dann schneller das nochmal zu machen.
StefanW hat geschrieben: ↑Di Aug 11, 2020 9:52 pm
Wir fanden diese vielen tollen anderen Merkmale wichtig und haben eben diese implementiert.
Diese Merkmale sind auch toll und wichtig!
Für normale Programmiersprachen gibt es einen Debugger oder gar eine IDE die dass leistet. Wer eine eigene Programmiersprache baut muss das dann aber auch mitliefern, damit man effizient programmieren kann.
StefanW hat geschrieben: ↑Di Aug 11, 2020 9:52 pm
Dass geübte und erfahrene Programmierer schnaubend mit dem Fuß aufstampfen, weil die Definition einer umfangreicheren Logik mit einer json Beschreibungssprache erfolgen kann, verwundert nicht nur Robert_MIni. Dafür wird in einem anderen Thread eine andere Lösung mit Yaml propagiert. was dann unter dem Strich GENAU das gleiche ist (Yaml ist auch nur eine xml ähnliche Beschreibungssprache) nur dass man in der dortigen Logik die oben genannten spezifischen Vorteile nicht hat.
Ob JSON, Yaml, XML, ... ist hier ziemlich egal, genau so wie die Frage ob man nun C++, Java oder C# nimmt (nicht ganz, nur C++ ist das einzig wahre...

). Es geht darum intuitiv zu verstehen was da passiert. Gerade ohne Debugger, Zeitreihen, ... - die kommen dann bei der Detail-Analyse zum Einsatz.
Grob geschätzt gilt bei produktiv genutztem Code, das der 1x geschrieben wird, 10x den Debugger gesehen hat - aber 100x - 1000x gelesen wurde.
StefanW hat geschrieben: ↑Di Aug 11, 2020 9:52 pm
Jetzt gebt Euch mal einen Ruck und lernt das einfach. Das ist nicht so schwer.
Würde ich gerne machen. Ich habe auch schon eine nicht zu kompexe Logik in Perl aus Wiregate-Zeiten die überarbeitet werden muss und die ich folglich gerne TWS-Nativ umsetzen wollte. Bisher war mir - bei bereits mehreren Anläufen - der Einstieg über einige verteilte Foren-Threads und KB-Artikel zu mühselig - und der dabei entstehenden Custom-Funktion hat mir gegraust (s.o.)
Das ganze bitte auch nicht falsch verstehen! Wenn einer der existierenden Logik-Blöcke genau die Funktion liefert, die man braucht, dann ist der schon jetzt gut geeignet.
D.h. für jemanden der rein aus der KNX Ecke kommt und nun Logik-Bausteine ersetzen möchte (z.B. weil zu Teuer), für den ist die jetzige Funktionalität der TWS Logiken absolut ausreichend und eine Erweiterung der bestehenden Möglichkeiten.
Nur wenn man aus der Ecke einer frei programmierbaren Logik-Engine kommt, so sind die vorhanden Blöcke noch zu Basic und die Verbindung zu komplexeren Elementen noch zu unübersichtlich. Mit der bereits gelegten Basis im TWS sehe ich aber durchaus die Möglichkeit, dass auch das gelöst werden kann.
