Hallo zusammen,
aktuell lerne ich Python für Hobbyprojekte wo LV einem einfach im Weg steht und eh eine Sackgasse wäre (Linx).
Dabei fällt mir auf, wie einfach gewisse Sachen gelöst sind und wo drauf recht früh Blickpunkte gelegt werden.
Zum Beispiel beim Unittest:
In Python programmiere ich diese gewohnt einfach runter und die unittest Bibliothek ist auch eine Standardbibliothek von Python. Bei LV dürfte man erst mal Geld für das Toolkit ausgeben (außer bei LV Prof) um sich dann durch Menüs zu klicken. Gerade dieses Geklicke reißt mich da aus dem Programmierfluss raus. Hinzu kommt ja noch das man mit LV ja primär Messanwendungen und Prüfstände programmiert, welche sicher ohne Bug Funktionieren sollten.
Dann Dateiversionierung wo es immer noch keine wirkliche Git Integration in der IDE gibt, mal abgesehen davon das Compare und Merge einfach ein Graus sind.
Ich bin da Mittlerweile an dem Punkt wo ich mich frage ob man als LV Entwickler nicht auf ein Totes Pferd setzt. Aktuell denke ich auch das es einfacher/besser ist sich Wissen über eine andere Programmiersprache anzueignen und dieses dann nach LV zu "portieren". Weil auf GitHub, GitLab etc. pp. findet man immer ein paar gute Ideen und kann auch den Quellcode mal schnell im Browser sehen, das geht ja bei LV dank des Dateiformates nicht.
Wie seht ihr da die Zukunft/Weg von LabVIEW?
Schönes WE und Gruß
Max
Hallo Max,
du provozierst etwas hier im LabVIEW Forum - mache ich auch gelegentlich - soweit sogut.
Wenn sich jemand sehr auf textorientierte Programmiersprachen fokusiert hat, und sich nicht davon lösen kann, der wird mit LabVIEW nie und nimmer glücklich werden. Wenn das so ist, dann sollte derjenige einfach bei den textorientierten Programmiersprachen bleiben und alles ist gut.
Über das Unit Test Toolkit kann man streiten. Aber egal wie oder mit was automatisierte Unit Tests ausgeführt werden, die Testfälle und deren Ergebnisse müssen vor der Ausführung festgelegt werden. Das ist der Hauptaufwand. Wenn dir das Toolkit nicht gefällt, dann mach einfach dein eigenes Toolkit - so kompliziert ist das nicht.
Wenn jemand mit einer Programiersprache alles machen will, dann wird es immer problematisch. LabVIEW hat durchaus seine Berechtigung, eher nicht für Hobbyprojekte mit Arduino und ähnlichen Systemen. Der Focus von LabVIEW liegt nicht auf derlei Projekte. Das hat sich irgendwie so ergeben weil einige Leute damit herumgespielt haben. Ich halte auch nicht viel von solchen Kombinationen.
Letzendlich ist eine Diskussion zum Thema: "LabVIEW ist toll oder ist sch*" einfach sinnlos. Das gilt übrigens für alle Programmier- oder Scriptsprachen.
LabVIEW hat seine Berechtigung und dran wird sich in absehbarer Zukunft auch nichts ändern.
(16.07.2021 11:48 )MScz schrieb: [ -> ]ob man als LV Entwickler nicht auf ein Totes Pferd setzt.
Keinesfalls setzt man als LV Entwickler auf ein Totes Pferd. Auch nicht als einer, der mit LabVIEW Applikationen entwickelt.
Die Aufgabe ist es, das Mittel zum Zweck zu finden: Nur die allerwenigsten werden mit dem Steinelaster zum Bäcker fahren wegen Frühstücksbrötchen holen. Die Kunst ist es, das richtige Mittel für den gegebenen Zweck zu finden. Zum Brötchen holen reichen die Mittel von Pedes bis Maybach.
Wie du ja selbst schreibst: "mit LV ja primär Messanwendungen und Prüfstände programmiert, welche sicher ohne Bug Funktionieren sollten.". Wie kann LabVIEW da ein Totes Pferd sein? Ich kann deiner Aussage hier zustimmen (außer dass ich noch ein Und zwischen sicher und ohne einfügen würde).
Sicher ist klar. Schließlich ist LabVIEW eine Datenfluss-orientierte Sprache, und die gelten gemeinhin als sicherer als Text-orientierte Sprachen. Was meinst du denn mit Bug? Die Features von LabVIEW? Oder doch die Bugs, die der Anwender von LabVIEW produziert? Selbstverständlich können auch LabVIEW-Entwickler Bugs produzieren. Allerdings: Hält man sich an die Vorschriften für einen guten LabVIEW-Programmierstil, so sind die Möglichkeiten, Bugs zu produzieren doch recht gering - im Gegensatz zu Text-basierten Sprachen.
Zitat:das es einfacher/besser ist sich Wissen über eine andere Programmiersprache anzueignen und dieses dann nach LV zu "portieren".
Selbstverständlich programmiere ich nicht nur in LabVIEW. Je nach Zweck, womit ich wieder bei meinem Lieblingsbäcker wäre, kommt da ASM, C/C++ oder auch Pascal zum Einsatz. Portieren allerdings ist eher schwierig. Was für alle Programmiersprachen gilt, sind eher grundsätzliche Eigenschaften einer Software: Debugbarkeit, Lesbarkeit, Wiederverwendbarkeit, Kapselung, Einfachheit.
Hallo zusammen,
danke für eure Antworten. Der Beitrag war in der Tat etwas provozierend formuliert. Vll. habe ich die Punkte auch falsch beschrieben.
Mir geht es nicht darum welche Sprache besser ist, sondern eher wo ihr die Zukunft von LV seht.
Mir ist bewusst das LV diverse Vorteile hat gerade was Messprogramme angeht und da auch nicht so schnell verschwinden wird. DaisyLab findet man ja auch noch an ein paar Stellen.
Hauptsächlich programmiere ich in LabVIEW und bin damit auch im Grunde zufrieden. Es macht Spaß, ist ne tolle Sprache und man kommt gerade bei Messprogrammen schnell ans Ziel.
Beim Blick über den Tellerrand war ich dann aber echt überrascht wie einfach ein paar Sachen in anderen Entwicklungsumgebungen sind.
Gerade bei der Git Integration ist mir dies aufgefallen. Diese ist ja Seitens NI nicht vorhanden und bei VS Code einfach drin.
Beim Unittesting meinte ich die Bugs die man selber einbaut. Ja mit LV macht man weniger Fehler, aber m.M.n. genug um ein paar Sachen mal mit einem Unittest abzufangen.
Da den Leuten noch ein extra Toolkit zu verkaufen und Testing in den Grundlagen überhaupt nicht zu erwähnen finde ich schon "sportlich".
Eine Bekannte, welche an der RWTH Aachen lehrt sagte mir, dass ein paar Ihrer Kollegen*innen kein LV mehr sondern Python einsetzen. Eben genau für kleinere Messprogramme in der Lehre.
Daneben wird Python ja auch so recht viel genutzt. Mit recht wenig Suche findet man auch Quellcode für diverse Messgeräte und Messprogramme.
Bleibt natürlich abzuwarten, was passiert wenn diese jungen Ing. mit dem Arbeiten anfangen. Lernen die dann LV oder machen die mit Python weiter?
Die Summe der Punkte lässt mich dann wirklich zu der Frage kommen ob NI da nicht schon schauen etwas den trennt verpennt. "Totes Pferd" war da zu hart, aber leicht kränklich ist es für mich ja schon etwas.
Bin ich da der einzige mit diesen Gedanken und für euch ist alles tutti in der NI Welt?
Gruß Max
PS: Hatte viel zu tun, deswegen die späte Antwort.
Es ist immer gut, űber den Tellerrand hinauszuschauen, schon allein wegen der Vergleichsmöglichkeit.
Und es immer gut ein zweites Standbein zu haben.
Python ist (neben C/C++) eine gute Wahl, weil
1. NI Python Bibliotheken für einige HW und SW Produkte anbietet,
2. NI Python in LabVIEW, DIAdem, SystemLink und Teststand unterstützt,
3. Parameter in Funktionsaufrufen "by value" űbergibt, was dem Datenfluss nahe kommt. (Einschränkung: veränderbar Datentypen, z. B. Listen)
Nachteil ist das eingeschränkte Multi-threading wegen des globalen Mutex-Lock, welches man aber durch das Multi-threading Modell von QT umgehen kann.
Gruß Holger