Swift vs. Objective-C:将来がSwiftを支持する10の理由

プログラミング言語は簡単に死ぬことはありませんが、衰退するパラダイムに固執する開発ショップは死にます。モバイルデバイス用のアプリを開発していて、Swiftを調査していない場合は、次の点に注意してください。Mac、iPhone、iPad、Apple Watch、および今後のデバイス用のアプリの開発に関しては、SwiftはObjective-Cに取って代わるだけではありません。ただし、Appleプラットフォームでの組み込みプログラミングのCも置き換えられます。

いくつかの重要な機能のおかげで、Swiftは、没入型で応答性の高い、消費者向けのアプリケーションを今後何年にもわたって作成するための事実上のプログラミング言語になる可能性があります。

AppleはSwiftに大きな目標を持っているようだ。コンパイラのパフォーマンスと開発用の言語を最適化し、SwiftのドキュメントでSwiftが「「hello、world」からオペレーティングシステム全体に拡張できるように設計されている」ことをほのめかしています。Appleはまだこの言語のすべての目標を表明していませんが、Xcode 6、Playgrounds、およびSwiftのリリースは、他の開発ツールチェーンよりもアプリ開発をより簡単で親しみやすいものにするというAppleの意図を示しています。

今すぐSwiftを使い始めて、ゲームを先取りする10の理由を次に示します。

1.Swiftは読みやすい

Objective-Cは、Cで構築された言語に期待されるすべての問題を抱えています。キーワードとタイプをCタイプと区別するために、Objective-Cは@記号を使用して新しいキーワードを導入しました。SwiftはC上に構築されていないため、すべてのキーワードを統合し、すべてのObjective-Cタイプまたはオブジェクト関連キーワードの前にある多数の@記号を削除できます。

Swiftは従来の規則を廃止します。したがって、行を終了するためのセミコロンや、if / elseステートメント内の条件式を囲むための括弧は不要になりました。もう1つの大きな変更は、メソッド呼び出しが相互にネストしないため、ブラケットが地獄になってしまうこと[[[ ]]]です。Swiftのメソッドと関数の呼び出しでは、括弧内に業界標準のコンマ区切りのパラメーターリストが使用されます。その結果、構文と文法が簡素化された、よりクリーンで表現力豊かな言語が実現します。

Swiftコードは、他の最新の人気のあるプログラミング言語に加えて、自然な英語にさらに似ています。この読みやすさにより、JavaScript、Java、Python、C#、およびC ++の既存のプログラマーは、Objective-Cであった醜いアヒルの子とは異なり、Swiftをツールチェーンに簡単に採用できます。

2.スイフトはメンテナンスが簡単です

レガシーはObjective-Cを妨げるものです—言語はCが進化することなしに進化することはできません。Cでは、実行可能アプリの作成のビルド時間と効率を向上させるために、プログラマーが2つのコードファイルを維持する必要があります。これは、Objective-Cに引き継がれる要件です。

Swiftは2ファイルの要件を削除します。XcodeとLLVMコンパイラは、Swift 1.2で依存関係を把握し、インクリメンタルビルドを自動的に実行できます。その結果、目次(ヘッダーファイル)を本文(実装ファイル)から分離するという繰り返しの作業は過去のものとなりました。Swiftは、Objective-Cヘッダー(.h)と実装ファイル(.m)を1つのコードファイル(.swift)に結合します。

Objective-Cの2ファイルシステムは、プログラマーに追加の作業を課します。そして、それはプログラマーを全体像からそらす作業です。Objective-Cでは、できれば標準の規則を使用して、ファイル間でメソッド名とコメントを手動で同期する必要がありますが、チームがルールとコードレビューを実施しない限り、これは保証されません。

XcodeとLLVMコンパイラーは、プログラマーの作業負荷を軽減するために舞台裏で作業を行うことができます。Swiftを使用すると、プログラマーは簿記を少なくし、アプリロジックの作成により多くの時間を費やすことができます。Swiftは定型的な作業を削減し、サポートされているコード、コメント、および機能の品質を向上させます。

3.Swiftの方が安全です

Objective-Cの興味深い側面の1つは、ポインター(特にnil(null)ポインター)の処理方法です。Objective-Cでは、nil(初期化されていない)のポインター変数を使用してメソッドを呼び出そうとしても何も起こりません。式またはコード行は操作なし(操作なし)になり、クラッシュしないことは有益に思えるかもしれませんが、バグの大きな原因となっています。何もしないと、予期しない動作が発生します。これは、ランダムなクラッシュを見つけて修正したり、異常な動作を止めたりしようとするプログラマーの敵です。

オプションタイプを使用すると、Swiftコードでnilオプション値の可能性が非常に明確になります。つまり、不正なコードを記述したときにコンパイラエラーが発生する可能性があります。これにより、短いフィードバックループが作成され、プログラマーは意図的にコーディングできます。コードを書くときに問題を修正できます。これにより、Objective-Cのポインターロジックに関連するバグの修正に費やす時間と費用が大幅に削減されます。

従来、Objective-Cでは、メソッドから値が返された場合、返されたポインター変数の動作を文書化するのはプログラマーの責任でした(コメントとメソッドの命名規則を使用)。Swiftでは、オプションの型と値の型により、値が存在するかどうか、またはオプションになる可能性があるかどうか(つまり、値が存在するか、nilであるか)がメソッド定義で明示的に明確になります。

予測可能な動作を提供するために、nilオプション変数が使用されている場合、Swiftはランタイムクラッシュをトリガーします。このクラッシュは一貫した動作を提供し、プログラマーに問題をすぐに修正するように強制するため、バグ修正プロセスを容易にします。Swiftランタイムのクラッシュは、nilオプション変数が使用されているコード行で停止します。これは、バグがより早く修正されるか、Swiftコードで完全に回避されることを意味します。

4.Swiftはメモリ管理と統合されています

Swiftは、Objective-Cにはない方法で言語を統合します。自動参照カウント(ARC)のサポートは、手続き型およびオブジェクト指向のコードパス全体で完全です。 Objective-Cでは、ARCはCocoaAPIとオブジェクト指向コード内でサポートされています。ただし、手続き型CコードやCoreGraphicsなどのAPIでは使用できません。これは、iOSで利用可能なCore Graphics APIやその他の低レベルAPIを使用する場合、メモリ管理を処理するのはプログラマーの責任になることを意味します。プログラマーがObjective-Cで発生する可能性のある巨大なメモリリークは、Swiftでは不可能です。

プログラマーは、作成するすべてのデジタルオブジェクトのメモリについて考える必要はありません。 ARCはコンパイル時にすべてのメモリ管理を処理するため、メモリ管理に向けられたであろう頭脳は、代わりにコアアプリロジックと新機能に集中することができます。 SwiftのARCは、手続き型コードとオブジェクト指向コードの両方で機能するため、プログラマーが低レベルのAPIにアクセスするコードを記述している場合でも、プログラマーがメンタルコンテキストスイッチを必要としません。これは、Objective-Cの現在のバージョンの問題です。

自動で高性能なメモリ管理は解決された問題であり、Appleはそれが生産性を向上させることができることを証明しました。もう1つの副作用は、Objective-CとSwiftの両方で、Java、Go、C#などの未使用のメモリのクリーンアップを実行するガベージコレクターの影響を受けないことです。これは、特にiPhone、Apple Watch、iPadなどの触覚デバイス(ラグがイライラし、ユーザーにアプリが壊れていると感じさせる)で、応答性の高いグラフィックスとユーザー入力に使用されるプログラミング言語にとって重要な要素です。

5.Swiftはより少ないコードを必要とします

Swiftは、繰り返しのステートメントと文字列操作に必要なコードの量を減らします。 Objective-Cでは、テキスト文字列の操作は非常に冗長であり、2つの情報を組み合わせるには多くの手順が必要です。 Swiftは、Objective-Cにはない「+」演算子を使用して2つの文字列を追加するなど、最新のプログラミング言語機能を採用しています。このような文字と文字列の組み合わせのサポートは、画面上でユーザーにテキストを表示するプログラミング言語の基本です。

Swiftの型システムは、コンパイラーが型を理解できるため、コードステートメントの複雑さを軽減します。一例として、Objective-Cのは、特殊な文字列トークンを(記憶するプログラマを必要とする%s%d%@)各トークンを交換するための変数のコンマ区切りのリストを提供します。 Swiftは文字列補間をサポートしているため、トークンを記憶する必要がなく、プログラマーはラベルやボタンのタイトルなど、ユーザー向けの文字列に直接インラインで変数を挿入できます。型推論システムと文字列補間は、Objective-Cで一般的なクラッシュの一般的な原因を軽減します。

Objective-Cでは、順序を台無しにしたり、間違った文字列トークンを使用したりすると、アプリがクラッシュします。ここでも、Swiftは、テキスト文字列とデータの操作をインラインでサポートしているため、簿記の作業から解放され、書き込むコードが少なくなります(コードのエラーが発生しにくくなります)。

6.Swiftの方が速い

従来のC規則を廃止することで、Swiftの内部が大幅に改善されました。Swiftコードのパフォーマンスのベンチマークは、Swiftがアプリロジックを実行できる速度を改善するためのAppleの献身を示し続けています。

人気のGeekBenchパフォーマンスツールのメーカーであるPrimateLabsによると、Swiftは、マンデルブロアルゴリズムを使用して、2014年12月にコンピューティングバウンドタスクのC ++のパフォーマンス特性に近づいていました。

2015年2月、Primate Labsは、Xcode 6.3 BetaがSwiftのGEMMアルゴリズム(大規模アレイへのシーケンシャルアクセスを備えたメモリバウンドアルゴリズム)のパフォーマンスを1.4倍改善したことを発見しました。最初のFFT実装(大きな配列にランダムアクセスするメモリバウンドアルゴリズム)では、パフォーマンスが2.6倍向上しました。

ベストプラクティスを適用することにより、Swiftでさらなる改善が観察され、FFTアルゴリズムのパフォーマンスが8.5倍向上しました(C ++のパフォーマンスが1.1倍向上しただけです)。この機能強化により、SwiftはマンデルブロアルゴリズムのC ++をわずか1.03倍上回りました。

Swiftは、FFTアルゴリズムとMandelbrotアルゴリズムの両方でC ++とほぼ同等です。Primate Labsによると、GEMMアルゴリズムのパフォーマンスは、SwiftコンパイラがC ++コンパイラができるコードをベクトル化できないことを示唆しています。これは、Swiftの次のバージョンで達成できる簡単なパフォーマンスの向上です。

7.オープンソースプロジェクトとの名前の衝突が少ない

Objective-Cコードを悩ませてきた問題の1つは、名前空間の正式なサポートがないことです。これは、コードファイル名の衝突に対するC ++のソリューションでした。この名前の衝突がObjective-Cで発生した場合、それはリンカーエラーであり、アプリを実行できません。回避策は存在しますが、潜在的な落とし穴があります。一般的な規則は、2文字または3文字のプレフィックスを使用して、たとえばFacebookによって記述されたObjective-Cコードと独自のコードを区別することです。

Swiftは、ビルドの失敗を引き起こしたり、NSString(次のステップ—Appleから解雇された後のSteveJobsの会社)やCGPoint(Core Graphics)のような名前を必要とせずに、同じコードファイルが複数のプロジェクトに存在できるようにする暗黙の名前空間を提供します。最終的に、Swiftのこの機能により、プログラマーの生産性が向上し、Objective-Cに存在する簿記を行う必要がなくなります。 Objective-Cに名前空間がないことから生まれたNSArray、NSDictionary、NSStringの代わりに、Array、Dictionary、Stringなどの単純な名前でSwiftの影響を確認できます。

Swiftでは、名前空間はコードファイルが属するターゲットに基づいています。これは、プログラマーが名前空間識別子を使用してクラスまたは値を区別できることを意味します。Swiftのこの変更は巨大です。オープンソースプロジェクト、フレームワーク、ライブラリをコードに組み込むのが非常に簡単になります。名前空間により、さまざまなソフトウェア会社が、オープンソースプロジェクトを統合する際の衝突を心配することなく、同じコードファイル名を作成できます。これで、FacebookとAppleの両方が、エラーやビルドの失敗なしにFlyingCar.swiftというオブジェクトコードファイルを使用できるようになりました。

8.Swiftはダイナミックライブラリをサポートします

十分な注目を集めていないSwiftの最大の変更点は、メジャーポイントリリース(iOS 8、iOS 7など)で更新される静的ライブラリから動的ライブラリへの切り替えです。ダイナミックライブラリは、アプリにリンクできる実行可能なコードのチャンクです。この機能により、現在のSwiftアプリは、時間の経過とともに進化するSwift言語の新しいバージョンとリンクできます。

開発者は、ライブラリと一緒にアプリを送信します。ライブラリは両方とも、整合性を確保するために開発証明書でデジタル署名されています(こんにちは、NSA)。これは、Swiftが最新のプログラミング言語の要件であるiOSよりも速く進化できることを意味します。ライブラリへの変更はすべて、App Storeのアプリの最新アップデートに含めることができ、すべてが簡単に機能します。

ダイナミックライブラリはMacで非常に長い間サポートされてきましたが、SwiftとiOS 8がリリースされるまで、iOSでダイナミックライブラリがサポートされることはありませんでした。ダイナミックライブラリはアプリ実行可能ファイルの外部にありますが、AppStoreからダウンロードされたアプリバンドルに含まれています。外部コードは使用時にのみリンクされるため、アプリがメモリに読み込まれるときにアプリの初期サイズが小さくなります。

Apple Watchのモバイルアプリまたは埋め込みアプリへの読み込みを延期する機能により、ユーザーに認識されるパフォーマンスが向上します。これは、iOSエコシステムの応答性を高める特徴の1つです。Appleは資産とリソースのみをロードすることに重点を置いており、今ではその場でコードをコンパイルしてリンクしています。オンザフライの読み込みにより、画面に表示するためにリソースが実際に必要になるまでの初期待機時間が短縮されます。