Diskussion:LabVIEW

aus Wikipedia, der freien Enzyklopädie

Der Sache mit dem Drahtwirrwarr und den Variablen die angeblich eingefügt werden "müssen" kann ich nicht zustimmen.

• In einem ordentlich strukturierten LabVIEW-Projekt wird der Wirrwarr durch Aufteilung in Sub-VIs und eine durchdachte Struktur in einem erträglichen Maß gehalten.

• Es stimmt dass lokale Variablen die Geschwindigkeit deutlich reduzieren (nicht nur laut Doku). Sie sind aber auch nicht als Ersatz für lange Leitungen gedacht, sondern für spezielle Sonderfälle, in denen der reine Datenfluss nicht ausreicht.

• Globale Variablen benötigen tatsächlich einen etwas höheren Aufwand (einigen Aufwand kann ich hier nicht erkennen seit es "echte" Globals gibt und man keine VI-based Globals mehr schreiben muss), ich kenne aber auch nur sehr wenige Einsatzzwecke bei denen Globale Variablen in LabVIEW wirklich Sinn machen.

Ich hab's nicht direkt im Artikel geändert und würde mich über eine Stellungnahme insbes. von Montauk freuen. Dass das kein Werbetext für LabVIEW ist, ist mir auch klar, ich finde aber man sollte diese Nachteile, die größtenteils auf einer falschen Herangehensweise an das Problem beruhen nicht als allgemeingültig für LV hinstellen.

Ich stimme dir im Prinzip zu, dass sich andere Programmiersprachen für sehr große Projekte deutlich besser eignen als LV, nur deine konkreten Argumente kann ich nicht nachvollziehen. --silmaril 17:32, 9. Dez 2004 (CET)

Es freut mich, dass Du nicht einfach loeschst, sondern die Sache zunaechst ausdiskutieren moechtest. Die Nachteile, die ich beschrieben habe beruhen auf einem langjaehrigen Erfahrungschatz mit sehr vielen interpretierten und kompilierten textbasierten Sprachen und eben auch LabVIEW.

• Bei textbasierten Sprachen ist es so, dass sich der Benutzer nicht um das Format selbst kuemmern muss: Einrueckungen und Farbmarkierungen werden z.B. von Programmen wie dem Emacs der Syntax entsprechend mehr oder weniger automatisch vorgenommen. In LabVIEW ist das anderes: Hier muss der Benutzer nicht nur den Programmablauf festlegen, sondern auch die Position eines jeden Drahtstueckes und eines jeden Symbols. Dieser Mehraufwand faellt bei kleinen Projekten nicht ins Gewicht, so dass es bei diesen auch nicht als Nachteil zu bezeichnen ist.
• Hat man jetzt aber grosse Projekte und man muss noch eine Funktion hinzufuegen oder massiv abaendern, dann ist eine grossflaechige Neuanordnung der Draehte, Symbole und Strukturen faellig, selbst dann, wenn es sich nur um eine kleine Veraenderung handelt, die aber einfach Platz auf dem Bildschirm benoetigt: Die Formatierung, die man bisher aufwendig per Hand vorgenommen hat muss nochmals neu gemacht werden. Muss z.B. eine Struktur auf innerer Ebene vergroessert werden (if, case etc.) dann muss auf allen darueberliegenden Ebenen auch Platz geschaffen werden. Bei textbasierten Sprachen wird der Text einfach eingefuegt, die Formatierung kostet keine Zeit.
• Die hier geschilderten Probleme beruhen meines achtens nicht auf einer falschen Herangehensweise. Man koennte zwar sicher die Durchfuehrung eines Projektes so gestalten, dass die Probleme nicht so haeufig und massiv auftreten, aber das ist nicht praxisgerecht. LabVIEW wird z.B. in der Forschung angewandt, nicht von Informatikern, sondern von Leuten, die LabVIEW nur als Mittel zum Zweck sehen. Es ist keine Zeit und das Wissen fuer grosse Projektplanung vorhanden.
• Da es sich hier nicht um einen Werbetext handelt, der Artikel zudem fuer die Breite Masse der Anwender gedacht ist, sollten Nachteile im Klartext und nicht verklausuliert formuliert werden, auch wenn es erfahrene Anwender wie Dich gibt, fuer die das keine Probleme sind.
• Ich stimme zu, dass lokale Variable fuer Spezialfaelle und nicht als Ersatz fuer lange Leitungen gedacht sind. Aber mit der Groesse und Komplexitaet eines Projektes nimmt die Anzahl der Spezialfaelle zu.
• Dass man fuer globale Variable kein eigenes VI mehr braucht, wusste ich nicht. In 6i war es jedenfalls so und das war sehr nervig.

P.S.: Wenn Du anderer Meinung bist, dann aendere den Text einfach. Auf einen Diskussionskrieg lasse ich mich nicht mehr ein, dazu habe ich die Zeit und Motivation nicht. --Montauk 12:44, 10. Dez 2004 (CET)

Deine Argumente lassen sich in dieser ausführlichen Form durchaus nachvollziehen. Ich habe den Artikel nochmal angepasst und hoffe, dass diese Fassung einen sinnvollen Kompromiss unserer beiden Ansätze verwirklicht.

Den Aufwand beim Erstellen globaler Variablen habe ich gestrichen. Die Aussage, dass Variablen verwendet werden "müssen" habe ich dadurch ersetzt, dass sie oft verwendet werden (ist in der Praxis ja wirklich so) und dass das die Geschwindigkeit herabsetzt und dem Datenfluss widerspricht. --silmaril 18:58, 15. Dez 2004 (CET)

Ich bin Ingenieur und arbeite hauptsächlich mit LabView. Die von Euch erwähnten Nachteile kann ich nicht nachvollziehen. Ein GLEICH UMFANGREICHES Projekt mit einer Hochsprache verbraucht in Punkto Änderungsaufwand und Planung DEUTLICH mehr Zeit, als LabView. Das beides nicht auf Null reduziert wurde, ist kein Nachteil, sondern die GERINGERE Planungszeit und der GERINGERE Änderungsaufwand ist ein großer Vorteil. Darüber hinaus wird LabView durchaus in der Industrie eingesetzt, nicht nur in der Forschung. --84.167.193.165 13:54, 16. Dez 2005 (CET)

Sämtliche genannten Nachteile sind entweder nicht labViewspezifisch oder es handelt sich um Fehlverhalten von Usern. Ist die hohe Geschwindigkeit beim Porsche auch ein Nachteil, da diese den unreifen Fahrer zur Raserei verführt? MV

Ich muss meinen beiden Vorrednern vollkommen recht geben. Ich kann einige Kritikpunkte beim besten Willen nicht nachvollziehen, allerdings sind Verweise auf eine bestimmte Quelle nicht zu übersehen. Es gibt eine besondere Klientel von Programmierern, die der Welt einfach die Vorteile von JAVA oder Lunix unter die Nase reiben müssen. Mag sein, dass diese Vorteile in den reinen Informatikerdisziplinen mit sich bringen, bei den meisten Ingenieurstechnischen Anwendungen ist das aber nicht der Fall.

Dort wird Software nur als Mittel zum Zweck verstanden, Übersichtlichkeit ist oberstes Gebot. Mich interessiert das Ergebnis und die Interpretation einer Messung, der konkrete Weg dahin ist mal eher zweitrangig. Und so finden Programme wie LabVIEW auch in solchen Bereichen Anwendung, sei es in der Forschung, an Hochschulen oder aber auch in der Industrie.

Ich bin von Berufswegen für die Ausbildung von Ingenieuren zuständig und beobachte dort zunehmend ein gedankliches Problem: Einige dieser Programmierspezialisten können zwar hervorragend mit diversen Hochsprachen umgehen - und müssen das einem auch ständig und ungefragt unter die Nase reiben. Wenn in einem Diagramm aber mehr als zwei Messsignalverläufe auftauchen ist deren geistiger Horizont bereits überschritten.

Es gibt bei den meisten Problemstellungen mehrere unterschiedliche Lösungswege, doch denke ich, dass die höchste Priorität für einen Ingenieur in der Problemerfassung und der Ergebnisinterpretation liegen sollte, unabhängig davon, mit welchen Tools die Lösung erreicht wird.

Gerade hier liegt aktuell ein großes Problem: Es setzt sich zunehmend eine Ideologie (schon ein direkter Widerspruch zur Technik) durch, man könne mit Software alles lösen. Dies ist sicherlich nicht der Fall. Stattdessen führt diese starke Überbewertung der Rolle der Software zu der Absurdität, dass Studenten drauf los programmieren was das Zeug hält und zugegeben "schöne" Lösungen präsentieren - aber nicht im geringsten wissen, was und warum sie das eben gemacht haben. Wenn ein Ingenieur nicht weiß, was ein Messergebnis aussagt, spielt es auch keine Rolle, ob dieses mit kürzerer Rechenzeit erzielt wurde - es ist wertlos, weil faktisch nicht vorhanden.

Man sollte etwas mehr Wert auf Grundsätzliches legen und nicht soviel Zeit mit möglicherweise höherwertigen Hilfsmitteln verschwenden. Wenn ich nun mal primär an einem Ergebnis interessiert bin, dann tut es für mich auch ein einfacheres Tool. Ich stehe mit dieser Denkweise nicht alleine, ansonsten hätten Programme wie LabVIEW auch keine Präsenz am Markt. Ich selbst arbeite nicht mit LabVIEW, kann aber absolut nachvollziehen, dass viele Ingenieure dem graphischen Interface den Vorzug geben, da es wichtig ist einen strukturellen Überblick zu haben, was bei Programmierung in Hochsprachen weit weniger der Fall ist.

Sprich, man entscheidet sich für ein Tool (hier LabVIEW), weil es die notwendigen Funktionen erfüllt und einfach und übersichtlich ist. Es muss nur funktionieren, die eigentliche Arbeit ist woanders. Warum einige Programmier-Fetischisten das nicht so stehen lassen können und immer etwas zu bemäkeln haben (vergleich bei MATLAB, dort wird die gleiche Diskussion über Skriptsprachen geführt) bleibt für mich ein Rätsel. Ich weiß nur, dass es mich tierisch nervt, dass jeder Informatiker ungefragt über die Vorteile von Lunix und JAVA schwadroniert; und weil dies noch nicht gereicht hat, suchen diese zunehmend die Öffentlichkeit (Wikipedia bietet hier leider eine sehr gute Plattform), um wirklich jedes weit verbreitete Programm pauschal zu kritisieren.

Bitte, lasst uns in Ruhe oder bleibt wenigstens objektiv, einige Menschen haben halt andere Präferenzen als ihr, auch wenn ihr nicht verstehen könnt, dass diese die von Euch so geliebten und verehrten Programme nicht so mögen.

Inhaltsverzeichnis 1 Inhalt von "Diskussion:LabView" hierher verschoben 2 LabView 8.20 3 Screenshots und Urheberrecht 4 Vor- und Nachteile

[Bearbeiten] Inhalt von "Diskussion:LabView" hierher verschoben

Ist es normal, dass es noch ein LabVIEW existiert?

Nein, normal ist das nicht. --Montauk 01:13, 28. Nov 2004 (CET)

Inhaltlich scheinen sich die beiden Artikel ganz gut zu ergänzen, wir sollten sie aber besser zu einem zusammenfassen. Ich bin dafür, das unter LabVIEW zu tun, da das die offizielle Schreibweise von National Instruments ist. (Abkürzung für "Laboratory Virtual Instrument Engineering Workbench"). --silmaril 13:22, 29. Nov 2004 (CET)

Ich habe die beiden Artikel nun unter LabVIEW zusammengeführt. Die Inhalte des Artikela LabView habe ich übernommen, ergänzt und einige Fehler korrigiert. --silmaril 14:36, 7. Dez 2004 (CET)

Verschoben durch: --SirJective 09:23, 21. Dez 2004 (CET)

[Bearbeiten] LabView 8.20

Ich finde es wäre wichtig zu ergänzen das ab LV8.2 Objekorientiertes programmieren möglich ist. Mit Klassen und Vererbung ein nicht unwesentlicher schritt für die Entwicklung diverser Anwendungen unter LV.--Mr.Sieb 14:44, 15. Aug 2006 (CEST)

Vorschlag: Am Ende des Absatzes "Programmiermethoden" folgendes anhängen

Bei sehr großen und umfangreichen Projekten ist es (wie in jeder Programmiersprache) extrem wichtig, von Anfang an eine durchdachte Struktur zu verwenden und den Code zu Modularisieren. Durch den vorhanden Projektmanager (ab V8.0) wird dies um einiges erleichtert. Die Verwaltung einer großen Anzahl an VI’s sowie externer Dateien ist dadurch um vieles übersichtlicher. Auch die major und minor Versionsverwaltung gestaltet sich hiermit wesentlich einfacher. Eine wesentliche Neuerung (ab V8.20) besteht darin Objektorientiert programmieren zu können. Klassen und Attribute sowie dessen Methoden können natürlich auch vererbt werden.

irgendwelche einwände ? --Mr.Sieb 13:14, 16. Aug 2006 (CEST)

offensichtlich nicht ... eintrag gemacht --Mr.Sieb 15:30, 17. Aug 2006 (CEST)

[Bearbeiten] Screenshots und Urheberrecht

Ich find's ja toll, dass wir jetzt ein paar Screenshots von LabVIEW im Artikel haben. Leider deckt sich das m.E. in keiner Weise mit Wikipedia:Bildrechte#Screenshots. Solange wir keine ausdrückliche Freigabe von National Instruments haben, müssen wir die Bilder wohl aus dem Artikel rausschmeißen.

Irgendwelche Gegenmeinungen?

Macht sich jemand die Arbeit, offiziell bei NI anzufragen? --silmaril 15:57, 28. Aug 2006 (CEST)

Ich werde dies tun, hab gute kontakte bei NI.--Mr.Sieb 15:21, 11. Sep 2006 (CEST)

Habe nicht vergessen, nur immer noch keine Antwort bekommen, werdmal nachhacken. --Mr.Sieb 19:59, 6. Dez. 2006 (CET)

Super, schonmal danke für die Mühe! Ich hoffe, Du bekommst eine sinnvolle Antwort. Leider befürchte ich, dass NI Germany nicht die Kompetenz besitzt, das zu entscheiden, und von den Amis eine sinnvolle Antwort zu Urheberrechtsthemen zu bekommen kann schwierig werden. --silmaril 13:47, 12. Dez. 2006 (CET)

Nachdem bis jetzt immer noch nichts bewegt hat, habe ich die Bilder mal rausgenommen. Wenn jemand Bilder mit NI's Einverständnis besorgen kann, wäre das natürlich super! So ganz grafik-frei sieht der Artikel schon enorm trocken aus :-( --silmaril 22:58, 13. Mär. 2007 (CET)

[Bearbeiten] Vor- und Nachteile

Wie weiter oben bereits ausgeführt, sind die unter "Nachteile" aufgeführten Punkte

a) entweder keine Nachteile

b) "Nachteile" bei falscher Bedienung (wobei nicht erklärt wird, wieso diese falsche Bedienung bei LabView wahrscheinlicher ist, als bei anderen Umgebungen)

c) oder Nachteile, welche jede Umgebung hat, jedoch bei LabView DEUTLICH geringer sind, als bei anderen Umgebungen (oder Sprachen). Der "Nachteil" an einer bestimmten Progammiersprache oder Entwicklungsumgebung ist jedoch nur ein solcher im Vergleich zu anderen Sprachen.

Der ganze Abschnitt, zumindest die "Nachteile", sollten neu geschrieben werden und sich dabei an den wirklichen Nachteilen im Vergleich zu Programmiersprachen orientieren. --217.224.26.160 09:21, 12. Dez. 2006 (CET)

Ja, da gebe ich Dir Recht. Jetzt brauchen wir nur noch jemanden, der sich die Zeit nimmt... (nein, ich komme in absehbarer Zeit nicht dazu.) --silmaril 13:44, 12. Dez. 2006 (CET)