タスクを自動化するためにスクリプト言語のみを使用するのはなぜですか？
タスクを自動化するために、スクリプト言語を使用している人のことしか聞いたことがありません。
コンパイルされた言語を使用してタスクを自動化しないのはなぜですか？
スクリプト言語は、コンパイルされた言語ではできないタスクを自動化するために何ができますか？
編集：
これらのフレーズを明確にしましょう：
「スクリプト言語」とは、その言語で記述されたプログラム（またはスクリプト）をインタープリターで実行できるようなプログラミング言語を意味します。スクリプトをコンパイルする必要はありません。
「コンパイルされた言語」とは、その言語で書かれたプログラムを実行する前にコンパイルする必要があるようなプログラミング言語を意味します。
スクリプトは自動化です。スクリプト言語は、自動化タスク用に特別に開発されました。多くの場合、スクリプト作成を容易にする機能があります。他のプログラムまたはそれほど厳密でない言語を呼び出すための単純なメカニズム（通常、型システムがない、または変数を宣言する必要がない、組み込みのコレクションなど）。例えば。 Perlは、「簡単なことを簡単にし、難しいことを可能にする」ように設計されました。
多くの場合、スクリプト言語の言語ランタイムはターゲットシステムにプリインストールされているため、これらの自動化スクリプトの開発と展開は簡単です。ファイルをこのフォルダーに配置するだけで完了です。たとえば、Shell、Perl、およびPythonは、ほとんどのUnixおよびLinuxオペレーティングシステムで広く利用できます。
コンパイルされた言語は異なる傾向があります。それらの言語は、大規模なプロジェクトを伴う「深刻な」プログラミングに向けられていることがよくあります。例えば。 Javaは、最も単純なプログラムでもかなりのボイラープレートが必要です。最初にツールチェーンをインストールし、実行する前にコードをコンパイルする必要があります。これは克服できないものではありませんが、シリーズです余分なハードルの。
もちろん、スクリプト言語と実際の言語の間の障壁は、今では完全になくなっています。
- ブラウザのスクリプト言語であるJavaScriptは、サーバー側の本格的な開発に使用されています。それを使用すると、多くの追加のビルドツールやツールが必要になる傾向があり、他の言語を恥じることになります。
- JVMで実行される言語はJavaだけではありません。スクリプトタスクには、Groovyを使用できます。
- PythonとPHPは巨大なプロジェクトで使用され、型システムとOOPサポートがJavaのサポートを超えています。
- コンパイルがハードルになるのはなぜですか？ C、Go、Haskellなど、従来からコンパイルされている多くの言語には、インタープリター、またはプログラムをその場でコンパイルするラッパースクリプト（cint、runhaskell、gorun）があります。
一部のサークルでは、スクリプトタスクにBashではなくGoを使用する必要があるのは seriousの提案 です。それはちょっとおかしいです。2つの言語がリモートで同様のタスクをターゲットにすることはありませんが、利用可能なツールがあれば、それは完全に可能であり、状況によってはそうするのが賢明かもしれません。
そんなに厳しいルールはないと思います。プラットフォームが自然にコンパイル済み言語をサポートしている場合は、それも使用できます。たとえば、私はWindowsオートメーションの「スクリプト」言語としてC＃をよく使用します。
実用的な違いは1つだけ指摘できます。自動化タスクはアドホックであることが多く、複数の人が一緒に作業している場合、一部の人が別の人から離れてしまうことがあるので、不明なOrigin。誰も変更する方法を知りません。バイナリisソースの場合、そのようなリスクを防ぎます。
「コンパイルされた」と「スクリプト」の間の線はかなりぼやけていますが、一方の端のCともう一方の端のBashのような極端を見ると、それらがさまざまな種類のタスクに最適化されていることは明らかです。
Cの利点：
- 非常に速くなることができます
- 金属に近い
短所：
- 正しく使用することを学ぶのは複雑
- コンピュータをクラッシュさせるのは簡単
- 開発およびテスト時のターンアラウンドが遅い。
バッシュの利点：
- ワンライナーまたはショートプログラム用に最適化
- インタラクティブな開発による非常に迅速なターンアラウンド
- あらゆる種類のシステムと統合するために設計されています。
短所：
- かなり遅い
- 大規模なプログラム向けに設計されていないため、維持が困難になる可能性
システムを自動化する場合、Cの利点は重要ではないことに注意してください。パフォーマンスがまったく問題でなければ、ボトルネックはおそらく自動化スクリプト自体ではありません。スクリプトのリソース使用量は、スクリプト化されているアプリケーションと比較して、ほとんど意味がありません。
通常、スクリプトの自動化はそれほど複雑ではないため、大きなBashスクリプトの保守性の問題は関係しません。これは定義によりほぼ当てはまります。プログラムに多数の複雑なロジックが含まれている場合、それを自動化スクリプトとは呼びません。
したがって、コンパイルされた言語は実際にはそうではありませんできませんスクリプト言語と同じタスクを実行します。それは、スクリプト言語を使用して同じタスクを解決する方が速くて安全なだけです。