Clever Geek Handbook

Typeableでプログラミング言語を選択する方法



HaskellやRustなどのプログラミング言語を使用することを好む理由を何度も尋ねられました。それらは最も広く使用され、人気のあるツールではありません。この投稿は、テクノロジーの選択について考えるときに頭の中で何が起こっているのかをわかりやすく説明することを目的として書かれています。



長期的な運用が要求され、ある程度の信頼性を備えたソフトウェア開発は、ある意味でチェスゲームに似ています。両方のイベントの発生のバリエーションは、人間の脳が理解するのは非常に困難であり、経験の役割は非常に重要であり、すべての動き/選択が重要になる可能性があります。チェスのように、開発が非常に「位置的」であるという意味で類似性は続きます-一連の動き全体は、ポーンの勝利につながる操作の準備を目的とすることができます。これはたった1つのポーンのように見えるかもしれませんが、シリアスゲームの場合、これは大きな利点になる可能性があります。チェス盤のポジショナルゲームと同様に、大規模なプロジェクトの設計と開発の間、私たちは常に、より大きな問題を解決したり、プロジェクトの要件を満たすことを目的とした決定を下します。すべてのソリューションの効果は、たとえ小さなものであっても、エンドゲームに向かって、またはソフトウェア製品が動作するまでに蓄積される傾向があります。状況を悪化させる違いは、チェスとは異なり、ソフトウェア開発はコンピューターでは解決されず、コンピューターエンジンを実行するだけでは最良の動きを見つけ出すことができないということです。したがって、私たちを徐々にこの目標に導く多くの決定を下す必要があり、私たちの戦略的「立場」を改善するためのすべての手段は良いことです。そして、コンピュータエンジンを実行して、ただ行って最良の動きを見つけることはできません。したがって、私たちを徐々にこの目標に導く多くの決定を下す必要があり、私たちの戦略的「立場」を改善するためのすべての手段は良いことです。そして、コンピュータエンジンを実行して、ただ行って最良の動きを見つけることはできません。したがって、私たちを徐々にこの目標に導く多くの決定を下す必要があり、私たちの戦略的「立場」を改善するためのすべての手段は良いことです。



ソリューションは、アーキテクチャ、方法論、およびインストルメンタルのいくつかのカテゴリに簡略化できます。建築家は、私たちがどのようにプロジェクトを構築するかについて話します。メソッドは、作業プロセスをどのように編成するかを決定し、実装の品質と正確さを確認します。ツールは、結果を得るために開発チームが何を扱う必要があるかを決定します。完全な開発サイクルでは、今日、多数のツールが使用されています。要件、開発プロセスを形式化する必要があり、プログラムコードを記述してテストし、リリースを構築する必要があります。このような豊富なタスクにもかかわらず、プログラミング言語の選択は、次のパラメータのセットを決定するため、最も重要な役割を果たすことができます。



  1. ソフトウェアの速度のベースライン。
  2. , .
  3. , . , .
  4. // , .
  5. , , .
  6. .


さらに、プログラミング言語の選択も方法論の問題に大きな影響を与える可能性があります。たとえば、言語エコシステムのツールは、単体テストを作成する方法と範囲を決定できます。プロパティテストに適したインフラストラクチャは、この方向性を後押しする可能性があり、単体テストに適したインフラストラクチャがないため、作成と保守が困難になる可能性があります。



ツールはアーキテクチャの問題にも影響します。システムでのモジュールの再利用は、ブロックを概念的に分割してコードを構造化することがいかに便利であるかに関係しています。たとえば、エフェクトシステムを明示的に操作すると、コードをより一般化し、コードモジュールがネットワークやディスクの操作などのI / O操作を実行しないようにすることができます。これにより、セキュリティとアーキテクチャについて推論できます。



これに基づいて、プロジェクトとチームに適切なプログラミング言語を選択すると、広範囲にわたる結果が生じる可能性があることに注意する必要があります。チェスの例えを念頭に置いて、すべての小さなプラスは言語の貯金箱に行き、大規模な開発で重要な役割を果たすことができることを覚えています。また、大規模なエコシステムがすでに何かに書かれている場合など、テクノロジーの選択に厳密な制限がない状況での開発ツールの選択について話していることにも言及する価値があります。 Typeableでは、汎用言語に関する次の考慮事項に基づいています。



  1. . . , , .
  2. — , , . . - , , , .
  3. . GIL (Global Interpreter Lock) . .
  4. , . , , , .
  5. . , CS . « » , IT , .
  6. , .


上記のすべての結果として、ツールボックスには十分なブロックがあり、多くのプロジェクトで自信を持ってポジションをとることができます。チェスの例えに戻ると、これらは私たちがポジショナルゲームをプレイすることを可能にする私たちの原則です。ポジショナルプレイは、プレーヤーにチャンスを与え、弱点を最小限に抑える長期的なポジションを作成することを目的としたゲームです。これは、リスクの大きな部分を占める攻撃的な「鋭い」ゲームとは対照的であり、攻撃しているプレーヤーは、対戦相手が適切な防御位置をとる前にこのゲームを完了しようとします。 「シャープ」な開発は、オリンピックプログラミング、マーケティング実験のMVP、データサイエンスの多くのタスク、そして多くの場合、コンピュータサイエンスの出版物に付随するソフトウェアの作成です。彼らはしばしば長期的な支援を必要としないという事実によって団結しています、彼らは特定の時点でのみ働く必要があります。ポジショナルプレイは長期的なゲームであり、保守性とアップグレード性が重要な指標です。これは私たちが行っていることであり、私たちが作成および更新するソフトウェアの長期的なパフォーマンスに自信を持つためには、優れた基盤が必要です。このようなプロジェクトはMVPで開始することもできますが、完全に異なる前提条件で実行されます。



テクノロジーを選択する際の考慮事項のリストがまさにこのようなものであるのはなぜですか？これにはいくつかの理由があります。第一に、長期にわたる予測可能性を高めるために、ファッションやテクノロジーのトレンドの問題を排除することが望ましい。長い歴史と活発なコミュニティを持つコンパイラは、保守的ですが信頼できる選択ですが、毎年登場する光沢のある新しいものとは対照的です。確かにそれらのいくつかは最後のカテゴリーから最初のカテゴリーに移動しますが、これについては後で、おそらく数年以内にわかります。トレンドの代わりに、私たちは基本的なコンピュータサイエンスと、私たちが使用するプログラミング言語でのアプリケーションを見つけたこのトピックに関する大量の研究を使用しようとしています。例：型理論は、要件の形式化の基本的な問題を扱う数学とCSの関連分野です。これはまさに何ですかソフトウェアを書くために必要なもの。また、これは精密科学に携わる他の人々の累積的な経験であり、私の意見では、この経験を無視することはどういうわけか愚かです。何も取らないよりも、そのような規律を基礎としてとらえたり、一人の人生経験に基づいて主観的な意見をとったりする方が良いです。



第二に、プログラミング言語とコンパイラで採用した最大数の原則の実装を探しています。このため、私たちの最愛のHaskellに加えて、Rustがツールボックスに表示され始めました。リアルタイムの要件とメモリ使用量の厳しい制限により、十分に低レベルのものが必要です。 Cでのタイピングの厳密さには、まだ多くの課題が残されているため、そのようなタスクにRustを使用できる場合は、それを実行することをお勧めします。



3番目の理由：私たちは主にお客様のためにソフトウェアを作成しており、お客様を私たちの偏見から保護してほしいと考えています。したがって、商品を選択する際、リスクは一定のレベルを超えることはできず、クライアントとの合意が必要です。しかし、そのような状況でも、GHCJSのような技術はごくわずかです。長所と短所を組み合わせて分析した結果、私たちとクライアントにとって、この絵は依​​然として魅力的でした。この決定に至った経緯については、すでに書いています： Elm vsReflex。



大規模なコードベースや複雑なソフトウェアを使用する場合は、この複雑さをなんとかして抑える必要があるため、あらゆる手段と理論的な正当化が適切です。正しいアプローチの私たちのアイデアは、すべてのポーンを守り、その位置をスムーズかつ正確に改善して、プロジェクトがクライアントのビジネスに決定的な役割を果たすことができる瞬間まで良好な状態で生き残ることができるようにすることです。私たちはあなたに同じことを望みます。


More articles:


All Articles