プログラミング言語の選択を擁護するとき、COCOMOモデルは良い議論ですか？
現在、組み込みソフトウェア開発のコースを受講しています。講師は、モデル駆動型ソフトウェア開発のアーキテクチャ言語として [〜＃〜] j [〜＃〜] を選択しました。 J自体は非常に簡潔なプログラミング言語であり、この言語に対する彼の主な議論の1つはその簡潔さです。たとえば、これはJでのQuicksoftの実装です。
quicksort=: (($:@(<#[) , (=#[) , $:@(>#[)) ({~ ?@#)) ^: (1<#)
もう1つの議論は、そのような言語と文字数の削減により、バグを減らし、バグを修正する時間が短縮されるということです。
私はソフトウェアエンジニアリングのバックグラウンドが強く、Clean Code、Pragmatic Programmerなどのさまざまな本を読んでいるので、これらの議論は有効ではないと感じています。自然言語のように読める説明的な名前とコードへの強い動きがあることがわかりました（これは、ビジネスロジックが多く、数学が少ないアプリケーションにのみ関連している可能性があります）。
したがって、問題は、簡潔なプログラミング言語を使用するとエラーが少なくなり、バグを修正する時間が短縮されると本当に主張できるでしょうか。また、言語が簡潔であるため、コードの行数が減り、COCOMOの評価が向上します。しかし、これはそもそも適用できますか、それともCOCOMOモデルはプロジェクトの全体的なサイズを見積もる方法としてコードの行数を使用しますか（プロジェクトのサイズは、簡潔な言語で実装する場合でも命令型で実装する場合でも同じである必要があります） 、しかし、繰り返しになりますが、COCOMOモデルを正しく理解していなかったのかもしれません）？
更新
ご回答ありがとうございます。確かに、私の意図はCOCOMOモデルに関するより多くの情報を取得することであったことをより明確に述べる必要がありました（繰り返しになりますが、S.Lottは申し訳ありません）。そのため、ThomasOwensの広範な回答とコメントがこの質問に最も適していると思います。再度、感謝します！ :-)
プログラミング言語の選択を擁護するとき、COCOMOモデルは良い議論ですか？
いいえ。ココモは言語の選択については何も述べていません。これは、一連の入力が与えられた場合に、特定のソフトウェアシステムを構築するのにかかる費用を決定するためのコスト見積もりツールです。最新のイテレーションはCOCOMO IIであり、 このモデルを適用するときに使用するWebベースのツール があります。 COCOMO IIへの入力の一部には、SLOCまたは機能点での推定サイズ、チームの結束、プロセスの成熟度、望ましい信頼性、複雑さ、チームのさまざまな役割を担当する人々の能力、プラットフォームの制約、およびスケジュールが含まれます。出力は、プロジェクトの労力、スケジュール、およびコストの見積もりです。
テクノロジーとプログラミング言語に関連する入力はほんの一握りです。これらの領域をカバーする主な調整要因は、プログラマーの能力、アプリケーションドメインにおけるプログラマーの経験、プラットフォームと言語の経験、およびサポートツールを入手して使用する能力です。
言語を守る限り、COCOMOでできる最善のことは、チームがさまざまな程度で知っているさまざまなテクノロジーと言語の複数の見積もりを作成することです。おそらく、チーム全体が以前に使用して成功しているテクノロジーが1つあるため、プラットフォームと言語の経験は高くなりますが、その言語にはサポートツールがほとんどないため、それは低くなります。それを、おそらく1人だけが非常によく知っていて、数人が少し知っている言語と比較することができます。経験は名目上のものでありながら、豊富なツールセットを考慮に入れています。 2つ（またはそれ以上）の作業、スケジュール、およびコストの見積もりが与えられた場合、どちらを使用するのがより効果的かを比較して確認できます。
また、言語が簡潔であるため、コードの行数が減り、COCOMOの評価が向上します。
ココモ格付けなどはありません。 COCOMOは、プロジェクトの完了に必要な労力（人月）、スケジュール（月）、およびコストを決定するために使用できる推定ツールです。見積もりを行う際、このデータをプロジェクトチームの規模およびビジネススケジュールと比較して、それが現実的かどうかを判断し、プロジェクトマネージャーにプロジェクトスケジュールの管理に必要な情報を提供します。
たとえば、COCOMOは、15か月のスケジュール見積もりと、500,000ドルのコスト見積もりを生成する場合があります。ただし、ビジネススケジュールは12か月と$ 450,000になる可能性があります。このスケジュールは不合理ではありません。プロジェクトマネージャーは、プロジェクトを管理し、顧客と交渉するときにこの情報を使用できます。
しかし、これはそもそも適用できますか、それともCOCOMOモデルはプロジェクトの全体的なサイズを見積もる方法としてコードの行数を使用しますか（プロジェクトのサイズは、簡潔な言語で実装する場合でも命令型で実装する場合でも同じである必要があります） 、しかし、繰り返しになりますが、COCOMOモデルを正しく理解していなかったのかもしれません）？
コードのソース行（SLOC）はCOCOMOへの有効な入力ですが、SLOCの数はプログラミング言語によって異なるため、コードのソース行を使用してサイズを見積もることはお勧めしません（ 他の多くの問題 ） 。 ファンクションポイント はサイズ推定の好ましい方法です。ファンクションポイントの数を見積もり、その比率を適用して、特定のプログラミング言語でシステムのサイズを決定できる変換率があります。
さて、あなたの質問には他の部分があります。
現在、組み込みソフトウェア開発のコースを受講しています。講師は、モデル駆動型ソフトウェア開発のアーキテクチャ言語としてJを選択しました。 J自体は非常に簡潔なプログラミング言語であり、この言語に対する彼の主な議論の1つはその簡潔さです。もう1つの議論は、そのような言語と文字数の削減により、バグを減らし、バグを修正する時間が短縮されるということです。 [...]これらの議論は有効ではないと思います。自然言語のように読める説明的な名前とコードへの強い動きがあることがわかりました（これは、ビジネスロジックが多く、数学が少ないアプリケーションにのみ関連している可能性があります）。
それはすばらしい。私の経験では、講師は典型的な学生よりもトピックについて多くの経験を持っています。コンテンツを教えるために使用する特定の言語、フレームワーク、プラットフォーム、またはテクノロジーを選択するとき、彼らには正当な理由があります。
私の意見では、簡潔さは言語について議論するためのかなり貧弱な尺度です。プロジェクトを実装する言語を選択するときに使用する基準は、プラットフォームサポート、ツールサポート、利用可能なリソース、チーム知識など、はるかに優れています。 Jを見たことがないので、読みにくいです。ただし、プロジェクトが解決しようとしている特定の問題を解決するのは非常に優れている可能性があり、チームのメンバーはそれを経験している可能性があります。学ぶのも簡単かもしれません。
クラスの特定のケースでは、ポイントに焦点を当てる必要があります-学習の概念と技術。 Jについて学ぶだけでなく（新しいツールを学ぶことも常に良いことです）、他の言語にも適用できるテクニックを学ぶことができます。
したがって、問題は、簡潔なプログラミング言語を使用するとエラーが少なくなり、バグを修正する時間が短縮されると本当に主張できるでしょうか。
私の直感はノーと言っていますが、それは重要なことではありません。エラーと時間を削減する方法を適切に検討するには、言語の知識、サポートツール（コンパイラ、IDE、静的分析）、およびプロセス方法（ペアプログラミング、コードレビュー、スタイルガイドライン）などを考慮する必要があります。修正する。
COCOMOの詳細とその内容に興味がある場合は、どちらもBarry Boehmによる Software Engineering Economics および COCOMO IIでのソフトウェアコストの見積もり をお勧めします。ソフトウェアエンジニアリングの経済学は、主に一般的なソフトウェアプロジェクト管理、コスト見積もり、労力見積もりです。 COCOMOについて説明している本の一部では、COCOMO 89バージョンについて説明しています。これは、COCOMO IIバージョンで修正された不正確さのために、ベームが使用すべきではないと述べていますが、本の残りのセクションは引き続き関連しています。
結果としてプログラムごとの不良文字が少なくなるになる可能性がありますが、予測できるのはそれだけです。また、COCOMOメトリックは、さまざまな言語の自然な冗長性を考慮していないため、ある言語の引数として別の言語を使用することは無意味です。
いいえ、言語がより優れた、よりエラーのないコードを促進するかどうかの問題は、厳密に制御された対照実験によってのみ解決できます。残念ながら、本当に偏りのない調査研究はほとんどなく、非支持者が特定の言語を支持して支持者の発見を拒否する理由は常にあるようです。
おそらく最も説得力のある議論は、実際の使用です。確かに、商用ソフトウェア開発の世界には多くの慣性、下位互換性の制約、意図的な無知などがありますが、Wonder Language X（J、LISP、Haskellなど）かどうかを自問する必要があります。 ）really一貫してより優れたプログラムをより速く生成します-少なくともsome下位のマネージャーの最終的に気づき、少なくとも取得しようとしますそれを使用して競争に勝ちますか？そして、それはactualのメリットをもたらす必要があることに注意してください。学術玩具の問題のサイズでのみ機能するメリットや、非常に賢い人々がそれを使用する場合にのみ機能します。
最初。コースに合格しますか？もしそうなら、講師と議論するのではなく、Jを学びましょう。 Jを学ぶことには価値があります。
第二に。 COCOMOはあなたではなく講師をバックアップします。
簡潔なプログラミング言語を使用するとエラーが少なくなり、バグを修正する時間が短縮されると本当に主張できますか？
はい。それがココモの言葉です。コード行➜労力➜期間（および人員とコスト）。
言語が簡潔であるため、コードの行数が減り、COCOMOの評価が向上します。
正しい。
しかし、これは最初から適用できますか
何？
または、COCOMOモデルは、プロジェクトの全体的なサイズを見積もる方法としてコードの行数を使用しますか（プロジェクトのサイズは、簡潔な言語で実装する場合でも、命令型の言語で実装する場合でも同じである必要があります。
番号。
cOCOMOモデルを正しく理解していなかったのかもしれません）？
あなたはしました。 CoCoMoは、コード行==努力を示し、Jはコード行を最小化します。
三番。 Jは、最初は不明確だと思っても価値があります。
Jの前身であるAPLは、推論の数学的概念、演算子がさまざまなデータ型で機能する方法、関数型プログラミングの意味で関数を組み合わせる方法を反映するために特別に発明されました。
APL（およびJ）のポイントは、コードが通常の数学のように見える（そして感じる）ように、新しい高次のアプリケーション固有の演算子を作成できるようにすることです。仕様、設計、実装の間の「ギャップ」を減らします。