Perl、PHP、Javaが全盛の時代(2006年）
15年、Web開発をしていて感じるのは、時々で使われる端末や環境がかわりそれに応じて、採用されるプログラム言語も変わるということ。
自分が、Web開発を始めた2006年ぐらいは、PHP、Perl、Javaが全盛の時代。
ちょうど、mixiが上場（2006年）が象徴的で、SNSをこぞっていろんな会社がつくっていた。そこで、モバゲーとかもゲームSNSという形でうまれてきた。
2006年あたりの開発環境、Webシステムのモジュール構成
当時は、まだ、IDEも今みたいに種類がなく、EclipseやNetBeansで書いているのもそれほど多くなくて、エディタで開発している人も多かった。秀丸、サクラエディタなど。VimやEmacsは今と変わらずいたと思うけど、Phper界隈だと、それほどみたなった気がします。
また、Webシステムのモジュール構成は、2019年では当たり前のようにいわれる、フロント開発という言葉はなかった。
Javascriptを使うのはほんの少しで、SPA(Single Page Application）の発想はなかった。1画面ごとにサーバにリクエストを投げて、サーバ側でレンダリングしてViewのデータをブラウザに表示する。
今のように、Javascriptの役割は高くなく、サーバサイドエンジニアがJavascriptをおもちゃのように捉える風潮があり、「JavascriptなんかJavaができたらわかるよ」という感じがあった。今では想像もつかないかもしれない。
つまり、MVCのV（View）の部分もサーバサイドで開発しており、Ruby On Railsのように、サーバサイドのフレームワークがViewの機能をもっているのは、この時代では特に不思議なことはなかった。
今となっては、RailsをはじめとするサーバサイドのViewの機能はどこまで必要なのだろうかという気もする。JSON返せばいいんじゃないかという人もいると思う。Flaskとかマイクロフレームワークにして、Viewを切り離すのもありだと思う。
でも、今は、フロントのJavascriptの技術を中心にして、そこからの延長でフロントと同等の技術でサーバサイドを作るというNuxt.jsのような仕組みもある。昔は、サーバサイドが中心であったが、最近は、必ずしもそうではない。
リーマンショック、iPhone登場、景気回復、人材不足（2007年～2012年）
そして、時は流れ、リーマンショック(2008年）を経験して、ソフトウェが業界もリストラに襲われ、プログラム云々以前になった。今のソフトウェア業界の人材不足なんて、嘘みたいな状況だった。
並行して、iPhoneの初代が登場（2007年）し、段々、Macがプログラマーの間で使われるようになってきた。また、徐々に、RubyOnRailsも普及してきた。ちょうど、第２次安倍政権が発足（2012年）から景気も徐々に上向いて、AIとかロボットなど新しいものも徐々に話題に登るようになった。
Go、Rust、Node.js、Elixir、次世代言語の登場(2006年～2012年）
今では、かなり認知度があがった、次世代言語は、2009年あたりに生まれている。そこから今のような認知度や採用をみるまで約10年ぐらいの期間がかかっている。(Rust:2006年、Go:2009年、Node.js:2009年、Elixir:2012年）
その間に、それらを受け入れるに足る、プログラムの作業的な変化があるように思う。
Ruby、Railsの台頭、AI・機械学習・深層学習、ビッグデータとPython、スクールの乱立、プログラム学習者の増加（2012年～2019年）
Web開発でいえば、JavaやPHPは、相変わらず使われていたけれど、RubyOnRailsの普及は特徴的だと思う。今でも、その流れは完全には消えていない。
さらに、昔から存在はしていたけれど、AIや機械学習など、統計・科学計算の社会的なニーズを背景に、Pythonの採用が増え、学習者も比例して増えてきた。
そして、2020年のプログラムの義務教育への組み込みや人材不足を背景に、RubyやPythonというスクリプト言語を題材にしたプログラミングスクールやオンライン講座が増えてきた。
そして、今は、Twitterでもプログラム初学者は溢れ、並行して、多くのプログラミングスクールが生まれている。プログラミングスクールだけでなく、人材紹介も合併しているような企業すら存在する。
SPA（シングルページアプリケーション）の普及開始（2010年～2014年）
iPhoneなどのスマホが普及してくると、従来のPCのWebページ閲覧とは異なることが求められてきた。
当時はまだ3Gで通信速度も遅く、端末自体もそれほど高速ではなかった。そこで、１回のリクエストである程度レンダリングを行い、必要な部分は、必要なだけ取得するというSPAの発想がWebページ作成に持ち込まれていった。
私がはじめてSPAの開発をしたのは、2014年にKnockoutJS(2010年）というMVVMのフレームワークを使ったものだった。当時すでに、Angular(2009年）はあったのだがIE対応の必要があり、KnockoutJSはそれを満たしていたからだった。
いずれにしろ、2012年～2014年あたりから徐々に、SPAの採用が広まってきた。そして、フロント開発という言葉も段々一般化し、Javascript全盛の時代が幕を開ける。
次世代言語普及の背景にある、IDEの発展、ビルドという作業の一般化
Go、Rustに関して言うと、静的型付けでコンパイルをする言語で、Javaと似たような位置づけ。けれど、昔のPHPを始めとするスクリプトのプログラマーがJavaに抱いていた"敷居"(煩わしさ難しいのではという先入観）は、少ないのかもしれない。
それは、IDEの発展 が大きいかもしれないし、プログラム言語への馴染みがやすさが時代と共に高まっているのかもしれない。また、一方で、Javascriptのwebpackや、SassなどCSSのプリプロセッサーなどを利用する時、かならずビルド環境を整える。
つまり、昔は、CやC++でしてたような、ビルド・コンパイルという手続きを、Webのスクリプトプログラマーも当たり前のようにするようになってきた。
コンパイルやビルドという手続き、概念がすごく敷居の低いもの、身近なものになったのかもしれない。
オブジェクト指向へのアンチテーゼとしての関数型言語
2006年のJava全盛の時代は、オブジェクト指向は宗教というか、ある国のモラルというか、それぐらい当たり前であり、それがわからない人は、プログラマーにあらずに近い雰囲気があった。
多くのプログラマーは、デザインパターン、ドメイン駆動、アスペクト指向などを身に着け、オブジェクト指向を使いこなそうとしていた。
今でもそうした流れは消えずにあると思う。
そして、それが間違っているとは個人的に思わない。
けれど、近年、オブジェクト指向が抽象的で習得が難しい故に、逆に、開き直って、それへのアレルギーを示す人もでてきている。それも理解できるし、それもまた間違っているとか思わない。
結局、いくらすごい手法であっても、いろんなレベルのプログラマーが使いこなせないようでは、手法として採用は難しいという意見も理解できる。
私も、グローバル企業、大手企業でJava開発をしてきたけど、オブジェクト指向をきれいに使いこなしているのは皆無に等しかった。もっぱら手続き指向のように使うか、抽象化をこじらせてスパゲッティコードに出くわすことが多かった。
そういった意味でも、オブジェクト指向というのは使いこなすのが難しいし、それへのアンチがでてくるのも理解ができる。
そして、関数型言語側から、こうした反論がでるのも無理はないなと思う
Object-Oriented Programming — The Trillion Dollar Disaster (オブジェクト指向プログラミング - 数兆ドル規模の災害)
Railsがオワコンと呼ばれてくる（2018年～2019年）
2019年に入ると、今までもてはやされていたRailsへの風当たりが強くなってくる。スクールをはじめとして様々なレベルのプログラマーがRailsを触っていることもあり、質のひどいRailsアプリが世にでてきたからかもしれない。これは、Railsが原因ではないのだが、人はどうしても、何かの失敗を有名なキーワードと結びつけたくなるのかもしれない。
同じようなことは、PHPやJavaへの批判にも当てはまると思う。それぞれの言語にそれほど問題がなかったとしても、それらで作られたソフトがひどければ、言語が駄目だといわれがちである。
また、一方で、Railsがオワコンと言われる原因としては、技術的なところもあると思う。まず、SPAなどJavascriptでフロント（View）を作るようになると、RailsのMVCという構成やその機能だけでは、便利さを享受できなくなってきた。Rails6では、Webpackerが標準でインストールされるようにはなったが、そもそも、サーバサイドのフレームワークがそこまでする必要があるのだろうか？
もしバックエンドだけ変えたい場合、設定とかめんどくさくならないだろうか？コーディングでは、疎結合といわれるけど、モジュールレベルでも疎結合の方がよくないだろうか。
コーディングの生産性についても、IDE前提の場合、静的型付け言語の方がコード補完やコード解析の恩恵を受けやすい。Rubyに限らないが、静的型付けでないスクリプト言語は、このあたりのメリットが薄い。
スクリプトの手軽さは、IDEが貧弱であったり、IDEを使わない状況では意味があったのかもしれないが、IDE前提で便利になった今、静的型付けの言語を使い、人・プログラム共にハイパフォーマンスが得られることが望まれているのではないだろうか。
同じハード資源でも、50%のパフォーマンスしか得られない言語よりは、80%のパフォーマンスを得られた方が経済効率的でも有る。そして、2019年現在、そして、これからはよりパフォーマンスが求められる時代になってきているように思う。
フロントとサーバサイドの分離、BaaSの登場、サーバサイドの役割の変化
ここまで見てきたように、2006年にはサーバサイドのプログラムがMVCすべてを担っていたが、2014年あたりからJavascriptがフロントを担うSPAが台頭してきた。
そして、サーバサイドは、JSONなどを返すRestfulAPIとして振る舞うことが増えてきた。スマホアプリとの連携にもAPIとして振る舞うだけ。
また、2012年にはGoogleのBaaS（Backend as a Service）、Firebaseが発表され、2018年頃には利用するサービスも徐々に増えてきた。
フロントはJavascriptのVueやReact、または、Flutter、ReactNativeでスマホアプリをつくり、バックはBaaSを使って、サーバサイドへの開発工数を下げるような設計も採用されてきている。
サーバサイドの開発の役割は2006年と比べるとビューの部分を切り離し、MC（モデルとコントローラー）に特化するようになってきた。
更に、BaaSに至っては、サーバサイドは自前で開発せずに、サービスとして使おうという動きさえある。
SaaSの一般化と、APIを介したサービス間連携
2006年あたりでは、いろいろなソフトはローカルのPCにインストールして使うのが一般的であったが、2019年の現在、オンライン上のサービスをアプリのようにして使うSaaS（Software as a Service）が段々増えてきた。
MicrosoftのOffice365もオンライン版のOfficeがあったり、FlowなどOfficeのバッチをオンライン上で組める機能があったりする。
会計アプリもマネーフォワードやfreeeなどオンラインで使うこともできる。アプリを通しても、データの保存先はオンライン上のサービス内ストレージになる。
その他いろいろなものがSaaSとして存在するのが一般化してきた。そして、各分野において有名なサービスが生まれ、それを使うのが当たり前になってきた。（Github、Trello、BackLog、Zeplinなど、その領域では当たり前に使われるサービスがある。）
つまり、アプリはオンライン上に存在し、そして、いろいろなアプリは自らに不足している機能はAPIを介して他のサービスによって補完するようになってきた。
サーバサイドはビューを提供することから、データを提供することへとシフトし、サービス・アプリ間の連携がその役割の一つとなってきた。
ネットの普及、リクエスト・トラフィックの増大を背景とした関数型言語の台頭
最近は、ネット人口の増大、PCならず、スマホやIoTの普及、SaaSによるAPI連携により、多くのトラフィックやリクエスをWebサービスがさばくことが当たり前になってきた。
そして、そのミドルウェアを開発するプログラム言語としてEarlang、Elixir、Scalaなどの関数型言語の利用が増えてきた。Goのgoroutineを使うケースもあるだろう。
単純に、オブジェクト指向によるプログラムの可読性や生産性の低さ、バグを生みやすい副作用への指摘にとどまらず、純粋に、並行処理という多くのリクエスト・トラフィックをさばくニーズに応えるために関数型言語が採用されてきている。
最近は、WhatsAppなどのメッセージングアプリ、オンラインゲームなどにもEarlangや、EarlangVMで動くElixirが使われ、その注目を浴びている。
総括１（開発技術の変化、学習しやすい次世代言語）
2006年あたりからWeb開発をしてきて、2019年現在、Web開発も様相がだいぶ変わったと感じている。
2006年当時は、まだエディタでする人も多く、それほどIDEも発展していなかった。まして、CやC++、Javaのビルドなどは厄介で、敷居が高いと言われていた。
Javaについては、オブジェクト指向設計を採用し、使いこなすのがなかなか難しく、分かりにくいスパゲッティコードを量産していたのだが、なぜかそれが当たり前のような雰囲気があった。
アンチJavaというわけではないが、Javaを厄介だと思う人達はPHP、Ruby、Perlなどのスクリプト言語を採用していった。
これらのスクリプト言語はビルドも必要なく、比較的自由な雰囲気があり、敷居の低さを感じた人たちに利用され、世界的に普及していったのだと思う。
そして、時は流れ、IDE、ビルドツール、CIツールなどが発展し、プログラム開発は人間の手だけでなく、ツールを使った開発が一般化してきた。また、プログラマー学習者も増え、徐々に、開発に対する全体的なスキルもあがってきた。
こうしたツールの発展とプログラム学習者の増加、学習意欲の向上などを背景として、言語の敷居は段々と低くなってきたように思う。
また、Go、Rustなどの次世代言語は、スクリプト言語のシンプルな文法を取り入れ、比較的学習しやすい文法になっている。静的型付けの言語とはいえ、以前のJavaほどの敷居を感じている人は少ないのではないだろうか。実際、GoやRustは、VSCodeをつかって比較的簡単に実行ファイルができてしまう。
総括２（2020年以降の5G、IoT、SaaS、AIの時代に向けて）
トラフィックやリクエストの増大により、同一のハード資源でより高速に、より効率的に処理をすることが求められるなか、スクリプト言語よりは、静的型付けの言語のほうがよいと判断されてきているのではないだろうか。
一方、オブジェクト指向のアンチテーゼにとどまらず、並行性が有利なEarlangやElixirなどの関数型言語もまた台頭してきている。関数型言語は、Webサービスに限らず、AIの分野でも使われることが増加してきている（たとえば、LispとかClojureなど）。
こうしたネットの普及と膨大なトラフィックとリクエストを背景に、2006年あたりに全盛だったPerl、PHP、RubyなどWebで中心的に使われていたスクリプト言語は、その歴史的な使命を終えようとしているのではないだろうか。
そして、静的型付けでコンパイルする次世代言語や関数型言語がこれからは求められていくように思う。また、Webに限らず、AI、機械学習、深層学習、ロボティクス、IoTなどもまた、こうした次世代言語や関数型言語を必要としているように感じる。
さいごに
以上、15年ぐらいWeb開発をみてきて、プログラム言語がこれからどうなるんだろうかというポエムでした。
これから言語学習する上での参考になればと思います。
ちなみに、Elixirは、Rails学習者には最適な関数型言語だと思います。Railsのコアコミッターがつくった言語で、Rubyにそっくりなので。
これから流行ってくるのかなと思います。
Go、Elixirが今後、Web開発では利用者が増えていくのではないだろうか。
蛇足ではあるが、Javascriptはフロントにとどまらず、ローカルアプリやスマホアプリでも使われ続けるだろう。そして、Pythonは、AI、機械学習、科学計算、IoT、教育分野で引き続き利用されていくのだと思う。