アカウント名:
パスワード:
本来期待される「和暦が「1」だった場合に「元」に変換する処理」より「和暦の1の位が「1」だった場合に「元」に変換する」の処理の方が面倒くさそうなんだけど？（それも 31年→元年 ではなくて、 31年→3元年 なんて･･･）なんで、あえて面倒くさい処理にしたんだろう？
実は、「1を全て「元」に変換する」処理だったんではないだろうかと邪推してしまう。
固定長レコードなんでしょ。したがってCOBOLと推測した。
「令和100年問題」の予感
159歳まで生きないからヘーキヘーキ
> 159歳まで生きないからヘーキヘーキこういう安易な思い込み、想定の甘さが、いざ何十年後かに「令和以降は元号いちいち改定するの止めます、令和で２００年ぐらい行きます」とかなったときにバグを生み出すんやで。
COBOLスタイルだと既存のプログラムを改変せず1を元に置換するプログラムを追加するのが普通なんですかね？＞COBOLerの方
COBOLを馬鹿にする人はCOBOLの知識が無いので無視して良いです。
PL/IはもちろんFORTRANだって固定長が普通なのにな
無視するのはよくないと思うけど…
IEが9から10になるのか何かのタイミングでJavascriptで、JDKが9から10になるのか何かのタイミングでJavaで1桁だけチェックはNGの話はあったので、他の事例にも当てはまる内容でCOBOLを馬鹿にしてるなら、馬鹿なんでしょうな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
面倒くさくない？ (スコア:0)
本来期待される「和暦が「1」だった場合に「元」に変換する処理」より
「和暦の1の位が「1」だった場合に「元」に変換する」の処理の方が面倒くさそうなんだけど？
（それも 31年→元年 ではなくて、 31年→3元年 なんて･･･）
なんで、あえて面倒くさい処理にしたんだろう？
実は、「1を全て「元」に変換する」処理だったんではないだろうかと邪推してしまう。
Re:面倒くさくない？ (スコア:2)
固定長レコードなんでしょ。
したがってCOBOLと推測した。
Re:面倒くさくない？ (スコア:2)
「令和100年問題」の予感
Re: (スコア:0)
159歳まで生きないからヘーキヘーキ
Re: (スコア:0)
> 159歳まで生きないからヘーキヘーキ
こういう安易な思い込み、想定の甘さが、いざ何十年後かに
「令和以降は元号いちいち改定するの止めます、令和で２００年ぐらい行きます」
とかなったときにバグを生み出すんやで。
Re: (スコア:0)
COBOLスタイルだと既存のプログラムを改変せず1を元に置換するプログラムを追加するのが普通なんですかね？＞COBOLerの方
Re:面倒くさくない？ (スコア:2)
Z9を置き換えるならともかく
Re: (スコア:0)
COBOLを馬鹿にする人はCOBOLの知識が無いので無視して良いです。
Re: (スコア:0)
PL/IはもちろんFORTRANだって固定長が普通なのにな
Re: (スコア:0)
無視するのはよくないと思うけど…
IEが9から10になるのか何かのタイミングでJavascriptで、JDKが9から10になるのか何かのタイミングでJavaで1桁だけチェックはNGの話はあったので、他の事例にも当てはまる内容でCOBOLを馬鹿にしてるなら、馬鹿なんでしょうな。