本サイトからスピンオフした姉妹サイトです。7にはどんな新機能が含まれるのかが見えてきた。7はかなり速いペースでのリリースとなる。その背景にはどんな事情があるのだろうか。7としてリリースするかが決まってきた。リリース時期は明示していないものの、今このタイミングで機能を決めたということは、今年中のリリースもあり得るだろう。これまでのC#のリリースサイクルからすると、少し短くなっている。新規追加する機能を小さめに区切っている。今回はこのリリースサイクルの短縮についての話をしていこう。15)に実装される予定の機能は以下のページにまとまっている。Statusこれで確定というわけではないが、変更は細々としたものにとどまっている。本稿的に重要な点は、このページが作られたのが4月初旬で、並んでいる機能は4月時点で実装のめどがある程度立っていたものということである。機能としては結構絞られた印象がある。7から除外された(取りやめではなく、後回しになっただけなのでご安心いただきたい)。型パターン以外のパターンマッチングレコード型(次回以降で説明)非null参照型(次回以降で説明)絞られた代わりといってはなんだが、恐らくリリース時期が近づいている。6がリリースされたときのペースと比較すると、2016年中のリリースもあり得るだろう。仮に2016年末のリリースと想定して、これまでのリリース時期と一緒に並べてみよう。C#の歴代リリース時期これまで、C#のリリースは約2年半に1度のペースだった。6の間は少し長引いたが、これは、コンパイラーを一から再実装する必要があり、この作業に手間取っていたせいであって、例外的である。7の間はずいぶん短くなっている。これまでの半分程度である。実のところ、C#チームとしては「年に1回程度のリリース」を目指したいようだ。その目標からすると、むしろ遅れ気味なくらいである。短期リリースの理由どうしてリリースサイクルが短くなっているかといわれると、「そういう時代だから」と感じる。マイクロソフトは、2000年代には「動きが遅い」などと言われ、何とか改善を図ろうと、ずっと「リリースサイクルを縮める」と言い続けていた。抱えている製品が大きく、かつ、歴史あるため、これを実現するには困難も大きい。実際、ライバル企業もどんどん製品が大きくなる中、製品のリリースサイクルは短かく保ち続けている。ソフトウェア開発手法や、それを支えるツールも進歩して、生産性は上がっているはずで、リリースサイクルを縮められるはずなのだ。最近のプログラミング言語は本当にリリースサイクルが短い。例として、Go、Swift、TypeScriptの主要なバージョンのリリース時期を並べてみよう。図2のようになる(参考までにC#も並べている)。見ての通りの短期リリースである。少ない機能を細かくリリースするか、多くの機能を一気にリリースするかの差ではある。リリース頻度が高いものは、小数点以下のバージョンアップで新機能も少ない。中には、パフォーマンス改善とちょっとしたライブラリ追加程度のリリースも含まれている。小さいリリースを重ねて、プログラミング言語が少しずつ進化し、ユーザーにも少しずつ慣れてもらうのが今時の流れなのだろう。ツールの改善ただし、単に好みの問題で短期リリースサイクルな流れになっているわけではない。リリース作業は、作る側にとっても使う側にとっても負担である。この負担を減らす仕組みが整ってきたことによって、リリースサイクルの短縮傾向が生まれている。図1でも触れているが、C#を使ってC#コンパイラーを再実装するために、言語機能の更新が遅れていた時期がある。この時期には他にも、オープンソース化、Gitへの移行など、開発体制の変化もあった。新たな環境への移行には時間がかかったものの、移行が終わった今、開発に勢いが付いている。C#コンパイラーの実装がC++からC#に変化したのは大きいだろう。C#自体の生産性の高さに加え、C#を誰よりも分かっているC#チームがC#を使って開発できる。リリース作業の負担軽減にはGitも貢献しているだろう。オープンソース化は、開発効率にも影響があったようだ。フィードバックを得やすくなったことから、早い段階で新機能に自信が持て、手戻りを減らしている。マイクロソフトは非常に大きな会社で、社内でのドッグフーディングだけでもかなりのフィードバックにはなっていただろう。オープンになったことで桁違いのフィードバックが得られている。C#を使う側の都合バージョンアップは使う側にも負担となる。最新機能をすぐに試したい人にとっては頻繁なリリースはありがたいだろうが、現状維持を望む人にまで負担をかけてはいけない。Frameworkを入れてくれ」とは言いにくい(特に、エンドユーザーには全く言えないこともあるだろう)。バージョンアップする意思があっても、すぐには動けないこともある。バージョンアップに伴う負担を減らすために、以下のような仕組みが必要だろう。依存するライブラリや開発環境まで含めてバージョン管理システムにコミットできるようにする(もしくはコミットしたものから自動復元できるようにする)既存のものをそのまま使えることに関しては、C#はもともと恵まれている。以下のように、後方互換性がしっかりしていて、ライブラリ作者やエンドユーザーの環境は据え置きで、自分たちが使うC#のバージョンだけを上げることができる。Framework上で動くバージョンアップの簡単さに関してはC#には足りていなかった部分も多いが、徐々に、表1のような仕組みが整ってきている。Coreがインストールされていないマシン上で単独実行できるようになる。Studioに、VSIX(ユーザー単位でのインストールができる拡張パッケージ)として、C#コンパイラーやプロジェクトテンプレート、C#ソースコードエディターをインストールできる。現状は、開発者個々人がVSIXをインストールする必要がある。C#関連のバージョンアップを簡単にする仕組みライブラリと実行環境に関してはだいぶ環境が整った。開発環境の自動復元はまだ不十分だ。Studio自体の更新を頼む必要がある。Studioであれば1台のマシンに同時にインストールできるが、拡張パッケージ違いの同バージョンを同時にインストールすることはできない(プロジェクトによってC#コンパイラーのバージョンを使い分けるといったことはできない)。Studioでの改善を期待したい。新機能の小出しリリースサイクルが短くなることで、新機能の提供は小出しになるだろう。小出しになることによる影響についても考えてみたい。機能単位リリースはしないまず、小出しといっても、機能単位でそれぞれ別リリースにしたりはしない。タプル型だけが使えるリリース、パターンマッチングだけが使えるリリース、ローカル関数だけが使えるリリースというようなパッケージは作らない予定である。パッケージとしてリリースされないという話で、ソースコード上は機能単位でブランチが作られている。機能単位で最新機能を試してみたい場合には、GitHub上のリポジトリから最新のソースコードを取ってきて、所望のブランチに移動してから、自分でビルドして試してみることができる。Studio拡張になっていて、ソースコードを取ってきた本人以外に試してもらうこともできる。ペースの違い機能ごとに実装にかかる時間に大きな開きがある。2進数リテラルは案が出てすぐにプロトタイプ実装があったくらい単純だし、ローカル関数もすぐに実装が終わっていた。6リリース直後から始まっているもののまだ作業が続いている。7から外れそうである。機能ごとに実装にかかる時間には、数週程度から数年程度までばらつきがある。リリースサイクルが長い場合、リリース時期はこのうちで一番長いものにそろいがちである。初期の段階で実装が終わっている2進数リテラルが、安定するまでにまだまだ時間がかかりそうな非null参照型につられて、2~3年先までリリースされないということがあり得る。Infoなどの小さな機能も2~3年待たされていた。リリースサイクルの短縮によって、こういうある機能が別の機能の完成を待たなければならない時間は減るだろう。一般論としてよくある話だが、「2割の実装が8割のユースケースを満たす」というようなことがある(いわゆるパレートの法則)。この場合、その有用な2割を優先的に実装すべきだろう。7では、パターンマッチングを部分的に実装することとなったが、これはまさにその「有用な2割」だ。以下のようなことが言える。段階的な普及の意味もあるだろう。「有用な2割」である型パターンになれることによって、「残り8割」である再帰パターンのユースケースも見えてくるかもしれない。正当な進化形なので、「せっかく覚えたのにすぐに書き方が変わるの?」というような心配も必要ない。先に2割をリリースしたことで「残りの8割」に当たる部分の追加実装が阻害されないことだけはしっかり検討する必要がある。7に取り込む機能を大きく絞っていることにはちゃんと意味があるのだ。C#利用者としては、「案として出ていた機能が消えた」と悲しむのではなく、「有用な部分だけ早く試せる」と喜ぶべきだろう。機能間の依存ある機能が別の機能に依存している場合がある。ある構文が落ち着いてからあらためて実装を検討したい構文、構文が入ってからでないと効率的に実装できないライブラリや、構文とライブラリを同時にリリースしなければ存在意義が弱くなるものなどがあり得る。7と関連するものでは、以下のようなものがある。レコード型は、タプル型やパターンマッチングとの整合性が必要で、これらが落ち着いてからでないと実装が怖いライブラリやアプリのパフォーマンス改善作業の際には、参照戻り値やローカル関数を使いたい標準ライブラリにUtf8Stringクラスを追加する際には、同時にUTF-8文字列リテラルがほしい非null参照型などは、.NETランタイムのレベルで手を入れられるならより良い言語構文にできる可能性がある依存があるので当然、1世代遅らせないと実装できないということも起こり得る。結果的に、リリースサイクルが長いと、それだけで欲しい新機能や機能改善が遠い未来のことになってしまう。5.0までの2年半サイクルだと、「次の次」は5年も待たされることになる。リリースサイクルの短縮は、こういう依存による遅延の積み重ねを減らす意味がある。7ではリリースサイクルの短縮を目指していて、もしかすると2016年中のリリースもあり得るペースになっている。これまでの2年半に1回程度のリリースからすると、約半分になっている。C#の便利な新機能を一刻も早く使いたい人にとっては朗報だ。リリースサイクルの短縮は「ご時世」なのだろう。最近のプログラミング言語はいずれもリリースサイクルがかなり短い。開発ツールの生産性も上がり、プログラミング言語を開発する側にとっても使う側にとってもリリース作業に伴う負担が減ったことによって、頻繁なリリースが可能になっている。1.0がプレビュー版だった頃からC#によるプログラミング入門を公開していて、C#とともに今年で15年になる。最近の自己紹介は「C#でググれ」。※以下では、本稿の前後を合わせて5回分(第6回~第10回)のみ表示しています。INDEX]を参照してください。機能や構文ばかりが注目されるが、プログラミング言語ではパフォーマンスも重要だ。パフォーマンス向上に対する要求が高まってきた背景と、向上のための改善方法を説明。7以降で追加が検討されている新機能にも言及する。前編に続き、次期C#のパフォーマンス向上について解説。7以降での採用が予定もしくは検討されているパフォーマンス向上関連の新機能の内容を具体的に見ていこう。7にはどんな新機能が含まれるのかが見えてきた。7はかなり速いペースでのリリースとなる。その背景にはどんな事情があるのだろうか。Task-likeC#の進化の中でも「非同期メソッド」はコーディング方法を大きく変えるほど革新的だったが、そこにはまだ課題もある。7~将来のC#で、非同期処理はどう進化するのか、前後編で見ていこう。Basic)が切り開いた非同期処理の新たな世界。そこにはまだ課題もある。7でどうなるかを見てみよう。機械学習エンジニアを目指す人~初中級者のための技術情報サイトです。「機械学習&AI」「クラウド&ビッグデータ」「IoTデバイス」のネット記事情報を共有中。開発者のためのSlackチーム、作りました:「機械学習&AI」「クラウド&ビッグデータ」「IoTデバイス」のネット記事情報を共有中。2020最適なビューへの切り替えを推奨します:スマートフォン用表示に。