富士通がCOBOLをJAVAに変換する超画期的システムを開発

COBOLなどの既存システムから日本語の設計書とJavaソースを作成、富士通が新サービス

図1●設計書化モダナイゼーションサービスの概要（富士通の発表資料より引用）
http://itpro.nikkeibp.co.jp/article/NEWS/20120815/416081/15a.jpg

図2●COBOLプログラムから生成した設計書とJavaプログラムの例（富士通の発表資料より引用）
http://itpro.nikkeibp.co.jp/article/NEWS/20120815/416081/15bl.jpg

　富士通と富士通アドバンストソリューションズ（FASOL）は2012年8月15日、
企業情報システム向けの「設計書化モダナイゼーションサービス」を発表した（図1）。同日より販売活動を開始する。

　このサービスでは、富士通およびFASOLの担当技術者が顧客企業のメインフレームを調査。
COBOLやPL/Iなどで書かれているアプリケーションのソースコードを解析し、日本語の設計書に置き換える（図2）。
アプリケーションの保守担当者はソースコードではなく日本語の設計書によってアプリケーションの仕様が把握できるため、
アプリケーションの保守性が向上するという。

　また、日本語の設計書から新規システム用のJavaソースも生成可能。
この作業で富士通側はFASOLの開発支援ツール「InterDevelopシリーズ」を使う。
同ツールはテスト関連の機能も備えており、設計書からJavaソースの動作テスト項目の候補を自動抽出する。
作成されたテスト仕様書を使って、単体テストも併せて実行できる。
既存システムの再構築作業を効率的に進められるため、顧客企業側は再構築の低コスト化、短期化が実現できるとしている。

　本サービスはまず有償の「プレ解析」によりサービス適用の可否を判断する。
プレ解析の料金は10キロステップ当たり35万円。本サービスの料金は個別見積もり。

http://itpro.nikkeibp.co.jp/article/NEWS/20120815/416081/

保守屋泣かせのクソコード生成しまくりだろ、自動移植なんてろくなもんじゃない

こういうのは日立がやりそうなんだけどな

こんなことしたらIT土方の仕事がなくなってしまうだろ

javacを通るけど java とは呼べないシロモノなんだろ、まず。
あかん、あかんでぇ

画像のソース見るだけで可読性皆無の糞コードだとわかる

>>4
むしろ、これでシステムを移行してみたもののパフォーマンスが出なくて、
慌ててjava系のITドカタを多数招集、訳のワカランコードを前に地獄に落されるケースの方がありえそう・・・

>>4
むしろ仕事が増えるｗ
つらい仕事が

>>4
いやたぶん増えると思う、富士通がそんな完璧な仕事するわけがない

間違いなくとんでもないバグを生む

失業者増やすつもりか

コボラー終わった？

YPS は、どこにいったの？

コボラーの方が相対的に高給取りになっちゃったんだっけ
昔はＩＴ土方の代名詞だったのに

手動でソース解析して一式移行とかやる方も死ぬなこれ
スパゲティの中の重要コード見逃して障害が発生するいつものパターン

何このひっでえjavaのサンプルコード、俺COBOL知らないけど元のコードの方が万倍読みやすい

IDENTIFICATION DIVISION.
CONFIGURATION SECTION.

英文を自動和訳した後にそれをまともな日本語に直していく感じ？
頭から自分で和訳した方がよっぽど楽だけど、それより辛そうｗｗｗ

SOURCECOMPUTER ACOS.
OBJECTCOMPUTER ACOS.

そういや昔にEJBでCOBOLアプリ動かすとかキチガイじみたことやってた気がするんだけど
それじゃダメなのかね

javaってよく知らないんだけど

sagyounen = new Date();
sagyounen.setYear(2012);
sagyounen.isUruuDoshi();

ぐらいできるんじゃないの？

こんなソフト導入するくらいなら
z10あたりにリプレイスしたほうが
安くあがったりして

枯れたコードを富士通に弄らせるってマゾかよ

JAVでググってはいけない

>>23
失業者対策だろ、粋な計らいじゃん

>>24
jav-teenいいね

日本語設計書ってのは自分で書くの？

富士通の下請けが日本語設計書作ってそれを元にソフトでjavaを自動で作成
下請けがjava確認して手直し
完成




仕事が増えるな

ステップ（）

コボルらしいな

これは糞システムを量産するだけ

今あるCOBOLプログラムなんてホストのをそのまま移植しただけだろ
最新アーキテクチャにまったくついていけてない　多分2000年当時の最先端にも追いついてない

それをさらにJavaに移植とは狂気の沙汰
いくら高性能なハードがあっても足りん　そこが狙いなんだろうが

一番いいのは捨てて1から作り直すこと
過去の設計者は全員再教育が必要
大規模システムの構築運用は今の日本の大手ITの技術レベルでは不可能　ドコモを見よ

Web規模へのスケーリング技術はGoogle, Yahoo!, Amazon, Azureなどアメリカの大手はすべて独自開発を完了している
日本にはせいぜい『大規模クラサバ』時代までのノウハウしかない

スレタイの時点で皮肉入ってるし
クソなの分かり切ってるから
ドヤ顔で解説いらねーから

>>1
＞　本サービスはまず有償の「プレ解析」によりサービス適用の可否を判断する。
＞プレ解析の料金は10キロステップ当たり35万円。本サービスの料金は個別見積もり。

たっか

ただの単コンをハードウェアスペックのパワーで強引に回すわけですね

別に自動化したって書いてないだろ

使い物にならなくなった三流PGを100人ぐらい蛸部屋に押し込んで
手作業でやるんじゃないの

>>1
コぼるのソースから自動生成した日本語の設計書(笑)
人が読めたもんじゃねーだろ

重複するコード増やして何がしたいの？

なおクソ高い料金のItaniumサーバ（販売終了）では主にCOBOLが稼働した
Itanium用のCOBOLコンパイラなんて世界でもまともなものがなく性能では当時のXeonサーバにも完敗

COBOLやるならまともなコンパイラ作りからやれよ
だがIntelプロセッサ用の最適化COBOLなんて作れる奴いるのかね

フルスクラッチで書きなおしたほうが
早そうだし、今後のためにもいいんじゃねーの？

大昔のクソコードに延命措置施して
誰が得するんだ？

スレタイ速報ワロタ
人力変換だぞ

変換してそのまま動けばいいけど
その後仕様変更したくなったらどうすんのさ？

このレベルで35万かよありえねー

こりゃCOBOLからJAVAに組み替える仕事大幅に減るなｗ
ましてCOBOLぐらいしか満足に出来ないようなおっさんは確実に終了するなｗｗ

>>38
もう動きゃいいよって世界だけだろこれ使うの

今のシステムを使いつづけたいけど、ハード寿命等々で使えなくなる
新しいハードにいこうにもCOBOL縛りだとハード選定は難航する
Javaに変換して大部分はそのまま動くならみたいな

COBOLで動かす処理系をJavaで動かすキチガイなんかいるの？

絶対に触りたくないな

仮想マシン上にホスト環境を構築するとか無理なのかな
変態I/Oばかりだろうが

もうその方が早そうな気がする

>>46
今は仮想化じゃないの？
でもまあ仮想化したところでコードは生きてるので保守が必要・・・

COBOL
COMPUTE A = B * 100.5 / C.

JAVA
a = b.multiply(new BigDecimal("100.5")).divide(c);

COBOLの資産は果てし無く残ってるけど
COBOLを扱える人間はどんどん消えている
お前ら、COBOL覚えておけば一生食っていけるぞ、マジで

知り合いが大手でSEやってて仕様書からソース吐くシステム使ってるが、
そのトラブル対応大変すぎて納期すっ飛ばして訴訟になってたぞ

でもまあ難しく考える必要はないんだよな

COBOLソースを当時のマシンのマシン語に変換して
そのマシン語コードをＶＭで使う中間コードとみなせばいいだけだし

仕様書からソースを吐くようなツールって、人工知能でも開発されないかぎり、
けっきょく日本語プログラミング言語でコーディングするだけになるんじゃないの?

>>52
霞ヶ関文学（）を卒業できれば可能だよ

それができない以上は永遠に無理だな

日本語は霞ヶ関文学（）見ればわかるようにいくらでも
糞にできるんだから

あと日本の企業はｵﾚｵﾚ実装が過ぎる

>>50
いや、普通は使う前にわかるだろそんなこと
うちも20年くらい前にYPS使って開発することが決まったけど、
速攻で欠点レポート作って納期守れませんって指摘したら即座に中止になったな

>>49
無理です

>>48
1兆円クラスの小数点付き銭計算を山盛りするとなると、
COBOL一択なんだよな。

うちの親父が昔富士通に勤めててCOBOLでいろいろな役所か何かのシステム作ってたらしいが
「俺がいたころはトラブルは一度もなかった」って言ってたぞ

>>47
ホストのOS自体がVM前提になってるからホスト環境では当然VMだけど、
その環境全体をx86でエミュレートすればいいんじゃないかと

もう性能的にも

＞http://itpro.nikkeibp.co.jp/article/NEWS/20120815/416081/15bl.jpg

COBOLってソースにいちいち行番号書かなきゃいかんの？

普通はエディタが連番ふってくれるから気にしなくて良い
行挿入した時とかは入力した気がする

>>58
でも所詮は仮想マシンだから古いマシンに合わせたソースを書かないと駄目だけどねｗ

何れは中間コードベースに新しいソースにリバースエンジニアリングしないとｗｗ


>>59
今はどうかしらんがメインフレーム関連はそういう物よ
もっと糞なのが1ライン半角80文字制限があってしかも
その80文字のうち[行番号][ソース][コメント]
みたいなエリアが存在して実際コードに使えるのは70文字程度wwww

世の中には恐ろしいことを考える人間がいるもんだ

こんなの仕事増えるだけだろ

富士通のソフトでまともに動くものなんてないよ

>>59
書かなくても良い
行頭6バイトはコンパイラは無視してるはずでここに修正日付のYYMMDDを入れてる人もいる
ただこのエリアに全角文字書くとコンパイル出来なかった気もする

>>62>>63
だって国内大手メーカーなんて官僚と変わらないやつらが集まってるから、
恐ろしい考えをするよ自分たちにとって都合のいい仕事を増やす

尻拭いは関連企業を通じてソルジャーにやらせておけばいいんだしｗｗｗ

むしろこの分野こそ日本語コボルとかが役立ちそうだけど

VB6にも対応していただけませんでしょうかorz

JAVAをCOBOLやCに変換する未来が見えるな

>>69
ＪａｖａってCOBOLと同じ道を辿りそうなのにそのJavaに変換するところが
これまた役所ぽい企業の考えることだよね

まあある時期のJavaブームに乗っかった企業が多くてサーバー側は
変えられないんだろうけどさｗｗｗｗ

COBOLソース　(変換)→ 日本語設計書　(変換)→ JAVA

ってことか

これを保守するほうが手間掛かるだろう弾はｺﾎﾞﾗｰより潤沢だ

>>61
まだパンチカードの制限引きずってるのか

お前ら勘違いしてるけどCOBOLほど寿命の長い環境も無いぞ、COBOL技術者は不足でプレミアつき始めてるし

COBOLを棄てなければならない理由ってあるのか？
まだテープドライブが動いてる運送屋とかあるけど会社が潰れてなけりゃ50年後も使ってそうな感じだが・・・
OSに不備がない分古い資産は意外と優秀らしいけど

>>75
高額なメンテナンス代とか定期的に払ってくれるなら
ロートル技術者を飼ってられるけど、お金がでなければ
わかる人がいなくなる

パイソン辺りに変換したほうがまだマシなんじゃない？

見えてる地雷

どうせCOBOLもJAVAも使えないと扱えない代物になるんだろ

画期的なシステムでも開発したのかと思えば、
下請けに放り投げて解読して作りなおす糞人力だった。

>>1
設計書ｗｗ
設　　計　　書ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
あかんｗｗｗｗｗ

>>75
>COBOLを棄てなければならない理由

・組織の変更、統廃合
・法制、税率、年号などの変化
・連携する外部システムの変化
・新しい機能の追加要求
…に対応できなくなったときが捨てどき

今から新人にCOBOLを教えるのは人権侵害として訴えられるかも知れんw

>>75
浮動小数点が使えない銭計算、それも小数点付き、
数えるのもおぞましい位のファイル数に、魑魅魍魎の
レコード種類、とくればCOBOL一択。

ファイルとレコードを定義するのに９割の時間を使う
のが最大の特徴。

いまいちよく見えないけど、こんなJavaソース絶対に嫌だ
http://itpro.nikkeibp.co.jp/article/NEWS/20120815/416081/15bl.jpg

COBOLを取るか、システムを更新するか、どっちかにしろよ

ヒュー

そんなもんより
ARROWSのクソ発熱で充電するシステムでも作れよボケ不治通

>>84
完璧な物作ると将来仕事減るからな

将来ＣＯＢＯＬと同じポジションになりそうなＪａｖａの
しかも糞ソースとして出力することで将来の仕事も確保

知り合いのコボラーが四捨五入がどうのとかで金融はCOBOLじゃないと駄目なんだとか言ってたな

１円単位であう必要があるからけっこう致命的なんだとかで

そういえばこれ金銭計算はBigDecimalにするのかな
あれは文字列だぞ

ぶっちゃけ、発注側は動けばいいだけだからな
保守性なんざ考えてない

javaって仕事ないからこういうことして生き延びようとしてるの。

>>89
Javaだと上の人の通りBigDecimalにすることになるんだろうけど、
何百、何千って言う項目があって、各々の小数点も違えば
桁も違い、用途も違う、ってコトで、そこを定義するだけでJava
だと（保守で）死ぬw

>>82
> 今から新人にCOBOLを教えるのは人権侵害として訴えられるかも知れんw

新規の案件なのにVB6で作りたがるベテランとか、自分が新しいのをおぼえられない
だけなのに、なにか深遠な理由があってJava1.4を使い続けてるようなことを言ってる
ベテランとかも、ほとんど犯罪行為だよな。

割り算や小数点の問題で10進数使いたかったら
COBOLじゃなくてもDecimal型にすればいいだけじゃないの？

四捨五入どうのってのは言い訳じゃね？
そういうクラス作ればなんとでもなる気がするが

絶対上手くいくわけないｗ

で、COBOL使える奴この中にいるのか？

「COBOL技術者不足」っていうけど、実際は業務知識とか環境の知識のことを言ってるんだよな?
COBOLだけなら、そこらへんのJavaプログラマーやらCプログラマーを捕まえて、入門書をなげて
おけば翌日からでも実戦にほうりこめるよな。

わかってないみたいだから書くけど、こーいうのってハード保守切れで更新を余儀なくされてるユーザが金無くて一から作り直しできない時に使うもんだ

後々、余計に金がかかることになるのは既出のレスどおり
なーむー

COBOLって何の略だっけ

なんでオワコン言語をオワコン言語に変換するの？
馬鹿じゃね？

もう聞いただけで寒気のするシステムだ

>>94
新しいことに挑戦するのが面白いのに日本の似非技術者は公務員もどきが多いんだなｗ

怖ぇぇぇえ・・・

うわ・・・・・まあ、がんばれしか言えない

>>95-96
正しい計算結果を出すこと自体はJavaでももちろんできる
でもBigDecimal多用するのは速度面でも不利だし>>48みたいにソースの可読性も落ちる

COBOLの死ぬ死ぬ詐欺が実現する日が来そうで来ないな

>>93
これか
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/math/BigDecimal.html

ひどい解説ﾜﾛﾀ
static int ROUND_HALF_DOWN 「もっとも近い数字」 に丸めるモードです。
static int ROUND_HALF_EVEN 「もっとも近い数字」 に丸めるモードです。
static int ROUND_HALF_UP 「もっとも近い数字」に丸めるモードです。

うちのじーちゃん７０歳超えてるのに、
まだ呼ばれるぞ。
そんなにCOBOLって大変なのか。

>>110
古い糞言語な上に業務と絡んでるから・・・
http://www16.plala.or.jp/hiyokogumi/top.html

>>100
当の富士通はそんなこと思ってないだろう
自動化自動化て何年前から同じこと言ってるんだか
どうせ中開けたら素人が頑張って作ったようなシステムなんだろうな

>>104
俺の周りだけかもしれんが、会社にこれ学べって言われなきゃ学ばない奴も多い
おかげで、デザインパターンは知ってるけどオブジェクト志向は分からないなんていう
奇妙な人罪が量産されたりしてるw

ああ自動化じゃないのか
COBOLおじさんの雇用対策としてはいいんじゃないでしょうか

まだコードの自動生成なんてネタが残ってたのか

ガラパゴスはすげーな

そもそも勘定系でJavaみたいな欠陥言語使うのってありえないよな

予言

死人が大量に出るｗ

>>107
演算子のオーバーロード使える言語なら解決だな
きっちり仕様まとめないと混乱するけど

COBOLって一体なんなんだよ・・・
老技術者の特権みたいになってるけど、今からあそこに滑り込めないのか

成果主義を日本に持ち込んで、社会をギスギスさせてトンズラこいた富士通さんですか。
今度はベテランCOBOL技術者の仕事を奪った上、
クソjavaコード量産させてデスマーチを起こして自殺者を増やすつもりですか。
ほんと富士通は社会が負になることしかやらない。

ところで株主でもないのに社長をクビにしてしまったという秋草相談役は
まだ富士通さんが大事に保護なさってるのでしょうか。

Javaに変換しても手続き型のままなんだろ？
生産性あんま変わらねーだろ
Javaでいいとこはオブジェクト指向なんだからそれ使わないと意味ない

元のCOBOLソースを読んで作りなおした方が早かったね、的なオチになる予感

COBOLをJavaのVMで動くようにすればいいのにって思うけど、そこまでの技術はないんだろうな。

>>121
まさかとは思うがJavaの方がCOBOLをコンパイルしたのより速かったりしてw

>>123
そんなことしなくてもＣＯＢＯＬのコンパイラそのまま使って当時の古いマシン
のマシン語そのまま吐き出させればいい

当時のマシン語を新しく作ったＶＭの中間言語とみなして処理すればいいだけなんだし

>>125
俺あんまりJAVA詳しくないけどJAVAの中間言語は一つだから中間言語なんじゃないの？

>>126
ちげーよｗ
中間言語っていうのは特定のマシンのネイティブマシン語になってないものだよ
実行時にターゲットマシンのマシン語にＪＩＴすることで速度アップできたりする

ゲーム機のエミュレーターも見方によってはVMとみなせる

違う言語からJava VMで動くバイトコードを出すシステムはある
http://www.is-research.de/info/vmlanguages/

Java VMの実行性能はいま英知が集中している分野だから向上が著しい
ただやっぱりCOBOLの型の扱いだよな面倒なのは

>>128
もうCOBOLの後追い決定だからCOBOLの型に相当するものを
VMレベルで実装しちゃえばいいのにねｗ

こんなものおっかなくて使えねえよｗｗｗ

狐のjavaアドオンが停止されたったｗｗｗ

COBOLなら5年ほどやった。2種もCOBOLで取った。

Java以外で業務系でマルチプラットフォーム環境で使える言語って何がある？

あーあ改修ふえるなー
作り直させろ

>>133
無いよ

マルチプラットフォーム系はそろそろWebアプリにシフトしてもいい

と思ってたが、HTML5のぐだぐだっぷりを見ると…

ぬるぽ

こええよｗｗｗ

結局全部手直ししなきゃならないんだろｗｗｗ

>>5
安心しろ
この手のシステムって結局ところどころ人力で手直しすることになる

安くて逝きのいいコボラー養殖してJava捨てたほうが早いよね

これからの若い世代の為を思うなら、基幹はパッケージに置き換えてやった方がいい

基幹こそパッケージにしちゃダメだろ
スケーラビリティや柔軟性のあるパッケージなんて見たことない

『パッケージ開発』と『適用』に分けられた時点でSEは死ぬ　システムは硬直化する　そしてCOBOLは居座りつづける
日本がそうやっている間に世界はどんどん進歩していく　(AA略）

気がついた時には東証のように世界の標準性能から2桁ぐらい遅いシステムを高コストで使い続けている

日本が硬直化したシステムにあぐらをかいている間に世界標準のアーキテクチャははるかに進歩していた

でも1円合わないんでしょ？

COBOLerの単価が上がりそうだが今更学ぶのは死ねる

>>142
東証のシステムが遅いのはOSにLinuxみたいなフリーソフトを使っているから・・・
OSにWindowsServerを採用すればもっと安定性が高く高パフォーマンスなシステムになってたはず

javaがオワコンだからC#やろうと思うんだけどC#もオワコンだと言われた
一体、何を勉強すればいいのか

病院のシステムがCOBOLだけどこんな変換したら絶対アウトだわ
帰れない日々が待っている

>>146
Objective-C

>>146
どれもそれほどかわらん
軸になるどれかをある程度やれ

細かい記述とか癖はそれぞれの言語であるし
結局ターゲットマシン次第でAPIやライブラリなど変わるから
これをやっとけば安泰なんてない

そんなぬるいこと言ってるのは日本の公務員ぽい勤め人くらいだよ

ただJavaはCOBOLの後追いしかかってるので「今時Javaだってよｗｗ老害ｗｗロートルｗｗ」
とか将来言われたくなければやめた方がいいな

>>146
静的型付けの言語で何か一つ
動的型付けの言語で何か一つ

個人的なおすすめはそれぞれJavaとPythonだな
それぞれちゃんとしたプログラムが書けるようになれば将来の言語にも対応できる

JavaScriptのほうがよくね？

変換だけなら猿でもできるわ
まともに動かなかったら補償してくれるんなら考えてもいい

JavaScriptもいいがPythonにはSciPyなどのライブラリが充実している点が気に入っている

好みで選べばいいと思うけど

コボラーやめて別業種への転職考えてるけど、
実はコボラー食いっぱぐれなかったりするの？

>>154
俺もそれを考えてる
実際のとこ仕事があるのか無いのかサッパリ見えてこないからCOBOL怖い

2chだとCOBOLは希少価値高いみたいな話をよくみるけど、
おれの周囲だとCOBOLは安い案件ばっかりだわ。

>>146
オブジェクト指向と関数型言語のハイブリットで将来が期待されてるScala

動的片付け言語
Javascript・・・言語仕様は糞だが、フロントサイドを寡占している人気言語なのでこれからも安定。
PHP・・・言語仕様は糞だが、現在のサーバーサイドの開発を寡占している人気言語なのでこれからも安定。
Ruby・・・言語仕様はなかなかいけてるが、仕事が殆ど無くRailsでの開発ぐらいなので趣味にとどめるべき。
Python・・・言語仕様はなかなかいけてるが、いかんせん日本だと求人が皆無。


静的型付け言語
Java・・・言語仕様はC#に抜かれたが、仕事が腐るほどあるので今後も困らないだろう
C#・・・言語仕様は最先端だが、いかんせんWin限定で、そのWinの未来がちょっと不透明
C++・・・もうゲーム開発にしか使われないオワコン言語
VB.NET・・・実はC#と同時開発で言語仕様も最先端だし、仕事もC#以上にある言語だが、
　　　　　　　いかんせんVBコーダーの90％がバカで無能で糞コーダーなので避けた方がいい
C言語・・・組み込みやOS開発で人気。これからも地味に仕事はある。
Objective-C・・・C#と同じく実質的にMac/iOS限定で、しかもiOSだとガベコレすら無い化石言語。

JavaScriptを糞だというのはニワカ

>>159
糞じゃなかったらCoffescriptなんて作られないわｗ

COBOLの話聞くとジャップが衰退してゼロから構築できた新興国が勃興するのがよくわかるね

・実績がないものは使わない
・可能な限り先代の資産を引き継ぎ、無用な変更はしない

という方針で徹底されてるのがシステム屋だからな
あらゆる産業の中でもIT業界ほど保守的な業界はないだろ

富士通の知人に聞いたところアウ、アアしか言わないからダメっぽいぞ

>>160
それ以外にhaxeとかjsxとかいろいろでてるな。

Topjaxで開発したことある奴あつまれ〜　＾＾ﾉｼ

>>158
そのリストみるかぎりじゃPHPとC言語覚えるわ

この期に及んで新規案件にJAVAブッ込まれた企業は可哀想だな。
元から腐臭はしてたけどさ、ORACLEが買収した時点で決定的になったな。

でも業務系では実際Javaしか選択肢がないんだよなぁ・・・
C#は実質Windowsでしか走らない時点でフロントエンド系はともかく基幹系では問題外だし

なるほど、そう思いこんでる奴がJAVAブッ込んでくるって寸法だな。

あるアプリ(ゲームでも業務でもない)のためC++とC#の勉強することになったが、
C++の方が自分が今何やっているかわかりやすくて好き。
でもFormアプリ作れと言われたらC#一択

ScalaとClojureの案件増えねーかな

JavaはSunやらIBMが後押ししたから普及したけどScalaはそういうのないから
広まらなさそう。

解析に3日、稼動まで10年かかる

>>169
C#でサーバサイドの開発なんかできんのか？
もちろんOSがウインドウズ一択ではお話にならないという前提で

>>174
つmono

>>175
商用それもエンタープライズ用途でそんなもん使えるかw

>>1
設計書ってなんだよ・・・
需要ねーだろこんなもん・・・

>>174
別にWinだけでも致命的じゃないだろ
大規模開発は、ASP.NET>>>PHP

最近.NetからLinux＋Javaへのリプレース案件が多いよね

お金掛かるからね

>>179
ウチは一回り遅れてて、大量にあるVB6資産をどうやって
.NETに移植しようか悩んでて、とりあえず動いてるからって
ことで放置してるw

.NET通過して、それこそLinux+Javaなんかもしれないね。

Webじゃなくてクラサバやるなら.NET一択だと思うけどね
Javaでまともにクライアント作れる？

言語なんてなんだっていいんだよ。
んなことばっか気にしてるからお前らは土方なんだ。
大事なのは何を作ってどんなビジネスを回すかだ。
それ考えない技術者は一生バカ文系の下請けだ。

>>183
釣りだと思うけど、そんなこと言い出す馬鹿が>>1みたいなことやりだすんだよね。

そんな上辺だけじゃ
韓国みたいな脆弱なもんになってしまう

>>185
こいつらが現場みないで金勘定ばっかりしてるから歪が出るんだよ
ユーザーの声が聞こえないんだわ

>>184
ドカタ乙〜

>>184
>>1みたいなものを下請けで作らされる道を選ぶか、
自分で作るべきものを考えるか、
きみに選択の自由はあるぞ。

>>188
俺はもう仕事選べる立場に居るからドカタ仕事は金輪際一切やらない