プログラミング / 言語選びの要領
- 2017年12月13日：作成 12年間放置されていた予定項目です(^_^;)
目的と好み（と能力 ^_^;）で選ぼう
次章にDos～Windows環境で使えるフリーの開発環境をまとめてあります。それぞれに特徴があり、商用利用の可否など使用条件も違いますから、個々人の目的と好み（と能力 ^_^;）で選んでください。
開発環境の確保＝プログラムが書ける、でない事は確実に理解して下さい。どの言語を選択しても、使いこなすにはそれなりに努力が必要です。それこそ、コマンド総当たりのトライアンドエラーで徹夜したBasic時代を思い出して下さい、頑張れば解決できます（と思います、だと良いですね ^_^;）。
フリーの定義
ここで言うフリーの開発環境とは無償で入手可能なのであって、何をしてもよい！を意味しません。紹介した中には製品版も含まれており、それぞれ使用許諾条項＝制限があります。
純粋な個人利用かつ成果物（作成したプログラム）も非公開であれば特に気にする必要はないと思いますが、そうでなければ誰が（個人か法人か）どのような目的で（営利か非営利か）何を（業務ソフトか趣味のソフトか）作ることができるか、成果物にどのような権利（販売の可非）と義務（ソース公開など）があるのか、など確認する必要があります。
次章の紹介文では便宜を図るために使用許諾に関する1行コメントを付けてありますが、必ず添付されている使用許諾（ライセンス）に関する文書で直接確認して下さい。つーか、契約・法律関係の文章は解り難くて人のことまで面倒見れませんので (^^ゞ。
FSF（Free Software Foundation）のGPL（General Public License）にしたがって公開されているものも含まれていますが、GNU一般公有使用許諾書の非公式日本語訳とGNU GPLに関して良く聞かれる質問をまとめると次のようになります。
- GPLで保護されたプログラムの成果物（出力結果）が画像や文書など単なるデータである場合は、全ての権利は利用者にあり義務や制限は発生しない。
- 原則的に、GPLで保護されたツールでプログラムをコンパイルしても、成果物のライセンスに制限は発生しない。
- インタプリタが単純にソースを解釈実行するのであれば、成果物（ソース）のライセンスに制限は発生しない。
- 成果物がGPLで保護されたプログラムを利用していても、fork（子プロセス生成）やexec（プロセス置換）などで単純に呼び出す場合は、成果物は独立したプログラムでありライセンスに制限は発生しない。
- ダイナミックリンクのように成果物がGPLで保護されたプログラムを呼び出し、互いに連携し単一のプログラムを形成しているならば成果物はGPLを継承する（インタプリタのソースでも同じ）。
- スタティックリンクのように成果物にGPLで保護されたものが埋め込まれているならば成果物はGPLを継承する。
プログラムの書き方／構造でGPLが継承される場合があり、その成果物を配布／販売するにはソースコードを公開する義務が発生する、が私の解釈です。したがって、企業秘密に触れる、ソースを人に見られたら恥ずかしさで死んでしまう σ(^_^；) など、都合でソースが公開できない場合は派生物にならないように書く、不可能な場合は別の環境で開発するのが妥当／安全です。
言語選びのキーワード
コンパイラ vs インタプリタ
前章でくどく説明したように高水準言語でプログラミングする場合、人間は言語規則に従ってソースコードをテキストファイルで記述し、コンパイラやインタプリタがマシン語に変換実行します。
注： プログラミング関連用語の解説も兼ねているので、ここも十分にくどいです (^^ゞ。
コンパイラはソースコードを事前にマシン語に一括変換し保存、それを一気に実行します。これに対し、インタプリタではソースコードを逐次変換しながら実行します。そのため、絶対的な実行速度はコンパイラ型が勝りますが、パソコンの高速化で最近はインタプリタ型でも十分な速度が得られます。その一方で、インタプリタ型には記述しながらちょこちょこ実行できる（結果が解る）気軽さがありますが、これまた最近の高速パソコンならコンパイルも特に苦痛ではないのでコンパイル型でも結構気軽です。
コンパイラ型とインタプリタ型は単にマシン語に変換するタイミングの違いであって、原則的に言語の設計思想や構造とは無関係であり、その意味では言語選択の決定的要因ではありません。ただし実行にはインタプリタの導入が必要ですから、配布時の障害となる可能性があります。もっとも、コンパイラ型でも実行にランタイム導入が必要な場合は同じことですが。
スクリプト言語
スクリプト言語（script language）と分類されるグループがあり、エディタや表計算のマクロ（macro）もこれに含まれています。多くの場合インタプリタで実行される、記法が簡便な簡易プログラムである、機能が少なく習得が容易である、誰でも簡単に実行できる、などなど、特徴を羅列できても明確に定義することができません。
個別の紹介では世間でそう呼ばれている、あるいは自ら名乗っている場合はスクリプト言語と表記しています。しかし現実には非常に曖昧な便宜上のジャンルであり、スクリプト言語であること（でないこと）も言語選択の要因にならないと思います。
オブジェクト指向への対応
オブジェクト指向プログラミング（Object Oriented Programming）が最近の流れで、対応フリー言語も多数あります。しかし、オブジェクト指向を使わない（使えない(^^ゞ）のであれば対応の可否を選考要因からはずし、選択肢を増やしてより自分にあった言語を選ぶのが得策ではないでしょうか？
そもそも、言語の仕様は手段であって目的ではありません。言語仕様にこだわって書けないより、仕様は古くてもそれでプログラムが書けるのであれば、その方が遥かにマシだと私は思います。アーマライトを持てば誰でもゴルゴ13！などと言うことは絶対にありません、最も重要な要因は、本人の努力と努力と努力です (^_^;;)。
統合開発環境の有無
テキストエディタとコンパイラがあればプログラミングは可能ですが、プログラミングにバグ取りは必須、現実にはプログラミング＝バグ取りです。ソースコードを睨みつけすべて手作業、野生の感 (^_^;) で行なうことも可能ですが、デバッガ（debugger）を使えば効率よく問題を見つけ修正できます。
プログラムを指定した位置で停止する、ステップごとに確認しながら実行する、実行中の変数の変化を追跡するなど、ソースコードを修正する支援を行なうプログラムがデバッガです。なお、バグ取りを支援するのであってデバッガは自動バグ取り機ではありません（あったら欲しい）。バグ取りはバグを創った貴方のお仕事です。
テキストエディタ、コンパイラ、デバッガをバラバラに調達しても、インターフェイスが不統一ですから快適とは言えません。しかもコンパイラやデバッガの多くが（UNIXに起源を持つ？）コマンドラインツールなので不便です。
そこで登場するのが統合開発環境（IDE、Integrated Development Environment）です。エディタ、コンパイラ、デバッガなどを共通のインターフェースに統合して、単一のソフトを操作する感覚の快適な環境を提供してくれます。もちろん生産効率も向上し、コンパイル型も最近は結構気軽と言ったのは統合開発環境下を前提としています。使いやすい統合開発環境の有無は言語選びに重要です。
ここで、統合開発環境と使用言語を正しく区別しておかないと、無駄な努力となってしまいます。たとえば、MicrosoftのVisual StudioはC++にも対応する統合開発環境ですが、C言語のテキスト本を買ってきてもVisual Studioはまず使えません。そもそも、そうしたテキスト本にウインドウアプリの書き方など載っておらず、コンソールの一行表示や四則演算しかできないと腹を立てるのがオチです。逆にVisual Studioの解説本を読んで使えるようになっても、C++そのものが理解できているとは限りません。
常に、解決すべき問題が言語なのか環境なのかを意識していないと、底なし沼に自分から飛び込む事になります。さらに上を目指すのであれば、言語固有の問題とOS固有の問題を切り分けて考える必要もあります。ある言語でWin32APIを使う方法は言語の問題ですが、使われる個々のWin32API関数は言語とは無関係、OS、この場合はWindows固有の問題です。
ある開発環境のある記述方法が、じつはバグにも等しいその環境固有の方言であった場合、それがWin32API関数の正しい使い方であるとか、C++の正当な記述ルールだとか勘違いしてしまうと、将来的に無意味な壁にぶつかって苦しむことになります。
インタプリタ型の場合は、頻繁にプログラムを走らせながらソースを記述すると言う性質上、インタプリタがエディタを兼ねデバッグもそのエディタ上で行なうのが普通です。インタプリタそのものが統合開発環境であると考えて差し支えありません。もちろん、ソースを使い慣れたエディタで書くことも可能ですし、別途より使いやすい統合開発環境が提供されていることもあります。
開発環境とプログラムの実行環境
次章の案内には個別に動作環境が表示されていますが、それはコンパイラや統合開発環境の動作環境であって、コンパイルされる成果物の動作環境とは無関係です。生成されたプログラムの動作環境は書き方やコンパイルオプション*で決まります。したがって、プログラムを書く環境と実行する環境が異なっていても問題はありません。
2017.12.13：追記 *このところCPUのSSE2非対応問題に悩まされていますが、Pentium MMXやK6 3D-Nowが導入された当時、ほとんどのプログラムは新機能があれば使う、無いものは使わない、と常識的な作法で書かれていたので非対応問題は起こりませんでした。今回のSSE2問題は個々のプログラマが旧型を駆逐してやる！と一致団結して選択した結果ではなく、現行のコンパイラにオプションが存在せず無条件でSSE2命令を使用するからではないか？と疑っています。ばかやろ～！な事態ですが、であれば時代おくれ的には旧版コンパイラもキープしておかねばなりません (-"-)。
と言う事で、まとめ
貴方の要望を満たし夢を実現できる言語／環境が見つかったら、フリーの定義を思い出して下さい。実現できる＝実現してよい、ではありません。使用許諾条項が自分の使用形態を許可しているか、確認する必要があります。多くのフリー開発環境が業務使用と成果物の販売を禁止しており、General Public Licenseで提供されている場合には義務が発生します。
結論として、ここが参考になるレベルの人 (^_^;) のほとんどがそうだと思いますが、専門家になる気はないがプログラミングは勉強したい、できれば業務にも生かしたい、良いものができたら配布するかも、と言う場合は極端に突飛なものを避け使用許諾条項が緩く使いやすい統合開発環境が提供されているものを選べば大失敗はないと思います。
未経験者だから何が突飛なのかわんねーよぉ！と言う叫びも聞こえそうですが、ある程度使い込むとその言語／環境の（時に自身の ^_^;）長所短所や限界が見えてくるハズです。そのとき改めて、それまでの経験を踏まえて選びなおせば良いのだと思います。それまでの経験はけして無駄にはならないし、それは失敗ではありません・・・たぶん、ね？（って疑問形 (^^ゞ）。