Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

なぜ新しいプログラム言語を学ぶのか

プログラム言語は、一つ覚えておけば大抵のことはできます。なのにどうして多くのプログラム言語が作られ、学ぶ人がいるのか。それについて考察します。
by

光宏 新田

on 28 November 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of なぜ新しいプログラム言語を学ぶのか

なぜ新しいプログラム言語を学ぶのか 普通のプログラム言語でできることの範囲は、「チューリング完全」といって、全く同じであることが証明されています。 ではなぜ新しい言語がどんどんでき、それを学ぶ必要があるのか、それについて解説します。 複雑なプログラム A B C A,B,Cという処理がある時、 D それらをひとまとめにして、Dという処理として扱えるようにします。 これを繰り返すことにより、膨大なプログラムも扱いやすくなります。 こうするとA,B,Cについては、Dを扱う時だけしか考えなくてもよくなります。 それ以外の場合は中身を考えずに、Dの外側だけを見ていればいいのです。 また、ここでは処理だけ考えていますがデータも同じように、関数のローカル変数、オブジェクト指向のカプセル化などの工夫がなされています。そのため、全体の設計を考えるときは、データも一部分しか見えないようになり、全部を一度に理解する必要はありません。 この場合の下向きとは、標準ライブラリを実装まで熟知しているとか、組み込み向けにCやアセンブリ言語でプログラムを書いたりとか、そういう方向です。個人的にはそういう方向の成長を目指すのも大変必要なことなのですが。 プログラム言語はどこへ行くのか これまでの話のように現代のプログラミング言語は、シンプルだけれども実は奥深い表現が求められています。プログラミング言語は、それを満たすためにどういう方向に向かっているのでしょうか。 いろいろな方向に試みがなされていますが、人間に判りやすいという方向が、一番大きな方向性のようです。 世の中には、星の数ほどのプログラミング言語があります。 また、新しい
プログラミング言語がどんどん生まれています。 どんどん新しくなるので、どんな新しいことができるようになったかと思いがちですが、プログラムでできることは、全く増えも減りもしていません。 60年前からある、マシン語でできないことができるようになるプログラム言語を考えることは可能ですが。 プログラムは時代を追うごとにどんどん複雑になっており、たとえばWindowsOSのステップ数は、10年で10倍というスピードで増えています。複雑なものを複雑なまま扱うのは大変コストがかかるため、できるだけ単純化する必要があります。 このように数千の処理を扱う場合でも、一度に扱うのは数個ずつで済みます。時代を追うごとに扱う処理は等比級数的に増えていきましたが、こうやって管理することにより、増えすぎて管理できなくなることを避けています。 このように大きなプログラムは、処理の数が増えても生産コストに対する影響が少ないように工夫はされていますが、影響が全くないわけではありません。 ただ、ここで気をつけねばならないのは。プログラマー個人の成長の方向としては、下向きも重要だということです。 ただ、それを目指しても、最新の流れについていくことは、できません。アセンブリ言語は60年前からありますからね。それを混同し手はいけません。 人間がわかりやすいというのは、古くはFORTRANが出た時に、2+3を計算させたければ2+3と書けばよい。これならもうプログラマーなんていらないじゃないか、と言われた流れですね。人間がわかりやすいように書いて、それがそのままコンピューターへの指示になる、ということです。 自分で作る場合でも、既存のライブラリのいくつかを組み合わせる必要があることは多いですし、一部だけれど重要である、特に独自性のある部分については、利用できるライブラリもなく、一から自分で作る必要がある場合もあるでしょう。 そしてその時には、中身は複雑なものを表面上は単純に見せるにはどうすればいいかを理解している必要があります。使いにくいライブラリになっていると、そこが作業上のボトルネックになってしまいますからね。 と書くと、三日前を表すオブジェクトが取得できます。このプログラムの意味は、アメリカ人なら小学生でもわかります。大人なら、どれだけ寝ぼけていようが酔っぱらっていようが、一瞬で意味が分かります。そして業務ルールについて考え抜いて頭が煮詰まっている時でも、です。非常に可読性が高いといえるでしょう。 ここまで可読性が高くできるのはRuby特有ですが、他の言語でも似たようなことはできるものもあります。たとえばC#で同じようなライブラリを作れば、このように書くことができます。 一見同じ機能が使えると言ってもよさそうですが、読もうとするとかっこが混ざっているのが読みにくいですね。大文字が混ざっているのもいただけません。小学生には意味が分からないかもしれませんね。昔のライブラリの感覚でいうと、そんな細かいことはどうでもいいということになるでしょうが。現代のライブラリAPIには、それだけ強く可読性が求めらています。 このように、プログラム言語は進歩していっていますが、その進歩はそれぞれのプログラム言語が独自で進んでいるわけではありません。あるプログラム言語で先進的な文法やAPI設計が開発されると、それはほかの言語で真似されます。 たとえばRuby on Railsが有名になった時、他の言語のライブラリ製作者が、こぞって真似をし始めて、ほかの言語でもRuby on Railsライクに簡単にWebアプリケーションが作成できるライブラリが、いくつも出てきました。 プログラムで価値を創造しようとしている人間なら、プログラムの勉強は多くの言語を俯瞰して、10年20年先を考えながら行う必要があります。 自分でライブラリは作らなくても、言語に新しいライブラリができた時に、すでにその設計思想を理解した状態で使い始めることができ、またそのライブラリが今後どう発展をするかを予言して、それに合わせてノウハウを蓄積することができます。タイムマシン経営ならぬ、タイムマシン設計が可能となるのです。 世にある粒度の大きいライブラリを見ると、複雑な用途に使用する状況では、完全にそれだけで全機能をまかなうというわけにはいかないので、ただ使うだけではすみません。提供されていない機能は、誰もやっていない部分になるので、競争力の源泉となる部分でもあります。そしてそういう部分は、誰もやっていないのですから、自分で作るしかありません。 初めに その流れは現代まで続いていて、最近もRuby on Railsなんかで分かりやすいと評判になったのは、そういう方向のわかりやすさです。また、それ以外のプログラム言語の進化を見ていても、その方向が多いですね。 たとえば、Ruby on Railsのライブラリで評判になったものとして、日時オブジェクトの取得があります。 ただし現在はRubyなんかの先進的なライブラリAPIでも、ここまで自然言語的なAPIはそれほど多くはありません。ただ、先進的なライブラリでは、例えば人間が紙に極力読みやすい図を描いて、それと同等に読みやすいAPIを用意するくらいのことはできており、プログラムなんだから多少読みにくく手も仕方がないという感覚はそろそろ通用しなくなってきています。人間が人間を相手に工夫できる限りのわかりやすさを求められるという、ビジネス文書などと同等のものがそろそろ求められてきています。 今後プログラム言語の進歩の方向性としては、ますます自然言語に近づいていくでしょう。人間の脳というハードウェアは自然言語の解釈専用のコプロセッサがついているので、人間が設計をする限りにおいては、自然言語に近づくことは有効です。 自然言語は最新のプログラムと比較して、中身が複雑なことを表面上簡単に表現するという点ではまだかなり上です。たとえば、ボールを投げるという文章の意味を厳密に定義しようとしてみれば、見えないところに相当な複雑さが隠されていることがわかります。その方面でプログラム言語が自然言語を追い抜くことは当面ありえないので、しばらくは自然言語に近づく方向性は変わらないでしょう。 なぜ学ぶのか Microsoftは10分でマスタメンテWebアプリが作れる仕組みなんてものをを出してきましたが、これもRuby on Railsの真似ですね。技術的にはそういう仕組みを数年前に実現しておくことは可能だったはずですが、実際にはもっと面倒な仕組みしか作らず、それだけ便利なものはその時初めて出てきました。いわゆるコロンブスの卵ですね。 このくらい使いやすくて当たり前という発想は、実際に使いやすくなったものを見ないと、なかなか出てこないようです。もっと使いにくいのが当たり前だ、という発想が先に立ってしまうのですね。 なので、自分が使う必要がない言語の勉強でも、しておくとよいことがあります。いろいろな言語の最先端のライブラリAPIを見ていれば、自分が使う言語にそれをすべて取り入れてライブラリを作成することができます。 λ 数学的に厳密にするという方向性も大きいようですが、その流れから生まれた機能は一般に普及する前に、元の数学理論がわからなくても使えるように装飾されるようなので、一般プログラマーはあまり気にしなくてもよいでしょう。 COBOL FORTRAN LISP C BASIC Forth C++ Smalltalk Ruby Perl Python PHP Pascal Go Dart TypeScript CoffeeScript Cω Clojure Groovy Io なでしこ PowerShell Scala マシン語に出来ないんだから、インタプリタもコンパイラも作成不能になるので、その言語のプログラムを動かすことはできません。つまるところ、最新の言語で作れるソフトは必ずマシン語でも作れます。 新言語 コンパイラ インタプリタ 実行 マシン語実行環境 内部に複雑さを隠しシンプルなAPIを用意しているとはいっても、実際には複雑なことをシンプルに表現しているというだけですから、本当に中身までシンプルなのとはAPIは違ってきます。本当は非常に複雑なことを非常にシンプルに表現する、という設計技術が必要となってきますし、内部の設計は複雑なのですから、そこでも必要とされる技術は高度なものとなります。 動けばいいというならこれだけ作って呼び出せばいいですし。 ライブラリとして外側から使うことを考えても、外側も作ればいいですが。 ライブラリの中身の機能追加があることを考えると、全体を整理しておく必要はあります。
Full transcript