アカウント名:
パスワード:
仮に習得が容易だったとしても、作業自体の容易さは実物のソース如何なわけで、現代的なテスト環境や方法論の前に遺物扱いされるのは仕方がない面も。
移植とリファクタリングを同時進行させるっていう目論見もあるのかもしれないけど。ハノイの塔みたいに。
世の中には DB/DC Unit Test Function of COBOL Debugger [nii.ac.jp] だの COBOLUnit だのといった、中々楽しげなものも存在しますし、COBOL も言語自体のバージョンアップもされていっています。今時の COBOL は普通に Java や .NET と連携できますし、.NET なバイナリーの場合だと NUnit などのテスト系ツールも普通に使えるんじゃないかと。 一応変化して言っている COBOL を見ると、遺物扱いにしたい人が遺物扱いのレッテルを貼りたいだけ感は結構強いですね。
Perl/PHP/Ruby/Python/VB/Java/C/C++/C#/VB.NET 辺りであってもメンテナンス性の低いゴミコードが量産され
>COBOL で書くと自動的にそんな形になるなんてこともありません。
そんあ形になるゴミコードをいじらなければならなくなったのだが?どんな言語使ってもゴミはゴミです。それこそ、開発者しだいです。
たいていCOBOLerは、動いているならそのままでいいじゃんという時代錯誤な人ばかりですよ。そんな人たちがゴミ以外のコードを生産すると思いますか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
なんでもいいCOBOLを淘汰しろ (スコア:-1, フレームのもと)
Re: (スコア:0)
マシンスペックに余裕のできた今こそCOBOLのような高級言語を使えばいいのにと思うよ。
習得も容易だしさ。
Re: (スコア:0)
仮に習得が容易だったとしても、作業自体の容易さは実物のソース如何なわけで、現代的なテスト環境や方法論の前に遺物扱いされるのは仕方がない面も。
移植とリファクタリングを同時進行させるっていう目論見もあるのかもしれないけど。ハノイの塔みたいに。
Re: (スコア:2, 興味深い)
世の中には DB/DC Unit Test Function of COBOL Debugger [nii.ac.jp] だの COBOLUnit だのといった、中々楽しげなものも存在しますし、COBOL も言語自体のバージョンアップもされていっています。今時の COBOL は普通に Java や .NET と連携できますし、.NET なバイナリーの場合だと NUnit などのテスト系ツールも普通に使えるんじゃないかと。
一応変化して言っている COBOL を見ると、遺物扱いにしたい人が遺物扱いのレッテルを貼りたいだけ感は結構強いですね。
Perl/PHP/Ruby/Python/VB/Java/C/C++/C#/VB.NET 辺りであってもメンテナンス性の低いゴミコードが量産され
Re:なんでもいいCOBOLを淘汰しろ (スコア:0)
>COBOL で書くと自動的にそんな形になるなんてこともありません。
そんあ形になるゴミコードをいじらなければならなくなったのだが?
どんな言語使ってもゴミはゴミです。それこそ、開発者しだいです。
たいていCOBOLerは、動いているならそのままでいいじゃんという時代錯誤な人ばかりですよ。
そんな人たちがゴミ以外のコードを生産すると思いますか?
Re:なんでもいいCOBOLを淘汰しろ (スコア:1)
システム的には動いているものをいじるのはリスクあるから
そのままでいいじゃんは当たり前です。
ゴミでも動いていれば客は文句言いませんし、
リファクタリングに予算が付くなんてよっぽどの事態です。
COBOLに限ったことではありません。
#属人的な要素も大きいけど、謎コーディング規約が生きてるとかも怖いよね
トピ的にはよりパフォーマンスを求められるシステムでの
Linuxみたいな流れになっているので、そんなところでは
何使って開発しているかとかも気になりますね。
Javaなんかは開発効率的に良さそう(=質はともかく人は多そう)だけど
コードの最適化とか考えたらやっぱりC++に一日の長がありそうだし。