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