5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ライブラリ/フレームワーク込で考える開発効率が高い言語

1 :デフォルトの名無しさん:2012/03/20(火) 13:06:48.03
実際の開発ではすべてを自分で作るのではなく
既存のライブラリやフレームワークを使います。

いくら言語自体が優れていても、
その周りのライブラリやフレームワークが
未成熟だと、現実的には時間がかかります。

ライブラリやフレームワークを使う前提で、
開発効率が高い言語はなんでしょうか?


2 :デフォルトの名無しさん:2012/03/20(火) 13:09:04.12
Visual Studio。

どうせWindows案件が全体の8割超だろ?

3 :デフォルトの名無しさん:2012/03/20(火) 13:12:52.57
効率考えたら、Visual Studio + C# しかないじゃん。

4 :デフォルトの名無しさん:2012/03/20(火) 13:13:16.49
Javaも開発効率が高いね。
とくにウェブ系。

デスクトップはVisual Studioっていうか
言語で言えばC#だな。

5 :デフォルトの名無しさん:2012/03/20(火) 13:15:38.26
職業的なプログラミングでは、論理的な中核部分は考える時間が大半で
どの言語を使おうが書く時間はボトルネックにならない
言語の選択によって重大な差が生まれるのは
ファイル入出力だったりデータベースアクセスだったりWeb連携だったり
ネットワーク通信だったり。論理とはかけ離れたゴミのような部分
プログラマはそのことを知っているので、言語を選ぶときにそんなところは見ない。
「枝葉末節」をどれだけ簡単に書けるかという視点でサポートライブラリの豊富さを見る。
そっちの篩で先に「使えない言語」が落とされて、
残った言語の中ではじめて「スマートさ」が比較される。
言語屋と現場ではフィルタの順序が逆なんだ。



6 :デフォルトの名無しさん:2012/03/20(火) 13:25:35.81
VisualStudioはIDEで、フレームワークじゃなくね?
じゃあEclipseがフレームワークなんか?

7 :デフォルトの名無しさん:2012/03/20(火) 13:34:47.74
C++はオブジェクト指向のくせにCより開発効率悪くね?

8 :デフォルトの名無しさん:2012/03/20(火) 13:35:29.26
MVCフレームワークが充実してる言語だろ。
PHPは強いんじゃないか。

9 :デフォルトの名無しさん:2012/03/20(火) 13:41:08.22
Javaは、プログラマから見た開発効率は普通
経営者から見た開発効率は最強
なんてったっていつでもどこでもプログラマが買える

だから、開発言語のトップグループにJavaは常に存在するし、
Javaによる案件は絶対に減らない

10 :デフォルトの名無しさん:2012/03/20(火) 14:03:05.56
> なんてったっていつでもどこでもプログラマが買える

なぜかね?


11 :デフォルトの名無しさん:2012/03/20(火) 14:14:10.84
学のないボウヤにでも扱えるからさ

12 :デフォルトの名無しさん:2012/03/20(火) 14:22:51.44
プログラマを大量製造できて大量使用できるように考えて作られた言語だから、が正解

たとえばC++は大人数開発にはあんまり向かない
Perlも別ベクトルで共同開発にはそれほど向かない

Javaのコンセプトをスクリプト言語とWebという分野で(結果的に)特化したのがPHP
大多数の一般的な「Javaぷろぐまー」がプログラミング能力はもっさいのと同様、
大多数の一般的な「PHPぷろぐらまー」のプログラミング能力はがっさい

そんな人間(を取り扱う人間)でもいちおうのプロダクトを作ることができるという点では開発効率が高いとも言える

13 :デフォルトの名無しさん:2012/03/20(火) 14:25:02.74
>>11
なぜ、学のないボウヤにでも扱えるのかね?

14 :デフォルトの名無しさん:2012/03/20(火) 14:25:52.89
>>12
どういった点が、
プログラマを大量製造できて大量使用できるように
なっているのかね?

15 :デフォルトの名無しさん:2012/03/20(火) 14:27:36.95
>>14
明日になったら答えてあげてもいい
どうせ何を書いてもレスするはずだ

16 :デフォルトの名無しさん:2012/03/20(火) 14:28:17.81
>>7
それは単に知識のない奴がオブジェクト指向っぽいものを勘を頼りに作ってるだけだから。
もともとオブジェクト指向はパーツ単体で見ると非OOPよりも手間=コストがかかる。
しかし、全体としては再利用により効率化されてコストダウンとなる。
というよりも、再利用によって効率化されないならOOPを利用する価値がない。
開発が大規模であること、多人数であること、そしてコストの見極めを出来るリーダーが不可欠。

17 :デフォルトの名無しさん:2012/03/20(火) 14:31:06.80
>>15
まあね
ヤスミの鸚鵡返しの暇潰しにわざわざ付き合う義理はない

18 :デフォルトの名無しさん:2012/03/20(火) 14:32:39.82
>>15
いえ、結局言語が優れているからこそ
よく使われるわけなのに、
その理由が出てないのが不自然すぎるわけです。

19 :デフォルトの名無しさん:2012/03/20(火) 14:33:57.41
学が無くても使えるのも、
プログラマが大量製造できるのも
理由ではなく、結果でしょう?

20 :デフォルトの名無しさん:2012/03/20(火) 14:39:21.58
安いプログラマが大量に調達できるから、Java案件が増える。
Java案件が増えるから、とりあえずJavaを学んだプログラマが増える。


21 :デフォルトの名無しさん:2012/03/20(火) 15:04:56.05
>>20
フレームワークが山のようにあるから必要案件のロジック部分とグルーロジックだけで済むからだと思うが?



22 :デフォルトの名無しさん:2012/03/20(火) 15:07:28.39
素直に優れていると認められない。
面倒な人たちですなw

23 :デフォルトの名無しさん:2012/03/20(火) 15:14:15.32
javaは今最もプログラマの多い言語だけど
肝心のVisual Studioに入っていないから
javaがトップの高効率開発言語って認めたら
マイクロソフト的には死だからね。

ちなみにVisual Studioは
二番目にプログラマ人口の多いCもC99で止まっていて、
まともにフォローしていない。

ということは、第三位の言語C++が切られるのも時間の問題。
実際、テンプレートの対応状況は最悪で、C++11への対応も次期バージョンでは小範囲に留める、
C++/CLIはほぼ開発停止など、C++を切る気まんまんで萎える。

Windowsを捨てる時が近づいている。
NEXT STEP

24 :デフォルトの名無しさん:2012/03/20(火) 15:39:31.17
webならphpに勝てるものはない
GUIならC#最強説
phpとc#だけあれば他はいらない
javaなんてmacとlinuxさえ潰しちゃえば問題ない

25 :デフォルトの名無しさん:2012/03/20(火) 16:01:50.86
C++にはQtがあるじゃまいか

26 :デフォルトの名無しさん:2012/03/20(火) 19:42:26.74
>>13>>14
ポインタすら理解できずグローバル変数使いまくるようなレベルに合わせてあるからじゃね

27 :デフォルトの名無しさん:2012/03/20(火) 19:43:00.70
>23
そもそもMicrosoft的には.NET上で動作するアプリを作って欲しくて、ネイティブアプリは作って欲しくないんじゃないの?

28 :デフォルトの名無しさん:2012/03/20(火) 20:35:06.36
>>27
OSが売れなくなるじゃないか

29 :デフォルトの名無しさん:2012/03/20(火) 21:27:26.33
C#信者って無能なバカばっかだな。

30 :デフォルトの名無しさん:2012/03/20(火) 21:55:28.19
学会とか参加企業の都合考えるとJavaは.netに対してかなり有利なんだよな。
Oracleが自殺しない限り器用貧乏なJavaはまだまだ最強なんだわ。

ScalaとかPythonみたいな構文云々のLLは乱立する一方だし
もうしばらくはJavaやってるのが無難だな。

31 :デフォルトの名無しさん:2012/03/20(火) 22:07:53.84
受託とかフレームワーク仕事とかしてて、雇われプログラミングで飯食べるならJavaが無難だろ
放っておいても飯の種があっちから口に入ってくる(そのぶん、質は不問になるが)

32 :デフォルトの名無しさん:2012/03/20(火) 22:12:58.04
>>31はなんか意味がわかってなさそうだ。
雇われプログラマ?なんだそりゃw

33 :デフォルトの名無しさん:2012/03/20(火) 22:38:12.78
>>31
安いけどな。
一人月30万円が普通になってきた。

34 :デフォルトの名無しさん:2012/03/20(火) 22:48:53.31
来月もプログラミングとその付随作業でお給料がもらえる(予定)なんだから、このご時世それもアリだろう
自分で起業して開拓するほどの根性も技術もツテも話術もないわけで

35 :デフォルトの名無しさん:2012/03/20(火) 23:56:35.74
あれだ、無料で環境一式が揃うなんてことして
参入障壁下げまくったせいで自分の首を絞めているんだ

開発環境一式50万円みたいな時代に戻さないと

36 :デフォルトの名無しさん:2012/03/21(水) 11:59:26.49
マッチングサイトみたいなのが乱立してきたから仕方が無い
気軽に退職した主婦やら趣味でやってる学生が気楽に参加できるようになったからな
IT系でそれなりに名前が売れているような人も進んでこういう類のサービスを利用するようになってるし

37 :デフォルトの名無しさん:2012/03/22(木) 01:36:04.09
Python

38 :デフォルトの名無しさん:2012/03/22(木) 05:52:29.28
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所


39 :デフォルトの名無しさん:2012/03/23(金) 22:02:01.15
COBOLが生き残ってる理由がまさにこれだな
ドカタ仕事には重要なファクター

40 :デフォルトの名無しさん:2012/03/26(月) 10:17:18.76
COBOLはレガシーなだけだお
ライブラリが豊富とかいうのとは方向が違うお

41 :デフォルトの名無しさん:2012/03/27(火) 13:10:54.20
むしろライブラリやらフレームワークやらを切り離したからこそ
レガシーとして生き残れるのではないか

42 :デフォルトの名無しさん:2012/05/20(日) 07:04:14.14
毎回作り逃げで移行案件や新規案件ばかりもキツいので、
5年とか10年の運用コストも含めた運用対費用効果が高い言語も議論したいな。

cで作るのが鉄板かな。保守性がめちゃくちゃ悪いけど。


コボルは運用の為にメインフレームの運用コストを回収出来ないと割に合わないだろう。
銀行手数料とか投資顧問料が価格競争にならないのもこの理由だと思うよ。
自治体が運用してるコボル実行環境なんて税金で毎年凄い金額喰われてたりするよな。当時は数百万人の顧客情報で勘定処理なんてメインフレームしか選択枝なかったかもしれないが、今はインテルサーバにリナックス入れても現実的に処理出来るでしょうと。

確かにライブラリなんてものもなくいまだにisamファイルを力技でごりごりだもんなあ。sql何それ状態だし。
isamファイルごりごり遣るパフォーマンスを上げる為に、ディスク装置に専用のプロセッサ積んで処理させるヨだもんなあ。オープンとは真逆の閉鎖性。

43 :デフォルトの名無しさん:2012/05/20(日) 17:02:19.41
長く使いたいならC++で面倒くさい部分だけCで組むのが良い。じゃないと10年も耐えられない。

44 :デフォルトの名無しさん:2012/05/20(日) 17:59:40.70
>43
それだとソースコードが10年後使えるかもしれないが、吐いた実行ファイルは10年後はまず使えないだろうな。

45 :デフォルトの名無しさん:2012/05/20(日) 19:15:13.09
>>44
じゃあ、実行ファイルが10年後のハードでも確実に動くのってなによ?

46 :デフォルトの名無しさん:2012/05/20(日) 19:29:00.32
Javaはたぶん動くだろうな。
改修するのはJavaプログラムじゃなくてJVMのほうだから。

47 :デフォルトの名無しさん:2012/05/20(日) 19:44:46.10
そんな幻想は捨てようぜ…。
確かに純粋にJavaの仕様の範囲内でコードを書けば、いつでもどこでも動くものになるだろう。
が、そんなことはほとんど無理だ。

48 :デフォルトの名無しさん:2012/05/22(火) 07:10:28.19
javaで太古の昔に組んだクラスを今でも継承で使っていて再利用して使い回してるなんてのは無いのかな。
まあそれも5年程度のハードの更新で作り直してまっさらに再設計してるか。

12 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)