テキストプログラミング言語とグラフィカルプログラミング言語

https://stackoverflow.com/questions/13678

08-06-2019
|

質問

私は高校のロボット工学チームの一員ですが、ロボットのプログラミングにどの言語を使用するかについて議論があります。C (または C++) と LabVIEW のどちらかを選択しています。それぞれの言語に長所があります。

C(++):

広く使われています
将来に向けた適切な準備 (ほとんどのプログラミング職にはテキストベースのプログラマーが必要です)。
昨年の C コードベースを拡張できます
ロボットが何をしているのかをよりよく理解できるようになります。

LabVIEW

プログラムフローの視覚化が容易になります (コード行ではなくブロックとワイヤー)
教えやすくなる（おそらく...）
「プログラミングの未来はグラフィックです。」（そう思う？）
一部の新メンバーが持つ可能性のあるロボラボの背景に迫ります。
何が起こっているのかを詳しく知る必要はありません。赤いボールを見つけるようにモジュールに指示するだけで、方法を知る必要はありません。

これは私たちにとって非常に難しい決断であり、しばらくの間議論してきました。各言語の専門家とあなたの経験に基づいて、 より良い選択肢は何だと思いますか？ 必ずしも純粋な効率性を追求しているわけではないことに留意してください。また、プログラマーが将来のプログラミングに向けて準備できるようにしたいと考えています。

また：

LabVEIW のようなグラフィカル言語はプログラミングの未来だと思いますか?
グラフィック言語はテキスト言語よりも学習しやすいですか? それらは学ぶのが同じくらい難しいものであるべきだと思います。
私たちが部分的に人々の学習を支援することに根ざしていることを考えると、 事前に作成されたモジュールにどの程度依存すべきでしょうか。また、どの程度を自分で作成しようとする必要がありますか? (「優れたプログラマーは優れたコードを書き、優れたプログラマーは優れたコードをコピーする。」しかし、まず優れたプログラマーになる価値があるのではないでしょうか?)

アドバイスありがとうございます！

編集：この質問をさらに強調したいと思います。チームキャプテンは、学習と指導のしやすさの点で LabVIEW の方が優れていると考えています。 本当？ C も同様に簡単に教えることができ、初級レベルのタスクは C で引き続き使用できると思います。ぜひ皆さんのご意見をお聞きしたいです。 while の入力が「while ボックス」の作成より難しい理由はありますか?{} プログラムが 1 行ずつ流れ、if とループによってのみ変更されることは、プログラムがワイヤーを介して流れ、if とループによってのみ変更されることが直感的であるのと同じくらい直感的ではないでしょうか?

再度、感謝します！

編集：これは「言語討論」のトピックに該当することに気付きました。特定の目標を持って、プログラミングの特定のブランチに最適なものだからです。そうでない場合は...ごめんなさい...

解決

私が到着する前、私たちのグループ（プログラミングの経験がほとんどない博士課程の科学者）は、1 年近くにわたって断続的に LabVIEW アプリケーションの実装を試みていました。コードは乱雑で、（フロントエンドとバックエンドが）複雑すぎ、そして最も重要なことに、機能しませんでした。私は熱心なプログラマーですが、LabVIEW を使用したことがありませんでした。私が知っていたテキストプログラミングパラダイムをLabVIEWの概念に翻訳するのを手伝ってくれるLabVIEWの第一人者の少しの助けにより、1週間でアプリをコーディングすることができました。ここでのポイントは、 基本的なコーディングの概念はまだ学ぶ必要があり、LabVIEW のような言語であっても、それを表現する別の方法にすぎません。.

LabVIEW は、本来の目的で使用するのに最適です。つまりDAQ カードからデータを取得し、おそらくいくつかの小さな操作を間に挟んで画面上に表示します。ただし、プログラミングは、 アルゴリズム それは決して簡単なことではなく、もっと難しいことだとさえ思います。たとえば、ほとんどの手続き型言語では、実行順序は通常、疑似数学的表記法 (つまり、 y = x*x + x + 1）一方、LabVIEWは、必ずしも相互に従うわけではない一連のVIを使用してこれを実装します（つまり、左から右) キャンバス上で。

さらに、キャリアとしてのプログラミングは、コーディングの専門性を知るだけではありません。効果的に助けを求めたり答えを検索したり、読みやすいコードを書いたり、レガシーコードを操作したりすることはすべて重要なスキルですが、LabVIEW などのグラフィカル言語では間違いなくより困難です。

グラフィカルプログラミングのいくつかの側面が主流になる可能性があると私は信じています。サブVIの使用はプログラミングの「ブラックボックス」原則を完全に具体化しており、次のような他の言語の抽象化でも使用されています。ヤフーパイプそしてApple Automator - そしておそらく将来のグラフィック言語は私たちのプログラミング方法に革命を起こすでしょうが、LabVIEW自体は言語設計における大きなパラダイムシフトではありません。 while, for, if フロー制御、タイプキャスト、イベント駆動型プログラミング、さらにはオブジェクト。もし未来が本当にLabVIEWで書かれるようになったら、C++プログラマはそれほど苦労せずにクロスオーバーできるでしょう。

追記として、学生は間違いなくいつかは組み込みシステムや FPGA を扱うことになるため、ロボット工学には C/C++ の方が適していると言えます。この種のことを行うには、低レベルのプログラミング知識 (ビット、レジスタなど) が非常に貴重です。

@メンディカント 実際、LabVIEWは産業界、特に制御システムでよく使用されています。NASA がそれを衛星搭載システムに使用する可能性は低いのは確かですが、宇宙システム用のソフトウェア開発は重要です。まったく異なるボールゲーム...

他のヒント

私が現在所属している研究グループでも、似たような状況に遭遇したことがあります。これは生物物理学のグループで、機器を制御するためにあらゆる場所で LabVIEW を使用しています。それは本当にうまくいきます:計測器のあらゆる側面を制御したり、ステータスを表示したり、データを保存したりするための UI を簡単に組み立てることができます。

そして今、5ページにわたる暴言を書くのをやめなければなりません。なぜなら、私にとってLabVIEWは悪夢だったからです。代わりに、いくつかの長所と短所を要約してみましょう。

免責事項 私はLabVIEWの専門家ではないので、偏見のあること、時代遅れのこと、または単純に間違っていることを言うかもしれません:)

LabVIEW のプロ

はい、それは 簡単に学べる. 。私たちのグループの多くの博士号取得者は、数週間以内、あるいはそれ以下でハッキングするのに十分なスキルを習得しているようです。
図書館. 。これは大きなポイントです。これについては、自分の状況に合わせて慎重に調査する必要があります(何が必要なのか、それに適したLabVIEWライブラリがあるのか、あるいは他の言語に代替手段があるのかはわかりません)。私の場合、例えば Python で優れた高速グラフ作成ライブラリを見つけることが大きな問題となっており、そのためプログラムの一部を Python で書き直すことができませんでした。
学校ではすでにインストールされ、実行されている可能性があります。

LabVIEWの短所

それはおそらく あまりにも 簡単に学べる。いずれにせよ、わざわざベストプラクティスを学ぼうとする人はいないようで、プログラムはすぐに完全に取り返しのつかない混乱になってしまいます。確かに、注意しないとテキストベースの言語でもこのようなことが起こる可能性がありますが、私の意見では、LabVIEW で物事を正しく行うことははるかに困難です。
ある傾向があります LabVIEWのサブVIの検索に関する重大な問題 (バージョン 8.2 までだったと思います)。LabVIEWには、ライブラリとサブVIの場所を知る独自の方法があり、ソフトウェアを完全に破壊することが非常に簡単になります。このため、これを処理する方法を知っている人が周りにいない場合、大規模なプロジェクトは困難になります。
LabVIEWをバージョン管理で動作させるのは面倒です. 。確かにそれは可能ですが、いずれにせよ、私は内蔵 VC の使用を控えたいと思います。チェックアウト LVDiff LabVIEW の差分ツールの場合は、マージについてさえ考えないでください。

(最後の 2 つの点により、チームで 1 つのプロジェクトに取り組むことが困難になります。それはおそらくあなたの場合重要です）

これは個人的なものですが、多くのアルゴリズムは視覚的にプログラムすると機能しないことがわかりました。 めちゃくちゃだ.
- 一例としては、厳密にシーケンシャルなものがあります。それはすぐに面倒になります。
- コードの概要を把握するのは困難です。
- 小さなタスクにサブVIを使用する場合(小さなタスクを実行し、1つの画面に収まる関数を作成するのが良い習慣と同じように)、名前を付けるだけではなく、それぞれにアイコンを描画する必要があります。そのうちの。それはほんの数分以内に非常に煩わしく面倒になるため、非常に誘惑されます。ないサブVIに内容を配置します。それはあまりにも面倒です。ところで:本当に優れたアイコンを作成するには、専門的に何時間もかかることがあります。作成するサブ VI ごとに、すぐに理解でき、認識できるユニークなアイコンを作成してみてください:)
1週間以内に手根管ができます。保証されています。
@ブレンダン:聞いて聞いて！

結論

「独自のモジュールを作成すべきか」という質問については、次のようになります。よくわからない。時間の制約によって異なります。必要がないのであれば、車輪の再発明に時間を費やす必要はありません。低レベルのコードを書くのに何日も費やしてから、時間がなくなったことに気づくのは簡単です。それがLabVIEWを選択することを意味する場合は、それを選択してください。

LabVIEW と C++ などを組み合わせる簡単な方法があれば、ぜひお聞きしたいです。そうすれば両方の長所が得られるかもしれませんが、そんなものがあるとは思えません。

ただし、あなたとあなたのチームがベストプラクティスを学ぶことに時間を費やすようにしてください。お互いのコードを見てみます。お互いから学び合う。使いやすく、わかりやすいコードを書く。そして楽しんでください！

尖っていて、おそらく多少衒学的に聞こえることをお許しください。LabVIEW が本物私にとっては悪夢です:)

LabVIEWを選択するかどうかは、市場価値のあるスキルとして一般的に使用される言語でプログラミングを学びたいか、それとも単に何かをやり遂げたいかによって決まると思います。LabVIEWを使用すると、非常に迅速かつ生産的に作業を完了できます。他の人が述べているように、自分が何をしているのかを理解する必要から魔法のように解放されるわけではありません。理解しないとひどい混乱が生じる可能性が十分にあります。逸話ではありますが、LabVIEW の悪いコーディングスタイルの最悪の例は次のとおりです。一般に、テキスト言語の経験がありながら、「プログラミングの仕方はもう知っている、くそー!」という理由でLabVIEWの動作に適応することを拒否する人々によって行われます。

もちろん、LabVIEWプログラミングが市場価値のあるスキルではないという意味ではありません。C++ ほど大衆市場ではないというだけです。

LabVIEWを使用すると、ロボット制御の状況でよくある、並行して進行するさまざまな処理を非常に簡単に管理できます。シーケンシャルであるべきコード内の競合状態も問題にはならないはずです（つまり、もしそうなら、それは間違っています):必要に応じて正しい順序で処理を実行するための簡単なテクニックがあります。エラーワイヤやその他のデータを使用してサブVIを連鎖させたり、ノーティファイアやキューを使用したり、ステートマシン構造を構築したり、必要に応じてLabVIEWのシーケンス構造を使用したりすることもできます。繰り返しますが、これは、LabVIEW で利用できるツールとその仕組みを理解するために時間をかけて行っているだけです。サブ VI アイコンを作成しなければならないという不満は、あまり適切に表現されているとは思えません。数単語のテキストを含むテキスト (背景色付き) を非常に簡単に作成でき、ほとんどの目的に適しています。

「グラフィック言語は未来のあり方か？」というのは、誤った二分法に基づく危険な話です。グラフィカル言語に適したものもあります (並列コードなど)。他のものはテキスト言語にはるかに適しています。LabVIEWとグラフィカルプログラミングが消滅したり、世界を席巻したりすることはないと思います。

ちなみに、NASAだったら非常に驚くでしょう。 しませんでした 宇宙プログラムでLabVIEWを使用します。最近、ある人が Info-LabVIEW メーリングリストで、LabVIEW を使用してボーイング 787 の電気モーターによって駆動される飛行面の閉ループ制御を開発およびテストした方法について説明し、飛行機の開発に LabVIEW が広範囲に使用されているという印象を与えました。リアルタイム制御にも使用されます。大型ハドロン衝突型加速器！

National Instruments 独自のサイトやフォーラム以外で、LabVIEW に関する詳細情報やヘルプを得るために現在最も活発な場所は次のとおりです。溶岩.

これは質問に直接答えるものではありませんが、インタープリタ言語を混合するという 3 番目のオプションを検討することをお勧めします。ルア, たとえば、すでに使用済みロボット分野で。高速かつ軽量で、ほとんどのマイクロコントローラーには FPU がないため、浮動小数点数の代わりに固定小数点数で実行するように構成できます。前方へは、同様の使用法を使用する別の代替手段です。

C で薄いインターフェイス層を作成し、学生に解釈されたスクリプトを自由に使用させるのは非常に簡単です。チップの再コンパイルやフラッシュを行わずにコードを動的にロードできるように設定することもできます。これにより、反復サイクルが短縮され、生徒は結果をより早く確認できるため、より良く学習できるようになります。

私は偏見を持っています に対して LabVIEWなどのビジュアルツールを使用します。私はいつも、自分が望むように動作しない、または動作しないものに遭遇するようです。したがって、私はテキストコードで得られる絶対的な制御を好みます。

LabVIEWの（ライブラリ以外の）もう一つの強みは次のとおりです。 同時実行性. 。それはデータフロー言語, これは、ランタイムが同時実行を処理できることを意味します。したがって、高度な同時実行を行っていて、従来の同期を実行したくない場合は、LabVIEW が役立ちます。

未来は、現在のようなグラフィック言語に属しません。それは、グラフィカルなアプローチと同じくらい簡単でありながら、プログラマー自身のツールによって解析可能なデータフロー (または別の同時実行に適したタイプのプログラミング) の表現を思いつくことができる人のものです。

National Instruments が主催する、このトピックに関する研究結果が公開されています。

グラフィカル vs. の研究DSP を教えるためのテキストプログラミング

特に、LabVIEW と MATLAB (C ではなく) について考察します。

グラフィカル言語は、テキスト言語に比べて表現力が常に制限されると思います。視覚的なシンボル (REBUS や手話など) でコミュニケーションしようとすることと、言葉を使ってコミュニケーションすることを比較してください。

単純なタスクの場合は、通常、グラフィカル言語を使用する方が簡単ですが、より複雑なロジックの場合は、グラフィカル言語が邪魔になることがわかります。

ただし、この議論に含まれるもう 1 つの議論は、宣言型プログラミングと必須の。通常、何かの実行方法を詳細に制御する必要がない場合には、宣言型の方が適しています。あなた できる C++ を宣言型で使用しますが、そのためには事前にさらに多くの作業が必要になりますが、LABView は宣言型言語として設計されています。

百聞は一見に如かずですが、もし百の言葉が百の言葉に匹敵し、それがあなたにとって必要のないものであり、それを変えることができないのであれば、その場合、絵には価値がありません。一方、言葉を使って何千もの画像を作成し、あらゆる詳細を指定したり、見る人の焦点を明示的に誘導したりすることもできます。

LabVIEWを使用すると、すぐに使い始めることができ、（他の人がすでに述べているように）さまざまなテスト、測定、制御関連の作業を行うためのコードの膨大なライブラリが含まれています。

ただし、LabVIEW の最大の欠点は、プログラマが自分で作成したツールがすべて失われることです。

コードは VI として保存されます。これらは不透明なバイナリファイルです。これは、コードが実際にはあなたのものではなく、LabVIEWのものであることを意味します。独自のパーサーを作成したり、コードジェネレーターを作成したり、マクロやスクリプトを介して自動変更を行うことはできません。

これ最悪 5000 VI アプリを使用しており、全体的に小さな調整を適用する必要がある場合。あなたののみオプションは、すべての VI を手動で実行することです。どこかの隅で 1 つの VI の変更を見逃した場合は、天が助けてくれます。

そしてはい、バイナリなので、テキスト言語のように diff/merge/patch を行うことはできません。これにより、複数のバージョンのコードを扱うことは、保守性にとって恐ろしい悪夢になります。

何か単純なことを行っている場合、プロトタイプを作成する必要がある場合、またはコードをメンテナンスする予定がない場合は、ぜひ LabVIEW を使用してください。

実際の保守可能なプログラミングを実行したい場合は、テキスト言語を使用してください。始めは遅くなるかもしれませんが、長期的には速くなります。

(ああ、DAQ ライブラリが必要な場合は、NI にはそれらの C++ および .Net バージョンも用意されています。)

私の最初の投稿はここです:) 優しくしてください...

私は自動車業界の出身で、現在は防衛業界にいます。経験から言えますが、C/C++ と LabVIEW は、異なる目的を念頭に置いたまったく別の生き物です。C/C++ はコンパクトでコンパイラ/ツールが簡単に入手できるため、マイクロコントローラーの組み込み作業には常に使用されていました。一方、LabVIEWはテストシステムの駆動に使用されました（シーケンサとしてのテストスタンドとともに）。私たちが使用したテスト機器のほとんどはNI製でした。そのため、LabVIEWは、作業に必要なツールとドライバ、そして私たちが望んでいたサポートを備えた環境を提供してくれました。

学習のしやすさという点では、C/C++ に関するリソースがたくさんあり、設計上の考慮事項やアルゴリズムの例を掲載している Web サイトも数多くあり、自由に利用できます。LabVIEWの場合、ユーザーコミュニティはおそらくC/C++ほど多様ではなく、サンプルコードを検査して比較するにはもう少し労力がかかります（LabVIEWの適切なバージョンが必要など）...LabVIEWは習得して習得するのが非常に簡単であることがわかりましたが、ここで何人かが言及しているように、並列処理やその他のさまざまな事柄に関連して、それらに気づく前に少しの経験を必要とする厄介な問題があります。

それで、結局のところ、結論は何ですか？どちらの言語も学ぶ価値があると言えます。なぜなら、これらは実際に 2 つの異なるプログラミングスタイルを表しており、両方を認識して習熟することには確かに価値があるからです。

なんと、答えはとても簡単です。使用 LabView.

私は 10 年間組み込みシステムをプログラミングしてきましたが、少なくとも 2 か月間はインフラストラクチャ (非常に慎重なインフラストラクチャ!) がなければ、初日のような生産性は得られないと言えます。 LabView.

販売および軍事用に使用されるロボットを設計している場合は、C から始めてください。これは良い判断です。

それ以外の場合は、短時間で最も多くの種類を試すことができるシステムを使用してください。それは LabView.

グラフィック言語は未来の言語になるかもしれないと私は考えています。アドホックな MS Access 開発者全員のために。純粋にテキストを作成するプログラマーのための場所は常に存在します。

個人的には、ロボットを作ることがすべて自分でできるとしたら、その本当の楽しさは何なのかを尋ねなければなりません。そこに「赤いボールを見つける」モジュールをドロップして、それが進むのを見ていただけでしょうか?あなたは自分の達成に対してどのような誇りを感じますか?個人的には、あまり持っていないでしょう。さらに、コーディングについて、あるいはロボット工学において重要なソフトウェア/ハードウェアインターフェイスの (非常に重要な) 側面について、何を学ぶことができるでしょうか?

私はこの分野の専門家であるとは主張しませんが、次のことを自問してください。NASA は火星探査機のコーディングに LabVIEW を使用したと思いますか?ロボット工学で本当に著名な人が LabView を使用していると思いますか?

実際のところ、私に言わせれば、LabVIEW のようなクッキーを使ってこれを構築することで準備できるのは、裏庭のロボットビルダーになることだけであり、それ以上のものはありません。業界経験に近いものが必要な場合は、独自の「LabVIEW」タイプのシステムを構築してください。独自のボールを見つけるモジュール、または独自の「フォロー・ザ・ライン」モジュールを構築します。それははるかに困難になりますが、よりクールでもあります。:D

LabVIEWが大好きです。特に他の記憶者が同様のものを使用している場合は、それを強くお勧めします。通常のプログラマがそれに慣れるまでには時間がかかりますが、すでにプログラミング方法を知っている場合は、結果ははるかに優れています。

C/C++ は独自のメモリを管理することに相当します。記憶のリンクを泳ぎながら、それについて心配することになるでしょう。LabVIEW を使用する場合は、LabVIEW に付属のドキュメントを必ず読み、競合状態に注意してください。

言語を学ぶのは簡単です。プログラミングを学ぶことはそうではありません。これはグラフィカル言語であっても変わりません。グラフィカル言語の利点は、コードをじっと座って大量のテキストを解読するよりも、コードが何を行うかを視覚化する方が簡単であることです。

重要なのは言語ではなく、プログラミングの概念です。少し努力すれば、どんな言語でも上手にプログラミングできるようになるはずなので、どの言語でプログラミングを学ぶかは問題ではありません。言語は現れては消えていきます。

免責事項:私は LabVIEW を目撃したことはありませんが、WebMethods Flow や Modeller、大学の動的シミュレーション言語、そして MIT の Scratch など、他のいくつかのグラフィカル言語を使用したことがあります :)。

私の経験では、グラフィカル言語はプログラミングの「配管」部分ではうまく機能しますが、私が使用した言語はアルゴリズムの邪魔をすることが多かったです。アルゴリズムが非常に単純であれば、それで問題ないかもしれません。

一方で、C++ があなたの状況に適しているとも思えません。有益な作業に費やすよりも、ポインタとメモリ管理の問題を追跡することに多くの時間を費やすことになります。

スクリプト言語 (Python、Ruby、Perl など) を使用してロボットを制御できる場合は、それがより良い選択になると思います。

次に、ハイブリッドオプションがあります。

ロボットにスクリプトオプションがなく、チームに C++ マニアがいる場合は、そのマニアに C++ ライブラリをスクリプト言語にマップするバインディングを作成させることを検討してください。これにより、他の専門分野を持つ人でもロボットをより簡単にプログラミングできるようになります。このバインディングはコミュニティへの良い贈り物になるでしょう。

LabVIEWで許可されている場合は、そのグラフィカル言語を使用して、テキスト言語で書かれたモジュールを組み立てます。

あなたは高校生です。このプログラムにどれくらいの時間がかかりますか?あなたのグループには何人いますか?彼らは C++ や LabView をすでに知っていますか?

あなたの質問から、あなたは C++ を知っていますが、グループのほとんどは C++ を知らないことがわかります。また、グループリーダーは、チームの一部のメンバーがテキストベースのプログラミング言語に怯えている可能性があることに気づくほどの洞察力を持っているのではないかとも思います。これは許容範囲です、あなたは高校生です、そしてこれらの人々は規範. 。普通の高校生ならC++よりもLabViewの方が直感的に理解できる気がします。おそらく高校生の多くは、一般の人々と同様、コマンドラインを怖がっていると思います。あなたにとっては違いははるかに少ないですが、彼らにとっては昼と夜です。

同じ概念が C++ として LabView に適用される可能性があるということは正しいことです。それぞれに長所と短所があります。重要なのは、作業に適したツールを選択することです。以前の LabView この種の用途のために設計された. 。C++ はより汎用的で、他の多くの種類の問題に適用できます。

LabView をお勧めします。適切なハードウェアがあれば、ほぼ箱から出してすぐに稼働できます。チームはより多くの時間を費やすことができます ロボットに自分のやりたいことをやらせる, 、これがこの活動の焦点となるべきものです。

グラフィカル言語はプログラミングの未来ではありません。これらは、長年にわたって、特定の種類の問題を解決するために作成された、利用可能な選択肢の 1 つでした。プログラミングの未来は、マシンコードから離れた抽象化の層の上にあります。将来的には、なぜ「セマンティクス」のプログラミングを何度も繰り返して時間を無駄にしたのかと疑問に思うことになるでしょう。

事前に作成されたモジュールにどの程度依存すべきでしょうか。また、どの程度を自分で作成しようとする必要がありますか?車輪の再発明に時間を無駄にするべきではありません。Labview で利用可能なデバイスドライバーがある場合は、それを使用します。機能が似ているコードをコピーして自分のニーズに合わせて調整することで、多くのことを学ぶことができます。他の人が同様の問題をどのように解決したかを見ることができ、自分の問題に適切に適用する前に、その解決策を解釈する必要があります。やみくもにコードをコピーしても、それが機能する可能性はほとんどありません。コードをコピーする場合でも、上手でなければなりません。

幸運を祈ります！

LabVIEWを使用すると、ロボットのやりたいことをより速く簡単に作成できるため、LabVIEWを使用することをお勧めします。LabVIEWはこの考えに基づいて設計されています。もちろん C(++) は優れた言語ですが、LabVIEW は他の言語よりも優れた機能を備えています。LabVIEWは十分な範囲とサポートを提供するため、LabVIEWで本当に優れたソフトウェアを作成できます。

LabVIEW をアプリケーションに使用する際に、大きなマイナス点が 1 つあります。設計の複雑さを整理します。物理学者として、Labview はプロトタイピング、機器制御、数学的分析に最適であると感じています。LabVIEW よりも速く、より良い結果が得られる言語はありません。私は 1997 年から LabView を使用しています。2005 年以来、設計と保守が容易な .NET フレームワークに完全に切り替えました。

LabVIEWでは、単純な「if」構造を描画する必要があり、グラフィックデザイン上で多くのスペースを使用します。商用アプリケーションの多くは保守が難しいことがわかりました。アプリケーションが複雑になればなるほど、読むのが難しくなります。

今ではテキスト言語を使用しているので、すべてを維持するのがはるかにうまくなりました。C++ と LabVIEW を比較する場合、私は LabVIEW を使用しますが、C# と比較すると、LabVIEW は勝りません。

いつものことですが、それは状況によります。

私は約 20 年前から LabVIEW を使用しており、単純な DAQ から非常に複雑な視覚化、デバイス制御からテストシーケンサまで、非常に幅広い種類の仕事を行ってきました。もしそれが十分に良くなかったら、私は間違いなく乗り換えていたでしょう。とはいえ、私はパンチカードを使用して Fortran のコーディングを開始し、Z80 ベースのものから始めて、8 ビット「マシン」上で多くのプログラミング言語を使用しました。言語はアセンブラーから BASIC、Turbo-Pascal から C まで多岐にわたりました。

LabVIEWは、データ収集と解析のための広範なライブラリを備えているため、大幅に改善されました。ただし、別のパラダイムを学ばなければなりません。そして必ずトラックボールが必要です ;-))

私は LabView については何も知りません (または C/C++ についてはあまり詳しくありません)。

LabVEIW のようなグラフィカル言語はプログラミングの未来だと思いますか?

いいえ...

グラフィック言語はテキスト言語よりも学習しやすいですか?それらは学ぶのが同じくらい難しいものであるべきだと思います。

学びやすくなりますか？いや、でも彼らはは説明と理解が容易になります。

プログラミング言語を説明するには、変数とは何かを説明する必要があります (これは驚くほど難しいです)。これは、LEGO Mindstroms プログラミングインターフェイスや Quartz Composer などのフローグラフ/ノードコーディングツールの問題ではありません。

例えば、これはかなり複雑な LEGO Mindstroms プログラムです - 何が起こっているかを理解するのは非常に簡単です...しかし、ロボットに実行させたい場合はどうなるでしょうか。 INCREASEJITTER 5 回ブロックし、10 秒間前進してから、INCREASEJITTER ループをもう一度試しますか?物事はすぐに混乱し始めます。

Quartz Composer はその好例であり、グラフィカル言語が「未来」になるとは私が思わない理由です。

これにより、非常にクールなもの (Web カメラからのピクセルの平均輝度によって制御されるカメラを使用した 3D パーティクルエフェクト) を非常に簡単に作成できます。しかし、XML ファイルの要素を反復処理したり、平均ピクセル値をファイルに保存したりするなど、簡単なことを行うのは非常に困難です。

私たちが部分的に人々の学習を支援することに根ざしていることを考えると、事前に作成されたモジュールにどの程度依存する必要があり、どの程度を自分で作成するように努めるべきでしょうか?(「優れたプログラマーは優れたコードを書き、優れたプログラマーは優れたコードをコピーする。」しかし、まず優れたプログラマーになる価値があるのではないでしょうか?)

学習する場合、グラフィック言語を説明することも理解することもはるかに簡単です。

そうは言っても、私は進歩として特化したテキストベースの言語をお勧めします。たとえば、グラフィックスの場合は次のようになります処理またはノードボックス. 。これらは「通常の」言語 (Processing は Java、NodeBox は Python) であり、非常に特殊化された使いやすい (しかし途方もなく強力な) フレームワークが組み込まれています。

重要なのは、これらは非常にインタラクティブな言語であり、画面上に円を表示するためだけに何百行も書く必要がないということです。ただ入力するだけです oval(100, 200, 10, 10) 実行ボタンを押すと表示されます。これにより、実演や説明も非常に簡単になります。

もっとロボット関連で、LOGO のようなものでも入門には最適です。「FORWARD 1」と入力すると、カメが 1 箱前に進みます。「LEFT 90」と入力すると 90 度回転します。これは非常に単純に現実に関係しています。各命令が何を行うかを視覚化し、それを試して実際にそのように機能することを確認できます。

光り輝くものを見せてあげると、途中で C から学ぶ役に立つ内容を拾い上げます。もし興味を持ったり、「本物の」言語が必要になるところまで進んでいるのであれば、彼らはその知識をすべて持っているでしょう。構文エラーが発生し、コンパイルが困難になります。

将来のプログラミングに向けてチームを準備しようとしているのであれば、C(++) を使用する方が良い方法だと思われます。ビジュアルな構成要素を使用して構築される一般的なプログラミング言語の期待は、これまで実現したことがないようで、私は実現するのだろうかと疑問に思い始めています。特定の問題領域に対しては実行できますが、多くの一般的な問題を解決しようとすると、テキストベースのプログラミング言語に勝つのは難しいようです。

かつて、私は実行可能 UML のアイデアにある程度同意していましたが、オブジェクトの関係や一部のプロセスフローを乗り越えると、UML はアプリを構築するのに非常に悲惨な方法になるようです。それをすべて GUI に接続しようとしているところを想像してみてください。間違っていると証明されても構わないが、今のところ、近いうちにポイント・アンド・クリックによるプログラミングができるようになる可能性は低いと思われる。

私は約 2 年前に LabVIEW を使い始めて、今では常に使用しているので偏見があるかもしれませんが、データの収集と制御が関係するアプリケーションには理想的であると考えています。

当社では主に、連続測定を行ったり、ガスバルブやATEエンクロージャを制御したりするテストにLabVIEWを使用しています。これには、デジタルとアナログの両方の入出力が含まれ、信号分析ルーチンとプロセス制御はすべて GUI から実行されます。各部分をサブVIに分割することで、マウスのクリックとドラッグでテストを再構成できます。

C/C++ とまったく同じではありませんが、Visual BASIC を使用した同様の測定、制御、分析の実装は、比較すると複雑で保守が難しいように見えます。

私は、実際のコーディング言語よりもプログラミングのプロセスの方が重要であり、グラフィカルプログラミング言語のスタイルガイドラインに従うべきだと考えています。LabVIEWブロックダイアグラムはデータの流れを示します(データフロープログラミング）そのため、問題が発生したことはありませんが、潜在的な競合状態を簡単に確認できるはずです。C コードベースがある場合は、それを DLL にビルドすると、LabVIEW がそれを直接呼び出すことができるようになります。

どちらの選択にも間違いなくメリットがあります。ただし、あなたのドメインは教育的な経験であるため、C/C++ ソリューションが学生にとって最も有益であると思います。グラフィカルプログラミングは常にオプションですが、低レベルのプログラミングではテキストプログラミングよりも効率的に使用できるような洗練された方法での機能が提供されません。これは悪いことではありません。抽象化の要点は、問題領域の新しい理解と見方を可能にすることです。しかし、多くの人がグラフィカルプログラミングに失望するかもしれないと私が考える理由は、どのプログラムであっても、C 言語でのプログラミングからグラフィカルプログラミングへの移行による増分効果は、アセンブリから C への移行とほぼ同じではないからです。

グラフィカルプログラミングの知識は、将来のプログラマーにとって確実に役に立ちます。おそらく将来的には、グラフィカルプログラミングの知識だけを必要とする機会があり、おそらく学生の中には、グラフィカルプログラミングの初期の経験から恩恵を受ける人もいるでしょう。一方で、テキストによるアプローチによって得られる基本的なプログラミング概念の強固な基盤は有益です。全てあなたの生徒の意見を聞いたので、間違いなくそれがより良い答えに違いありません。

チームキャプテンは、LabViewは学習と教育のしやすさの方が良いと考えています。本当？

それが単一の言語やパラダイムに当てはまるとは思えません。LabView は、電子工学のバックグラウンドを持つ人にとっては確かに簡単かもしれません。その中でプログラムを作成することは、「単に」ワイヤーを引くことです。繰り返しになりますが、そのような人々はすでにプログラミングに触れている可能性もあります。

グラフィック以外の重要な違いの 1 つは、LV がデマンドベース (フロー) プログラミングであることです。結果から始めて、そこに到達するために何が必要かを伝えます。従来のプログラミングは命令的である傾向があります (その逆)。

言語によっては両方を提供できるものもあります。最近、Lua 用のマルチスレッドライブラリ (Lanes) を作成しました。これは、命令型の環境でデマンドベースのプログラミングに使用できます。主に Lua で実行され、成功しているロボットがあることは知っています (クレイジー・イワンルアオーシックスにて）。

Microsoft Robotics Studio をご覧になったことがありますか?http://msdn.microsoft.com/en-us/robotics/default.aspx

ビジュアルプログラミング (VPL) が可能になります。http://msdn.microsoft.com/en-us/library/bb483047.aspxC# などの最新言語も同様です。少なくともチュートリアルを参照することをお勧めします。

Labview (およびこの点での Matlab) に対する私の不満は、コードを x86 以外に埋め込むことを計画している場合 (Labview には Labview VI を ARM に配置するツールがある)、問題に対して同じだけ多くの処理能力を投入する必要があることです。非効率なのでできる限り。

Labview は優れたプロトタイピングツールです。ライブラリがたくさんあり、ブロックを組み合わせるのは簡単ですが、高度なアルゴリズムを実行するのは少し難しいかもしれませんが、おそらくやりたいことのためのブロックがあるでしょう。機能を素早く実行できます。しかし、その VI をそのままデバイスに配置できると考えているなら、それは間違いです。たとえば、Labview で加算器ブロックを作成すると、2 つの入力と 1 つの出力が得られます。その場合のメモリ使用量はどのくらいでしょうか?3 つの変数に相当するデータ?二？C または C++ では次のように書くことができるため、ご存知のとおりです。 z=x+y または x+=y コードが何を実行しているのか、メモリの状況がどのようなものであるのかを正確に把握できます。特に (他の人が指摘しているように) Labview は並列性が高いため、メモリ使用量が急速に急増する可能性があります。したがって、問題に対処するには、思ったよりも多くの RAM を投入する準備をしてください。そして処理能力も向上。

つまり、Labview はラピッドプロトタイピングには最適ですが、他の状況では制御が失われすぎます。大量のデータを扱う場合、またはメモリや処理能力が限られている場合は、テキストベースのプログラミング言語を使用して、処理内容を制御できます。

人々はいつも labview と C++ を比較しますが、「ああ、labview は高レベルで、非常に多くの機能が組み込まれている。dfft を実行してデータを取得してデータを表示してみると、labview ではとても簡単なので、C++ で試してみてください。」となります。

通説 1:C++ で何かを行うのは困難です。C++ は非常に低レベルであり、labview にはすでに多くの機能が実装されているためです。問題は、C++ でロボットシステムを開発している場合、 opencv 、 pcl などのライブラリを使用しなければならないことです。ROS (ロボットオペレーティングシステム) のようなロボットシステムを構築するために設計されたソフトウェアフレームワークを使用すれば、さらに賢くなるでしょう。したがって、ツールの完全なセットを使用する必要があります。実際、ROS + Python/C++ と opencv や pcl などのライブラリを使用すると、より高レベルのツールが利用可能になります。私は labview ロボティクスを使用しましたが、率直に言って、ICP のような一般的に使用されるアルゴリズムは存在せず、他のライブラリを簡単に使用できるわけではありません。

通説2:グラフィカルプログラミング言語は理解しやすいですか

それは状況によります。複雑なアルゴリズムをコーディングしている場合、グラフィック要素が貴重な画面スペースを占有し、メソッドを理解するのが難しくなります。labview コードを理解するには、今読んだコード内の O(n^2) 複雑さの領域を上から下に読む必要があります。

並列システムがある場合はどうなるでしょうか。ROS は、コールバックを使用して実装されたサブクライバー/パブリッシャーメッセージに基づいたグラフベースのアーキテクチャを実装しており、複数のプログラムを実行および通信するのは非常に簡単です。個々の並列コンポーネントを分離すると、デバッグが容易になります。たとえば、制御フローがある場所から別の場所にジャンプするため、並列 labview コードをステップ実行するのは悪夢です。ROS では、labview のようにアーキテクチャを明示的に描画することはありませんが、コマンド ros run rqt_graph を実行するとそれを確認できます (接続されているすべてのノードが表示されます)。

「プログラミングの未来はグラフィックです。」（そう思う？）

そうでないことを祈りますが、labview の現在の実装では、テキストベースのメソッドとグラフィカルなメソッドを使用したコーディングが許可されていません。( mathscript がありますが、これは信じられないほど遅いです)

並列処理を簡単に隠すことはできないため、デバッグが困難です。

非常に多くの領域を見渡さなければならないため、labview コードを読むのは困難です。

Labview はデータ処理や信号処理には最適ですが、実験ロボット工学には適していません。これは、SLAM (同時位置特定とマッピング)、点群登録、点群処理などの高レベルのコンポーネントのほとんどが欠落しているためです。たとえこれらのコンポーネントを追加し、ROS のように簡単に統合できたとしても、labview はプロプライエタリで高価であるため、オープンソースコミュニティに追いつくことはできません。

要約すると、labview がメカトロニクスの未来であるなら、私は投資銀行へのキャリアパスを変更します...仕事を楽しめないなら、お金を稼いで早期退職したほうがいいかもしれません...

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow