- 関数型言語ML (SML, OCaml, etc.), Part 6
877 ：デフォルトの名無しさん[sage]：2014/09/26(金) 20:54:07.13 ID:mU/FSdzC - >>872
前半で散々オブジェクト指向をこきおろしておきながら、
中盤でOCamlを推すという意味不明な文章の論理の展開がある
ML族を推すのなら Caml か SML にしないと一貫性が無いし、
Caml にオブジェクト指向を後付けした "O"Caml 開発時の判断は
今となっては流行に踊らされた大きな失敗であったと断罪すべき
おまけに「個人的にOCamlがすごいと思う」とあるから何かと読んでみたら、
単なるパラメタ型多相の話でしかないことに笑ってしまった
「とがった」とか「すごい」とか、小学生の感想文とレベルは変わらない
こんなポエム記事で給料をもらえるのだから、日経ITproの記者とは楽な職業だね
>>873
タイトル以前の問題で、記事に中身が無くて話にならん
>>876
ソースコード解析ツールなら言語処理系と似た構造になるから、
(一般的には副作用を模倣するために使われる)do記法を使う必要性は無いと思われ
| - 集合論に基づいた言語を作りたい
367 ：デフォルトの名無しさん[sage]：2014/09/26(金) 22:40:52.33 ID:mU/FSdzC - （>>856 の続き）
始めは「考えられるリスクの低減」から
・ライブラリや共通部品の多くは(アルゴリズムやデータ変換を実現する単純なものもあるが)
データベース/ファイル／ネットワーク/プロセス間通信といったプログラムの
外部インターフェイス処理が多くを占める
これらを実装するには、プログラマにシステムコールや標準ライブラリ(>>829)、
そして社外のライブラリや社内の共通部品等等、幅広い知識が求められる
これを経験の浅いメンバに負わせるのは無謀
・ライブラリ/共通部品の実装技術は機能仕様(=ビジネスルール)には依存しないから、
類似のシステム開発プロジェクトがあれば、類似の実装になる
もしライブラリ設計担当がいくつかのプロジェクトを経験したベテランであれば、
過去の(失敗を含めた)経験から、既存の設計やコードを改造母体にして短期間で設計できる
これと同じことを経験の浅いメンバに期待するのは無茶
・万が一、ライブラリ/共通部品の開発日程が遅延して結合テストに間に合わなかったり、
結合テストでバグが多発する事態になれば、その影響はプロジェクトの全体に及ぶ
もしモスク(>>856)の中位/上位層であれば影響範囲は限定的だし、
その炎上の火消しのためにライブラリ/共通部品を担当させて余力のあるベテランを投入できる
（当然、ライブラリ/共通部品設計には日程厳守(or 前倒し)と高品質(=バグ0)をベテランに要求する）
| - 集合論に基づいた言語を作りたい
369 ：367[sage]：2014/09/26(金) 22:44:51.94 ID:mU/FSdzC - >>367 は誤爆だから無視してくれ、スマソ
|
|