新しい環境も善し悪し
私は仕事柄、古〜いシステムと新しい環境との橋渡しをすることが多くあります。
環境としては.NETなど比較的新しいものを扱っているのですが、一方の古いほうといえば大抵がCOBOLなんですね。
COBOLというのはデータ領域をぶった切る能力に長けており、それは単にデータ領域をバイト単位で定義した型にはめて眺めているだけなのですが、このCOBOLが普通に実現していることをいざjavaやら、.NETやらで実現しようとすると物凄い苦労を課せられます。
まず第一にあるのが、オブジェクト。
COBOLだのCだのというアセンブラより*1の言語は、メモリイメージを意識しどの変数がデータ領域の何バイト目から何バイト目…といった変換が容易にできます。
しかし、.NETなんぞは全てがオブジェクト型ですので、メモリ中にどのように展開されているのか想像つきません。
つまり、データ領域の先頭に構造体をあわせて内部データにアクセスなんてこともできません。
できるのはバイト配列の一部を取出し、対応する型にあわせて変換することで、非常に大きなオーバーヘッドがかかります。
次にあるのがコード体系。
.NETなんかでは内部コード体系がUnicodeなわけですが、どこの馬鹿が考えたのか知りませんが、どんな文字でも１文字*2であつかうこのコード系のせいで、日本語を扱うときに苦労しまくります。
そういう意味では、半角文字は１バイト、全角文字は２バイトときっちりかっちり決まっていたSJISの方がよっぽどプログラマには優しく感じられます。
一番悔しいのは英字はunicodeでも１バイトなので、英語圏には影響なんてないってことです。
だいたいにおいてファイルにしろ何にしろ、入力も字数制限がかかるのは確保したバイト領域なんだから英字の１０文字と漢字の１０文字を同じに扱われると困るにきまってます*3。
これはなんでしょうか？
ファイルは全部XML形式にしやがれという崇高なお達しなのでしょうか？
新しくシステムを作るのであれば環境にあった作り方も可能な訳ですが、旧システムとのデータ関連の無い新規システムなんて(とくにうちの会社では)巡り合うほうが難しく、このような悩みは避けて通れないものです。
それぞれの言語に得て不得手というものはあるもので、ただ闇雲に新しい環境に走るのも考え物だと思う今日このごろです。
ま、どうしても.NET*4でCOBOL的処理をすることが避けられない事情があるから、苦労してるんですけどね。(- -;
＃項目数が1000以下の小規模構造体だったらなんとかなるんだけどなぁ…(T-T)
