モバイル

Swiftプログラミングの学習：プライムタイムの準備はできていますか？

りんご今年の6月のスイフトを発売、書くための新しいプログラミング言語 iOSアプリ、全体に大きな話題と興奮を生み出しました iOS開発者コミュニティ。

発売以来、多くのiOS開発者は、Objective-CからSwiftに移行するかどうか、どのように、いつ移行するかという問題に苦労してきました。もちろん、その質問に対する答えは、チームやプロジェクトごとに異なります。

あなたが読むことができる多くの記事があります Swiftの利点。そのため、この記事では、同じ点を再ハッシュする代わりに、Swiftを使用したアプリ開発を学ぶ前に検討する必要のあるいくつかの懸念事項に焦点を当てます。

Swiftを使用したプログラミングは、プライムタイムの準備ができている場合とできない場合があります。Swift言語をもう習得しましたか？

しかし、最初に、時計を少し戻しましょう…

Swiftの前：Objective-Cを使用すると、気に入るはずです…

年は2010年でした。 iPhone まだ3歳ではなく、iPhone用のネイティブアプリを作成する機能は約2年しかありませんでした。その年の4月8日、AppleはiPhoneOSのバージョンを発表しました。 iPhone OS（これは、名前がiOSに変更される前のことです）には、マルチタスク、高速アプリ切り替え、バックグラウンドサービスなどの魅力的な新機能が含まれていました。当然のことながら、iPhone開発者は、新しいSDKを手に入れて、これらすべてのエキサイティングな新機能を試してみたいと考えていました。

しかし、iPhone OS 4SDKには予期しない爆弾が含まれていました。この爆弾はソフトウェアにはなく、使用契約に含まれていました。 iPhone OS 4 SDKでは、開発者契約のセクション3.3.1は更新しました次の厄介な言葉を含めるには：

アプリケーションは元々Objective-C、C、C ++で記述されている必要があり、C、C ++、Objective-Cで記述されたコードのみがコンパイルされ、ドキュメント化されたAPIに直接リンクできます。
– iPhone OS 4SDK開発者契約のセクション3.3.1

言うまでもなく、この新しい制限は多くの開発者を驚かせました。変更の公式の理由は、スティーブジョブズ自身によって提供されたは、最近発表されたFlashCS5などのクロスプラットフォームツールの使用を防ぐためでした。 Jobsは、「プラットフォームと開発者の間の中間層は、最終的に[原文のまま]標準以下のアプリを作成する」と述べたと伝えられています。しかし、これらの「中間層」と戦うためのAppleのアプローチが、iPhoneアプリの作成に使用できるプログラミング言語を制限することであったという事実は、Appleの考え方についてさらに何かを明らかにしました。Objective-Cは誰にとっても十分であるはずです。

Objective-CがTiobeIndexの「ProgrammingLanguageof the Year」賞を受賞したため、この主張に同意することは許される可能性があります。 2年連続。しかし現実には、Objective-Cの人気は、成長するアプリエコシステムの機能であり、その逆ではありませんでした。 2010年にさえ、多くの人々がすでにObjective-Cに不満を持っており、その結果、iPhoneアプリを作成する別の方法がありました。他のプログラミング言語ですでに収穫されていました。

最終的に、開発者コミュニティ全体からの圧力の下で、Apple セクション3.3.1へのこれらの変更を取り消しましたわずか5か月後のSDK開発者契約のそれでも、メッセージは明確でした。iPhone用のアプリを作成したい場合は、おそらくObjective-Cを使用する必要があります。

… またはそうでないかもしれません。新しいiOS言語Swiftを入力します。

その事件からAppleが開発者に新しい言語を紹介した2014年6月までの4年間を早送りします。迅速。 4年前のメッセージがAppleがObjective-Cに完全に満足しているというものだった場合、Swiftの紹介によって送信されたメッセージは、Appleがついに真実を認める準備ができたというものでした。 Objective-Cは、モバイルアプリを作成するのに必ずしも最適な言語であるとは限りません。

SwiftがObjective-Cよりも「現代」の言語である方法については多くのことが言われています。 Swiftプログラミング言語の学習方法に興味がある場合は、 Objective-CからSwiftに移行するためのガイド。

ただし、Objective-C言語とSwift言語の間には2つの重要な違いがあることに注意してください。

スウィフトはない C言語の厳密なスーパーセット。
Swiftは静的に型付けされ、ない動的に型付けされます。

Cの厳密なスーパーセットではないということは、Swiftが他の方法では許可されない構文構造を自由に利用できることを意味します。これはそれを可能にします、例えば、Swiftでカスタム演算子を実装します。

静的に型付けされるということは、Swiftが次のような言語によって開拓された型システムの最近の進歩の多くを利用できることを意味します。 Haskell 。

されていたにもかかわらず 4年間開発中 Swiftは、一般に公開される前はまだ若いプログラミング言語であるため、いくつかの注意点があります。

Objective-Cとの互換性

iOSはOSXと共通の遺産を共有しており、OSXはその歴史を次の一歩 1989年に最初にリリースされたオペレーティングシステム。NeXTSTEPは元々Objective-Cで作成されており、OS XおよびiOSのコアライブラリの多くは、これらの元の実装にまでさかのぼります。（ちなみに、これはNSStringなどのコアクラスにあるユビキタスな「NS」プレフィックスの由来です。）Swiftは理論的にはこれらのコアライブラリがなくても存在する可能性がありますが、実際には、Swiftプログラムを作成する可能性があります。近い将来、Objective-Cとのインターフェースが必要になります。

彼らの名誉のために、Swiftの背後にいる開発者は、既存のObjective-Cライブラリとの対話を可能な限り簡単にする素晴らしい仕事をしました。しかし、それはプロセスが完全に痛みがないということではありません。アップルは役立つガイド SwiftからObjective-Cコードを呼び出す方法、およびその逆の方法を説明しますが、注意すべき重要なインピーダンスの不一致がいくつかあります。

おそらく最も明らかな不一致はヘッダーファイルに関連しています。 Objective-Cは、Cのルートがあるため、呼び出される前に関数を宣言する必要があります。ライブラリを呼び出すと、これらの宣言はライブラリのヘッダーファイルにあります。ただし、Swiftはヘッダーファイルを使用しません。したがって、Objective-CからSwiftコードを呼び出す場合は、最初に「ブリッジヘッダー」を作成する必要があります。概念的にはこれはそれほど複雑に見えないかもしれませんが、実際には、実際にはかなりのタスク。

SwiftとObjective-Cの間のインターフェースにおける別の一連の問題は、それらの型システムの固有の違いに起因します。 Swiftは、他の現代言語からヒントを得て、nilの概念を廃止しました。その代わりに、Swiftのオプションタイプがあります。たとえば、ファイルがすでに存在する場合にのみファイルを開くメソッドの戻り値の型はFile?です。（Fileだけでなく）Swiftで。型がオプションであるすべての場所を追跡することにより、Swiftコンパイラは恐ろしい「ヌルポインタエラー」に遭遇することを事実上不可能にすることができます。それはもちろん、Objective-Cを呼んでいない限りです。 Objective-Cはnilを返さないことについてそのような保証をしないので、Swiftにはと呼ばれるタイプの特別なカテゴリがあります 暗黙的にアンラップされたオプション これは、Objective-Cコードを呼び出すときに使用されます。これらのタイプは、存在チェックに必要なすべての付随するオーバーヘッドとともに、Swift言語ではオプションとして扱うことができます。または、オプション以外のタイプと同じように使用できますが、Objective-Cの場合 しますか nilを返しますランタイムエラーが発生するため、Swiftのコンパイル時の安全性の保証の一部が失われます。

最後に、SwiftとObjective-Cの間でプログラミングするときに考慮すべきもう少し微妙な不一致は、これら2つの言語でオブジェクトとクラスが内部で作成される方法と関係があります。 Objective-Cは、その動的な性質により、動的ディスパッチを利用してオブジェクトのメソッドを呼び出します（objc_msgSendを介して）。確かにスイフト できる 動的ディスパッチを使用しますが、静的に型指定されるため、vtableを使用するオプションもあります。各メソッドの関数ポインタを格納します。 Swiftが使用するこれら2つのメカニズムのどちらが、いくつかの要因に依存します。 Plane OldSwiftオブジェクトはvtableを使用しますクラスまたはクラス内のメソッドに@objcを使用して注釈が付けられていない限り、メカニズムSwift属性。 Objective-Cクラスから継承するSwiftクラスは、継承されたメソッドに動的ディスパッチを使用しますが、サブクラスによって導入された新しいメソッドには使用しません（ただし、ここでも、@objc属性を使用して動的ディスパッチの使用を強制できます）。とにかく、Swiftコードは常にSwiftクラスで機能しますが、Objective-Cコードは、適切に注釈が付けられたSwiftオブジェクトとメソッドのみを利用できます。

Objective-Cよりも速いですか？

Appleが発売を発表したとき、特に強調されたSwiftの利点の1つは、その速度でした。これは、AppleがObjective-Cから高級言語に切り替えることを躊躇する理由の1つとして、本質的にCの拡張機能であるObjective-Cが、はるかに高速で効率的なプログラムを作成できることを考えると理解できます。 PythonやRubyのようなものよりも。それでも、Objective-Cは絶対的なパフォーマンスに関してはロケット船ではなく、その多くは動的型付けに起因する可能性があります。したがって、Swiftが静的型システムを採用している場合、Swiftは すべき 少なくともObjective-Cと同じか、それよりも速くなります。

もちろん、ことわざが行く、「嘘には、嘘、大嘘、ベンチマークの3種類があります。」（またはそのようなもの…）確かに、多くの理由 Swift言語はより速く実行される可能性があります。残念ながら、SwiftがAppleを利用する方法は ARC（自動参照カウント）メモリ管理の手法により、Swiftのコンパイラが生成されることがあります 大幅に 遅いプログラム、特に最適化設定が低い場合（開発中に使用する可能性があるものなど）。良いニュースは、Swiftの改善がこの問題に継続的に対処する、したがって、近い将来、SwiftはObjective-Cと少なくとも同じかそれよりも高速に実行可能ファイルを生成する可能性があります。

ただし、Swiftの速度には別の注意点があります。 Swiftの要点は、開発者が しません Objective-Cで書いていたのと同じコードを書いている。これはパフォーマンスにとって何を意味しますか？まあ、確かにそれはSwiftとObjective-Cのパフォーマンスを比較することはもっと関与する単純なベンチマークが明らかにすることができるより。また、生成された実行可能ファイルの絶対実行時パフォーマンスを比較しても、話の半分しかわかりません。

誰もが高速なプログラムを望んでいますが、多くの場合、開発速度は、それ以上ではないにしても、重要です。より表現力があり、より少ないコード行でより多くの作業を実行できる言語は、この点で大きなメリットになります。一方、編集-コンパイル-実行-デバッグのサイクルがプログラマーの1日の大半を占めるコンパイル言語で作業する場合、遅いコンパイラーは実際に生産性を損なう。証拠は主に逸話的ですが、Swiftコンパイラは現在、特にSwiftの高度な型システムを実行するコードを操作する場合は、煩わしいほど遅いようです。あるグループは、コンパイル速度がスイッチを動機付けるのに十分問題があることさえ発見しました Objective-Cに戻る。

コンパイラ

Swiftコンパイラーと言えば、新しいSwift言語への切り替えを検討する際には、それ自体がさらに多くの警告の原因になります。コンパイル速度は別として、SwiftがAppleでそれを使って作業している開発者の小さな幹部から現れ、大衆に解き放たれるにつれて、コンパイラーはストレスの下で亀裂を示し始めました。全体もあります GitHubリポジトリ Swiftコンパイラをクラッシュさせるコードの例を収集することに専念しています。

Swiftコンパイラがどのように変更されるかという問題もあります。別の GitHubのプロジェクトは、Swiftにどのような変更が加えられるかについて、コミュニティから推測と分析を収集しています。たとえば、カスタムオペレーターは、パーサーに大きな負担をかける可能性があります。当初、Swiftのカスタム演算子は疑問符（？）文字を使用できませんでした。これは最新のSwiftリリースで修正されていますが、Swift開発者の成長するコミュニティからのリクエストは引き続きストリーミングされます。さらに柔軟性有効なカスタム演算子と見なすことができるもので。

あなたがそれを聞くときはいつでも パーサー 言語が流動的であるため、それはあなたに一時停止を与えるはずです。言語のパーサーは、プログラミング言語の核心です。コードに意味を与えるために言語セマンティクスを適用する前に、最初に有効なコードとそうでないコードを決定するのはパーサーです。それで、Appleが持っていることは励みになります約束した Swiftのランタイム互換性をある程度確保するため。ただし、XcodeやiOSの新しいリリースごとに再コンパイルせずにSwiftコードが実行されることを必ずしも保証するものではありません。また、Swiftの将来のリリースとの互換性を維持するために、Swiftコードの一部を書き直す必要がないことを保証するものでもありません。しかし、繰り返しになりますが、このプロセスを可能な限り無痛にするというAppleの取り組みは、少なくともいくつかの小さな慰めです。

コミュニティ

これまでに作成された最悪のプログラミング言語のいくつか（名前は付けられないままです）は、常識がそれぞれのコミュニティの力だけで失敗したテクノロジーのゴミ箱に追いやられるべきだと言ってからずっと後のことです。同時に、コミュニティの不足のために定着しなかった本当に素晴らしいプログラミング言語のコレクションは数えきれないほどたくさんあります。強力なコミュニティはチュートリアルを作成し、質問に答えますスタックオーバーフロー、オンラインまたは会議で直接、ストーリー、ヒント、トリックを共有し、便利なライブラリを作成して共有します。プロジェクトに使用する言語を選択するとき、コミュニティは間違いなく考慮すべきものです。

悲しいことに、iOS / Objective-Cコミュニティ最高の評判を持っていません友好的で歓迎してくれて。それは徐々に変化しており、オープンソースはますます増えていますより重要な役割を果たす Objective-Cの開発において。それでも、この初期段階では、Swiftコミュニティが今後どのようになるかを判断するのは困難です。それは主に、公式のApple APIと独自のコードのプライベートコレクションだけで作業する孤立した開発者で構成されますか？それとも、ヒント、コツ、便利なライブラリを共有するグループの活気に満ちたコミュニティになるのでしょうか。

コミュニティの役割のもう1つの側面は、Swiftの開発者自身の役割です。プログラミングの全体的な傾向は、プロプライエタリプログラミング言語とプラットフォームからオープンソースソリューションに移行することです。オープンソース開発は、特にプログラミング言語とランタイムのレベルで、真の利点になる可能性があります。 Swift開発者は、Swift言語とランタイムを完全にオープンソース化することを意図していると何度も述べていますが、それはまだ行われていないため、注意が必要です。

とは言うものの、Swiftの背後にいる開発者は、長期にわたる開発者の一部です。 LLVM 事業。 LLVMは、イリノイ大学アーバナシャンペーン校のプロジェクトとしてオープンで活動を開始したため、完全なアナロジーではありません。しかし、彼らの名誉のために、コア開発者は非常にオープンなままであり、コミュニティとの関わり、それらのほとんどがAppleで働くように移行した後でも。コミュニティからのパッチや機能の提案が言語に浸透するかどうかはまだ分からないが、Swift言語が（ほとんど）オープンで開発され続けることを期待することは完全に合理的である。

Swiftを学ぶべきですか？

もちろん、ここに「1つのサイズですべてに対応する」という答えはありません。いつものように、仕事に適したツールを選択するには、問題のプロジェクトのすべての詳細についての深い知識が必要です。確かに、現時点では、Objective-CはiOS開発にとって「安全な」選択肢であり続けますが、Swiftは間違いなく検討に値します。

ただし、SwiftがiOS開発にもたらす最も重要な変更は、多くの開発者が初めて、「どの言語を使用すべきか」という質問をすることです。 Apple、Objective-C、およびiOSプラットフォームの歴史を考えると、特に選択がバイナリではないことを考えると、この変更だけでもかなりエキサイティングです。 Appleは彼らの好みを明らかにしましたが、iOS開発者コミュニティ全体は何年にもわたって懸命に働いており、すでにこの質問に対してさらに多くの可能な答えを提供しています。