休日としてのJavaScript

この金曜日の記事は、著者がJavaScriptに対する根拠のない批判を提示した現象としてのJavaScript記事への応答です。 個人的に、私はJavaScriptを15年間書いており、これまでで最も強力なPLの1つであると心から思っています。 この記事は、可能であれば、批判の主な点について理にかなった位置を持ちます。初心者はJavaScriptに本当に問題があることが多いからです。 スクリプトの接頭辞と言語の軽薄なイメージは誤解を招きますが、実際には、この言語はフロントエンドおよびバックエンドからデスクトップおよびモバイルアプリケーション、集積回路のプログラミング、ビデオ処理など、さまざまな分野で使用されています。 私は長い間、 JavaScrip t についての一般的な誤解を明らかにしたかったのですが、ここでは理由が明らかになったので、猫の下で歓迎します。



JavaScriptは現在、地球上で最も人気のある言語です。 JavaScriptが（Web上の独占以外で）人気を博した理由は、その民主的な性質です。 手続き型のスタイルで、オブジェクト指向で機能的なプログラミングが可能です。 開発者に最小限の制限を課し、「愚かさ」を実行できるようにします。 しかし皮肉なことに、ナンセンスなことはあるクラスのタスクに適用され、別のクラスに適用されるのは適切以上です。 伝説によれば、JavaScriptは2週間で作成されました。 繰り返しになりますが、このような状況での人生の皮肉は、言語に最も重要なものだけを置くことが可能であり、 余分な 、伝統的な、「正しい」 すべてを残します。 言語の最初のバージョンは非常にコンパクトで簡潔であることが判明しました。 これらのget / set、const、awaitはすべて、後で登場しました。 この言語の最初の原則は非常に優れていたため、10年間（1999年から2009年まで）、言語は何の変更もなく生き続けました。 もちろん、MicrosoftやMozillaのポリシーなど、これには否定的な理由がありましたが、他の人気のある言語の多くが同じテストに合格し、その後上昇することはないと確信しています。 10年間更新されなかった後、TypeScriptまたはRustがどうなるか想像してみてください。 JavaScriptが生き残った理由は非常に単純です;それは1つの問題を解決し、完全にそれをします。



JavaScriptは、構文糖またはクールな機能のセットであると主張していません 。プログラマーは自分で記述/接続できます。 JavaScriptは、デバイスのハードウェアをユーザーから隠し、 ロジックで何でもできるようにし、そのままにしておきます 。 evalが必要ですか-オブジェクトを再定義してください-問題はありません。関数に渡すことは「不可能」です-ようこそ、それはあなたの頭でのみ「不可能」だからです。 GoまたはC＃プログラマーは、なぜこれが良いのか理解するのが非常に難しいと感じています。 彼らの帽子に挑戦しないために、これらは美しい言語であり、まったく異なっています。 古典的に、言語は、型チェック、さまざまな必須のベストプラクティスなど、プログラマーが自分の足を撃てないようにする障壁を設けています。 JavaScriptにはこれらの障壁がなく、どこにでも撃つ権利があり、0.01％の場合、脚で撃つことも理にかなっています。 これはスポーツカーと比較できます。多くの言語では、一部の機能がブロックされていますが、JavaScriptではブロックされていません。 運転が不十分な場合-マイナスや危険などかもしれませんが、言語、アーキテクチャ、パラダイムを実際に理解し、すべての使用方法を知っている場合-一般的なタスクではJavaScriptよりも優れています見つけられない。 プライベートの場合、一般的には、普遍的であり、客観的には不可能です。 多くの人は、Javaでは辞書を作成でき、JSオブジェクトの類似物であり、PythonとRubyも型付けされない、多くのevalとduckの型付けがあるが、JavaScriptのように使いやすいと主張します。 たとえばJavaでは、辞書は型付きのクラス指向フレームワークに追加されるだけであり、JavaScriptでは、これは言語のコアであり、2つの "{}"文字で作成されます。 スポーツカーの場合、アフターバーナーは3つのボタンとレバーではなく、右手の親指の下にある1つのボタンによって呼び出されたようです。 自由は単に可能であるだけでなく、奨励されています。



彼らは額を壊さないように慣れているため、これは多くの人をmany迷に陥れます。 WindowsからLinuxに切り替えるようなものです。 「sudo rm -Rf /と入力すると、すべてが壊れました。 システムではなく、r ...が。」 このような考慮事項により、マスターへのパスは非常に長くなります。 JavaScriptを入力するためのしきい値は非常に低いままであり、多くの初心者は、自分が理解していないものをscる理由を与えています。 さらに、人はLispで20年の経験を持つことができますが、JavaScriptでは、スマートなどのドキュメントを読んでいませんでした。 これは単純なプログラムを書くのに十分ですが、人がなぜ真<2 ===真であり、なぜそれが正しく論理的であるかを理解したい場合、型変換について読む必要があり、理想的にはすべてのドキュメント（または良いフルブック）はそうではありません長い間。



ここで、ポイントに関する批判に答えます。

質問1：シングルスレッドランタイム

これは非常に便利で、オブジェクトのロックと所有権、およびマルチスレッドのその他の機能に問題はありません。 なぜマルチスレッドが必要なのですか？ 長い操作が完了するのを待っている間にプログラムをさらに実行しますか？ Kolbeksはこれをはるかに改善します。 1つの中規模マシン上のNodeJSは、100,000の接続を保持できます。 コールバックをフローアプローチに置き換えた場合、いくつになりますか？ マルチプロセッサマシンでは、jsはローカルクラスターの起動に対応します。 8コア-8プロセス、16コア-16プロセス。それぞれ独立しており、内部は単純です。 これは、800万人のユーザーがいるオンラインゲームのメインサーバーテクノロジーとしてのアプリケーションの実例です。 非同期/スレッドの操作は弱点ではありませんが、JavaScriptの最も強力な利点の1つです。 これには再訓練と習慣の変更が必要かもしれませんが、私を信じてください、あなたは多くを得るでしょう。

質問2：モジュールの実装のための統一システム/標準の欠如

JavaScriptには、モジュールを操作するための2つの主なオプションがあります。

• 公式、輸入を通じて
• そして従来の

どちらの方法もうまく機能し、相互に完全に互換性があります。 好みの方法を選択できます。 たとえば、私はrequireを好むが、それはオーバーライドできるからであり、これはJavaScriptの哲学にもっと沿っている。 これは、たとえば、プリプロセッサを作成するときなどに意味があります。 2つの「主な」オプションは、JavaScriptコミュニティがあらゆる革新に対してオープンであり、モジュールを操作するための3番目、4番目、1000番目のシステムを作成できるためです（多くは既に作成済みです）。 もう1つの質問は、プロジェクトの外部で使用するかどうかです。 記載されている2つの方法は、Web開発の事実上の標準です（標準に興味がある場合）。

質問3：プロジェクトの構造に関する共通の標準の欠如（誰もが望むことをします。ソースコードを理解することは非常に困難です）

私は「彼らが望むことをする」同僚に同情します。 またはあなたと同僚。 原則として、Web開発にはいくつかの典型的なプロジェクト構造がありますが、そのうちの1つが使用されますが、これはどこにも仮定されておらず、都合の良い見方に基づいて誰でもプログラムを書くことができます。 何が欲しかった？ これは地球上で最も人気のある言語であり、DSLの一種ではありません。 JSアプリケーションごとに異なる標準があり、当然です。 練習に関しては、たとえば、ライブラリの難読化されたコードも非常によく読んでいます。 経験を積んで、一般的なパターンを学びます。

質問4：暗黙の（そして時には奇妙な）変換を伴う弱い型

誰のために奇妙なの？ Java、C＃、PHP、Python、Lisp、またはAmsプログラマーですか？ asmは奇妙ではないと言いますか？ Lispはどうですか？ 世界はあなたの好きな言語よりもはるかに豊かであり、一部の人にとって奇妙なことは他の人にとっては普通です。 少なくともHaskellとそのモナドとファンクターを見てください（ところで、非常に強力なもの。これらはJS、jQueryでも使用されています）。 研究所はこれを教えませんでしたね？ OOPは世界のごく一部にすぎず、非常に小さく、ハックされているため、話すのも退屈です。 JavaScriptの型は弱くはありませんが、基本的には弱くはありません（プリミティブ型を除く）。 WeakMapなどは、他の言語からの移民を喜ばせるためだけに導入されました。 アヒルのタイピングについて読み直し、それを使用することを学ぶと、タイプに問題はありません。

質問5：通常のクラスの欠如/ OOP

繰り返しになりますが、クラスは他の言語からの移民とIDEのために特別に導入されました。 NodeJSはもちろん、すべての主要なブラウザーでサポートされています。 JavaScriptのOOPは、他のほとんどの言語よりも豊富です。 クラスを介して継承でき、プロトタイプを介して継承できます。 多くの場合、JavaScriptプロトタイプの適切な使用はより速く、より便利で、より論理的であり、プログラムはよりコンパクトで読みやすいです。 しかし、このことは研究所で教えられていないため、JavaScriptコミュニティはこれも可能であることを証明しなければなりません。

質問6：単一の正気で動作する静的コードアナライザーの欠如（undefinedのような愚かなエラーの素晴らしい世界へようこそ）は機能ではありません

これは、evalを使用するすべてのインタープリター言語に共通する問題です。最も愚かな間違いの5％をキャッチできるようにするために、この権限を放棄するのは疑わしい考えです。 一般に、IDEスカートの後ろに常に隠れているとは限らず、コードの規律を開発します。 これは冗談ではありません、アナライザーは良いですが、あなたにとって問題がそのようなエラーである場合-どういうわけかあなたは正しくプログラミングされていません。

質問7：言語自体またはツールに型推論がない

つまり、構文を学習します。 状況に応じた1つのオプション：

typeof myVar
myVar.constructor

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

8: this ( this — ? ?)

this . myObj.func(), , this myObj. , myObj , , bind. JS, , , myObj2.func = myObj.func, . this myObj myObj2, . , , . this window undefined, strict mode. , . . , this , ? - . , , , . - , . JavaScript , C++ , , , . . , this , - « 2 , 2 , ?» . , this . , , , . JavaScript , , , PhantomJS c User-agent Chrome — .

9: pattern matching ( / — , undefined, , ? ) cannot read property foo of undefined

:

1. . —
2. — . , C# , Facebook . , , , .

10: — , , , async ( npm )

, , async/await — , . , , . , , . async/await , . async/await await , . async node, , JS . , ES6. , , npm ( ). Fibers, Sync, , . , , , .

11: const ( const )

, . :

const a = 5
const a = 4
VM1825:1 Uncaught SyntaxError: Identifier 'a' has already been declared
    at <anonymous>:1:1

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

— , const , . const. , // , - , JavaScript, . . .

12: npm, « »

. , github. . , , . . . , , /, . — , , Sencha. , . npm , . , .



JavaScript , , , . JavaScript. -, . JavaScript , . - .