アカウント名:
パスワード:
まあP言語の特徴である, お手軽に何でもできるってのだけではおっつかない案件が増えてきたんでしょうね. 1人から数人程度でできる案件と100人以上で作る案件では, 言語に求められる物が違ってきますから.
大規模開発で使う言語だと
あたりが必要だと30年以上前から言われていて, それを実現した言語の系譜がModula, Adaなどと続いてきてJavaに至って
違う. 高負荷・ミッションクリティカルな部分は数人でC言語を使います.
P言語が駄目なのは, あくまでも組織的な開発をサポートする強制力が弱いってことです. 大規模開発では良い物を作ることよりも, 駄目な物を作らないことが重要になります. 縛りがゆるい言語は楽に作れますが, レベルが低いプログラマはいくらでも酷いコードを吐き出してくれます. また駄目なコードであることが分かった時に, いかにきれいに切ることができるかが重要になります.
大規模開発で優れたプログラマのみを集めるなんてのは一種のファンタジーです. そこで駄目なプログラマが混入しても最悪を避けられる開発環境が求められるわけです.
P言語が駄目なのは, あくまでも組織的な開発をサポートする強制力が 弱いってことです. 大規模開発では良い物を作ることよりも, 駄目な 物を作らないことが重要になります. 縛りがゆるい言語は楽に作れま すが, レベルが低いプログラマはいくらでも酷いコードを吐き出してくれます.
「俺のC言語コードは絶対バッファオーバランを起こさない!」というのは無しですよ。 それは非科学的です。
そしてさ、これは想像なんだけど(というのは俺もそういう場に居た事が無いんで)、 良い組織は最初から駄目プログラマを排除しているんじゃなかろうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
太陽超小型装置 (スコア:1)
サーバーサイドだと結構メジャーになってきたようだし
アーミーナイフで家を建てる (スコア:4, すばらしい洞察)
まあP言語の特徴である, お手軽に何でもできるってのだけではおっつかない案件が増えてきたんでしょうね. 1人から数人程度でできる案件と100人以上で作る案件では, 言語に求められる物が違ってきますから.
大規模開発で使う言語だと
あたりが必要だと30年以上前から言われていて, それを実現した言語の系譜がModula, Adaなどと続いてきてJavaに至って
Re: アーミーナイフで家を建てる (スコア:2, すばらしい洞察)
それもまた危ないな。
高負荷・クリティカルミッションなところはJavaで書いて、
そうでないところはP言語で書けばみんな幸せになれると思うけど。
それができないのは切り分けが
Re: アーミーナイフで家を建てる (スコア:4, すばらしい洞察)
違う. 高負荷・ミッションクリティカルな部分は数人でC言語を使います.
P言語が駄目なのは, あくまでも組織的な開発をサポートする強制力が弱いってことです. 大規模開発では良い物を作ることよりも, 駄目な物を作らないことが重要になります. 縛りがゆるい言語は楽に作れますが, レベルが低いプログラマはいくらでも酷いコードを吐き出してくれます. また駄目なコードであることが分かった時に, いかにきれいに切ることができるかが重要になります.
大規模開発で優れたプログラマのみを集めるなんてのは一種のファンタジーです. そこで駄目なプログラマが混入しても最悪を避けられる開発環境が求められるわけです.
Re: アーミーナイフで家を建てる (スコア:1)
言語に不自由な人は、どんな言語が開発されようともなくならないのでは?
# 私はCは嫌い。高級言語のアセンブラなんていうぐらいなら、直接アセンブリへ行く。必要とあれば
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re: アーミーナイフで家を建てる (スコア:1)
平気で駄目な家を建てることでしょう。 駄目なプログラマをなんとかして束縛して、駄目なコードを生産させ
ないようにしたい、そのために Java 言語を採用するというのはあり
そうな話ですが、あまり効果的とは言えません。
Java には束縛がありますが、それでも十分に駄目なコードを書くだけの
余地があります。単なる言語に、コーチの代わりは務まりません。
大規模開発で優れたプログラマのみを集めるのがファンタジーだとすれば、
そもそも大規模開発がペイするという考えもまた、ファンタジーであるかも
知れません。あるいは、ペアプログラミングがペイしないという考えに
見切りを付けるべきときかも知れません。
バッファオーバーラン (スコア:1)
確かに高負荷には耐えられると思いますが、
セキュリティの面から見ればバッファオーバーラン [e-words.jp]という別の危険性が出てきます。
バッファオーバーランの危険性と秤にかけて見合うだけの高負荷ってどんなものでしょうかね。
「俺のC言語コードは絶対バッファオーバランを起こさない!」というのは無しですよ。
それは非科学的です。
Re:バッファオーバーラン (スコア:1)
たとえば、Apache httpd にコードを提供するようなレベルの人は、
バッファオーバランもメモリリークも"絶対"起こさない所まで
行っていなければなりません。でなきゃ危なくて仕様がないですよ。
C言語なんか生産性が低いから書きたくないけれど、もし書かなければ
ならないときはメモリ関係のエラーを出さないコードが書けること。
これが、プロの入り口じゃあないでしょうか。
別件で、C言語でCGIっていうのは bad idea だと思うけれど、これについては論じません。
Re:バッファオーバーラン (スコア:0)
バックエンドで動いててボトルネックになることが確実なモジュールはC/C++で実装することはたまにあります。
#そろそろそういうのもJavaでやってみたいんだけど、
#いかんせん経験が少ないのでどこまで耐えられるかの見積もりが難しい。
Re: アーミーナイフで家を建てる (スコア:1)
ってことは裏返すと、
大規模プログラムだからといって、
なにか「素晴らしい」プログラムだ、と思うのは
幻想に過ぎないってことですね。
>縛りがゆるい言語は楽に作れますが, レベルが低いプログラマはいくらでも酷いコードを吐き出してくれます.
>また駄目なコードであることが分かった時に, いかにきれいに切ることができるかが重要になります.
ただ、しょせんJavaだのCだの程度の「縛り」では、
酷いコードを排除できませんし、
駄目コードを切り離す機能も不足してます、けどね。
Javaとか程度の縛りに何かを期待するのもまた、幻想だと思うです。
余談:
「なるほど、この言語のこの機能のおかげで、プロジェクトは破滅を免れたのか!」という実例って
有るんでしょうかね?
いや、たぶん「測定できない」ってのが本音だと思う。
つまり、Javaだのなんだのが言われているようなメリットって、ホントに実在するメリットなのだろうか?
思うんですが、強い型の言語の「メリット」は、その成立年代から察するに、
往年の、UnitTestなんて夢の夢だった時代のバランス感覚
によってバイアスがかかった評価だ、といってもいいと思います。
>大規模開発で優れたプログラマのみを集めるなんてのは一種のファンタジーです.
小規模でも同様かも(わら
どっちかてーと、問題は組織のほうだと思う。
駄目組織は、大だろうが小だろうが問わず、とにかく駄目プロジェクトを編成してくれやがる。
そしてさ、これは想像なんだけど(というのは俺もそういう場に居た事が無いんで)、
良い組織は最初から駄目プログラマを排除しているんじゃなかろうか?
#あるいは、教育において却って駄目プログラマを作るようなヘマをしない、とか。
Re: アーミーナイフで家を建てる (スコア:1)
まさにそういう意味のことが書いてありましたね。
間違って不合格にした開発者が一杯いるはずだが、御免なさい、とさ。
Re: アーミーナイフで家を建てる (スコア:1)
"この採用システムに多くの欠陥があることは分かっています(採用すべき人間を不採用にしてしまったりとか)。" [capsctrl.que.jp]
なんて書いてあるのが、それですね。
Re: アーミーナイフで家を建てる (スコア:0)
で、それが出来ない無能がP言語のせいにして、Javaを使えば、「組織的開発が出来て」「ダメコードを上手く処理できる」とJavaマンセーして、今のいろんな意味で悲惨な状態になっていると。
個人的には、ニホンでは営業的には不遇なPerlによる小規模開発をよく提案するのですが、この手の「PerlはJavaに比べて~」系の話が出ると、eToysの事例 [bulknews.net]を出します。2000年の時点で、ほぼ、現在トレ