開発工数を大幅削減できた言語は存在しない
■ このスレッドは過去ログ倉庫に格納されています
開発工数を大幅削減するのは
ライブラリとフレームワークであって
言語による差は、開発工数の差に影響しない。 と、ドカタ言語しか使えないドカタは信じたいのであった 俺なら○○言語で倍のスピードで開発できるぜ!
↓
じゃ、開発工数半分な。半分の期間で作れるんだろう? >>4
作ってもらう側から見ると、短い期間で作ってもらえると、
その時間の分だけ他社に対して競争優位に立てる
つまり開発期間が短いことには市場価値があり、
素早く作れるプログラマ/組織は高い資金を請求できる
ドカタの>>4には関係ない話だけど このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所 Fortranって書こうとしたら既に書かれてた。
10はFortranだよNE? リファクタリングを生んだのも
xUnitを生んだのも
eclipseを生んだのも
オブジェクト指向を生んだのも
Smalltalkだなあ
この4つがなければ開発工数は今よりずいぶん増えるだろうな
開発で直接Smalltalkを使っていなくても
Smalltalkは開発工数を大幅削減したと言ってもいいんじゃね? Smalltalk由来のものがほかでも出来る以上
やっぱり言語じゃ差はつかないんだなっていう証拠にはなっても
言語で開発工数が削減できたという理由にはならない。 元Java開発者にRubyを書かせたら
Javaかと思う程冗長なコードを書いたから
低能はどの言語使っても同じなんだなぁ、と思った 馬鹿はどの言語使っても糞コードしか書けないけど、
リファクタリング思いついたり
xUnit思いついたり
GUIのIDEを思いついたり
オブジェクト指向を思いついたり
するぐらい凄い人がSmalltalkで開発工数を削減したんだね そして型推論やモナドを使いこなすHaskell使いの人が
現在進行形で開発工数を削減してる >>23
逆やってみ。
すごい技術を持ったプログラマに
Javaを触らせてみるの。
そのプログラマ主観である「嫌い」は無視するとして
純粋にそのプログラマが書いたコードだけをみて、
冗長かどうか判断する。
少なくとも俺が書いたら冗長にはならんからさ。
えと、念のため。冗長というのは無駄な処理があるということで
そのコードに理由があるのなら冗長とはいわないので。 ディスることは得意だけど褒めることは出来ない。
Java使いがRubyを使ったら・・・という話はするが、
Ruby使いがJavaを使ったらという話はしない。というかできない。
書いたコード出せと言ったら、絶対に出せない。
なぜなら、Ruby使いは凄い。という前提になってるので、
凄いプログラマがJavaを使ったら当然良いコードが書けてしまうことになるから。
出されたコードが汚ければ、それはプログラマの問題だってバレてしまう。 どう考えても
Ruby使いがJava使うよりも
Ruby使いがRuby使った方が
開発工数が少ないと思うが? Java使いがRuby使うよりも
Java使ったほうが開発工数少ないよね。
で? Java 100人×2年でモノにならなかった物が
Haskell 6人×0.5年で動いたという話もある >>30
人数変わってるってことは
人変わってるってことじゃんか?
それじゃ、言語ではなく人間の問題だろ。
言語の比較実験なら、同じ人間を使って同じ条件でやらないと意味が無い。 >>29
そうか?
そのJava使いがマトモなら、Rubyのほうが工数少なくなる可能性は十分あるぞ。 >>32
大差ないよ。
だって冗長なコードは
ライブラリを使ったり作ったりすればいいだけだから。 それ言い出したら、何だって「だってライブラリ使ったり作ったりすればいいだけ」だろw うん。だからスレタイの通り。
開発工数を大幅削減できた言語は存在しない。
開発工数削減に重要なのはライブラリのほうさ。 そりゃ、やりたい事そのままのライブラリがあればねー
まあ土方仕事は他人の仕事の後追いだから、
ライブラリはあるだろうけど なければ自分で作ればいいだけだよ。
> まあ土方仕事は他人の仕事の後追いだから、
> ライブラリはあるだろうけど
それこそ、言語関係ない話だな。
お前の好きな、○○言語にあるライブラリ言ってみ。
土方仕事だからそれらのライブラリがあるんだって
お前はいってることに気づいてるかい? ある言語で、自分で作らなければいけなくて作る工数が大きくかかるものは、
どうせ他の言語でも、同じように作らなければいけなくて工数が大きくかかる。
だから言語によって開発工数に差がない。 >>39はトートロジーだな。
同じ機能のライブラリの開発に必要な工数が言語によって大きな差異がなければ、
開発に必要な工数は言語によって大きな差異はない、
と言ってるだけ。 ないというなら、全部アセンブリで書いてみろって話。 現実見ろよ。
必要とされるライブラリの多くは既に存在し、
何か特殊なライブラリを作る場合でも、
既に存在する別のライブラリを使って楽できる。
ライブラリによって開発工数が大幅に削減できるため
言語で差が出ることは少ない。
>>42
アセンブリ言語はライブラリが少ないのでねw 開発しやすい言語はライブラリも書きやすい => ライブラリも充実しやすい なんでも極論して同じって言ってるだけじゃんw
つまんねー >>44
>開発しやすい言語はライブラリも書きやすい => ライブラリも充実しやすい
それだと、ライブラリの充実度を見れば、どの言語も大差ないので、
やっぱり、開発のしやすさは言語と関係ないってことになるじゃん。 Pythonのscipyと同レベルの科学技術計算ライブラリって
どの言語にもあるわけ? http://www.infoq.com/jp/news/2011/07/NumPy-NET
Visual Studioプロジェクト向けのPythonツールの一部として、
有名なNumPy と SciPy ライブラリが.NETにポートされた。
ネイティブなCコアへのC#とCインターフェースを合わせたもので、
全.NET言語が利用できるような方法でポートされた。
でも開発言語Pyothonじゃんというけれど、出来てしまった今は
他の言語でも同等の生産性になってしまったわけで
ライブラリができることによって、やっぱり差はなくなる。 RubyやPerlのライブラリなんか、
実際の所、Cのライブラリがコアだったりするわけで。 IronPythonのscipyも使った事あるけど、パッケージ数が
CPythonと比べて全然少なかったな
stats、special、linalg、fftpack、constants、misc くらいか? scipyなんか言語ではなくライブラリの存在で
開発効率の差が出るという典型的な例だね。 >>43
アセンブリは他の言語のライブラリ呼べるから、その言い逃れは通用しない。
さあ、全部アセンブリで書いてみろよ。 >>55
他の言語のライブラリを呼ぶための方法がある
アセンブリ言語ってなに?
その使い方をここに書いてみてよ。 >>54
Pythonのスライス記法があるからこそ
numpy/scipyのベクトル演算/行列演算は書き易いんであって
それが無かったら魅力半減
どの言語でも良いというわけじゃないよ >>57
ああ、そういう場合はね。
スライス記法と同等の事ができる
関数を作ればいいんだよ。
スライス記法は手段であって目的ではない。
同じ目的を達成できる方法が作れれば、
それで関数でも良い。
言語の基本機能だけで作ろうとするな。
関数は自分で作るもんだ。 ■ このスレッドは過去ログ倉庫に格納されています