動的言語と静的言語のアーキテクチャの違い


22

静的言語(C#やJavaなど)と動的言語(RubyやPythonなど)で構築されるアプリケーションを設計するときに、アーキテクチャ上の大きな違いはありますか?

一方のタイプに適した設計で、もう一方のタイプに悪い設計の可能性はどれですか?一方のタイプでは実現できない便利な機能がありますが、他のタイプでは実現できません(もちろん、設計とアーキテクチャにおいて)。

また、ダイナミック固有のデザインパターンはありますか?


1
それらのアーキテクチャの違いが何であれ、IronRubyとIronPythonの動的言語は、.Netの静的言語を簡単に補完します。
IAbstract

3
確かではありませんが、動的言語でメタプログラミングが簡単な場合(前回見たJavaよりもRubyで簡単だったと思います)、アーキテクチャの決定に影響を与える可能性があります。これらの動的言語でこれほど大きなものに取り組んだことがないので、どのような影響があるのか​​はわかりません。
FrustratedWithFormsDesigner

回答:


14

いくつかのことをまっすぐにしましょう。

  1. 対話型スクリプトと静的言語は相互に排他的ではありません。F#とHaskellの両方にREPLインターフェイスがあります。
  2. 動的言語と高性能は相互に排他的ではありませんが、一部の最適化は相互に排他的です。JavaScriptは、最近のほとんどのブラウザーで非常に高速に実行されます。
  3. 動的言語であっても、型について文書化し、記憶し、考える必要があります。
  4. 型推論の人気が高まっているため、多くの静的言語は型を頻繁に表記する必要がなくなりました。型推論が強力な静的言語では、ほとんどの場合、コンパイラーはコードから型が何であるかを把握し、型定義に違反する何かをしたかどうかを通知します。構文に関する限り、これは両方の長所を提供します。
  5. OOPと動的言語は相互に排他的ではありません。PHPはクラスと継承をサポートするようになりました。

これらの驚くべき類似点は別として、開発プロセスに影響する実際的な違いがいくつかあります。

  1. 動的言語は、小さなでデータを渡す興味深い方法を可能にします。
  2. 静的言語を使用すると、多くの種類のバグを不可能にすることで、実行するテストの量を減らすことができます。
  3. 同じように、静的言語では、F#の測定単位など、興味深い検証と自動変換機能が使用できます。
  4. 極端に言えば、静的言語はコードコントラクトと正式な検証を可能にします。これにより、潜在的なゼロ除算、無限ループ、null参照、無効なリストサイズまたはインデックス、範囲エラー、その他の論理的に無効な状態などを防止できます。定義するかもしれません。
  5. さらに極端に、これらの静的制約に基づいてCPU最適化を行うことができ、パフォーマンスがさらに向上します。

また、静的型付けなしでは作成できなかったプログラムの1つのタイプがあります。それは、ハードウェアプロセス境界のないOSであるSingularityです。少量のC、一部のC#、およびコードコントラクトをサポートするSpec#と呼ばれ​​るC#の方言で書かれています。

ガベージコレクションの言語で書かれているにもかかわらず、このOS上でマルチタスクやプロセス間通信性能は、実際にはより良い、そこに何よりも、すべてのプロセスが一つのメモリ空間で実行するという事実によると、原因フォーマル検証の最適化へのI上記の通り。プログラムがシステムの残りの部分を危険にさらすことができないようにするために、通信オブジェクトは静的に検証可能である必要があるため、静的なタイピングなしでこれを行うことはできません。

ただし、ほとんどの場合、アーキテクチャはほとんど同じように見えるはずです。静的言語は、型が明確に定義されているため、多くの場合、プログラムの推論を容易にしますが、適切に記述された動的言語プログラムには、少なくとも開発者の頭の中では明確に定義された型もあります。


Singularityはリアルタイム対応の最大遅延保証を提供できますか?
エオニル

@Eonil本当に私の分野ではありませんが、リアルタイムで難しいことができるかどうか尋ねていると思います。あちこちでガベージコレクションを使用しているので、そうは思いません。私の知る限り、特異性はしばらく更新されていませんが、リアルタイムガベージコレクターで似たようなものを作成した人がいるかもしれません。
宮坂Re

ありがとう。確認したかっただけです。...私はいくつかのリアルタイムGCの実装がそこにいる聞いたことがあるが、私は、彼らは、業界で実際に使用されているか聞いていない
Eonil

2

アーキテクチャには大きな違いがあります。パフォーマンス。

ハードウェアの予算、予想されるワークロードおよびサービスレベル契約によっては、動的言語で要件を満たすことができない場合があります。

ほとんどの場合、動的言語によって提供される開発速度と柔軟性が、応答時間の低下とCPUおよびメモリ消費の増加を相殺します。しかし、予算やパフォーマンスの制約がある大規模なシステムでは、動的言語のオーバーヘッドが高くなる可能性があります。


1

私はこれらの線に沿って考えたことはありません。したがって、Googleを行ったとき、Peter Norvigのブログはトップヒットの1つでした。いくつかの設計パターンは、C ++などの従来のオブジェクト指向言語よりも動的言語で実装する方が簡単だという。動的言語では実装が簡単であると彼は指摘しているので、設計/アーキテクチャにも違いがあると思います。私はさらに勉強しながら答えにさらに追加しようとします。


1

静的言語(C#やJavaなど)と動的言語(RubyやPythonなど)で構築されるアプリケーションを設計するときに、アーキテクチャ上の大きな違いはありますか?

いや

動的言語用の派手なフレームワークを書く方が少し簡単です。しかし、それはアプリケーションのことではありません。

一方のタイプに適した設計で、もう一方のタイプに悪い設計の可能性はどれですか?

なし、本当に。

どちらの種類の言語でも良いことを書くことができます。

一方のタイプでは実現できない便利な機能がありますが、他のタイプでは実現できません(もちろん、設計とアーキテクチャにおいて)。

いや

違いは、動的言語は「書き込み、実行、修正」であることです。すばやく実験して修正できます。

静的言語は「書き込み、コンパイル、ビルド、実行、修正」です。簡単に実験することはできません。

それ以外は、機能はほぼ同じです。

ダイナミック固有のデザインパターンはありますか?

多分。Python eval()execfile()関数は、ある意味で、静的言語での処理が難しい(しかし不可能ではない)動的言語機能を指し示しています。同じプロセス空間でコードをコンパイルして実行するには、さらに多くのコード行が必要です。

動的言語固有ではありません。簡単です。


2
「これほど簡単に実験することはできません。」-トレードオフは、コンパイラーがエラーの発見に役立つのに対し、インタープリター言語ではユーザーがそのコード行を実行するまでエラーを発見できない可能性があることです。
ダグT.

4
@Doug T .:「コンパイラはエラーの発見に役立ちます」。時々。十分ではありません。興味深いエラーは、コンパイラーではまったく発見できません。それがユニットテストの目的です。
S.Lott

2
@ S.Lott動的言語で記述されたAPIには、もう少しドキュメントが必要であることがわかりました。静的言語では、メソッドシグネチャは、必要な引数のタイプを示します。動的言語では、それほど簡単に伝えることはできません-APIのドキュメントでは、どのオブジェクトが期待されるかを伝える必要があります。

1
@quanticle:それは本当に建築的ではありませんか?
-S.Lott

2
「これほど簡単に実験することはできません。」-F#とHaskellはどちらも静的言語であり、本格的なREPLを備えており、識別子や式のタイプを尋ねることはほとんどありません。
宮坂
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.