プログラミング言語とは、コンピュータにおけるソフトウエアを開発することを主目的に作られた人工言語である。つまり、ソフトを作るときに書いたりする、映画とかで研修室の画面に流れてたりする、ムズカシソーなアレ。
プログラミング言語の歴史は、コンピュータこと電子計算機よりも長いわけだが、面倒なのでここではスルー。詳しくは、Wikipedia:階差機関にでも。
プログラミング言語は、コンピュータへの命令することを第一に作られている。それを支援する、構造記述能力、表現力が備わっていることが普通である。また、日本語や英語といった自然言語と異なり、曖昧な解釈はできない[1]。
一般に歴史的な理由と使える領域の広さから、C言語はプログラマーの一般教養言語となっている。
プログラミング言語には高級言語と低級言語がある。
低級言語とは、機械語及びアセンブリ言語(アセンブラ)のことである。
アセンブリ言語は、機械語を英語などの自然言語などで解釈しやすいように作られたものだが、いずれもCPUの処理手順を1つずつ記述しなければいけない。しかもCPU毎に言語仕様が違うため、あるCPU用に書いた機械語プログラムを全く別のCPUに再利用することはできない。
また、論理的には1つの処理も、複数の手順を踏まえないといけないので記述数が膨大になりやすく、現在では処理手順の細かい最適化を行う際に部分的に使われることが多い。
対して高級言語とは、自然言語をベースに人間の論理に合わせて作られたプログラミング言語を指す。CPUの仕様から自由ならば高級言語である。
低級言語よりは習得が楽ではあるが、高級言語を機械語に翻訳するコンパイラーやインタープリターの性能が悪いと、非効率で処理の遅いプログラムになる恐れがある。
高級言語の中でも、記述内容が機械語に近いもの(例えばメモリへの書き込みの方法やタイミングを指定できるなど)ほど低級で、人間の感覚に近いもの(オブジェクト指向など)をより高級とする考え方もある。
近年の様々なパラダイムを取り込み洗練された言語に親しんでいる人から見ると、過去の言語は野暮ったく低級のように見えてしまうかもしれないが、あくまでも人間の考え方に近いか遠いかの違いを表す表現であって、言語の優劣を論じる用語ではない。パフォーマンスの問題から言えば、むしろ低級な言語ほど(労力を惜しまなければ)できることの種類が多く、高級な言語ほど処理速度が遅くなる傾向にある。
実際の言語の優劣は、言語仕様の良し悪しよりも入手可能なライブラリの量と質や処理系の最適化レベル、開発環境の充実度、動作可能なプラットフォームの普及状態などによって決まってしまうことが少なくない。
実行する前にコンパイルという変換作業を必要とするものをコンパイラ言語と呼び、操作や処理を記述したプログラムをそのままインタプリタに解釈させ実行する言語をスクリプト言語(インタプリタ言語)と呼ぶ。言語仕様そのものの違いではなく、処理系の違いなのだが(スクリプト言語でも別途コンパイラを作ってコンパイルしてから実行するようにすればコンパイラ言語といえなくもない)、実用上は両者を区別することが多い。
一つのアプリケーション上で動作し、アプリケーション上の操作を一括して行うように記述できるものもプログラミング言語(スクリプト言語)と呼ぶことができるが、一般にはマクロと呼ばれて汎用プログラミング言語とは分けて扱われる。
一般的な傾向としては処理速度はマクロ < スクリプト言語 < コンパイラ言語 < 機械語 の順番だが、処理系の最適化やプログラマの技量(使用するアルゴリズム)によって大きく変わってしまうこともあるので、「〜で書かれているから速い」という考え方があてはまらない場合もありえる。
ほとんどの高級言語に型の概念が実装されているが、型が実行前に決まっていなければならないかどうかで静的型付け言語と動的型付け言語に分かれる。
→ 型付け
プログラミング言語では、その言語に対するパラダイムが存在する。
パラダイムとは、プログラムを離れて一般的な広義で言えば、物の捉え方の事を指す。
プログラミング言語におけるパラダイムとは、プログラミング言語の捉え方を表したものである。
以下に、代表的なパラダイムを記述する。詳細はプログラミングパラダイムの記事参照
これらは、排他的な特徴ではないため、当然複数のパラダイムをを併せ持つ言語が存在する。そのような言語をマルチパラダイム言語という。多くの言語はマルチパラダイム言語だが、特に多くのパラダイムを実現している言語を指して言うことが多い(例: C++, D言語)。
現在、プログラミング言語は非常に多く存在しているが、言語が作られる理由にはさまざまな理由がある。
面倒なことに、言語内でもバージョンやら実装の違いがあって、トラブルの原因になったりもする。とても面倒。
同様の趣旨で検索すればいくらでも類似の記事が見つかるのに今更感があるが、どのような視点でプログラミング言語を選択するべきか記しておく(個人の感想です)。異論は認める。
無駄に長くなったのでまとめを書いておくと、
もちろん異論は認める。
プログラミングは、入門書で文法を一通り覚えればゲームだろうがExcelのような高度なアプリケーションだろうが何でも作れるようになる、というようなものではない(TASレベルの意味で理論上可能かもしれないが、現実的ではない)。
プログラミングをマスターしたと言えるためには以下のようなものを全部とまでは言わないが習得する必要がある。文法よりもそれ以外の習得事項のほうが多いかもしれない。
多くの言語において、「コンソール上でHello Worldする」のと、「Hello Worldと書かれたウィンドウを表示する」との間には大きな隔たりが存在する。前者は知っての通り初心者が最初に書くプログラム(Haskellを除く)、後者は並列処理あたりまで理解した中級者がGUIフレームワークの勉強を始めるときに書くプログラムである。
希望を打ち砕くようで申し訳ないが、入門書を読んだくらいでは「Hello Worldと書かれたウィンドウを表示する」ことすらおぼつかないのが現実である(例外: Javascript, PHP)。
プログラミング言語以前の問題として、あなたは英語力に自信はあるだろうか。多くのプログラミング言語が英語圏出身である以上、プログラミングに関する情報は英語が原文で提供される。
もちろんWeb上には日本語で書かれたリソースも存在する。しかしそれもメジャーな言語に限られ、マイナーな言語は公式ページの英語のチュートリアルが唯一の情報源ということも珍しくない。メジャーな言語でも、マイナーなライブラリやフレームワークになると同じような状態になる。バグなどのように非常にマイナーな話題は、メジャーな言語でも英語の掲示板にしか情報がないことが多い。
とはいえ、日本語の情報である程度勉強すれば、英語は完全に読めなくても(サンプルコードを参考にして)どうすればいいか見当がつくこともあるので、それほど悲観しなくてもいいかもしれない。
コンピューターの計算能力の上昇はすさまじいものがあるが、それでも限界はある。1万件の単純なデータの処理はすぐに終わっても、1万件の個々のデータに1万個ずつ項目が入っていていたら1億の処理をすることになり結構な時間を要する、その1項目にさらに1万ずつの小項目が存在したら、1兆の処理をしなければならなくなり、合理的な時間で終わらないケースも出てくる。
こういった問題を解決するにはアルゴリズムを工夫する必要があるが、アルゴリズムの理解・応用にはかなりの数学力が必要になる。ここでいう数学力は「数学は70点だったけど国語は55点だったから得意科目を強いて言うなら数学かな」と言ったレベルではなく、「証明問題は解けない問題はなかった。可算無限と非可算無限の違いの証明も余裕。」といったレベルの数学力である。
あなたが中高生ならともかく、文系大学生や社会人だったりするならば、スーパーハカーになろうと思っても既に越えられない壁が出来てしまっている可能性がある。学校の勉強は将来役立たないって言ってた奴出てこいwwww
もっとも、手作業でやっている定型的パソコン操作を自動化したり、IT土方の仕事をするレベルでは関係のない話だと思われるので、気にしなくていいのかもしれない。
それでも、マニュアルに「以上、以下」を調べる機能だけ記載されていて、「より大きい、より小さい」を調べる機能がないときに「より大きい」=「以下ではない」、「より小さい」=「以上ではない」と脳内変換する程度の機転は求められる。
まずは、あなたがプログラミングで何を実現したいのか思い浮かべよう。
何がしたいか(具体的に)決まっている人は幸いである。目的に一番近い機能を有したライブラリを探せばよい。そのライブラリが対応している言語が、あなたの使うべき言語である。選択の余地がないという意味では不幸かもしれない。
プログラミングをすると必ずと言っていいほどプログラミングミス(バグ)が発生する。プログラミング言語の進化の歴史は、いかにこのミスの発生を防ぐかの歴史でもある。
決してミスを犯さないプログラマであるならば、どの言語を選ぼうと関係ない。
プログラミング言語の選択方法について検索すると「オブジェクト指向は時代遅れだ。これからは関数型プログラミングだ」という記述をみつけるかもしれない。
関数型プログラミングの項目で私見を述べたが、関数型プログラミングがもてはやされるのは、参照透過性があるという点と、高階関数を駆使した抽象が可能になるという点が理由になっていると思われる。
参照透過性は、間違いを防ぐために、他の言語を使用する場合でも積極的に心がけると良い。
しかし、参照透過性に完全性を求めると純粋関数型言語に行き着く。2017年の時点で最もメジャーな純粋関数型言語といえばHaskell(それでもかなりマイナーである)だが、これを使いこなすには、モナドを初めとする高階関数を駆使した抽象化の理解を要する。
高階関数を駆使した抽象化というのは、理解するのに数学的素養しかも、単純な数値計算ではなく抽象的なものに関する理解力・応用力が求められる。根性で使っているうちに体得するという考え方もあるが、それは学習が大変ということに他ならない。
関数型プログラミングという言葉に踊らされて言語選択するよりは、関数型プログラミングがどうして有用なのかを理解し、選択した言語でそれを実現するよう心がけた方がいいように思う。関数型プログラミングの重要性も2010年代前半には声高に叫ばれたが、後半には前半ほどは強調されなくなったように思う。
プログラミング言語の大きな分類に静的型付けと動的型付けという分類がある。動的型付けは型を決めなくていいので初心者向けとすることが多いが、(前述のように選択の余地がない場合は別として)少々面倒でも静的型付けの言語を選択することを勧める。
動的型付け言語は、動作内容の詳細が日本語2-3行で表現できてしまうような本当に小さなプログラムを組むときには確かに有利だが、少しでも複雑な動作をさせようとすると静的型付けの言語の型チェックが働いた方が有利になってくる。プログラミングをしようというからには、プログラミングを学んでまでコンピューターにやらせたい面倒な仕事があるのだと思われる。そして面倒な仕事は往々にして複雑であり、単純だと思っていても繰り返す中に例外的な扱いを要するものが混じっていて複雑だったりするものである。
やりたいことがなく、単にプログラミングを勉強したいというだけの場合でも、静的型付けの型安全の考え方は学ぶ価値がある。
「書きにくく読みにくい言語」というのは、どこまでも書きにくく、どこまでも読みにくくすることが可能だが、「書きやすく読みやすい言語」を追求しようとするとどこかで限界にぶち当たる。
書きやすいということは、複雑な処理を短く書ける記法が多数存在するということである。しかし、それを読むときには短い記法からその裏に隠れている複雑な処理を思い出さなければならない(ということは使用頻度の低い記法も含めて多数のことを覚えていなければならない)ということである。つまり書きやすさを追求すると読みにくくなり、読みやすくしようとして文法を単純化し過ぎると書きにくくなる(やりすぎると読みにくくもなる)[2]ということである。
どこかで、書きやすさと読みやすさの折り合いを付けないといけないわけだが、ベストのバランスというのは人によって異なる。すなわち、職業がプログラマだという理由で毎日コードを書くのであれば記法は多いほうが良く、趣味などでたまにしかコードを書かないのであれば記法は少なくていい。
従って万人にとって最良な言語というものはないと思って良いが、「プログラムを書く時間よりも、(バグ探しや仕様確認等のため)にプログラムを読む時間の方が長い」と広く言われており、言語仕様を聞いたときの「書きやすそう」という直感で走るよりも、使用頻度が少なくて忘れてしまいそうな言語仕様はないか、書きやすくても読むときに不利にならないだろうか、など冷静に考えて選んだほうが良いのではないかといえる。
使わない機能は覚えなくていいやと思っても、サンプルプログラムを読む時に知らない言語機能を用いていることがあり、実際に使用していて不便をきたすことは結構ある。
NullPointerException が引き起こすバグを防止するnull安全の考え方が2010年代に入ってからのトレンド。
HaskellにはMaybeモナドがあるが、ScalaのOptionやJavaのOptionalは中身ではなくそれ自身がnullとなりうるのに対し、Maybeモナドはそれ自体がnullになることはないので、上記では区別している。
プログラミング言語は無数にあるが、GUIの製作方法が標準化されている言語は意外と少ない。標準化されていない部分は書籍化もされず情報も手に入りにくいので、GUIアプリを作りたい場合は、闇雲に進んで文法を学んだ後に立ち往生しないためにも、事前にGUIをどうやって作るかまで視野に入れておきたい。
またオープンソース化されているが、GUI製作部分はクローズドになっている場合もある。
使ってない言語のことも書いているので、大きな偏りはある。異論は認める。
こうして書いてみると、言語が設計された経緯が、特徴として色濃く反映されている気がする。
プログラミングをしたことがある人とない人で感じ方はかなり変わるので、余裕があるならとりあえず適当な言語で少しプログラミングを経験した後、ゆっくり本格的に使う言語を探すといいのかもしれない。一つの言語から次の言語に移ると強く違和感を感じるのは慣れの問題か。
何でもできるが、出来てはいけないことまで出来てしまう。ミスを防ぐという観点からは、あまり良くないと思われる。また、C++は仕様が複雑すぎることで悪名高い。
CやC++の反省を元に作られた言語。静的型付け。
APIドキュメントの書き方が言語仕様で規定されている。実際に使ってみるとライブラリの使用方法の調べ方が統一されているというのは大きい。統合開発環境との組み合わせでさらに効果を発揮する。
大半の言語でソースコード内にコメントは書けるが、たいていは言語仕様の策定に終始してドキュメントの仕様がJavaほど厳密に規定されている言語は少ない。
ソースコードが冗長になるという批判が多いが、ソースコードを読むという観点からは黙示的に定義される部分を補う必要がないので読みやすいという見方もできる。
歴史ある言語のため古い考え方も残っているが、後発の言語に一見無駄に複雑と思える仕様が存在する理由が理解できるので勉強にはなる?
2014年のJava8でラムダ式やOptionalが導入されてから、かなり変化したので、書籍や情報源はそれ以降のものを頼ったほうが良い。
動的型付け。ブラウザ上でHTMLにインタラクティブな要素を加えるために開発されたという経緯がある。そのため、プログラミング言語としてはややいびつなところがある。
GUI構築に関してはHTMLと組み合わせる方法が標準化されている一方で、ファイルの読み書きが弱い(ブラウザが勝手にファイルを読み書きしたら困るから)。
Microsoftが開発した、JavaScriptを静的型付けにした言語。JavaScriptの上位互換でJavaScriptのコードをそのまま持ってきても動作するのが特徴。今から始めるならJavaScriptよりはこちらか。
JavaScriptとの互換性を保つため、プログラミング言語としてはややいびつなところが引き継がれている。
動的型付け。実行結果がHTMLになる。インタラクティブなWebページ製作という観点からは最も手軽に結果を得られる反面、もともとプログラミング言語ではなかったせいか、プログラミング言語としては扱いづらい。
iPhoneアプリ開発向けにAppleが2014年に発表した言語。null安全。
オープンソース化されて他のプラットフォームでも動作するが、GUIを構成するCocoaの部分はオープンになっていない。
iPhoneのイヤホンジャックに限らずAppleは昔から旧環境を切り捨てることに定評があるが、SwiftもObjective-Cを捨てて移行したし、Swift自身もメジャーバージョンアップ時に互換性を保てない変更をしている。バージョンも4になったし、もうそろそろ落ち着いてもいいのかも。
Microsoftが開発した.NET Frameworkのメイン言語。
Javaに対抗して作られた経緯があるので、Javaに似てJavaより書きやすいと言われている。
有志が作ったオープンソース実装Monoが存在するが、2016年に公式からオープンソース化された。
GUI周りに関してはオープンソースになっておらず、Monoでも実装されていない。
動的型付け言語。ライブラリやフレームワークの関係でこれらの言語を選択するケースも多いと思われる。
注意点としてはいずれもRuby2.0, Python3.0で互換性のなくなる変更を行っており、区別して検索しないといけない(特にPython)ということがある。
蛇足だが、Rubyの開発者は日本人。
日本人の開発したRubyを推すべきなのかもしれないが、Rubyのキャッチフレーズは「書くのが楽しい」に対しPythonは「見やすさ」を目標に掲げているので、このコラムでは以下省略
静的型付け言語。いずれもJava仮想マシン上で動作するため、Javaで作られた豊富なライブラリが利用可能。Kotlinはnull安全な言語仕様が売り。ScalaもOption型でnull問題に対処しているが、Java8でOptional型が導入されたのでその点ではJavaと差が無くなった。
Javaでの反省を元に作られ、Javaよりも短いコードが書けるという触れ込みだが、コードを読もうとすると黙示的動作を脳内補完する必要があり、いきなりこの言語から入るのは厳しいかもしれない(特にScala)。
コードを書く頻度が高いなら、これくらい機能があった方が便利だと思われる(Scalaはそれでも高機能すぎるという意見もある)。
純粋関数型言語。ちまたに出回っている解説はそれなりに数学力のある人が書いていると思われ、数学力に強い自信がないなら平易な情報が手に入らないのでやめておいたほうがいい。
他の言語と同じようなことをする分には言われているほど難しい言語ではないのかもしれないが、Haskellならではの使い方をしようとするならかなりの数学力が必要。
職業プログラマーが時間をかけて長く付き合っていくならありかもしれない。
意識高い系がうっかり手を出すと、挫折した腹いせにこんな毒を吐くことになる。
書きやすく読みにくい言語の代表格。どうしても使いたいライブラリがあるのでなければ、今から始める理由はないように思う。
急上昇ワード改
最終更新:2025/12/10(水) 17:00
最終更新:2025/12/10(水) 16:00
ウォッチリストに追加しました!
すでにウォッチリストに
入っています。
追加に失敗しました。
ほめた!
ほめるを取消しました。
ほめるに失敗しました。
ほめるの取消しに失敗しました。