かつて
YPS
というプログラミング言語があってだな！
(；・`д・´)
・・・・といって
「あぁ、、」
と思う方は某社のSEなりプログラマーなりを
30年ほど前に経験した方ではないかと
勝手に邪推する。
・・・・だって、某社の
独自ローカル言語だもん。
あー、今回は
興味のない向きはマクラ完全スルーで。
(。-∀-)
時に、30数年前と言えば
大型汎用機全盛期
かつ
COBOL言語全盛期
であった。
それ以前の世代により
積み上げられた膨大なプログラムが
現役として動いているのだが
そのプログラムが個人ごとに
クセのある記述になっていて
のちの世のメンテナンス要員に
まったく解読不能な
スパゲッティソース。
↑
これまた独自の用語。
スパゲッティのように絡まりねじくれ
おびただしく重なったような
理解不能なプログラムソース
（コーディング）
のこと。
特にアタマのよいヒトの書いたプログラムは
本人には読み解けるが
他人が見ても
ナニしてるんだかサッパリ
という記述になりがち。
しかも、その頃メインの
COBOL
というプログラミング言語
ホントに基礎的な命令のみの組み合わせで
条件分岐などを記述していると
長大なコードになって
しかもトンデモなく読みにくい。
IF XX = 0 THENA = A + 1
IF YY = 0 AND ZZ = 0 THEN
A = A = 0
END IF
ELSE
IF XX = 1 THEN
A = A + 2
IF YY = 0 AND ZZ = 0 THEN
A = A = 0
END IF
ELSE
IF XX = 2 THEN
A = A + 3
IF YY = 0 AND ZZ = 0 THEN
A = A = 0
END IF
ELSE
IF XX = 3 THEN
A = A + 4
IF YY = 0 AND ZZ = 0 THEN
A = A = 0
END IF
END IF
IF YY = 0 AND ZZ = 0 THEN
A = A = 0
END IF
END IF
END IF
END IF.
・・・・といったように
入れ子（ネスト）構造になった条件文など
複雑な条件になればなるほど
どこからどこまでがどの条件に合致するのか
などがサッパリわからなくなるのであった。
しかもすべて英大文字数字なので
項目を定義しようとすると
HANTEI-KOUMOKU
とか
CHOICE-FLAG
とか
C-FLG
とか
ヒトによって名付けの決め方がバラバラで
とにかく読みにくい。
これをナントカしようと考えたＦ社が
（あ、言っちゃったww）
COBOLの考え方をそのままに
日本語項目が使えるように
かつ
わかりやすい仕様書を
そのままプログラム言語化する
という
壮大な計画のもと
作ったのが
YPS/COBOL
という言語である。
YPS/COBOLは
以下のような特徴がある。
１）仕様書とプログラムの一体化
YPS/COBOL言語は、
YPS/COBOLの文法に基づいて作成した
YPS仕様書の作成が必要になる
プログラムはこの
YPS仕様書を基にして生成されるため
仕様書とプログラムの内容が違う
という事が起きない作りになっている
２）視覚的な図記号の使用
データの構造や処理の流れを
図記号を使用して表現する
そのためプログラムの内容を
視覚的に捉える事ができ、
プログラムの理解を容易にする
また処理や条件が日本語で記述できるため、
プログラミング未経験者でも
処理の内容を理解する事ができる
まぁ、お題目はわかった。
実際のところ、
どうだったのかというと・・・・
2番目の構造化した図記号などは
確かにパッと見て
どこからどこまでが条件の範囲なのかを
確実に把握できて
たいへんわかりやすかった。
しかし・・・・
1番目の日本語項目については
日本語独特の問題で
とにかくコンパイルエラー
（翻訳エラー）
が頻発した。
それは
送り仮名の問題
である。
日本語ではたとえば
日付項目
日付け項目
ひづけ項目
など、複数の記述方法があるが
そのどれもが
日本語的には正しい。
だがしかし、これを
バラバラの記述でプログラムの中に書くと
事前に定義されている項目以外
すべて変換エラーになってしまうのであった。
よって、プログラミングする際に
事前に定義された項目名が
何であるかという
項目名一覧
を手元に置いて
同一プログラム内では
その項目を間違えずに記述するという
余計な手間がかかる。
しかも似た項目名だと
それを取り違えて
意味不明な結果になるなど
別の問題も。
年月日項目 ＝ 年月日項目 ＋ 1
↓
年月項目 ＝ 年月日項目 ＋ 1
ということで小生が編み出したのは
YPSエディタの視覚的な図記号の中に
フツーのCOBOLの命令を記述する
というやり方。
これで構造化された図式の中に
馴染みのあるプログラムを書き
しかも可読性が高まる
のであった。
(。-∀-)
だがしかし、
当時まだ駆け出しだった小生
「勝手なことをするな」
と先輩から
シコタマ叱られましたが。
現在では
C言語やJavaなどにおいても
このように
構造化エディタが一般的で
そうじゃない方がマレだと思うのだが。
(*´･ω･)
そんな時代の先取りはさておき。
↑
日本語使おうと思った時点で
『バカじゃね？』
( ﾟσωﾟ)
遡ること金曜日。
長男氏と昼餉を摂りに。
長男氏、実は
鹿児島餃子の王将未体験
というではないか！！
だいたい鹿児島から県外に
進学などで出た諸氏が
まずぶち当たるのが
【醤油の壁】
鹿児島の甘い醤油に
慣れ親しんで育った身には
関東のひたすら塩っぱい醤油や
関西の甘くない醤油の洗礼
が降りかかってくるのであった。
小生はもともと
親父氏が鳥取出身だったこともあり
実家が甘くない醤油だったので
どこに行っても違和感ないが
・・・・いや、逆に
ヨメ氏の甘い醤油文化が違和感だったなww
いまではすっかり飼い慣らされたが。
(*´･ω･)
それと同時によく聞くのが
王将の天津飯の味の違い
である。
鹿児島の餃子の王将は
みなさんご存じの通り
いわゆる京都発祥の
餃子の王将
(株)王将フードサービス
とも
大阪王将
(株)大阪王将
とも
別モノである。
鹿児島餃子の王将
は
鹿児島王将(株)
である。
詳細については
8年前のww
コチラの記事をご参照あれ。
そんなわけで
長男氏の今後の
餃子の王将ライフ
のためにも
一度は体験させておかねばと
思った次第。
あ、たぶん次男氏も
未体験かも。
(*´･ω･)
そんなわけで。
やって参りました。
鹿児島餃子の王将 騎射場店
2階の「アイフル」のロゴが
ヤル気なさげな雰囲気に変わっているな。
サラ金イメージ払拭のためか？
(╬⊙д⊙)
さて。
カウンター席へ。
鹿児島餃子の王将騎射場店 - Spherical Image - RICOH THETA
メニュー表。
やはり天津飯シリーズイチオシかww
長男氏
「そういえばこういう学割って
今まで一度も使ったことないな。」
とか言いつつ
学生証の入ったサイフ置いてきてるし。
つか、東京の辺境大学の学生証で
学割きくのか？
(*´･ω･)
小生は
酸辣湯麺と餃子
長男氏は
天津飯（小）とエビチリを。
さて。
まずは餃子から。
餃子のタレとラー油。
これに浸けて。
(ﾟдﾟ)ｳﾏｰ！！
さすがは餃子屋さんww
そして、酸辣湯麺！！
このシンプルイズベストのルックス！！
たっぷりのスープの中には
申し訳程度のミンチ肉？
ネギ？
そしてそんなに多くはないが麺。
すすってみると。
おおっ！！
味もシンプル！！
ウマ味のあるスープに
ジャストな塩味
ラー油が効いて
酢もガッツリと。
とにかく味つけが大胆で
それでいてジャスト。
やはり酸辣湯麺はこうでなくては。
某有名担々麺店で出される
日和った酸辣湯麺の
8倍はウマい。
アソコは厨房のメンバーによっては
「ナニこれ」
的な味つけの時があるからな。
あ～酢が沁みる。
(*´ω｀*)
美味しゅうございました。
ごちそうさまでした。
やはりもう少し訪問頻度を上げて
他のメニューも制さねば！
( ・`д・´)
