優等プロジェクトの一環としてLabVIEWの使用方法を学んでいますが、グラフィックプログラミング言語にはテキストプログラミング言語よりも優れている点は何ですか?
7 に答える
私にとって、LabVIEW の利点は、グラフィック対テキストではありません。
それはデータフロー対命令です。
データフロー プログラミングは同時実行に適しています。実行は、入力が有効なときに実行されるブラック ボックスとしてモデル化され、入力と出力が相互に接続されているためです。これは、変更方法に関する指示のリストを含む暗黙的な状態とは対照的です。(「キペディア」を大まかに言い換えると、上記のリンク先の記事の方が優れています。)
各ブラック ボックスは個別のコア/プロセッサ/ノードで実行できるため、データフローの方法でプログラムを構成すると、事実上無料の同時実行性が得られます。
残念ながら (これは一般的にデータフロー プログラミングの致命的な欠点です)、データフロー プログラムを視覚化および編集する最良の方法は、テキストではなくグラフィカルです。これにより、リビジョン管理やコード ジェネレーターなどのツールの使用が非常に困難になります。
問題は、あなたとあなたのプロジェクトにとって、データフローの長所は短所を上回っていますか?
LabVIEWを使用したグラフィカルプログラミングの主な利点の1つは、ソースコードが回路図に非常に似ているため、電気/電子技術者が理解しやすい言語であるということです。これが、EEが豊富なデータ取得および自動化の分野でLabVIEWが非常に人気を博している理由の1つです。
私が見つけたもう1つの利点は、開発の生のスピードでした。Visual Studioで行う方法と非常によく似た、使用可能なフロントパネルコントロールのパレットからGUIを組み立てます。ソースコードも同様の方法で記述されており、メニューからドロップインして相互に接続できる多くの事前定義されたコンポーネントが含まれています。
3番目の利点は、ハードウェアとの互換性です。National Instrumentsの主な事業はデータ取得ハードウェアであり、すべての製品がそのままLabVIEWソフトウェアと通信できるようにするために多大な努力を払っています。データ取得および自動化制御業界の他の多くのハードウェアベンダーも同じことを行っています。
そのすべては、機器のドライバーとユーザーの機能に関するものです。NI (Labview) には、簡単にインターフェースできる、十分にサポートされた一連のラボ機器ドライバーがあります。テスト オペレーター (開発者ではない) には、大きな緑/赤の合格/不合格ボタンを備えた GUI が必要です。cygwin で python を介して複雑な自動化を実装しました。Labview の開発者は、cygwin/python システムを起動し、ログ ファイルをデータ マイニングすることができました。したがって、両方を行うことができます。Python システムは、移植可能で、保守可能で、拡張可能で、使用可能であり、何よりも無料です。
以前、nMRI マシンを調整するためのパラメータを計算するために labview を使用しました。それらが存在するのは、理論的には、プログラミング言語の経験がほとんどない人がプログラムを作成する方が簡単だからです。制御フローと意思決定構造はグラフィカルに配置でき、必要な場所に数式を入力できます。
教授や研究室の助手の場合...役に立ちます。本当のソフトウェア開発者にとっては、別の言語で書く方が簡単でしょう。
過去に LabView を使用したことがありますが、データ取得、仮想計測などにこれ以上のものはありません。最後に使用したのは 10 年前で、それ以来 90 年代半ばの状態に匹敵するものはありません。
私の見解では、LabVIEW のいくつかの利点は次のとおりです。
ボタンやグラフなどの組み込みのユーザー インターフェイス コンポーネントは、文字通りプログラミングを一切必要としません。それらをフロント パネルに配置するだけで、データ端子がブロック ダイアグラムに表示されます。
データ取得ハードウェアおよびテスト機器用のドライバの大規模なライブラリがあります。あなたの仕事が基本的にこれらとの間でデータを取得し、それにユーザーインターフェイスを配置することである場合、ほとんどプログラミングをせずにそれを達成できます。
複数のタスクの並列実行は自動的に処理されます。ダイアグラムに 2 つの独立したループを配置すると、それらが同時に実行されます。これは、多くの場合、データ取得および制御アプリケーションの要件です。
「実際のソフトウェア開発者」を含む多くの人々は、グラフィック パラダイムが自分の考え方に合っていると感じており、テキスト パラダイムよりもソフトウェアを視覚化するのに適しています。テキスト言語がLabVIEWよりも優れていることは間違いありませんが(このサイトの別のディスカッションで説明されています)、LabVIEWが適している場合は、作業を完了するのに非常に優れています.
テキストベースの言語に慣れている場合は、Labview が別の学習曲線を導入するだけであることに気付くでしょう。Labview を学習して使用するという具体的な目標がない限り、あなたのプロジェクトには何の意味もありません。
一方、テキストベースの言語に特に慣れていない場合は、特にソフトウェア エンジニアではない人にとっては、Labview のほうが習得しやすく、習得しやすいという意見を持つ傾向があります。
私は、Labview や TestStand だけでなく、テスト エンジニアリングにもテキスト ベースの言語を頻繁に使用しています。一部の企業には、Labview のトレーニングを受けた個人が何人かいますが、テキストベースの言語で書くことを好む企業もあります。別の言語のトレーニングは、全社規模で非常にコストがかかる可能性があり、企業内のポジションの採用要件が変わるため、一部の企業は事実上、1 つのパラダイムまたは別のパラダイムに「ロックイン」されています。業界で働くつもりなら、両方に精通していることが最善の策だと思います。そうすれば、柔軟性があります。もしそうで、どちらかを学ぶ時間があれば、一番苦手な分野で働き、知識の幅を広げる、それが学校ですよね?