プログラミング言語

プログラミング言語とは、コンピュータにおけるソフトウエアを開発することを主目的に作られた人工言語である。つまり、ソフトを作るときに書いたりする、映画とかで研修室の画面に流れてたりする、ムズカシソーなアレ。

概要

プログラミング言語の歴史は、コンピュータこと電子計算機よりも長いわけだが、面倒なのでここではスルー。詳しくは、Wikipedia:階差機関にでも。

プログラミング言語は、コンピュータへの命令することを第一に作られている。それを支援する、構造記述能力、表現力が備わっていることが普通である。また、日本語や英語といった自然言語と異なり、曖昧な解釈はできない^[1]。

一般に歴史的な理由と使える領域の広さから、C言語はプログラマーの一般教養言語となっている。

高級言語と低級言語

プログラミング言語には高級言語と低級言語がある。

低級言語

低級言語とは、機械語及びアセンブリ言語(アセンブラ)のことである。

アセンブリ言語は、機械語を英語などの自然言語などで解釈しやすいように作られたものだが、いずれもCPUの処理手順を１つずつ記述しなければいけない。しかもCPU毎に言語仕様が違うため、あるCPU用に書いた機械語プログラムを全く別のCPUに再利用することはできない。

また、論理的には1つの処理も、複数の手順を踏まえないといけないので記述数が膨大になりやすく、現在では処理手順の細かい最適化を行う際に部分的に使われることが多い。 

高級言語

対して高級言語とは、自然言語をベースに人間の論理に合わせて作られたプログラミング言語を指す。CPUの仕様から自由ならば高級言語である。

低級言語よりは習得が楽ではあるが、高級言語を機械語に翻訳するコンパイラーやインタープリターの性能が悪いと、非効率で処理の遅いプログラムになる恐れがある。

高級言語の中でも、記述内容が機械語に近いもの(例えばメモリへの書き込みの方法やタイミングを指定できるなど)ほど低級で、人間の感覚に近いもの(オブジェクト指向など)をより高級とする考え方もある。

近年の様々なパラダイムを取り込み洗練された言語に親しんでいる人から見ると、過去の言語は野暮ったく低級のように見えてしまうかもしれないが、あくまでも人間の考え方に近いか遠いかの違いを表す表現であって、言語の優劣を論じる用語ではない。パフォーマンスの問題から言えば、むしろ低級な言語ほど(労力を惜しまなければ)できることの種類が多く、高級な言語ほど処理速度が遅くなる傾向にある。

実際の言語の優劣は、言語仕様の良し悪しよりも入手可能なライブラリの量と質や処理系の最適化レベル、開発環境の充実度、動作可能なプラットフォームの普及状態などによって決まってしまうことが少なくない。

コンパイラ言語とスクリプト言語

実行する前にコンパイルという変換作業を必要とするものをコンパイラ言語と呼び、操作や処理を記述したプログラムをそのままインタプリタに解釈させ実行する言語をスクリプト言語(インタプリタ言語)と呼ぶ。言語仕様そのものの違いではなく、処理系の違いなのだが(スクリプト言語でも別途コンパイラを作ってコンパイルしてから実行するようにすればコンパイラ言語といえなくもない)、実用上は両者を区別することが多い。

一つのアプリケーション上で動作し、アプリケーション上の操作を一括して行うように記述できるものもプログラミング言語(スクリプト言語)と呼ぶことができるが、一般にはマクロと呼ばれて汎用プログラミング言語とは分けて扱われる。

一般的な傾向としては処理速度はマクロ < スクリプト言語 < コンパイラ言語 < 機械語 の順番だが、処理系の最適化やプログラマの技量(使用するアルゴリズム)によって大きく変わってしまうこともあるので、「〜で書かれているから速い」という考え方があてはまらない場合もありえる。

静的型付けと動的型付け

ほとんどの高級言語に型の概念が実装されているが、型が実行前に決まっていなければならないかどうかで静的型付け言語と動的型付け言語に分かれる。

→ 型付け

プログラミング言語におけるパラダイム

プログラミング言語では、その言語に対するパラダイムが存在する。
パラダイムとは、プログラムを離れて一般的な広義で言えば、物の捉え方の事を指す。
プログラミング言語におけるパラダイムとは、プログラミング言語の捉え方を表したものである。
以下に、代表的なパラダイムを記述する。詳細はプログラミングパラダイムの記事参照

• 構造化プログラミング
• 手続き型言語
• モジュール型
• オブジェクト指向
• アスペクト指向
• イベント駆動型
• 関数型言語

これらは、排他的な特徴ではないため、当然複数のパラダイムをを併せ持つ言語が存在する。そのような言語をマルチパラダイム言語という。多くの言語はマルチパラダイム言語だが、特に多くのパラダイムを実現している言語を指して言うことが多い(例: C++, D言語)。

主なプログラミング言語（高級言語）

• BASIC
• COBOL
• FORTRAN
• Pascal
• C
• C++
• C#
• Java

主なスクリプト言語

• Perl
• Python
• Ruby
• JavaScript
• Visual Basic for Application(VBA)
• PHP

プログラミング言語が作られる目的(一覧)

現在、プログラミング言語は非常に多く存在しているが、言語が作られる理由にはさまざまな理由がある。

• 以前の言語の拡張として (例: C++,　C++マネージ拡張, C++/CLI, Objective-C)
• ちょっとしたことをお手軽にやりたい (例: シェルスクリプト系)
• ちょっとしたことをお手軽にやりたい。高機能で (例: Ruby, Python)
• OSを移植しやすくするため (例: C言語)
• そもそも仮想マシンで動かせばどこでも動くんじゃね (例: Java)
• Javaの人気に嫉妬して(いつものように)パクった。後悔はしていない(例: C#)
• 言語設計の研究のため。ネタ言語じゃないよ!! (例: BrainF*ck)
• コンビネータ理論に基づいて言語を作ってみたもの。ネタ言語じゃな…くもない(例: unlambda, LazyK)
• 環境に特化した言語が必要になって (例: PostScript, SQL, JavaScript, ニワン語&ニコス)
• 実は別目的だったんだけど、機能追加してたら言語になってた (例: ActionScript)
• 新しい概念実装のため (例: Lisp)
• ハードウエア設計のため (例: Verilog)
• 英語よりも日本語だろJK (例: ひまわり, なでしこ)
• 他の言語に組み込むため (例: Lua)
• 俺最強言語を作って、俺TUEEEEEしたくなって (例: D言語)
• サンプルプログラム内蔵してみた (例: HQ9+)
• 読みにくくしてみた (例: grass, whitespace)
• ゲームだ (例: CarnageHeart)
• 教育用だ (例: LEGO MindStorm, LOGO, CASL)
• Hello,World!を最短コードで表示してみた (例: BrainCrash)
• WebとDBに強い言語を作ってみた。文法？とりあえずCっぽくしとけば良いんじゃね。（例: PHP）
• 新言語（信玄後）だから（例: 織田信長）
• 昔は皆これから始めたもんだ（例: BASIC）
• IT土方専用 (例: Visual Basic)
• 元祖最強俺言語、何でもできるよ！ (例: Perl)
• 成果物のスパゲッティさは他の追随を許さない。爺専用 (例: COBOL)
• 非情シス部門で勝手システムを作るためのもの。あまり関りたくない (例: Visual Basic for Applications)
• 日本においては税金の無駄使い公共事業用だった (例: Prolog)
• 真祖とか始祖とかそんな感じ。ゆとり世代には伝説の類 (例: Fortran)
• なにげにインストールベースでは最多クラス (例: Visual Basic Scripting Edition)
• 主に教育用だ。ターボとか付いてて、エディタにタダで付いてくるすごいのもあった (例: Pascal)
• 副作用が許されるのは小学生までだよね (例: Haskell)
• 関数型言語とオブジェクト指向を合せたら最強じゃね？ (例: Objective Caml, F#, Scala)
• マイクロソフト帝国には誰も逆らえないことを、結果的に証明した(例: Delphi, Object Pascal)
• 制御構造を持たないシンプルな文法、なんでも文字列、簡単GUI(例: Tcl/Tk)
• grepやsedじゃ物足りなくなって (例: awk、Perl)
• WebでもやっぱりBASICだろう(例: VBScript)
• おれは数学向け組版用言語を開発していたと思っていたら　いつのまにかチューリング完全になっていた (例: TeX)
• Cの速さ、Rubyの動的さが欲しいし、科学計算、線形代数計算、統計処理、機械学習を手軽に分散コンピューティングで出来るようにしたい。でも言語としてはシンプルなのがいいね。え?欲張りだって?(例: Julia)
• プラットフォームが十分に普及し、何をしてもみんな追随してくれるようになったので (例: Swift)
• ぬるぽをなくしたかった ← ｶﾞｯ (例: Swift, Kotlin)

面倒なことに、言語内でもバージョンやら実装の違いがあって、トラブルの原因になったりもする。とても面倒。

関連動画

タグ検索「プログラミング」

関連商品

関連コミュニティ

関連用語

• プログラミング
• 日本語じゃない日本語
• チューリング完全
• 統合開発環境(IDE)
• ガベージコレクション
• プログラミング関連用語の一覧
• ソフトウェアの一覧
• ソフトウェア開発

コラム: プログラミング言語選択ガイド

同様の趣旨で検索すればいくらでも類似の記事が見つかるのに今更感があるが、どのような視点でプログラミング言語を選択するべきか記しておく(個人の感想です)。異論は認める。

まとめ

無駄に前置きが長くなったのでまとめを書いておくと、

• やりたいことが決まっているなら、目的に最適なライブラリを選べば、選択すべき言語がほぼ決まる。
• 勉強したいだけなら情報の多いJava。
• Microsoftに囲われるのが嫌でなければC#という選択も。

もちろん異論は認める。

その幻想をぶち殺す!!

プログラミングは、入門書で文法を一通り覚えればゲームだろうがExcelのような高度なアプリケーションだろうが何でも作れるようになる、というようなものではない(TASレベルの意味で理論上可能かもしれないが、現実的ではない)。

プログラミングをマスターしたと言えるためには以下のようなものを全部とまでは言わないが習得する必要がある。文法よりもそれ以外の習得事項のほうが多いかもしれない。

• 文法
• 統合開発環境の使い方
• 個々のライブラリの使い方
• 並列処理の書き方
• GUIフレームワークの使い方
• ユニットテストの書き方
• ビルドシステムの使い方
• UML設計ツールetc.....
• アルゴリズム

多くの言語において、「コンソール上でHello Worldする」のと、「Hello Worldと書かれたウィンドウを表示する」との間には大きな隔たりが存在する。前者は知っての通り初心者が最初に書くプログラム(Haskellを除く)、後者は並列処理あたりまで理解した中級者がGUIフレームワークの勉強を始めるときに書くプログラムである。

希望を打ち砕くようで申し訳ないが、入門書を読んだくらいでは「Hello Worldと書かれたウィンドウを表示する」ことすらおぼつかないのが現実である(例外: Javascript, PHP)。

プログラミング言語? そんなことより英語だ!

プログラミング言語以前の問題として、あなたは英語力に自信はあるだろうか。多くのプログラミング言語が英語圏出身である以上、プログラミングに関する情報は英語が原文で提供される。

もちろんWeb上には日本語で書かれたリソースも存在する。しかしそれもメジャーな言語に限られ、マイナーな言語は公式ページの英語のチュートリアルが唯一の情報源ということも珍しくない。メジャーな言語でも、マイナーなライブラリやフレームワークになると同じような状態になる。バグなどのように非常にマイナーな話題は、メジャーな言語でも英語の掲示板にしか情報がないことが多い。

とはいえ、日本語の情報である程度勉強すれば、英語は完全に読めなくても(サンプルコードを参考にして)どうすればいいか見当がつくこともあるので、それほど悲観しなくてもいいかもしれない。

数学力…たったの5か…

コンピューターの計算能力の上昇はすさまじいものがあるが、それでも限界はある。1万件の単純なデータの処理はすぐに終わっても、1万件の個々のデータに1万個ずつ項目が入っていていたら1億の処理をすることになり結構な時間を要する、その1項目にさらに1万ずつの小項目が存在したら、1兆の処理をしなければならなくなり、合理的な時間で終わらないケースも出てくる。

こういった問題を解決するにはアルゴリズムを工夫する必要があるが、アルゴリズムの理解・応用にはかなりの数学力が必要になる。ここでいう数学力は「数学は70点だったけど国語は55点だったから得意科目を強いて言うなら数学かな」と言ったレベルではなく、「証明問題は解けない問題はなかった。可算無限と非可算無限の違いの証明も余裕。」といったレベルの数学力である。

あなたが中高生ならともかく、文系大学生や社会人だったりするならば、スーパーハカーになろうと思っても既に越えられない壁が出来てしまっている可能性がある。学校の勉強は将来役立たないって言ってた奴出てこい。

もっとも、手作業でやっている定型的パソコン操作を自動化したり、IT土方の仕事をするレベルでは関係のない話だと思われるので、気にしなくていいのかもしれない。

それでも、マニュアルに「以上、以下」を調べる機能だけ記載されていて、「より大きい、より小さい」を調べる機能がないときに「より大きい」=「以下ではない」、「より小さい」=「以上ではない」と脳内変換する程度の機転は求められる。

「これをやりたい」と心の中で思ったならッ!その時スデに選択は終わっているんだッ!

まずは、あなたがプログラミングで何を実現したいのか思い浮かべよう。

何がしたいか(具体的に)決まっている人は幸いである。目的に一番近い機能を有したライブラリを探せばよい。そのライブラリが対応している言語が、あなたの使うべき言語である。選択の余地がないという意味では不幸かもしれない。

プログラミングとはミスとの闘いである

プログラミングをすると必ずと言っていいほどプログラミングミス(バグ)が発生する。プログラミング言語の進化の歴史は、いかにこのミスの発生を防ぐかの歴史でもある。

決してミスを犯さないプログラマであるならば、どの言語を選ぼうと関係ない。

関数型プログラミングという潮流

プログラミング言語の選択方法について検索すると「オブジェクト指向は時代遅れだ。これからは関数型プログラミングだ」という記述をみつけるかもしれない。

関数型プログラミングの項目で私見を述べたが、関数型プログラミングがもてはやされるのは、参照透過性があるという点と、高階関数を駆使した抽象が可能になるという点が理由になっていると思われる。

参照透過性は、間違いを防ぐために、他の言語を使用する場合でも積極的に心がけると良い。

しかし、参照透過性に完全性を求めると純粋関数型言語に行き着く。2017年の時点で最もメジャーな純粋関数型言語といえばHaskell(それでもかなりマイナーである)だが、これを使いこなすには、モナドを初めとする高階関数を駆使した抽象化の理解を要する。

高階関数を駆使した抽象化というのは、理解するのに数学的素養しかも、単純な数値計算ではなく抽象的なものに関する理解力・応用力が求められる。根性で使っているうちに体得するという考え方もあるが、それは学習が大変ということに他ならない。

関数型プログラミングという言葉に踊らされて言語選択するよりは、関数型プログラミングがどうして有用なのかを理解し、選択した言語でそれを実現するよう心がけた方がいいように思う。関数型プログラミングの重要性も2010年代前半には声高に叫ばれたが、後半には前半ほどは強調されなくなったように思う。

静的型付け vs. 動的型付け

プログラミング言語の大きな分類に静的型付けと動的型付けという分類がある。動的型付けは型を決めなくていいので初心者向けとすることが多いが、(前述のように選択の余地がない場合は別として)少々面倒でも静的型付けの言語を選択することを勧める。

動的型付け言語は、動作内容の詳細が日本語2-3行で表現できてしまうような本当に小さなプログラムを組むときには確かに有利だが、少しでも複雑な動作をさせようとすると静的型付けの言語の型チェックが働いた方が有利になってくる。プログラミングをしようというからには、プログラミングを学んでまでコンピューターにやらせたい面倒な仕事があるのだと思われる。そして面倒な仕事は往々にして複雑であり、単純だと思っていても繰り返す中に例外的な扱いを要するものが混じっていて複雑だったりするものである。

やりたいことがなく、単にプログラミングを勉強したいというだけの場合でも、静的型付けの型安全の考え方は学ぶ価値がある。

書きやすい言語 vs. 読みやすい言語

「書きにくく読みにくい言語」というのは、どこまでも書きにくく、どこまでも読みにくくすることが可能だが、「書きやすく読みやすい言語」を追求しようとするとどこかで限界にぶち当たる。

書きやすいということは、複雑な処理を短く書ける記法が多数存在するということである。しかし、それを読むときには短い記法からその裏に隠れている複雑な処理を思い出さなければならない(ということは使用頻度の低い記法も含めて多数のことを覚えていなければならない)ということである。つまり書きやすさを追求すると読みにくくなり、読みやすくしようとして文法を単純化し過ぎると書きにくくなる(やりすぎると読みにくくもなる)ということである。^[2]

どこかで、書きやすさと読みやすさの折り合いを付けないといけないわけだが、ベストのバランスというのは人によって異なる。すなわち、職業がプログラマだという理由で毎日コードを書くのであれば記法は多いほうが良く、趣味などでたまにしかコードを書かないのであれば記法は少なくていい。

万人に良い言語というものはないと思って良い。

「プログラムを書く時間よりも、(バグ探しや仕様確認等のため)にプログラムを読む時間の方が長い」と言われており、

サンプルプログラムが読みにくいのも、実際に使用する時が来たら不便である。

各論

使ってない言語のことも書いているので、異論は認める。

C言語 / C++

何でもできるが、出来てはいけないことまで出来てしまう。ミスを防ぐという観点からは、あまり良くないと思われる。C++は仕様が複雑すぎることで悪名高い。

Java

CやC++の反省を元に作られた言語。

APIドキュメントの書き方が言語仕様で規定されているのは、実際に使ってみるとライブラリの使用方法の調べ方が統一されているというのは大きい。

コメントは書ける言語が大半だが、たいていは言語仕様の策定に終始してドキュメントの仕様は規定されていない言語のほうが多い。

脚注

1. *曖昧さがないといっても実行時の話で、言語仕様書の段階では曖昧さが取り除ききれていない場合も少なくない。リファレンス実装がこの問題を解決している場合もある。
2. *なお、単純さを追求したい方は純Lispについて、極限まで追求したい方はLazy Kについて調べてみるとよい。本当に単純な話なのですぐ調べ終わる。