24

新しいシステム (Web アプリケーション) を開発するためのいくつかの可能性を探っています。

私は「昔ながらの」ちょっとした男で、本質的にオブジェクト指向です(何年も前に手続き型から変換されました)。Python をいじったり、Ruby を少し勉強したりしましたが、率直に言って、Microsoft のツール (C#、ASP.NET MVC) を使用することに魅力を感じています。このすべての実行時のタイピング、基本的なものでのコンパイラ エラーがないことなどにより、大規模で複雑なアプリケーションの構築に関しては、私の人生が難しくなります。

動的言語でできる素晴らしいことについて人々が話しているのをよく耳にしますが、犬や猫の例や、物を数えるクールな方法をいかに迅速にコーディングできるかという例を除いて、Visual Studio の「産業力」はそれらを排除しているように見えます。動的言語が提供するきちんとした小さなこと、特に VS の無料の Express バージョンとスタートアップ向けの無料の完全バージョンがある今。

大規模なアプリケーションは実際に動的言語で開発されているため、ここで何かが欠けているように感じます。大規模で複雑なアプリケーションを見ると、これらの言語によって何が可能になるのでしょうか? VS の強みを発揮できる理由は何ですか?

4

9 に答える 9

19

「どれだけ速くコーディングできるか」が非常に気になるので、コンパイルするまでの長くて遅いスローガンを喜んであきらめました。

動的言語の利点。

  1. コンパイルもビルドもありません。コードとテストを行った後、本番環境にデプロイするだけです。

  2. すぐに満足。API 呼び出しが何であるかを考えるのに時間を費やす必要はありません。Python の >>> プロンプトで対話的に入力するだけで、実際に何が行われるかを確認できます。

  3. 非常に短い設計サイクル。おまけのインターフェイス定義と適切な抽象宣言とオーバーライドを使用してクラス階層を慎重に作成するのではなく、クラスをコーディングして単体テストを実行するだけで済みます。

  4. コードが少ない。動的言語イントロスペクションにより、ソースの量が削減されます。私は自分のアプリケーションでこのようなことを書きません。私はこれを行うためにフレームワークに依存しています。しかし、フレームワーク ベースのコードは非常に短いことがよくあります。XML 構成で同じことを繰り返さなければならない Java ではよくある重複宣言はありません。

  5. 謎はありません。Python コミュニティで言うように、「ソースを使用してください、ルーク」。フレームワークが何をするか、または API が実際に何を意味するかについて、あいまいさはありません。

  6. 絶対的な柔軟性。要件が変化しても、アーキテクチャ全体を破壊するような壊滅的な変更に苦しむ必要はありません。Python の Duck Typing により、欠落しているインターフェイス定義を、必要とは思わなかった場所に後付けする必要がなくなるため、いくつかのクラスに簡単に変更を加えることができます。それらはまったくありません。私たちが書いていないコードは、修正または保守する必要のないコードです。

  7. 回復力。私たちのアクチュアリーが頭がおかしくなったとき、この新しい、より洗練された引受モデルをアプリに統合する方法を理解するために何ヶ月も費やす必要はありません. ほとんど何でも押し込むことができます。繰り返しますが、これは厳密にはダックタイピングの結果です。新しいビジネス モデルが見込めないアーキテクチャに無理やりはめ込むことから解放されます。

  8. ソースアプリケーションであるため、ソースは独自の構成ファイルにすることができます。XML または INI 構成ファイルは、一部の外部構文にはありません。Python の構成ファイルがあります。Django フレームワークはこれを行い、私たちはそのリードに従います。販売デモと単体テスト用の非常に複雑なモックアップ データ宣言があります。超複雑なデータは、実際にはデータベースから取得された Python オブジェクトのコレクションですが、データベースのロードを省略しています。SQL データベースをロードする代わりに、Python オブジェクト コンストラクターを微調整する方が簡単です。

[ところで。Cobol、Fortran、PL/I、Java、C、C++ で 30 年以上ソフトウェアを開発してきた私は、ほとんどのコンパイル済み言語が必要とする比較的低レベルの手作業による最適化にうんざりしています。何年も前に、ほとんどのコンパイラが非効率的であるというコメントを読みました。これにより、コンパイラの制限を回避するために精巧なビルド システムを作成することになります。makeは非常に遅いため、必要なだけですcc。]


編集

動的計画法はあなたを天才にはしません。それだけで多くの時間を節約できます。あなたはまだ学習プロセスを管理する必要があります。知らないことはどの言語でも難しい。動的言語を使用すると、仮定が間違っていることを発見するためだけに多くの設計作業を行うことなく、一度に 1 つの新しいことを明らかにし、段階的に進めることができるため、力が得られます。

誤解されている API に基づいて多くのコードを記述したい場合は、動的言語が役立ちます。C#、VB、C++、Java、または Python などの言語で、クラッシュして燃える多くのコードを自由に記述できます。動作しないコードをいつでも書くことができます。

コンパイラは、コードが機能しないことを事前に警告します。通常、コンパイルしないことは大きなヒントです。ただし、すべての単体テストをコンパイルして失敗するコードを大量に作成することはできます。コンパイラは構文のみをチェックし、セマンティクスはチェックしません。

Python は、コードが機能しないことを事前に警告することがあります。通常、インタラクティブに実行することはできません。ただし、すべての単体テストに失敗するコードを大量に作成することはできます。

于 2009-06-25T11:13:00.687 に答える
6

静的型付けは、時期尚早の最適化の一形態です。事前に詳細な決定を行う必要がありますが、それを行うための知識がない場合があります。論理的に意味をなすのに十分な型を作成しない限り、プログラムの正確性には特に役立ちません。その場でデータ構造を変更することは困難です。

それから得られるのは、非常に限られた量の正確性チェックです。たとえば、int の使用方法が分離されていないため、非常に制限されています。行と列を扱っているとします。どちらもおそらく int ですが、行変数と列変数を同じ意味で使用しないでください。また、最適化も得られます。これは非常に便利なことですが、初期開発を遅らせる価値はありません。適切なテストを作成することで、正確性チェックを補うことができます。

Common Lisp 型システムはこれに適しています。すべてのデータ オブジェクトはその型を認識しており、必要に応じてその型を明示的に指定できます。

評価ループのような実行モデルにより、作成したルーチンを非常に簡単にテストできます。前もって明示的にテストを書く必要はありません (ただし、そうすることを妨げるものは何もありません)。それらを書いて、その場で実行することができます (そして、それをテスト スイートに改良することができます - それをインクリメンタル テスト開発と考えてください)。

長いビルド ステップがないことで、テストの実行が大幅に高速化されるため、テスト駆動型開発が容易になります。テストするたびに作業を中断する必要はありません。

人々が動的言語について不平を言っているのを聞くと、排他ロックのないバージョン管理システムについて不平を言っている人々を思い出します。最新の VCS に移行することで得られるものを理解するのに長い時間がかかる人もいれば、動的言語を理解するのに長い時間がかかる人もいます。

于 2009-06-25T14:12:38.920 に答える
5

一般的に、私は「動的」言語よりも「対話型」言語について話す方が好きです。編集/コンパイル/実行サイクルしかない場合、ターンアラウンドには長い時間がかかります。まあ、少なくとも「保存、コンパイル、コンパイル レポートの確認、テスト実行、テスト結果の確認」の順序で。

対話型言語を使用すると、通常、小さな部分を簡単に変更して、すぐに結果をテストできます。テストの実行にまだ長い時間がかかる場合は、それほど成功していませんが、通常はより小さなケースでテストできます。これにより、迅速な開発が容易になります。既知の正しい実装ができたら、これは最適化にも役立ちます。新しい改善された関数をすばやく開発してテストし、さまざまな表現やアルゴリズムを試すことができるからです。

于 2009-06-25T11:38:12.727 に答える
3

以下は、以前の同様の質問に対する私の回答の一部です ( I know C#. Will I be more production with Python? ):

私は C#/.NET のバックグラウンドを持っています。abt で .NET のプログラミングを開始。2001 年、ほぼ同時期に Python が導入されました。2001 年、私が C# と Python に費やした時間は、C# が 90%、Python が 10% でした。現在、比率は C# 5% / Python 95% です。私の会社では、.NET ベースの製品ラインを維持しています。しかし、すべての新しいものは Python に基づいています。

Python で重要なアプリケーションを作成しました。

私の経験では、Python と C# で生産性が向上する理由は次のとおりです。

  • 動的言語です。動的言語を使用すると、多くの場合、アプリからアーキテクチャ レイヤー全体を削除できます。Python の動的な性質により、C# よりも自然で柔軟な (構文に関する) 方法で、再利用可能な高レベルの抽象化を作成できます。
  • ライブラリ。コミュニティが提供する標準ライブラリと多くのオープンソース ライブラリは高品質です。Python が使用されるアプリケーションの範囲は、ライブラリの範囲が広いことを意味します。
  • 開発サイクルの高速化。コンパイルのステップがないということは、変更をより迅速にテストできることを意味します。たとえば、Web アプリを開発する場合、開発サーバーは変更を検出し、ファイルが保存されるとアプリをリロードします。エディター内から単体テストを実行するのは、キーを押すだけで、すぐに実行されます。
  • 頻繁に使用される機能への「簡単なアクセス」: リスト、リスト内包表記、ジェネレーター、タプルなど。
  • 冗長な構文。通常の .NET ファイルよりも少ないコード行で、WSGI ベースの Python Web フレームワークを作成できweb.configます :-)
  • 良いドキュメント。良い本。
于 2009-06-25T11:43:42.263 に答える
2

インタラクティブシェル! これは生産性の大幅な向上です。irb / pythonを起動して、インタラクティブシェルの前に配置します(それぞれrubyとpythonの場合)。次に、クラス、関数をインタラクティブにテストし、式(正規表現に最適)、さまざまな構文およびアルゴリズムを試すことができます。これは本当のプログラマーの遊び場であり、デバッグのための優れたツールでもあります。

エラーについて私だけ2セント:

このすべてのランタイムタイピング、基本的なもののコンパイラエラーなどは、大規模で複雑なアプリケーションを構築することになると、私の人生を難しくします。

コンパイラで検出可能なエラーは、さまざまな自動テスト(ユニット、機能など)を実行するときに検出する種類のエラーであり、とにかく書き込む必要があります。おそらくLinusTorvaldsは次のように言うことができます:回帰テスト "?それは何ですか?コンパイルすれば良いです、起動すれば完璧ですが、彼には何千人ものテスターがいて、彼のために仕事をしてくれます。アプリケーションをコンパイルするときのような構文に関する自動フィードバックですが、コードはその場で実行されます。

于 2009-06-25T11:25:49.583 に答える
1

私も静的型付けが好きです。しかし、Pythonを書いているときは、それをそれほど見逃しているとは思いません(使用しているクラスが十分に文書化されている限り、言語機能が悪い文書から私たちを救うことはないと主張します) 。また、C ++を作成するときにPythonの動的機能のほとんどを見逃すことはありません(ラムダ、私は見逃します:構文がひどい場合でもC ++ 0xを持ち込みます。リスト内包表記)。

エラー検出の場合、ほとんどの「間違ったタイプが渡された」および「間違ったメソッドが呼び出された」エラーは微妙ではないため、主な違いは、例外がコンパイラエラーを置き換えることです。すべてのコードパスとすべての重要なデータパスを実際に実行する必要がありますが、もちろん、深刻なプロジェクトではそれを実行しています。特定の変数に割り当てることができるすべてのクラスをテストするのは難しいことではないと思います。主な問題は、C ++に慣れている人々がコンパイラーに頼ることを学び、コンパイラーがキャッチするエラーの大きなクラスを回避しようと努力しないことです。Pythonでは、コーディング時にそれについて考えるか、テストが実行されるまで待ってそれを見つけるかを選択できます。同様に、C++の「自動リファクタリング」操作

したがって、テストの正しいサブセットを実行していることを確認する必要があります。これは、大規模なPythonアプリの完全な単体テストの実行には、現在のC++コード/コンパイル/コード/の「コンパイル」フェーズで許容できるよりもはるかに長い時間がかかるためです。コンパイル/コード/コンパイル/テストサイクル。しかし、それはC++ですべてを再構築したくないのとまったく同じ問題です。

静的型付けは、コードの実行が実際に困難な場合(たとえば、組み込みデバイス、またはローカルで再現できない奇妙なサーバー環境)に優先されます。これは、シリアルケーブルをいじる前に、より多くのエラーをキャッチするためです。 rsync。しかし、それが、作成している言語に関係なくエミュレーターが必要な理由です。また、開発者のマシンが本番環境をシミュレートできない場合、本格的なサーバーコードに対して適切なテスト環境を用意する必要があります。

さらに、C ++コンパイラのエラーや警告の多くは、実際には設計に関するものではなく、正しく見えるが完全に間違った動作をするコードを記述するためのさまざまな方法があるという事実に関するものであることを覚えておく価値があります。Pythonプログラマーは、精神病のプリプロセッサーや厳密なエイリアシングに基づく最適化を行っていないため、誤ってトリグラフを挿入したり、ポインターを型のパンニングしたりしたことを警告する必要はありません。

于 2009-06-25T14:02:20.937 に答える
0

単一の引数を取るサブルーチンがある場合を考えてみましょう。

sub calculate( Int $x ){ ... }

今、あなたの要件は変わり、あなたは複数の議論に対処しなければなりません:

multi sub calculate( Int $x ){ ... }
multi sub calculate( Int @x ){
  my @ret;
  for @x -> $x {
    push @ret, calculate( $x );
  }
  return @ret;
}

異なるバージョン間でほとんど変更がなかったことに注意してください。

ここで、実際に浮動小数点数を使用する必要があることがわかった場合はどうなりますか。

multi sub calculate( Num $x ){ ... }
multi sub calculate( Num @x ){
  my @ret;
  for @x -> $x {
    push @ret, calculate( $x );
  }
  return @ret;
}

これは以前よりも小さな変更であり、これらのサブルーチンを呼び出したコードは、1回の変更なしでも引き続き機能することに注意してください。

これらの例はで書かれましたPerl6

于 2009-06-25T15:43:07.303 に答える