Webサイトの動的型と静的型の言語[非公開]

このステートメントは、静的に型付けされた言語がWebサイトに理想的ではないことを示唆しています。

ウェブサイトの構築とは対照的です。Webページをレンダリングするとき、多くの場合、Webページで相互作用する非常に多くのコンポーネントがあります。ここにはボタンがあり、そこには小さなウィジェットがあり、ウェブページにはそれらの数十があり、ウェブサイトにはすべて動的な数十または数百のウェブページがあります。そのような非常に大きな表面積を持つシステムでは、静的に型付けされた言語を使用することは実際には非常に柔軟性がありません。おそらく、Scalaでプログラムを作成し、それを使用してWebページをレンダリングするのは、ボタンやその他のものをインタラクティブにプッシュしたいときに苦痛になるでしょう。システム全体で一貫性が必要な場合、たとえば、システム全体でボタンを移動できるようにするためだけに型チェックを行う必要がある場合、それは非常に柔軟性に欠けると考えます。

^{ソース：http : //www.infoq.com/interviews/kallen-scala-twitter}

これは正しいです？なぜですか？

私はまったく同意しません。システムが大きくなると、静的に型付けされた言語により、コンポーネントレベルでの堅牢性が確保され、システムレベルでの柔軟性が確保されます。

また、著者によって与えられた例は本当に意味をなさない。むしろ、この男は、多型がカモタイピング以外の手段で達成できることを知らないように思えます。

動的言語が優れていると主張する人はたくさんいますが、それは通常、たとえば構造的なサブタイピング、代数的データ型、一次関数をサポートする表現型システムの経験の不足に基づいています。

まず、上記の声明の著者がウェブサイトの開発について話していることに留意してください。そのため、彼はプレゼンテーションの開発を心配しています。そこで彼は、Scalaは良い選択ではないと考えています...

そうは言っても、私はWeb開発の経験が豊富です。私は少なくとも8年間専任で仕事をしてきましたが、そのうち5年間はデジタル代理店で働いていました。

そして、はい、私の経験では、プレゼンテーション層で静的に型付けされたコンパイルされた言語は大きな障害になる可能性があります。コンテンツは、ビジネス要件よりもはるかに頻繁に絶えず変更する必要があります。通常、これは個別のチーム（「フロントエンド」開発者）が行う必要があります。彼らは通常、HTML、JavaScript、Web標準、CSSについて多くのことを知っていますが、JavaやC＃などのサーバー側言語についてはあまり知っていません。また、テンプレートのあらゆる種類の変更がすぐに利用できると想定しています。コンパイルおよびタイプエラーには使用されません。そして、それらは正しいです。静的に型付けされた言語は、データアクセスやビジネスルールなどのハードで複雑な要件には非常に適していますが、インターフェイス開発にはあまり適していません。

実際、これはVelocityのような特殊で解釈されたテンプレート言語を使用する主な利点の1つです。その使いやすさ、パワー、および柔軟性は、プレゼンテーション層の開発者に十分です。そして、サーバーサイドの人は、他のどこでも真剣に静的に型付けされた言語を自由に使用できます...

ただし、Scalaが多少異なることにも同意します。同時にJavaよりもはるかに冗長で表現力が高いため、プレゼンテーションの開発に使用できると考えています。したがって、テンプレート言語として使用できる可能性があります。また、Playのようなフレームワーク（変更のたびにWebサイトを自動的にコンパイルする）に組み合わせることができれば、勝者になる可能性があります。それでも、PlayでもGroovyに似た（動的な）テンプレート言語を選択していますが、これは良い兆候ではありません。

要約すると、Scalaの問題は、Scalaがコンパイルされているという事実により関連しています。実際、その型推論メカニズムにより、静的に型付けされていることもほとんど忘れられます。

（そして、私の英語についてすみません。何かはっきりしないことがあれば教えてください、私はそれを修正しようとします。）

テキスト（およびほとんどの回答）には、静的に型付けされた言語と過度に冗長な言語が混在していると思います。もちろん、交差点は非常に大きくなります（特に主流の言語のみを考慮する場合）。しかし、非冗長で静的に型付けされた言語の興味深い例がいくつかあります：Go、Haskell、Scala、Rust…

Bruce EckelのStrong Typing vs. Strong Testingを読むことをお勧めします。主な論点は、ソフトウェアの品質はすべてテストに帰着するということです。さまざまな方法でテストできます。コンパイラは、コンパイル時にいくつかのことをテストします。文字列をint変数に格納しようとすると、おそらくあなたに向かってbarえます。動的言語では、多くのテストが実行時に行われます。最終的に、テストがいつ行われるかは問題ではありません。それはただ起こらなければなりません。動的言語でコンパイルしないことで得られるのは、実行時のテストを失うことです。すべてを堅牢にテストしますか？

それを考えると、動的言語に対する固定型システムを備えたコンパイル言語の好みは、まさにそれ-好みです。種類のようなボクサー対ブリーフまたは皮ひも対フレンチニッカーズ。正解も不正解もありません。正しい姿勢でそれらを着用し、素晴らしいだけがあります。

ほとんどの場合、私はそれに同意します。Webプラットフォームでクライアントに対処する場合、柔軟性が不可欠です。

静的に型付けされた言語は、ダイナミカルに型付けされた言語よりも堅牢で安全ですが、コードの適応を開始することは意図されておらず、高速である必要があるため、ソリューションは複雑で厳格に見えます。

したがって、テクノロジーをマージするための変更がある場合は、静的に型付けされた言語でコアを作成し（コアはあまり変更しない）、ユーザーとの対話に動的に使用することをお勧めします。

この投稿の著者は、Scala自体を検討していません。JavaとC＃には制限があり、Web開発には少し柔軟性がないことに同意しますが、Scalaは静的に型付けされた言語であり、それを聞いたときに通常考えるものとはまったく異なります。Scalaでは、アヒルのタイピングと、モンキーパッチのタイプセーフバージョン（暗黙的な変換による）が可能です。型について考える必要があるため、プログラミングライブラリはもう少し複雑になりますが、Liftのようなライブラリを使用するだけの場合は、コンパイラが使用しない明らかなバグについて通知することを除いて、動的言語に非常に似ています正しい。私は、リフトWebフレームワークがRailsや同様のRubyから隠れる必要はないと個人的に考えています。こちらまたはこちらのコード例をご覧ください自分で決める。私は今かなり長い間リフトで開発しており、タイプエラーが発生する状況はありませんでしたが、「ああ、これは動的な場合は動作します」...動的な場合、それは私に言っていないだけだからです実行中にクラッシュするまでバグがありました。

個人的には、彼らが言うことはウェブサイトだけでなく、どんなシステムにも当てはまると思います。ハードウェアと話すときには静的型付けが必要になります。他のすべての型付けは、実際に何をしても同じ欠点と利点があり、最適なものは好みと各プロジェクトの特定の問題に依存します。

実用的なクイックアンサー：ウェブサイズのサイズと複雑さに依存します。小規模なWebサイト、動的なプログラム。lang。、Complex Large website、static progr。ラング。

拡張された退屈な答え：多くの開発者は、ウェブサイトは動的なプログラムで行われるべきだと主張しています。langr。しかし、実際には、最終的に、Web開発ツールは静的型付き言語を使用またはエミュレートする傾向があります。

私はPHPを何度か使用しましたが、遅かれ早かれ、与えられたデータの型を検証する多くのコードを追加する必要がありました。これは静的型付きプログラムで暗黙的です。ラング。

型付きLagn。また、多くの型検証が必要なIDEの使用にも役立ちます。

（隣人のプログラムとコンパイラの設計者によってもたらされた;-)）

ちょっと同意します。ほとんどのWebフロントエンドC＃コードを見ると、文字列からキャストしてデータを文字列にシリアル化することがたくさんあります。基本的に、プロトコルとしてのHTTPは動的言語に適しています。