トップページ⇒tech
1001コメント324KB

【コボル】COBOL不要論【いらない】

レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさん2009/07/30(木) 16:12:56
COBOLなんてもう必要ないよね。
0809デフォルトの名無しさん2011/09/14(水) 11:00:39.81
>>808
してなかったよ。
前の会社でＣＯＢＯＬを使っていたがテストで組み合わせを
使ってテストデータを作成しようとしたら怒られた

本番データを持ってきてそのまま流せばいいだろう
と言われた。皆、本番データを持ってきてテストデータの中身を
チェックしないまま使っていた。
0810デフォルトの名無しさん2011/09/14(水) 19:24:40.50
>>809
スゴい職場だな。
全然テストになってないじゃん。
トラブル出まくって、死人が出そうだ。
0811デフォルトの名無しさん2011/09/14(水) 19:40:01.53
うちの職場も最後に本番データでテストはするけどテストデータ無しのテストなんて考えられない…。
0812デフォルトの名無しさん2011/09/14(水) 20:25:22.84
>>808
順列や組み合わせを使ってデータ生成したものを
ランダムにシャッフルしてから使うべき
0813デフォルトの名無しさん2011/09/14(水) 20:51:35.86
境界値テストもないとか。
0814デフォルトの名無しさん2011/09/14(水) 21:11:32.38
けど809のとこみたいな会社案外多いと思う

オレの前の会社がそうだったw
0815デフォルトの名無しさん2011/09/14(水) 22:49:16.63
入力データってメッセージだけなのか？
ファイル内容とかDB内容に依存する場合は、わざわざ
その状況を作ってやらないとテスト出来ないだろ。
業務プログラムは外部データを参照しまくるから
単体でテストなんて不可能に等しかったけど。
0816デフォルトの名無しさん2011/09/15(木) 01:54:48.16
新しい区分やステータスを追加した場合に
本番のデータ使ってテストしたら、追加や変更を加えた処理に何も引っかからないから、
正しいプログラムかどうか検証できない。

ビッグバンテストで一気に確認してたのかな。
0817デフォルトの名無しさん2011/09/15(木) 10:16:18.73
>>816
809のテストは、まだしている方です。
忙しくなると上司の一言で変更前と変更後のプログラムを紙に
出力して目視で大丈夫ならテストＯＫとしていた。
0818デフォルトの名無しさん2011/09/15(木) 12:41:36.22
>>817
目視でOKのところだと、設計書や仕様署も作ってないんだろうな。

俺のところも、かろうじて仕様書作ってるけど、内容は一行しかないこともあるし。
0819デフォルトの名無しさん2011/09/15(木) 15:00:17.62
ソースが仕様書です(キリ)
0820デフォルトの名無しさん2011/09/15(木) 15:51:17.71
>>819
こんな書き方をすると勘違いをされる。

確かにソースが仕様書のようになってしまう。
特にＣＯＢＯＬの場合は、昔からあるので仕様書を見ても
変更が多くもはや仕様書が役目を果たしていないという事が多々ある。

その場合は、仕様書よりも現時点で動いているプログラムを
優先に考えないといけなくなる。
0821デフォルトの名無しさん2011/09/15(木) 17:25:57.90
バグも含めて再現してください(キリ)
0822デフォルトの名無しさん2011/09/15(木) 20:41:01.12
>>821
バグを含めて再現の意味が分からないのだが
0823デフォルトの名無しさん2011/09/15(木) 21:42:37.99
移植の時の条件のことじゃね
バグ前提に動いてる他モジュールに影響が出るからとかコボラーの笑い話にありがちだし
0824デフォルトの名無しさん2011/09/15(木) 22:05:33.42
>>823
確かにＣＯＢＯＬを移植する時には
バグも一緒に移植される。

しかし、昔から動いているプログラムで修正ばかりで大きくなりすぎた
から全体の流れが全く見えない。
バグが存在するのか、あったとしてどこに存在するのかも全く
掴めない状態。
1からシステムを作成すれば簡単に終わるが客がそれを拒否したら
どうしようもないからバグ前提で動いてもらうしかない状況。

つまり、バグも含めて移植するしかない。
0825デフォルトの名無しさん2011/09/15(木) 23:29:41.31
バグ混みで移植は、Microsoft 、Borland が得意。バグ再現用オプションがあったりする。
0826デフォルトの名無しさん2011/09/15(木) 23:42:18.54
>>824
言語のせいでバグが一緒に移植されるという言い方は正しくない。
正常処理かバグか現場の担当者すら分からない状態でシステムが運用されているから
>>821 のような話が出てくる。
引き継ぎや変更管理が正しく行われていなければ、
一から作り直しても、何度でも同じ問題が発生する。
0827デフォルトの名無しさん2011/09/16(金) 01:17:18.07
ご高説は納得なんだが、言語には寄るよ
Javaで細かく細かくクラスに切り刻まれた方がきっちり問題のスコープが絞られる
SEがかなりなヘボでも有名どころのフレームワークで統一さえしてくれれば読めるプロジェクトになる
実際に人員総入れ替えしても担当者が苦笑いで済む程度の物になる
末端のコーダーがヘボくても管理できる

COBOLじゃバグ対応用コードを非推奨にして切り分けて進めるとかさえ(やれん事はないが)管理できんよ
少なくとも馬鹿が一人でも混ざり得る現場ではね
0828デフォルトの名無しさん2011/09/16(金) 02:18:03.81
現代的なプログラミングは記憶力とトッピなロジックに頼るのではなく、
できるだけ小分けにして、テストもプログラムで自動化しましょうってことだからね
まだまだ、それが理解できない頭が固い馬鹿が多すぎるは事実
0829デフォルトの名無しさん2011/09/16(金) 03:09:19.50
>>825
バグ再現オプションって
人為的にバグらせるってことだろうけど
オンにすると何が起きるんですか？

毎日ブルースクリーンはヤダな。
0830デフォルトの名無しさん2011/09/16(金) 06:00:32.51
>>828
> 現代的なプログラミングは記憶力とトッピなロジックに頼るのではなく、
> できるだけ小分けにして、テストもプログラムで自動化しましょうってことだからね
> まだまだ、それが理解できない頭が固い馬鹿が多すぎるは事実
>
そして「関数が無いから組めません(ｷﾘｯ」とか「テストツールが無いのでテスト出来ません(ｷﾘッ」とか
真顔で言うプログラムが組めないプログラマが大量生産される…。
0831デフォルトの名無しさん2011/09/16(金) 06:12:49.34
>>830
CPUってなんですか?、OSってなんですか?　という人間でもプログラマとして通用する時代だから別にいいんじゃね?
0832デフォルトの名無しさん2011/09/16(金) 06:24:20.46
>>826
それは、COBOLを理解していない。
VBは、新しいプログラム言語　それに対して、COBOLは
約半世紀前に作られた古いプログラム言語。
VBやJAVAは、827が書いているようにクラスやメソッド単位で
細かく切り刻まれる。対してCOBOLは、プログラム自体が
大きくなりやすい。
COBOLは、昔からあって幾度と無く修正が繰り返されてきた
事を前提としなければならない。

<<引き継ぎや変更管理が正しく行われていなければ、
一から作り直しても、何度でも同じ問題が発生する。 >>

これは、今修正している会社がシステム構築をした会社では
ない場合（途中からいきなりシステムを渡された場合）
どうしようもない。
そして、修正ばかり繰り返す内に1から新規作成する力も
失われてしまう。
0833デフォルトの名無しさん2011/09/16(金) 06:48:13.12
現代のプログラミングはフレームワークやライブラリを組み合わせて構築するのが当たり前なのに
自分でロジックまで考えないといけないなんて時代錯誤だしナンセンス。
0834デフォルトの名無しさん2011/09/16(金) 07:25:52.84
ブラックボックス化は、いざというときに困る。
0835デフォルトの名無しさん2011/09/16(金) 07:53:21.42
>>826
なら、毎回1から新規作成するしかないですね

現実的に起こっているからそれをどうにかする方が大事
理想論だけでは、どうにもならない
0836デフォルトの名無しさん2011/09/16(金) 08:12:51.95
>>833
いや、プログラマはロジック考えないでどうする。
0837デフォルトの名無しさん2011/09/16(金) 08:15:30.50
この問題は、ずっと思っていたが
企業のシステムは、定期的に1から新規作成する必要が
ある　と思うがどうだろうか？

COBOLの場合は、PERFORM文が出来る前はGOTO文でしか渡せなかった。
そんな物が今でも動いている方がおかしい。
0838デフォルトの名無しさん2011/09/16(金) 09:16:12.10
2000年対応の時にめちゃ古いプログラムを掘り起こして修正しまくったからなぁ、その意見は判るよ。 w
現実問題不可能だろうけどな
0839デフォルトの名無しさん2011/09/16(金) 09:26:20.02
>>837
それこそ理想論じゃないか？
どんなに良い言語やパッケージができても
企業側が価値を見出せずにお金を出したがらないんだからさ。
0840デフォルトの名無しさん2011/09/16(金) 09:34:28.21
>>839
何か勘違いをしていないか？

もしかして全ての大企業にシステムを運用している会社
もしくは部署が存在していると思ってない。

実際は、ほとんどの会社でそんな会社や部署は存在しないよ

この時点で毎回プログラム修正が起きないから時期が来たら
プログラムを1から作成するという選択肢が生まれる
0841デフォルトの名無しさん2011/09/16(金) 09:39:39.56
まさか

店舗を追加/削除するたびにプログラム修正が発生しているとか
馬鹿な考えが起きていないよね

もし、そんな考え方なら1から出直せ！！
まずは、アルバイトから
0842デフォルトの名無しさん2011/09/16(金) 09:48:32.28
>>838
2000年問題ってCOBOL特有の問題ですよね

他の一般に使われているプログラム言語は、
日付型が存在するからいちいちプログラムを変更しなくても
2000年問題に対応済み
0843デフォルトの名無しさん2011/09/16(金) 09:57:31.64
>>836
今時プログラマーがロジックを考えるだなんてどんだけ非効率なんたよｗ
これだから時代錯誤な老害は困る。
0844デフォルトの名無しさん2011/09/16(金) 09:57:46.86
ねぇ
思ったんだけどさ
2000年問題の時にVBに全部システムを置き換えられてない？
0845デフォルトの名無しさん2011/09/16(金) 09:59:35.93
>>843
そういうのを世間では土方っていうんだぜ
0846デフォルトの名無しさん2011/09/16(金) 10:19:13.87
>>840
お前こそ勘違いしてるぞ。
価値や利益がコストを上回れば、時期なんて待たずに買い換えが起こるんだよ。
コストかけるのに値しないから、いつまでもCOBOLシステムが残り続けてるんだ。
0847デフォルトの名無しさん2011/09/16(金) 10:22:23.56
>>843
コーダー乙
0848デフォルトの名無しさん2011/09/16(金) 10:23:01.55
>>846
他にCOBOLが残り続けているパターンがある。
それは、システムを任せている会社に技術力がなくなって
したいのにできないパターン。
0849デフォルトの名無しさん2011/09/16(金) 10:24:50.56
>>843
中国人やインド人にでも作らせてるのっと
0850デフォルトの名無しさん2011/09/16(金) 11:48:06.57
>>842
それはどうかな。データの持ち方は、プログラム言語に依ると
いうよりも、ユーザのデータ観によって決まるから。
0851デフォルトの名無しさん2011/09/16(金) 12:06:06.55
>>850
意味が分かりません。

COBOLは、文字型(X)と数値型(9)で変数を定義しますよね。
VBは、Date型(100年1月1日〜9999年12月31日)まで可能。
Date型から年のみ取り出したり月のみ取り出せるので
2011年9月16日と表記したり2011年09月16日と表記も可能。
年号も可能。
JavaもVBと同じ。

どう見ても日付は、COBOLよりVBやJavaの方が扱いやすい。
0852デフォルトの名無しさん2011/09/16(金) 12:07:24.32
>>840
>もしかして全ての大企業にシステムを運用している会社
>もしくは部署が存在していると思ってない。
中小ならともかく大企業なら普通にあるだろ。
ないとこ教えてくれや。

>>842
違う。そもそも、COBOLにビット操作命令は無い。
それに、PCでも内蔵時計のハードレベルで問題があったはず。
0853デフォルトの名無しさん2011/09/16(金) 12:09:19.86
>>853
JR九州は、関連企業の所長がうちには関連企業にIT企業は
存在しないと言っていた
0854デフォルトの名無しさん2011/09/16(金) 12:11:28.63
>>851
設計者が日付は6桁の整数が過去との斉合性から好ましいと考えれば、
どんな言語でも整数にする。やはり文字列で有るべきだと考えれば、
文字列にする。そういった前提で書いたプログラムが一つでもあれば、
どんな言語にも2000年問題は存在した。
0855デフォルトの名無しさん2011/09/16(金) 12:17:26.43
>>853
COBOLの日付の定義
PIC X(4)
PIC X(2) value '年'
PIC X(Z9)
PIC X(2) value '月'
PIC X(Z9)
PIC X(2) value '日'

上のようにすると2011年 9月16日と入れることができる。
0856デフォルトの名無しさん2011/09/16(金) 12:18:54.60
>>851
はあ？2000年問題勉強してこいや。
当時の日付は、1990/09/16なら0x900916といった形式が多かった。
だいたい、2000年頃のマシン性能でJavaやVBなんて実用性がないだろ。
0857デフォルトの名無しさん2011/09/16(金) 12:31:29.61
Javaはともかく、VBは稼働しているプラットフォームが脆弱すぎて話にならない。
0858デフォルトの名無しさん2011/09/16(金) 12:33:56.18
>>856
予備知識
　『2000年問題』
　　　年を下2桁でプログラムを組んでしまった為に2000年を1900年と
　　　勘違いをしてしまう問題。

それを踏まえて
　VisualBasic6.0（2000年頃　下は、あるVBのホームページより）
　　　Private Sub Command1_Click()

　　'月末を取得したい日付
　　Dim dat As Date

　　dat = Text1.Text

　　'月末を取得する
　　Dim endDate As Date

　　'1.翌月の月初を求める
　　endDate = Format(DateAdd("m", 1, dat), "yyyy/mm/01")
　　'2.月初の1日前は月末
　　endDate = DateAdd("d", -1, endDate)

　　MsgBox Text1.Text & "の月末は" & endDate & "です"
　　　End Sub

　　　
0859デフォルトの名無しさん2011/09/16(金) 12:49:21.54
すまん。
COBOLの日付の定義が間違っていた
COBOLの日付の定義
PIC 9(4).
PIC X(2) value '年'.
PIC Z9 .
PIC X(2) value '月'.
PIC Z9.
PIC X(2) value '日'.

これでお願い
0860デフォルトの名無しさん2011/09/16(金) 12:59:55.89
三洋信販さんもSeibelという言語で1からシステムを
システム会社に頼んでいたので関連企業にIT企業は、
存在しないと思う。
0861デフォルトの名無しさん2011/09/16(金) 13:10:05.41
>>858
びっくりだな。まあ10年前のお話だから無理もないか。

そもそも、下２桁にしていた理由がメモリ節約のためだ。
FDなら512KB、HDでも2GB前後しかない時代だぞ。
だから言語なんて無関係。
ファイルから読み込んだバイト列0x900916がなんでVBだと
問題なくなるんだ？どんな言語でも1900年を加算して処理していた。
0862デフォルトの名無しさん2011/09/16(金) 13:14:49.33
>>852
確か防衛省も1からシステム受注を
確か富士通さんが受けたよ
あれは、全国のIT企業数社でのJavaでの開発だった。

アパレル企業関連もあった。これも海外から生地の発注画面
から全て作成だった。（VisualBasic）
0863デフォルトの名無しさん2011/09/16(金) 13:32:58.52
>>861
少し混乱しているな

下2桁は、メモリ節約の為。確かにそうです。
HDでも2GB。それは、Windowsの話。汎用機は、2GBもないのでは？
だからメモリ節約の為に下2桁にしているのでは？

下2桁が90や95は、VisualBasicが1900年代と認識するから
0864デフォルトの名無しさん2011/09/16(金) 14:22:37.64
>>853,>>860
自社または関連企業にIT企業が無いからといって、
ITシステムが存在しないってのは、苦しい話だな。
0865デフォルトの名無しさん2011/09/16(金) 14:28:57.25
>>863
まあ、極端な話だが、摘要の中に @981231　のように手形決済日が記入されていたとする。
これだけで、どんなプログラム言語であっても、2000年問題は発生してしまったのさ。
0866デフォルトの名無しさん2011/09/16(金) 16:09:35.96
>>864
アホ！！
IT企業がないからITシステムが存在しないとは言ってない

システムは、存在する。
事務の人などがシステムの入っているパソコンの電源を入れるだけ
で動くでしょ
0867デフォルトの名無しさん2011/09/16(金) 16:17:03.76
>>864
コボラーは、全ての大企業はITの関連企業を持っているのは
常識でそこで使用されているプログラム言語は全てCOBOLだと
思っている。だから、COBOLを知っておけば仕事は山のように
入ると思い込んでいる。だからコボラーは今でも一番世界で
使用されているプログラム言語は、COBOLと言っている。
そして、COBOLは未来永劫なくならないだろうとどこかの
ホームページに書かれてあった。
0868デフォルトの名無しさん2011/09/16(金) 16:22:35.98
>>865
摘要の欄にそのように書かれても
そのまま処理されるから2000年問題にはならないよ

日付ではなく文字として認識されるから
0869デフォルトの名無しさん2011/09/16(金) 16:34:05.85
>>868
そんなことはない。必要な時に6桁の文字列として切り出され、整列キーの対象にも
成りうるから、立派に2000年問題の対象となる。
0870デフォルトの名無しさん2011/09/16(金) 16:40:56.55
>>869
摘要って備考の事でしょう
と言う事は、「@981231」と書かれている所に
「手形決済：98年12月31日」と書いてもおかしくない。
ここで2桁目から切り取るとすると「手形決済：98年12月31日」の
部分がおかしくなる。つまり、この部分は日付として認識
させたらプログラムとしておかしくなる。
0871デフォルトの名無しさん2011/09/16(金) 16:43:24.39
>>869
それよりも、単純に6桁の頭2桁が"97"より大きいかなんて記述があったら
一発でだめじゃないか。
0872デフォルトの名無しさん2011/09/16(金) 16:59:32.31
>>871
19981231 1998年12月31日　98年12月31日
一言で、「@981231」と言っても書き方がいろいろある。
98年12月31日　このパターンの時、単純に6桁の頭2桁
を見ると一発でアウトとなる
0873デフォルトの名無しさん2011/09/16(金) 17:05:25.40
>>872
COBOLではあまりやらないけど、一般のプログラム言語では、@の次から始まり、
スペースが来る前までのN文字の文字列を切り出す、などということは当たり前にやる。
切り出した後でシステムの開発者がここは面倒だから、日付型の項目に変換せずに
文字列で比較してしまおうと考えたら、その途端に2000年問題が発生する。
08748382011/09/16(金) 17:07:47.26
お前ら、何で今頃2000年問題で揉めてんだ w
08758732011/09/16(金) 17:10:17.19
>>874
確かに。
0876デフォルトの名無しさん2011/09/16(金) 19:18:03.37
うちの会社では、西暦二桁表示と、和暦二桁表示のシステムが並存している。
0877デフォルトの名無しさん2011/09/16(金) 19:43:43.33
>>876
それは、VBなら簡単にできますね
西暦2桁（和暦2桁）　←みたいな感覚かな
0878デフォルトの名無しさん2011/09/16(金) 21:48:19.95
VBはWindowsでしか使えない時点で問題外。
つかWindowsのサーバーなんて多少落ちても問題ないフロントエンド系しか使い物にならないし…。
0879デフォルトの名無しさん2011/09/16(金) 22:12:11.22
VBてかWindows Formsて画期的なんだよな
Webはまだまだインタラクティブな需要に耐えられないだよね
0880デフォルトの名無しさん2011/09/16(金) 22:35:19.55
うーん、好み分かれると思う
htmlとJSライブラリのほうが、手軽で小回り効いて好きだな
Windows Formsで作り込むよりはAdobe Flexの方が個人的には楽
0881デフォルトの名無しさん2011/09/16(金) 23:22:59.23
24bitのバイナリで持てば47127年くらいは耐えられるのを
YY年MM月DD日のBCDで持ってたから問題なんでしょ?
で， さらには日付の計算まで複雑になると...

でも, 山ほどCOBOLの吐き出したデータがあるから移行
できない．

データの変換ソフト作った方が建設的なんじゃないの???

0882デフォルトの名無しさん2011/09/17(土) 00:54:44.46
>>881
何を言っているのかさっぱり分からない
0883デフォルトの名無しさん2011/09/17(土) 11:33:58.91
もしかして、VB6の話してる？
0884デフォルトの名無しさん2011/09/17(土) 14:56:21.16
>>883
COBOLは、事務系に特化している。
そして、現在事務系の言語はVisualBasicが主流になっている。

だから、COBOLとVisualBasicの比較
0885デフォルトの名無しさん2011/09/17(土) 15:00:56.19
題がCOBOL不要論なので
事務系に特化しているCOBOLと現在事務系主流のVBを比較した方が
はやいと思う。
0886デフォルトの名無しさん2011/09/17(土) 15:02:49.13
>>884
事務処理系でjavaなら判るがなんで今時VBなんだよw
0887デフォルトの名無しさん2011/09/17(土) 15:08:25.43
>>886
いや、今の事務系の主流がVBだから。。。

もちろんjavaでも事務処理ができるよ
Swing機能を使う　OR　VisualJを使う　という事でしょ？

※VisualJは、開発元が承認しておりません。マイクロソフトの独断です。
よって、Windows外での動作は保障外。
0888デフォルトの名無しさん2011/09/17(土) 15:08:34.42
VB6の時代は終わった
0889デフォルトの名無しさん2011/09/17(土) 15:19:50.15
>>881
COBOLで出来たプログラムを少しでも前にすすめるには
バッチ処理の部分をJAVAに置き換え可能なので
COBOL⇒JAVAにまず置き換えるぐらいしかないよね
0890デフォルトの名無しさん2011/09/17(土) 15:33:17.32
Windows上でしか動かないVBなんてホビーならともかく業務じゃ使い物にならんだろ・・・
0891デフォルトの名無しさん2011/09/17(土) 15:37:00.62
現在メインフレーム+COBOLで稼動している勘定系、鉄道・電気・水道の社会インフラのシステムが
全てWindows+VBに置き換わったとしたら…

(((((((( ；ﾟДﾟ))))))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙｶﾞﾀｶﾞﾀﾌﾞﾙﾌﾞﾙ

間違いなく文明社会の終焉を迎える…。
0892デフォルトの名無しさん2011/09/17(土) 15:57:17.65
今の時代、COBOLからVB6にリプレースする馬鹿はいないだろ。
0893デフォルトの名無しさん2011/09/17(土) 15:57:47.81
大アホ技術者が駆逐されて、最底辺がアホに格上げされる。
0894デフォルトの名無しさん2011/09/17(土) 16:07:01.94
Paasとかクラウドがもっと普及したら、COBOLもJavaもVBも脂肪だから安心しろ。
0895デフォルトの名無しさん2011/09/17(土) 16:12:21.16
Gのやつは、J。
0896デフォルトの名無しさん2011/09/17(土) 16:14:47.56
>>894
結局業務ごとの大まかなロジックやモデルは共通化できても
実際使うアプリはゴリゴリつくらなきゃいかんのでpaasだろうがsaasだろうが
かわらん

MSのアジュールはPHPとrubyにも対応してんだっけか…あれJavaは

.NetになってVBは結構復活してきてるぞ
まあ相変わらず大規模にはむかないけど、ちょいアプリとかはVBのほうがむいてる
0897デフォルトの名無しさん2011/09/17(土) 16:35:54.38
.net自体は魅力的だし期待もしているんだが、実質Windowsでしか稼動しないというのがどうも…。
Windowsというプラットフォーム自体1980年代の汎用機以下の安定性だし、
陳腐化が激しすぎて現在稼動しているシステムが10年どころか5年使用できるかどうかも怪しいもんだから
フロントエンド系ならともかく、基幹システムとしては使い物にならないと思う。
0898デフォルトの名無しさん2011/09/17(土) 16:38:56.90
このスレでちょいアプリが俎上に上がるとは
でも.netならぶっちゃけC#でも何でもいいからなあ。ますますVBである必要ないと思うんだけど
0899デフォルトの名無しさん2011/09/17(土) 19:29:10.89
VBはMSとしては終息させたい製品でしょう。C#に移ってくれたらと。
と云う訳で、少なくともこれからプログラマを増やす気はしないツールだな。
0900デフォルトの名無しさん2011/09/17(土) 19:42:20.70
>>899
> VBはMSとしては終息させたい製品でしょう。C#に移ってくれたらと。
MSの都合で短期間に次々と開発言語を変えられるのもたまったもんじゃないわな。
その都度システムを焼き直ししないといけないかと思うとぞっとする…。
まぁITベンダーにとってはいつまでもユーザーから金を搾り取れるので美味しいかもしれないけどw
0901デフォルトの名無しさん2011/09/17(土) 19:45:23.74
VB4でさえ、あと4年サポートする。ご苦労なこった。
0902デフォルトの名無しさん2011/09/17(土) 19:45:53.39
8年だった。
0903デフォルトの名無しさん2011/09/17(土) 19:46:40.04
>>897
monoがあるじゃん
0904デフォルトの名無しさん2011/09/17(土) 19:46:56.12
自分の会社で古いやつだと30年位前のCOBOLのコードがまだ現役で稼動しているけど
そんな古いコードが最新のマシン・OSでリコンパイル無しで未だに動作するってある意味凄いと思う。
WindowsだとOSのバージョンアップどころかSP適用しただけで動かなくなるアプリがあるというのにw
0905デフォルトの名無しさん2011/09/17(土) 19:53:22.97
うちの職場は.netへの移行を迫られた際にVBの資源を全てJavaに焼きなおした。
ついでにAPサーバーも2003Serverから全てRHELにリプレースした。
0906デフォルトの名無しさん2011/09/17(土) 20:17:06.67
>>896
恐らくVBを嫌がっているのは、2パターンの人がいる。
1つめは、COBOLが大規模になっているので今のロジックを残したい人達。
2つめｂﾍ、Windowsしか動作しない。要は、Windowsのアップデートでマイクロ
ソフトが仮に客のデータを入手できるような状況になると困る。（トロイの木馬）
だからWindows以外でも動作可能にして欲しい。⇒COBOLかJAVAがBESTだな
という事で.netでVBが復活して欲しくないという事だと思う。
0907デフォルトの名無しさん2011/09/17(土) 20:29:11.45
>>906
そんなことより、コンピュータ(ソフトウェア?)サイエンスのメインストリートから完全に
外れた製品で、このまま行ったらJAVAどころか、PythonやScalaにもどんどんシェアを
奪われ続ける製品だからだよ。MSが一番その事を承知している。
0908デフォルトの名無しさん2011/09/17(土) 21:39:42.23
Scalaは無いな。なんの冗談だ。
レス数が900を超えています。1000を超えると表示できなくなるよ。