問題は、難解な物の上に簡単な物を載せたからといって、その難解な部分が易しくなるとは限らない、ということだ。
アップルは Swift に大きな期待を寄せている。Swift は、先日のワールドワイド・デベロッパーズ・カンファレンス（WWDC）で開発者に公表されたばかりの真新しいコーディング言語だ。アップルにとって Swift は、 現在 iPhone、iPad、Mac のアプリケーションを書くのに使われている、無骨でエラーが発生しやすいObjective-C に代わる、より簡単かつ安全で、高速な言語である。
アップルは、Swift を使って時間と労力を節約することで、より多くの開発者がiOSのアプリケーションを構築してくれるようになることを期待している。そのためアップルは、開発者たちが Swift をしっかりと迅速に（swiftly）学習し、習得することを望んでいるのだ。
そう簡単にいくと良いのだが。
Swift は、現在の技術、つまり開発者が使い慣れている言語やツールと新しい未来の新言語の間で難しいバランスをとっている。Swift は確かに魅力的な新機能をいくつも提供している。Objective -C を苦しめた、たちの悪いバグをなくすための自動メモリ管理、プログラムの動作を可視化してデバックを容易にする「playground」機能、学習しやすくエラーが発生しにくいように設計された、単純化された構文などだ。
しかし既存のアプリケーション、ツールセット、コードライブラリとの連続性を維持するために、Swift は Objective -C にも寄り添っている。OS X と iOS アプリケーションを駆動するObjective -C のフレームワーク、Cocoa および Cocoa Touchとダイレクトに連動させることができるのだ。Cocoa のライブラリはObjective -C で実装されているので、開発者たちは Swift コードとObjective -C コードを並行して実行することができる。
Swift が成功するかどうかは、この種の相互運用が完璧に動作するかどうかにかかっている。そうでなければ、開発者は自分たちのアプリケーションを動かすために、また Objective -C をいじらなくてはならなくなるだろう。そうなると1つではなく、2つの言語をマスターする必要が出てくる。開発者はもちろん、こんな余計な作業を歓迎したりはしないだろう。
以前 Swift のような言語が登場したときも、これと同じ理由から開発者たちには不評だった。
RubyMotion の実験
Code School の創設者で最高経営責任者であるグレッグ・ポラックによれば、今のプログラマーの大多数はObjective -C の持つ複雑さに対する準備ができていない。「開発者の多くはJava、Ruby、Python を学ぶところから始めている。そこからObjective -C への移行は全くの別物で難しく、足元をすくわれるようなことばかりだ」とポラックは言う。
残念ながら、Objective -C は長い間、iOS と OS X アプリケーションを構築する唯一の言語であった。主な理由は、Mac OS X 用の Cocoa と iOS 用の Cocoa Touch の API が Objective-C で書かれているからだ。開発者たちは最適なパフォーマンスを得るために、同じ言語である Objective-C を使ってアップルデバイス用のアプリケーションを書くのが常だった。
だが別に、 Objective-C を使わなければならないという決まりがあったわけではない。Cocoa および Cocoa Touch の Objective -C コードライブラリと整合性さえとれれば、他のプログラミング言語を使うこともできる。そのため、プログラマーで Ruby の愛用者であるローラン・サンソネッティは7年間 Apple で働いた後、2012年に新しいベンチャーを立ち上げた。彼らは Ruby で iOS アプリケーションのプログラムを書けるようにしたインターフェース、RubyMotion を世に送り出したのだ。
プログラミング言語が広まるなかで、Ruby は広く愛された。英語のように読むことができ、構文はほとんど必要ない。しかし RubyMotion は決して流行することはなかった。
「うまく動かないと、やはり下層にいって、根底にあるObjective -C に手を加えなくてはならない」とポラックは言う。「だから効率的に iOS アプリケーションを構築するには Ruby と Objective-C の両方、さらに Cocoa フレームワークも知らなくてはならなくなる。だからみんな、『Objective -C だけを使ったほうがいいじゃないか』となるのだ」
ある意味で Swift は、RubyMotion が行った実験の、アップルによる公式バージョンのようなものだ。Swift は Objective -C ライブラリ、Cocoa 、そしてCocoa Touch フレームワークと直接相互作用する言語で、より簡素化されている。結局、ほとんど全てのSwift ユーザーは引き続き Objective -C を学ぶ必要があるだろう。だとしたら、既に知っている Objective -C だけに専念したほうが良いのではないか。これが、ポラックが急速に切り替えが進むことを期待していない理由だ。
「新しい言語には学習曲線というものがつきまとう」とポラックは言う。「大きな企業がSwift を取り入れるには何年もかかるだろう。そういった企業には長年にわたってObjective -C で作業してきた大規模なアプリケーションが存在する。すでにObjective -C の開発者も雇われているだろう。なぜ彼ら全員に、まだ実績のない言語である Swift を習得させる手間を掛けなければならないのだ」
Swift の約束
もちろんSwift には、RubyMotion にとっては夢でしかなかった利点がいくらかある。RubyMotion を考案したのは元開発者だが、Swift は アップル自身が手をかけて生み出したものだ。RubyMotion は Ruby on Rails と連動するよう設計され、iOS の開発フレームワークのためには手を加える必要があった。アップルによれば、Swift は Cocoa および Cocoa Touch と「シームレスな互換性」を提供しているということだ。
Objective -C を使うと作業の妨害が起こりやすい。アプリケーションの実行テストをするまでエラーを警告してくれないのだから。変数を作って値を割り当てるのを忘れたとして（よくやりがちだ）、その変数を計算で使おうとした場合、そこで発生するエラーはアプリケーションのクラッシュの原因になりかねない。一方 Swift は、値が割り当てられていない変数を使おうとしたら、あらかじめ警告してくれる。プログラムがクラッシュした原因を探すという頭痛の種を取り除き、時間を節約してくれるのだ。
Swift はまた、その速度においても Objective -C に勝っている。ソートやループといったObjective -C の処理には、内部で繰り返し呼び出される多くの関数のせいで固有の遅れが発生する。コンパイラは関数やオブジェクトがどのように使われているかが分からず、試行が繰り返されるからだ。しかし、Swift 専用に構築されたコンパイラの最適化により、Swift のコードの実行はObjective -C よりも格段に速くなったとアップルは言っている。
つまり、Swift で構築されたアプリケーションはエンドユーザーにとっても、速くなめらかなものになり得る。Code School の iOS 専門家、ジョン・フリスキックは、Swift でコーディングされたゲームやアニメーションが速くなっていることに、ユーザーも気が付くだろうと予測している。
「最適化はコンパイルの速度を上げたりエラーの発生を減らすだけでなく、アプリケーションそのものも高速化する」と彼は言う。「アニメーションのようにコンピューターに負荷がかかるタスクは多少スムーズに動くようになりそうだ」
Swift はまだ生まれたばかりのコーディング言語だ。おそらくは既にバグも報告されているに違いない（そう、コンピューター言語にもバグはある）。Apple とベータ版のテスターがそれを直しながら、数多くの試行錯誤と改良を重ねていくことだろう。
そして Swift は、RubyMotion にはなかった大きな切り札を持っている。アップルの正式な製品であるという点だ。アップルは自社の API を、新しい言語に合うように変更することもできるのである。もし Swift が期待に応えるものになったら、アップルは次第にObjective –C への依存をやめて、 Cocoa API を Swift に書き直していくに違いない。それが実現したとき、Swift はアップル唯一の開発言語となり、多数のプログラマーが必ず習得しなければならないものになるだろう。
Swift には iOS の開発を容易にする可能性と、楽しいものにしてくれるという希望がある。少なくともポラックは次のように予測している。
今後数年の内に人々は Swift だけを習得すればよくなり、Objective -C を学ぶ必要はなくなる。そうなればアプリケーション開発者になるための苦痛はかなり軽減されるはずだ。プログラムは人々にとって習得しやすく面白いものとなり、iOS の開発者になることは今よりもずっと楽しくなるだろう。
Lauren Orsini
[原文]
※本記事はReadWrite Japanからの転載です。転載元はこちら
