アプリケーション開発の手助けにならないと思います。以前は、アップルのフレームワークを使ってプログラムを書くのに守るべき作法(イディオム)がありました。いくつか挙げてみましょう。連続したメッセージを送信する。メッセージを送信する。カウントを増減させる。メッセージを送信する。オブジェクトを介して行う。これらの作法は、文法や言語仕様ではわかりません。ドキュメントを読む必要があります。不思議なことではなく、どんなライブラリにも順序立てて行わなければならない処理はあります。その他一つか二つのクラスと、メッセージ送信機構程度です。使われておらず、オブジェクトの生成、解放処理からして同フレームワークで実装されています。それくらい素っ気ない代物ですから、同フレームワークを使うためには、まず上記の作法を知ることから始まります。アプリケーションの開発を即座に始められるのかと言うと、大抵の人は難しいでしょう。受け継いだ洗練されたフレームワークだ」とも称賛される反面で、必然的に上記のような作法を生みました。確かに作法を守るととても楽に開発が進むのですが、私は今となってはこれらの作法はバッドノウハウだと思います(これを広げちゃうと、ライブラリはすべてバッドノウハウになってしまいますけどね)。呼ぶバージョンアップを行いました。ブームに乗った節操のない会社ですが、その変更内容は進化というより、これまでのバッドノウハウの取り込みです。使えないという中途半端な機能です。進化に見えなくもなさそうですけど、イテレーションのイディオムの最適化って進化に含めていいんでしょうか。アップルもコンパイラを握ってきたベンダーです。いう高価な商用製品もありましたし、高速にコレクション要素を列挙する必要性を痛感する機会も、導入する機会もいくらでもあったはずです。フレームワークの機構を利用した、インスタンス変数管理のノウハウの仕様化+αです。年になるまで行われなかった」とも言えるのかもしれません。コードの見た目は少し変わりました。回す」処理を文法として組み込みました。アプリケーションの開発に特化した仕様変更だと言えると思います(ただし、この仕様はアップルのフレームワークから独立しています。任意のライブラリで利用可能です)。使っているのはこの会社です。由来するメッセージ送信メタファーがやや崩れました。「崩れた」とか「逸脱した」とかいう表現は外部者の勝手な失望であって、アップルは「(一部の仕様において)メッセージ送信メタファーを『切り捨てた』=不要だと判断した」が実際です。空気ががらりと変わったということもなく、それだけを見れば些細な変更です。聞いて、「十年遅いんだよ」と思ったのは私だけでしょうか。自画自賛もいいとこです。スクリプト言語を作ろうとしたことはあります)。ある必要性が薄れるらしいです。特徴と言えばこんなところでしょうか。互換にかなり引きずられてしまっている感はありますが、そこは膨大な資産を活用しなければならないので仕方がない面もあるのでしょう。書かなくて済む」ようになりました。書く必要がなくなっていた」のではないかと思います。ライブラリと連携する必要がない)と思います。スペシャリストである必要はないでしょう。速いネイティブコードを吐く言語があればいい話です。」と言われればその通りなんですが、でもそんなの今更気が付くことでもないだろ?と思います。アップルにそこを解決するだけの技術力がなかったと言うのであれば無理な相談です。一つの大きな特徴は、強い静的型付けと型推論です(型推論があってもかなり面倒そうですけど)。ああ、あとクロージャーですか。クロージャーについては後述します。静的型付けはあまり強くありません。型へのキャストが可能で、宣言された型はせいぜい目安にしかなりません。総称型もないので、コレクションの要素の型がわかりません。対してメッセージを送ってもエラーにならず、その処理が無視されます(コンパイラオプションでエラーにできることはできます)。関しては、これを利用してコード量を短縮するスタイルが主流でしたので、ダメだったと言い切れない面もあります。チェックに慣れた人にすれば余計な仕様でしょう。いう名前を使ったことと、オプショナル型に関する演算子の多さは、「奥が深い症候群」を発症させる原因に見えなくもないです。事を面倒にしただけだと思います)。一つ、どうでもいい疑問があります。延長線上にある言語にしてもよかったのではないかと思います。開発コストも学習コストも下げられますし。この形になったのは、今後の開発を見据えてとか関数型言語やら型推論付きの強い型付けやらの流行に乗ってなどいくつも理由があるでしょうけど、ぶっちゃけ世間がオブジェクト指向言語に飽きたからなんじゃないかなと思わなくもないです。ライセンスを得て、自社製品の販売は続けていたようです)。