「他の」プログラミング言語が必要なのはなぜですか。フレームワークを管理できるのでしょうか。
Hacker Newsに関する議論を読んだ後、私は再びプログラミング言語について真剣に考えました。 それは重要ですか、あなたは1つまたはいくつかだけを知っていますか？ 5つの言語を同じようによく理解できますか？ または、少なくとも「知っている」と言ってもいいほどです。
静的型付けを使用してオブジェクト指向言語について話す場合、実際には違いはわずかです。 覚えておく価値があるのは、 メモリ管理だけです。 ガベージコレクターがある場合、ポインターやオブジェクトの削除について特に気にする必要はありません。 パフォーマンスとメモリの一部を犠牲にします（実際、ガベージコレクタはメモリの断片化とセグメンテーションを回避するのに役立つため、常にではありません。また、メモリの占有部分と、次の空きメモリ領域へのポインタで区切られた追加の分散メモリが常にあります。 ） ただし、スタックとヒープ、値、ポインター、オブジェクト間のメッセージングについての理解は、デフォルトのガベージコレクターがない言語から得られます。 実際には、ガベージコレクター（ Boehm GCなど ）を使用できますが、メモリの管理とオブジェクトの解放を支援するスマートポインターやプールなどのパターンがあります。 つまり、両方の「世界」から学べることがあります。メモリを管理する方法、メモリ管理を委任する方法、ガベージコレクションの実行方法を理解することです。 これは非常に便利だと思います。
動的言語について話すと、プログラムを呼び出す前にメソッドまたはフィールドの存在を確認できない場合、開始前に矛盾をコンパイルして特定することに慣れていると、それほど簡単ではないかもしれません。 動的言語を使用すると、オブジェクトを拡張し、システムをより柔軟にし、 不純物を使用し、標準クラスに機能を追加できます。 Rubyを使用すると、モジュールを介して不純物を実装し、クラスの追加メソッドを宣言できます。 これらはすべてRailsで非常に広く使用されています。 Active Recordはmethod_missingを広範囲に使用しますが、それ自体は素晴らしいアイデアです。 Kernel.autoloadも便利なソリューションです。 それ自体がRubyのファクトリーであるオブジェクト（基本的にオブジェクトのインスタンスを返す新しい/初期化メソッド）は、特定のセマンティック負荷も伴います。 これらのことはすべて、一種のパターンであり、言語の方法や機能だけではないようです。つまり、これらのことは他の分野にも適用できるのです。 同じことがScalaの Traitsにも当てはまります。 PythonのRuby Gemsおよびパッケージは、特定の範囲の問題の解決策でもあります（ここでは、リンク用のソースとヘッダーをダウンロードできるAptitude 、 RPM 、 BSD Portsも言及できます）。 Lispの S式もC＃でうまく実装されており、これは特にLINQ以降、非常に多くのことを変更しました。
コードを読むことは、開発者にとって基本的なスキルの1つです。 「自分の」プログラミング言語を非常に快適に使用し、他の人の可能性を見ようとさえしない人を何人か知っています。 しかし、それはそれほど悪くありませんか？ あまり好きではありません。 新しい言語を学習するとき、人々はしばしば言語自体を学習する代わりに、ライブラリのセットまたはフレームワークを研究し始めます。 事実、適切に作成され、適切に機能するオープンソースのフレームワークがある場合、氷山の一角-APIと機能を直接調べる代わりに、コードを開いてその実装を確認し、そこに適用される原則と実践を理解することができますチュートリアルで説明されています。
Rails / Rubyのalias_method_chainストーリーについては誰もが聞いたことがあると思います。 どうやら、同じことが.NETとViewState / Postbackモデルで発生し、ダウンロード間でページの状態を維持しているときに、人々がWeb開発の世界で実装する方が良い、簡単、速いという考えをやめたようです。 Django （Python）のモデルとビューについても同じことが言えます。デフォルトでは、モデルとビューは実際には2つのファイル、models.pyとviews.pyに格納され、多くの開発者はそれらを知らない、または分離することさえできません。 。 そして、C＃の優れたExpression Treesは、LINQ / Enterprise Librariesチームのみが使用したようです。
次に新しいフレームワークを見るときは、何に取り組んでいるかに関係なく、このような機能を実装できるかどうかを自分で確認してください。 そうでない場合は、コードを見て、実装を理解し、どのような理由ですべてが正確に行われ、より良く、より便利に実行できるかを理解してください。 これが常に可能であるとは限りませんが、オープンソースの開発は毎日ますます一般的になっており、ますます多くのタスクをカバーしています。 フレームワークを学習しようとしないでください。 言語を学ぶ。 APIは変更されるため、時間が経つにつれて、独自の問題を解決するために使用されるフレームワークのコードを変更する必要が生じる場合があります。 例として、JSセレクターが機能していないときに最初に思い浮かぶことは何ですか？ 問題の解決策をGoogleで検索した場合、解決されるのはタスクの半分だけです。 2つ目は、コードを読み取り、理解し、デバッグし、問題の根本に到達し、自分の手でソリューションを実装する機能です。
新しい言語はクールで楽しいです。 あなたは再び構文について考え、あなたの認識を変えます。 同様の問題を別の言語でどのように解決できるかを考えて、コードを異なる視点から見ます。 それにもかかわらず、どの言語を学ぶことも、現在使用しているツールのセットをより深く理解し、よりエレガントなソリューションを見つけるのに役立つと思われます。 ただし、APIを学習すれば、十分な時間快適に感じることができますが、すべてを覚えることは不可能であるため、大きなメリットはありません。 主なことは、ライブラリがどのように構成されているか、およびその開発にどのような基本原則が適用されるかを理解することです。
UPD： シルヴィオは賢明なことを言った。 多くを学ぶことができます：
もう1つのフレームワークと何かを解くもう1つの方法を学ぶことはあまり役に立ちません。これらの方法、型、 カテゴリ 、 セットなどの理論を自分で導き出すことができるより一般的な理論を学ぶ必要があります。
ただし、理論の応用問題を解決するだけでは十分ではありません。 また、既存のソリューションを知っておく必要があります。既存のソリューションを基にして考えてください。 適用される問題には、優れた理論的基礎も必要ですが、アプリケーションの経験によって確認する必要があります。
違いは何ですか？
静的型付けを使用してオブジェクト指向言語について話す場合、実際には違いはわずかです。 覚えておく価値があるのは、 メモリ管理だけです。 ガベージコレクターがある場合、ポインターやオブジェクトの削除について特に気にする必要はありません。 パフォーマンスとメモリの一部を犠牲にします（実際、ガベージコレクタはメモリの断片化とセグメンテーションを回避するのに役立つため、常にではありません。また、メモリの占有部分と、次の空きメモリ領域へのポインタで区切られた追加の分散メモリが常にあります。 ） ただし、スタックとヒープ、値、ポインター、オブジェクト間のメッセージングについての理解は、デフォルトのガベージコレクターがない言語から得られます。 実際には、ガベージコレクター（ Boehm GCなど ）を使用できますが、メモリの管理とオブジェクトの解放を支援するスマートポインターやプールなどのパターンがあります。 つまり、両方の「世界」から学べることがあります。メモリを管理する方法、メモリ管理を委任する方法、ガベージコレクションの実行方法を理解することです。 これは非常に便利だと思います。
動的言語について話すと、プログラムを呼び出す前にメソッドまたはフィールドの存在を確認できない場合、開始前に矛盾をコンパイルして特定することに慣れていると、それほど簡単ではないかもしれません。 動的言語を使用すると、オブジェクトを拡張し、システムをより柔軟にし、 不純物を使用し、標準クラスに機能を追加できます。 Rubyを使用すると、モジュールを介して不純物を実装し、クラスの追加メソッドを宣言できます。 これらはすべてRailsで非常に広く使用されています。 Active Recordはmethod_missingを広範囲に使用しますが、それ自体は素晴らしいアイデアです。 Kernel.autoloadも便利なソリューションです。 それ自体がRubyのファクトリーであるオブジェクト（基本的にオブジェクトのインスタンスを返す新しい/初期化メソッド）は、特定のセマンティック負荷も伴います。 これらのことはすべて、一種のパターンであり、言語の方法や機能だけではないようです。つまり、これらのことは他の分野にも適用できるのです。 同じことがScalaの Traitsにも当てはまります。 PythonのRuby Gemsおよびパッケージは、特定の範囲の問題の解決策でもあります（ここでは、リンク用のソースとヘッダーをダウンロードできるAptitude 、 RPM 、 BSD Portsも言及できます）。 Lispの S式もC＃でうまく実装されており、これは特にLINQ以降、非常に多くのことを変更しました。
コードの読み取りと練習
コードを読むことは、開発者にとって基本的なスキルの1つです。 「自分の」プログラミング言語を非常に快適に使用し、他の人の可能性を見ようとさえしない人を何人か知っています。 しかし、それはそれほど悪くありませんか？ あまり好きではありません。 新しい言語を学習するとき、人々はしばしば言語自体を学習する代わりに、ライブラリのセットまたはフレームワークを研究し始めます。 事実、適切に作成され、適切に機能するオープンソースのフレームワークがある場合、氷山の一角-APIと機能を直接調べる代わりに、コードを開いてその実装を確認し、そこに適用される原則と実践を理解することができますチュートリアルで説明されています。
Rails / Rubyのalias_method_chainストーリーについては誰もが聞いたことがあると思います。 どうやら、同じことが.NETとViewState / Postbackモデルで発生し、ダウンロード間でページの状態を維持しているときに、人々がWeb開発の世界で実装する方が良い、簡単、速いという考えをやめたようです。 Django （Python）のモデルとビューについても同じことが言えます。デフォルトでは、モデルとビューは実際には2つのファイル、models.pyとviews.pyに格納され、多くの開発者はそれらを知らない、または分離することさえできません。 。 そして、C＃の優れたExpression Treesは、LINQ / Enterprise Librariesチームのみが使用したようです。
次に新しいフレームワークを見るときは、何に取り組んでいるかに関係なく、このような機能を実装できるかどうかを自分で確認してください。 そうでない場合は、コードを見て、実装を理解し、どのような理由ですべてが正確に行われ、より良く、より便利に実行できるかを理解してください。 これが常に可能であるとは限りませんが、オープンソースの開発は毎日ますます一般的になっており、ますます多くのタスクをカバーしています。 フレームワークを学習しようとしないでください。 言語を学ぶ。 APIは変更されるため、時間が経つにつれて、独自の問題を解決するために使用されるフレームワークのコードを変更する必要が生じる場合があります。 例として、JSセレクターが機能していないときに最初に思い浮かぶことは何ですか？ 問題の解決策をGoogleで検索した場合、解決されるのはタスクの半分だけです。 2つ目は、コードを読み取り、理解し、デバッグし、問題の根本に到達し、自分の手でソリューションを実装する機能です。
結論は？
新しい言語はクールで楽しいです。 あなたは再び構文について考え、あなたの認識を変えます。 同様の問題を別の言語でどのように解決できるかを考えて、コードを異なる視点から見ます。 それにもかかわらず、どの言語を学ぶことも、現在使用しているツールのセットをより深く理解し、よりエレガントなソリューションを見つけるのに役立つと思われます。 ただし、APIを学習すれば、十分な時間快適に感じることができますが、すべてを覚えることは不可能であるため、大きなメリットはありません。 主なことは、ライブラリがどのように構成されているか、およびその開発にどのような基本原則が適用されるかを理解することです。
UPD： シルヴィオは賢明なことを言った。 多くを学ぶことができます：
もう1つのフレームワークと何かを解くもう1つの方法を学ぶことはあまり役に立ちません。これらの方法、型、 カテゴリ 、 セットなどの理論を自分で導き出すことができるより一般的な理論を学ぶ必要があります。
ただし、理論の応用問題を解決するだけでは十分ではありません。 また、既存のソリューションを知っておく必要があります。既存のソリューションを基にして考えてください。 適用される問題には、優れた理論的基礎も必要ですが、アプリケーションの経験によって確認する必要があります。
All Articles