アカウント名:
パスワード:
5年前にJavaではもう儲からない [developers.srad.jp]なんて記事があったのに、このポジションを堅持しているなんて。
一回でもある程度まで使われた言語は、一線を退いてもメンテだのなんだのとその後も需要はありそう。そういう感じのCOBOLは、最近COBOLをJavaにAIで置き換えるみたいなニュースもあったような気はするけど。
>最近COBOLをJavaにAIで置き換えるみたいなニュースもあったような気はするけど。
最近は、アセンブラ⇒COBOLですよhttps://it.impress.co.jp/articles/-/25288 [impress.co.jp]
＃COBOL⇒Javaのにユースに便乗した感も・・・（自動とは言っていない）
他社でもやっているのでニーズはあるのでしょうhttps://www.palsys.co.jp/service/cobol/ [palsys.co.jp]
現実問題として、SIerで大規模開発するならJavaじゃないですかね。
裾野が広いので作業員数を集めやすく、技術者でなくてもそこそこ知ってる人が多いので、共通言語にしやすいってことですね。自然言語で言うところの英語みたいに、ベストじゃないけど知ってる奴が多いしそれでいいか、みたいな。
Pythonなんて謎の言語(笑)選んで、案件炎上したら言語選定した人間の責任にされます。まあ、安めの人員調達が容易で、既存実績は豊富、ライブラリ群の揃いも良い。
新しい言語の便利な新機能は、大規模開発ではガンにしかなりませんし。ラムダ式とか弱い型とか、質の不安定な大人数に理解させるのとか嫌です。
> ラムダ式とか弱い型とか、質の不安定な大人数に理解させるのとか嫌です。
このへん、Java は便利よりも安全に振ってるので、素人がクソコードを作りにくいというのはあるよね。
もともとはPythonの方が「同じことをするならほぼ同じコードになる」を目指すことでクソコードを作りにくくしようとしたんだけどね。
Java案件の場合、コードはともかく設計がクソだという例が多いです。あと、Javaの方が1行にかけられる工数が多い分、ポカミスは少ない気がしますね。
Pythonの方の想定してるクソコードはPerlのクソコードでJavaの方はC++のクソコードだろうなあ
> Java案件の場合、コードはともかく設計がクソだという例が多いです。
クソ設計スキルの持ち主はどんな言語だろうが独創的なクソ設計を実現できます。だからそれは母数の多さ(今の需要だけでなく過去の蓄積も含むのでJavaの方がかなりでかいはず)によるものでしょう。
Javaが.Net前のVBみたくなってますね
Java人員のレベルも、当時のVB人員のレベルと変わらんな。9割ぐらいは使い物にならなくて、1割ぐらいの人間でまわってる。
まあ、9割に属する人間を用意出来るだけマシとも。そいつら束ねて人数分のお代をいただけるから、単金以上のお給料貰えるわけですし。
さて、自分は本当に1割の方なのか、束ねられる方なのか。
まあ、そういうところの決定権のある人の知識って、そんな感じだよね
Python 1991年Java 1995年
開発年よりも普及年の方が大事、ってとこまで言わないとわからない？
そうやって間違ったことを言っても誰も指摘しなくなるのも、ありがち。
ラムダ式は別に難しくない。ラムダ式がLisp以外に存在しなかった時代の老人に理解させるが難しいの間違いだろ。ただしC++のラムダ、てめーはダメだ。何だよコピーキャプチャーと参照キャプチャーって
Lispだと気にならないけどC風シンタクス言語のラムダって括弧がゴチャゴチャして目が滑るんだ
否定しようがなく現実的。だからそんな現実とは関わり合いになりたくない。
需要があるからと言って儲かるわけでもない。
Javaからの脱却に断念したものが多いいと聞く
Oracleさんはちょっと前にmysqlにも爆弾を仕掛けてくれたので「もー」っておもってます。
#スペクトルレディー
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
むしろJavaがすごい (スコア:2)
5年前にJavaではもう儲からない [developers.srad.jp]なんて記事があったのに、このポジションを堅持しているなんて。
Re: (スコア:0)
一回でもある程度まで使われた言語は、一線を退いてもメンテだのなんだのとその後も需要はありそう。
そういう感じのCOBOLは、最近COBOLをJavaにAIで置き換えるみたいなニュースもあったような気はするけど。
Re: (スコア:1)
>最近COBOLをJavaにAIで置き換えるみたいなニュースもあったような気はするけど。
最近は、アセンブラ⇒COBOLですよ
https://it.impress.co.jp/articles/-/25288 [impress.co.jp]
＃COBOL⇒Javaのにユースに便乗した感も・・・（自動とは言っていない）
他社でもやっているのでニーズはあるのでしょう
https://www.palsys.co.jp/service/cobol/ [palsys.co.jp]
Re: (スコア:0)
現実問題として、SIerで大規模開発するならJavaじゃないですかね。
Re: (スコア:0)
裾野が広いので作業員数を集めやすく、技術者でなくてもそこそこ知ってる人が多いので、共通言語にしやすいってことですね。
自然言語で言うところの英語みたいに、ベストじゃないけど知ってる奴が多いしそれでいいか、みたいな。
Re: (スコア:0)
Pythonなんて謎の言語(笑)選んで、案件炎上したら言語選定した人間の責任にされます。
まあ、安めの人員調達が容易で、既存実績は豊富、ライブラリ群の揃いも良い。
新しい言語の便利な新機能は、大規模開発ではガンにしかなりませんし。
ラムダ式とか弱い型とか、質の不安定な大人数に理解させるのとか嫌です。
Re: (スコア:1)
> ラムダ式とか弱い型とか、質の不安定な大人数に理解させるのとか嫌です。
このへん、Java は便利よりも安全に振ってるので、
素人がクソコードを作りにくいというのはあるよね。
Re: (スコア:0)
もともとはPythonの方が「同じことをするならほぼ同じコードになる」を目指すことでクソコードを作りにくくしようとしたんだけどね。
Re: (スコア:0)
Java案件の場合、コードはともかく設計がクソだという例が多いです。
あと、Javaの方が1行にかけられる工数が多い分、ポカミスは少ない気がしますね。
Re: (スコア:0)
Pythonの方の想定してるクソコードはPerlのクソコードで
Javaの方はC++のクソコードだろうなあ
Re: (スコア:0)
> Java案件の場合、コードはともかく設計がクソだという例が多いです。
クソ設計スキルの持ち主はどんな言語だろうが独創的なクソ設計を実現できます。
だからそれは母数の多さ(今の需要だけでなく過去の蓄積も含むのでJavaの方がかなりでかいはず)によるものでしょう。
Re: (スコア:0)
Javaが.Net前のVBみたくなってますね
Re: (スコア:0)
Java人員のレベルも、当時のVB人員のレベルと変わらんな。
9割ぐらいは使い物にならなくて、1割ぐらいの人間でまわってる。
Re: (スコア:0)
まあ、9割に属する人間を用意出来るだけマシとも。
そいつら束ねて人数分のお代をいただけるから、単金以上のお給料貰えるわけですし。
さて、自分は本当に1割の方なのか、束ねられる方なのか。
Re: (スコア:0)
まあ、そういうところの決定権のある人の知識って、そんな感じだよね
Python 1991年
Java 1995年
Re: (スコア:0)
開発年よりも普及年の方が大事、ってとこまで言わないとわからない？
Re:Re: (スコア:0)
そうやって間違ったことを言っても誰も指摘しなくなるのも、ありがち。
Re: (スコア:0)
ラムダ式は別に難しくない。ラムダ式がLisp以外に存在しなかった時代の老人に理解させるが難しいの間違いだろ。ただしC++のラムダ、てめーはダメだ。何だよコピーキャプチャーと参照キャプチャーって
Re: (スコア:0)
Lispだと気にならないけどC風シンタクス言語のラムダって括弧がゴチャゴチャして目が滑るんだ
Re: (スコア:0)
否定しようがなく現実的。だからそんな現実とは関わり合いになりたくない。
Re: (スコア:0)
需要があるからと言って儲かるわけでもない。
Re:Re:負の遺産ですからねぇ (スコア:0)
Javaからの脱却に断念したものが多いいと聞く
Oracleさんはちょっと前にmysqlにも爆弾を仕掛けてくれたので
「もー」っておもってます。
#スペクトルレディー