なぜ、VSCodeを使うのか？
Visual Studio Code Advent Calendar 2016：6日目
本記事は「Visual Studio Code Advent Calendar 2016」6日目の投稿です。
はじめに――開発環境の拠点としてのエディタ
なぜわざわざ、「Visual Studio Code」（以下「VSCode」）を使う理由を考える記事を書いたのかと言いますと、「開発環境の拠点としてのエディタ」を通して見ることで、最近の開発環境の変化を鳥瞰的に捉えられると考えたからです。
もっと平易に日常の言葉でたとえるとこうです。新しい駅ができるときには、新しい住宅地や商業地ができていたりだとか、生活拠点ができるときには、たいていその背景に何らかに需要がありますよね。そこで、VSCodeが開発された背景は何でしょうか？
簡単に一言でいうと、HTML5などを中心にした「Webアプリ」（もしくは「ハイブリッドアプリ」）の隆盛が大きな要因でしょう。それを書きやすいコードエディタの需要が出てきたので、VSCodeが開発されたのだろうと考えています。
しかし、それだけでは何の意外性もないので、もう少し掘り下げてみましょう。なぜ、Microsoft（以下「MS」）には「Visual Studio」というIDEがすでにあるのに、「VSCode」を新たに開発したのでしょうか？
開発形態の比較
静的言語 ／ 動的言語
それを考えるには、「静的（型付）言語 ／ 動的（型付）言語」の軸で捉えると、俯瞰的に把握しやすいと思います。
まず単純にざっくり言うと、Webアプリは動的言語と相性が良いです。じっさい、フロントエンド側スクリプトのデファクトスタンダードである「JavaScript」も動的言語。
バックエンド側で広く普及しているいわゆる「P言語」、「Perl」「PHP」「Python」「Ruby」もみんな動的言語。もちろん、「Java」などの静的言語のサーバもありますが、エンタープライズ向けが多く、P言語ほど大衆的ではありません。
それではなぜ、Webアプリでは動的言語が好まれるのか？ これ自体いくらでも記事が書けそうな題材ですが、ここでは紙幅の都合から、ごくかんたんに箇条書きで説明を済ませます。
- 「HTML」「CSS」「JavaScript」「PHP」「MySQL」などと5言語も使い分けることで、型で分ける以前に言語単位での分業がされている
- データベースからデータを取得して、それを処理、表示するだけのシンプルな「CRUDアプリ」なら、型で整理する必要性が薄い
- 動的言語は実行速度の面で不利だが、データベースのアクセス速度が最大のボトルネックになりがちなので、開発速度が優先される
- Webアプリはβ版で数多く開発して、ヒットしたものの開発を継続する、という市場探索的な開発形態を取ることが多い。そこで、ウォータフォール的な（型）設計よりも、アジャイル的な開発の方が相性が良い
そして、IDEは静的型付けの型情報が必要なので、動的型付けには起動や動作が軽いエディタで十分、といった状況が続きました。
ただしここで、それならなぜ、これもMSが開発した「TypeScript」のような静的型付け言語が、AltJSとして登場したのか？ という疑問が起こります。
それにはこう考えます。ここも紙幅の都合から、箇条書きで説明を簡略化します。
- まず、クラウドの潮流もあり、デスクトップアプリをWebアプリに移行する流れがあった
- すると、CRUDだけで完結せず、ネイティブアプリの複雑さを引き受ける必要が出てきた
- そこで、Ajaxの流れを汲んだSPAなどが出現し、フロントエンドが肥大化していく
- だから、フロントエンドを型付けで整理する需要が増え、TypeScriptが登場した
そしてとうぜん、そのTypeScriptを書くのに、VSCodeは適しています。IDEとエディタの中間的なVSCodeが必要とされる理由の大筋は、このように私は理解しています。
なお、やはりMSが開発した「PowerShell」も、VSCodeで書きやすいです。このPowerShellには「GUI／CUI」という軸が絡みます。ようするに、サーバ運用にはCUIの方が都合が良く、需要があったわけです。
他開発環境との比較
Visual Studio ／ VSCode
ここから、他のIDEやエディタと比較してみます。先に断っておくと、この比較に優劣を決める意図はありません。しかし、使いやすい分野は個々のソフトで違っているので、使い分けの参考のために書きます。
まず、同じMSの「Visual Studio」（以下「VS」）と比較してみます。
VSはIDEで、VSCodeはコードエディタです。エディタ以外にも、コンパイラやデバッガやGUIデザイナなどの開発ツールが統合されているものがIDEです。
性能だけならVSの方が高性能です。しかし、C#などの静的言語はIDE、RubyやPythonなどの動的言語はエディタ、と個人的には使い分けています。
たしかに、スペックや機能が上なら上位互換、という考え方もネットでは散見します。しかしたとえば、いくら大規模ショッピングモールが何でもそろっていても、だからコンビニが不要、とはならないようなものです。
同じようにたとえば、たかが数行のコードを書くのに、いちいちVSを立ち上げるのは面倒です。
大規模開発の場合は分業されていて、起動しっぱなしでコードを書けても、小規模の場合はデザインなどの他作業と行き来する場合が多いでしょう。そして、その小規模が多いのもWebアプリです。「静的／動的」の軸は、「大規模／小規模」の軸とかなり重なっています。
テキストエディタ ／ VSCode
逆に、「秀丸」などの従来のテキストエディタとの違いは何でしょうか。たとえば、「インテリセンス」の機能が挙げられます。テキストエディタにもマクロを利用した簡易なオートコンプリートならありますが、機能に差があります。
本格的なインテリセンスを実現するには、言語の解析情報が必要です。すると、「蛇の道は蛇」で、言語の開発元はとうぜん有利になります。MSはTypeScriptやPowerShellの開発元ですから、もしそれらの言語を使おうと考えているのであれば、VSCodeを使うのは自然な流れです。
また、ファイルツリーやコマンドパレット、スニペット、デバッガとの連携、コマンドラインとの連携、Gitとの連携、簡易リファクタリング（変数名などの文字列を一括して変換する）などの機能も開発しやすいです。
ただ、テキストエディタにはプログラム以外の文書編集用のマクロなどがあります。テキスト編集には、今も私はテキストエディタを使っています。
Atom ／ VSCode
コードエディタとしてのポジションが、VSCodeと一番近いのが「Atom」でしょう。
Atomは、Githubが開発したコードエディタです。VSCodeと同じ「Electron」というフレームワーク（実行環境）を使用しています。というより、これはAtomを作るためにできたものです。
というと、違いが気になるところですが、基本的には微差だと思います。ユーザとしてはエディタ同士で切磋琢磨して頂ければ幸いです。
しかし、あえて両者に違いを見いだせば、VSCodeはデフォルトでの使いやすさ、Atomは拡張性と自由度の高さ、という重点の違いがあります。
具体的には、Atomは基礎的な部分も拡張できるのに対して、VSCodeは拡張できる部分が限定されています。また、Atomの方がリリースが先発の分、既存の拡張が充実しているかもしれません。
その一方で、起動や動作の軽さではVSCodeの方が軽快です。また、使い方が分かりやすいです。たとえば、VSCodeの画面には左端に5つのアイコンがありますが、これが絶妙に使いやすいデザインだと思います。
これはMSが今まで、現実的な使いやすさやコストパフォーマンスを重視してきたことと関係あると思います。
たとえば、Windowsにしろ、IEにしろ、エクセルにしろ、競合製品に対して後発でありながらも、コスパが良かったので（当時の）シェアを取りました。
じっさい私も、VSCodeより先に、Atomを1.0時点から使っていたのですが、最近ではVSCodeを使う方が多くなっています。私が拡張性よりコスパを重視しているためです。
ただし、「もう一切Atomを使わない」などとは思ってはおらず、後で更新が進んで何か便利な機能が実装されたら、またAtomを使うかもしれません。
「エディタ戦争」（Emacs vs Vim など）のように、技術を宗教化しても不毛なので、たんに便利だから使う、という単純な立場を私は取っています。
Emacs or Squeak ／ VSCode
ここで、少しマニアックな「Emacs」と、相当マニアックな「Squeak」を取り上げます。
ほかのソフト、たとえば「Eclipse」はVS、「Sublime Text」はAtomで述べたことと似たようなことになるので、極端な例を挙げた方が、差が分かりやすくなると考えました。
「Emacs」と「Squeak」（Pharo）に共通するのは、際限のない拡張性と自由度です。単なるコードエディタというより、もはや仮想OSのようなフリーダムさを持っています。
それらの生みの親であるストールマンやアラン・ケイが掲げる理想は立派ですし、今なお古びない設計思想の美しさは魅力的です。
しかしそのかわり、使いやすさが犠牲になっています。とくに初心者が迷子になりやすい、複雑さや難解さや不親切さを持っています。
カスタマイズするための（Emacs）LispやSmalltalkの言語からして難しいです。少なくとも、VSCode（カスタマイズ用）のTypeScriptやAtomのCoffeeScriptよりは難しいでしょう。
そもそも、冒頭のWebアプリの話から言えば、言語にJavaScriptやRubyなどのLLを選ぶ時点で、エディタもライトなものの方が合っています。
それに個人的には、同じ時間と労力を注ぐのであれば、同じく難しい機械学習や自然言語処理など、「未来の可能性の一部となるもの」に浸りたいと考えています。
じゃあ、もう一切無関係なのかといえば、関数型プログラミングやオブジェクト指向、アーキテクチャ設計の学習用と割り切って、細々と学び続けようとは思います。
そもそもじつは、AtomだってEmacsの影響を受けています。Atomは最初、GitHub（共同）創業者のクリス・ワンストラスが開発していました。その彼が使っていたのがEmacsです。
しかし、普段使いにはあまりにも難し過ぎて、けっして誰にでもオススメできるものではありません。
たとえば、自然遺産は素晴らしいですが、その近くで自給自足的に暮らすのは大変でしょう。身も蓋もないですが、コンビニの近くに住んだ方が便利で楽です。
けっきょく、VSCodeはほとんどそのままで使える、コンビニエンスなところが最大の魅力です。
結論：VSCodeを使う理由
最後にかんたんにまとめ直しますと、VSCodeを使うのは、Webアプリやハイブリッドアプリの普及と、それを開発するLL言語と相性が良いからです。
そして、ほかのエディタもいろいろありますが、何より動作が軽くてデフォルトでそのまま使える便利さが、今メインで使っている一番の理由です。
もちろん、細かい不満がないわけでもないですが、VSCodeは今も頻繁に更新しているので、誰もが思いつくような部分は、発展的解消されることと期待しています。