多分、万年カレンダープログラムはプログラマへの第一歩だった
ここ半年ほど半端ではない忙しさでして...、GWは無い、土日もほぼ出社な状態で、久しぶりの投稿です。
管理が出来ず、管理について勉強しようとしない管理者は本当になんとかして欲しい。
いろんなプログラミング言語で1582年10月5日を扱ってみる| mwSoft を見てふと懐かしくなったので、懐かしみつつ書いてみます。
そもそも万年カレンダープログラムって自分の若い時には入門者が初めてある程度まともに調べて仕様というかアルゴリズムを考えながら作るプログラムだったりしました。
とは言っても基本的には未来に向けて万年カレンダーなのですが。
はじめは単純で年、月、日が表示出来れば良くてあと頑張れば曜日の表示程度です。
でもこれのほほんと生きてきた人間には結構難しくて、うるう年のルールをきちんと知らなくて4で割れたらうるう年と考えて、授業で出したらダメ出しを食らうというのが定番でした。
そして、うるう年を調べて、へーっとなって修正してOKもらって授業は先に進む程度なんですけど、多少でもプログラムを頑張る人は過去もチェックしだして、西暦1年をcalコマンドでチェックしてズレを発見して絶望を覚えるわけですね。
さてこのズレを調べると、1582年に行き当たってあーと思い出すのです。
歴史好きなのでこれ結構すぐにはっとして納得するのですが、こうなると色々頭をよぎるのです。
ロジャー・ベーコンだったり、日本でも明治に導入して混乱があったなぁとか、和暦対応も頑張りたいなぁと思っていた矢先でそういや和暦ってどうなのとか、それこそ無限に。
ということでいくつかややこしい話を上げていこうかと。
まず、明治の件。
日本におけるグレゴリオ暦導入に日本にグレゴリオ暦が入ってきた経緯があります。西暦と同じく一部日付の欠落が発生して対応が必要になります。当時ふと思い出して調べてふざけるなと思った記憶があります。
和暦のめんどくささ。
元号一覧 (日本) - Wikipediaを見ると分かるのですが、元号が無い時代があったり、南北朝時代には同じ年なのに年号が複数あったり。
多分真面目に作るとなると、和暦のデータをテーブルとかDBに保存しておいて、それで変換するとかになるのでしょうね。やってられない。
そもそもユリウス暦の前は?
さて、和暦を諦めたとして、グレゴリオ暦の前はユリウス暦なのですが、その前ってどうなっているかとかを考えるとこれまたややこしいのです。
ユリウス暦 - Wikipedia
ローマ暦、エジプト暦とか色々名前が出てくる。そしてさらにはユリウス暦も現在一部では使われているとか、さらにややこしい話が。
そういえば今でも旧暦とか時々使いますよね。
そして、グレゴリオ暦のみの世界に。
結局、calコマンドはグレゴリオ暦を全体を通して使っていてそれに合わすのが結局無難なわけです。
仮に頑張るにしても、DBを使わざるを得なくて、いろんなプログラミング言語で1582年10月5日を扱ってみる| mwSoft にもあるけどDB側の影響も結構大きい。
頑張るんであれば、過去はcalコマンドに準拠で、曜日とか六曜とかそういう方向が多分ベスト。
と多分誰もが通る道を通るわけです。
で、今思うとカレンダープログラムを初心者の頃に作るのに良いことってこんな所でしょうか。
- アルゴリズムと現実の結びつきがリアルに感じられる
- プログラミングって大きく言えば工学の1分野なのですが、工学は実社会で役立つ事が前提です。でも実社会との大きな隔たりがやっぱりあって、そこを肌で感じれる初めての機会だと思うわけです。もうちょっと言えば現実と以下に折り合いをつけるかを学ぶ機会でした
- それでも改良を頑張れる余地があって、頑張れるチャンスです。そしてこれがプログラミングの面白さでもあり、コードを綺麗に保つなどの大変さを知る機会でした。
現実的なプログラミングの大変さや何が必要かとかを知る良い機会でした。
