きっと今もなお、Objective-C使いやC/C++使いには、Swiftが異世界からやってきた黒船のように写っていることだろう。彼らは自身のテリトリーが侵されるのではないかという恐怖と戦い続けている。

C言語世代にとってSwiftは黒船のように見えている

Swift言語の登場によってApple向けアプリケーション開発への新規参入者が劇的に増えた一方で、いままでObjective-Cで開発を行ってきた世代のSwift移行がなかなか進まないという現状が見えてきた。少なくともMac App Store向けアプリの多くは既存／新規に関わらず、未だObjective-C製の物が多い。ブログやソーシャルメディアの書き込みを見ていても、Objective-CやC/C++の擁護を行う人達が妙に増えた気もする。

既存のアプリ開発者たちは、以外にもObjective-Cを好んで使い続けているのかもしれない。

プログラミング界でパラダイム・シフトが起こっている

今まで手塩にかけて磨いてきたC言語やObjective-Cのスキルを安易に手放したくないという心理は、当然大いに考えられる。しかし実際ここには、C言語やObjective-Cという言語の枠を超えたより壮大な心理が働いているように思える。

というのも、Swiftという言語はプログラミングの常識・手法自体を大きく変えようとしているからだ。そしてこの変化は従来のプログラミング手法を否定するものとなる。

楽しさよりも安全性が重視される世界

パラダイム・シフトと聞いて「プロトコル指向」や「関数型プログラミング」「リアクティブ・プログラミング」を思い浮かべた方々。期待に添えず申し訳ないが、今回はそれらの方法論について語るつもりは毛頭無い。

そんな小手先の理論よりも、もっと重要な物がある。今後のプログラミングで最も重要なキーとなるものは、なによりも安全性である。

規制社会の到来

誰もがプログラミングを行う現代では、プログラマの能力に依存する自由さや楽しさを重視した言語よりも、だれが書いても安定する言語が重視されるようになる（これはSIer業界や文系SEの世界でJavaが好まれる現状にも通じている）。

事実、Swiftは言語仕様を厳格に定めることでコードの高い安全性や安定性を実現している。開発者の自由を抑制することで、バグの生まれにくい言語環境を実現しているわけだ。これは今までプログラマの美徳とされてきた言語仕様を活かしたコーディングを否定する事にも繋がっている。

仕様は規約

仕様よりも規約を重視したSwiftではif/for/while文等の条件式内での0以外の値はtrueと見なされないし、0は当然falseと等価ではない（true/falseの判定ロジックはオブジェクト／プロトコル側に内包・譲渡されている）。加えて、nil（null）の代入は特殊な型に限られており、その型の扱いは例外的な言語仕様によって厳格に定められている。

C言語由来の仕様についてもかなりの制限が加えられており、if/for/while文でのブレース(波括弧 = {})省略はまずできない。またC言語スタイルのfor文for(;;)や前置／後置インクリメント++i, i++はSwift 3.0で廃止されることが決まった。上級者の怠慢心と知的欲求を満たす暗黙の型変換も存在しない（現在では一部制限が緩和されている）。

これらはC系列の言語が築き上げた長年の歴史と文化を愚弄する言語仕様といえよう。

ここで言うC系列言語とはCサイドの言語（C++, Objective-C, JavaScript等）を指し、SwiftやJava等の新興言語は含めないものとする

仕様は友達

JavaScriptやPHP、Perl、D言語、C++等のC系列言語の世界ではむしろ「仕様は友達」というスタンスが強く、プログラマにできることを制限しない自由度の高い仕様が何よりも好まれている。また仕様をうまく活用したハッカー的な遊び心が標準となることも多い。

JavaScriptの型変換イディオムがその良い例である。またC言語には本来「else if」構文は存在しないが、ブレース省略記法のメカニズムを逆手に取って、内部的に「else { if }」と同等の解釈をさせることで、事実上の else if 構文を実現していたりする。より具体的にはif文をelseに対応する文として解釈させているのだが、詳しくは以下の記事で解説する）
「else if」文は存在しない【美しきプログラミング言語の世界】

しかしC言語文化の数ある仕様や暗黙のルールは、技術力のないプログラマの混乱を深める結果となった（C系列言語の世界では他人の書いたコードが読みづらいと感じることがよくある。いわゆる変態コードと呼ばれるものも当たり前のように使われてしまう）。

波括弧の省略記法やgoto文、マクロ、暗黙のfall through，暗黙の型変換、型変換イディオム、符号無し型の整数オーバーフロー、コード短縮、カンマ記号、アンダースコア接頭辞、ヨーダ記法がその良い例である。C世界の住人にはそのような多様性に対する「空気を読む」力が求められ、これは一部の技術者に対する負担となり、ひいては技術格差を広げる要因となってしまった。

近年活躍しているプログラミング言語の多く（Java, Python, Swift）は、そのような自由度の高い仕様や複雑な仕様、暗黙のルールを言語仕様レベルで抑圧し、ルールを厳格化することで、より平等で安全性の高い世界を実現している。

Swiftはとにかくルールが厳格

SwiftとObjective-Cの決定的な違いはOptionalの有無だろう。Swiftはこのオプショナルの仕組みを用いることでnil（nullに相当）の状態を言語レベルで掌握しようとしている。プログラマは「?」や「!」「if let」記法を用いてnilの状態を厳格に意識しながらロジックを構築していく必要がある。

他にも、暗黙の型変換が行われないため、プログラマが明示的に型キャスト処理を記述する必要が出てくる。if/for/while文の波括弧は省略はできない。C言語由来の純粋なフリーフォーマットや強力なプリプロセッサも取り入れられていない。また値のオーバーフローは厳格にチェックされる。極めつけは代入演算子の戻り値型であり、こちらは多くの演算子で一貫してVoid型の戻り値が用いられている。

いずれも一見面倒な仕組みに思えるが、ルールに従っている以上はバグも生まれにくく、安全なコーディングが可能になる。

Optionalについては、nilの状態を開発者とコンパイラの双方で把握しやすくなり、安全性の向上や、単体テストの負担軽減にも繋がる。またC-style for文の制限は将来的に最適化の幅を広げることに繋がるだろう。

ちなみに、代入演算子におけるVoid型戻り値の制約には「return _cache = val, var view = this.view = new View()」といったコード短縮テクニックを書き手に使わせない効果があり、結果的に誰が読んでも理解のしやすいコードの記述をプログラマ側に強制させることにも繋がる。

Objective-Cはとにかく自由

一方Objective-CやC言語の世界はとにかく自由である。ルールは存在しない、あるのは仕様だけだ。

「nilは0と等価」「nilに対するメソッド呼び出しは無効」「その際の戻り値はnilと等価」等、極めてミニマルな仕様の元で、プログラマは自身のスキルとセンスを信じコーディングを行う。

Objective-Cの世界はC言語の世界と等価であり、その思想・文化は当然C言語由来のものとなる。C言語の自由さはObjective-Cの自由さにも直結しているため、創り上げるアプリケーションのクオリティはC言語よろしく、作り手次第で良くも悪くもなる。

これは言語側の欠陥でも怠慢でもなく、ある種の万能性であり、この万能性がObjective-CをObjective-Cたらしめていると言えよう。かく言う私もこの万能性に取り憑かれた者の一人である。

C言語由来のセンスが負の遺産として扱われる時代へ

そしてこのようなルールに縛られない自由で柔軟な世界観がObjective-C使い、もといC言語使いの美徳となっていたわけだが、Swiftの登場はこのナルシスト達の美徳、そしてその誇りを大きく傷つけた。

これまで培ってきたC言語由来のセンスは「Objective-C without the C」のスローガンの元で真っ向から否定され、世論の大多数は既にSwift側に傾き始めている。もはやC言語のCはクラシカルのCである。

ことObjective-C使いに関しては、今後もいつ消えるかも分からない言語への恐怖、そしてこのなんとも言えない孤独感や疎外感と戦い続けなければならない。

反論記事：Objective-Cは無くなるのか

今後のプログラミング言語の主流

これまでC言語世代にとっての仕様はルールではなく、あくまで仕様であった。しかしJavaやSwiftの時代では仕様は事実上の規約となり厳格なルールとなった。これは「仕様は規約」というスローガンに置き換えることもできる。これからの時代、次世代プログラミング言語では「安全性」がなによりも重要視され、そしてその安全性を担保するシステムとしての仕様や規約が重要な要素となってゆくだろう。

プログラミングの大衆化と秩序統制

これまで、安全なソフトウェア開発を実現する手段は、外部ツールの利用やコーディング規約への準拠が主であった。しかしこれからは言語仕様そのものがプログラマを統制し、安全なソフトウェア開発へと導く存在になっていくだろう。

自由放任で混沌としていたプログラミングの世界に絶対的な秩序が求められ始めている。そしてその秩序を維持するのはプログラマ自身ではなく、ほかでもない、言語仕様そのものである。言語仕様はプログラマの法となりつつある。

性善説から性悪説の時代へ

プログラマの性善説はもはや通用しない時代になりつつある。プログラマは皆、注意深く賢いオタクや研究者ばかりなので間違いも犯しにくいだろうという常識はもう通用しない。

今は子どもや主婦・サラリーマン・80歳を超えた婦人がアプリを作る時代である。様々なジャンルの人間がプログラミングを行う現代ではもはや性善説は通用せず、性悪説を前提とした規制や制約が求められてゆくだろう。

やり方はひとつでいい

「やり方はいろいろある」や「多様性は善」の時代は終わった。当面は「やり方がいろいろない」世界や「多様性は悪」の時代が主流となるだろう。「やり方はひとつでいい」や「一つのベストなやり方があれば、その他のやり方は不要」といった考え方が求められていく。「これさえあれば、何もいらない。」とはよく言ったものだ。もっとも、これはAppleではなくMicrosoft社のキャッチコピーなのだが。

番外編

プログラミングの主流が「If/Then」方式から「If/Then/Maybe」方式へと変わる。

タイムトラベラー、ジョン・タイターが予言した未来である。

SwiftやKotlinにおけるOptionalの仕様はまさにこのMaybeに当てはまる物ではないか。ひょっとすると今後主流になるプログラミング言語の多くはSwiftやKotlin, Haskellを意識したものになるのかもしれない。

まとめ

これからの時代のプログラミング言語では「安全性」が鍵となる
これからの時代のプログラミング言語では「仕様は規約」になる
より厳格で安全性の高い言語仕様が次世代プログラミング界を制する
「やり方はいろいろある」から「やり方はひとつでいい」という発想の切り替え
SwiftはC言語、Javaに次いで業界を牽引した言語の一つになるかもしれない
ジョン・タイターの予言はSwiftとKotlinが体現してくれそう

次世代言語の衝撃

昨今の新興言語達がもたらした現象とはつまるところ、使う側と使われる側の立場の逆転である。そういう意味で、SwiftとKotlinの登場、JavaとPythonの飛躍は衝撃的であった。もはや人がプログラムを書くという事が馬鹿らしく思えてしまう。もうあと何十年もすれば、人間が直接コードを書くようなこともなくなるかもしれない。プログラミングは愚かな行為なのである。我々は今さらそれに気づき始めたのだ。

本物のプログラマは今日もプログラムを書かない ─ MaSH