kmizuの日記

プログラミングや形式言語に関係のあることを書いたり書かなかったり。

それでも10進小数をデフォルトにすることは意味がある

改めて（？）か昔からあるのか不明ですが、10進小数を言語のデフォルトにすべきかどうかという議論が一部で行われています。私自身、特にプログラミング教育を最近やっている立ち場もあって、10進小数を言語のデフォルトにすることに賛成の立ち場です。ただ、正直言ってこれに大して「反対する」側は何が焦点になっているかについて「ずれている」と思わざるをえないです。まずは、直近で見かけたWindyMeltさんのブログ記事より。

blog.3qe.us

ちなみにこれはCOBOLかそうではないか、という軸が問題になっているのではなく、浮動小数点型を利用するか、それともBigDecimalのような十進演算のために用意された型を利用するか、という軸の問題であって、しかもそれも正確な軸の取りかたではない。

というのも、BigDecimalでカバーされない問題があるのだ。例えば、BigDecimal型を利用しても(1 / 3) * 3の結果はすぐ壊れる。

こんな話は10進小数派も基本的には問題にしていないわけです。重要なのは金融系だけでなく特に実世界の商慣習を扱う分野では基本的に10進小数でものごとを取り扱っているわけで、ここで2進小数を使うのは基本的にありえないということです。だから、数多の書籍やWebページなどでは「金銭などを扱う場合はdecimalやBigDecimalを使いましょう」という注意書きが本当にくどいほど書かれています。

そんな注意書きをくどいくらいにしなければいけないなら、もうデフォルトを逆転させてしまって、小数のデフォルトは10進小数にしてしまえばいいじゃんって話が重要な論点のはずです。ついでにいうなら「2進小数をなくしてしまえ」なんて乱暴な主張をしている人は見たことがありませんから（ごく少数いるかもしれませんが、多数派ではないでしょう）、それを前提にしたような主張をするなら相手の論点を正しく読めていないだろうと判断します。

もちろん、2進小数の方が適切な場面は科学技術計算をはじめ数多く存在しています。ただ、別にデフォルトが10進小数になったとしても、2進小数をメインで扱いたい人はそこまで不便にはならず、表記が多少冗長になるくらいで済むだろうと思います。ぱっと思いつく表記だと

BDouble x = 0.1bd ; // BDoubleは2進浮動小数点数（64ビット）を扱うものとする

とでもすればよくて、こういう設計で2進浮動小数点数を使いたい人が困るとも思えません。さらに、2進小数を使いこなせる人はより深い理解を持っている側ですが、そうじゃない人の方が最近は多いです。それでいて、10進小数で物事を主に処理する必要がある業務アプリケーションの需要は増え続けているわけで、罠にハマる人を減らしたいというのは正当な動機だと思います。

10進小数だろうが誤差は生じますが、高校までの学校教育で「習った」ことの延長線でとらえられるので、2進小数の罠を回避するよりはずっと容易と考えられます（高校物理でも高校数学でも誤差の話はでてきますよね）。

別の観点ですが、Scratchを使ったプログラミング教育（特に子どもを対象にした）に詳しい阿部先生も

このようなことを書いておられるわけで、言語のデフォルトが2進小数なせいでつまづく人が「大勢いる」のは間違いないと感じます。

教育の面から「10進小数デフォルト論」がでてきているのにその文脈を理解しようとしないのは悲しいことだと改めて言っておきたいです。

ChatGPTをプログラミング言語開発に役立てる

久し振りの更新です。巷では先日リリースされたばかりのGPT-4oの話題でもちきりですが、私も当日深夜2時のライブストリーミングを見てその後すぐにGPT-4oを試しています。性能に関する雑感としては

  • 全般的にはGPT-4-Turboより頭が良い
  • Claude 3 Opusと比較すると、お堅い & 無難な回答を返す傾向あり
    • ただし、Opusよりハルシネーションは起きにくい印象
  • 画像認識の性能が凄い

辺りでしょうか。特に最後の点は特筆すべきことで、GPT-4-Turboの画像認識よりだいぶ性能が向上したおかげで今までだとやりにくかったことも簡単にできるようになっています。その際たるものが先日バズった

でしょうか。とはいえ、今回の本題は画像認識機能でなくタイトルの通り、プログラミング言語開発にGPT-4o（の画像認識部分でない部分）を役立てるというものです。

ちょくちょく停滞気味なのが玉に瑕ですが、私は現在日本語プログラミング言語「ぬこ」を開発しています。

github.com

特徴としては

などが挙げられます。さて、プログラミング教育をやるようになってここ数年、漠然と考えていたことがありました。それは抽象構文木の概念をどうやって初心者に教えるかということです。実際、Scratchは抽象構文木を割と素直に視覚化したプログラミング言語および開発環境ともいえ、知られているようにプログラミング教育で大きな成果を収めています。

しかし、一方でScratchである程度「プログラム」が書けるようになっても、そこから先のテキストベース言語に移行する際に大きなギャップがあり、ここでつまづく人も少なくありません。

そんなこんなで色々考えを巡らせていましたが、今夜、ふと「プログラミング言語内でvisualize(1 + 2)のようにしたら、グラフィカルな形でASTを表示してくれればいいんでは」という（誰でも思いつきそうな）着想が浮かびました。実際、Nimではdumptreeという機能があるそうです。

ただ、調べてみた限り、dumptreeはアスキーアート風味に木構造を表示する代物のようで、惜しいけど求めてるものとはちょっと違うという感じでした。

ともあれ自作のプログラミング言語なら自分で作りこむしかないのですが、最初思い浮かんだのはJavaで書かれた木構造（かグラフ構造）描画ライブラリを使うことでした。しかし、調べてみると木構造の方は実用に耐えるものがあまりなさそうでしたし、グラフ構造描画ライブラリを使って木構造を描画するのは多少手間がかかります。

なんとかいいアイデアがないものかと考えていたのですが、ふと「JTreeを使って、素直にNukoの抽象構文木をビジュアライズすればいいんじゃね？」と思い至りました。というわけでChatGPTの出番です。

こんな感じのリクエストを出したら、見事にASTを受け取ってSwingのJTreeとして表示するライブラリができました。それを早速Nuko言語に組み込んでみた結果が以下です。

可視化した結果はまだ粗削りですが、これは手で修正してもよし、さらにChatGPTに依頼してリッチな見た目にしてもらうことも容易でしょう。

驚くべきは、最初にアイデアを思いついてから、ChatGPTに質問して実際に組み込むまでわずか1時間で完了したことです。少なくとも以前の私だったらここまで素早く思いついたアイデアを自作の言語に組み込むことはできなかったでしょう。ChatGPT様！といった感じです。

ChatGPT (GPT-4o) でなくても、Claude 3 OpusやGemini 1.5Pro、GPT-4-Turboでもできそうなことではあるのですが、以前に比べて一発でほぼ動くコードが出る確率が高くなったように感じます。

そんなこんなで、ChatGPTにコード生成させると便利な例の紹介でした。

Osaka-City.Mokumoku Vol.1を公開しました！（5/15（水））

　大阪に引っ越してくる前はKyoto.Mokumokuの方で集まってもくもく会をやっていたのですが、自分の住まいから京都市内まではやや遠いので通いづらくなったこともあり「大阪市内でもくもく会やりたい！」と思い、サクッとイベント立ち上げてみました。場所はJR大阪環状線駅の「西九条」駅徒歩2分程度の駅近の貸し会議室です。ちなみに、Kyoto.Mokumokuの運営は既に京都市内にお住まいの方にお譲りしてる感じです。

osaka-city-mokumoku.connpass.com

　大阪市内あるいは近郊にお住まいの方で、対面でもくもく会やりたい！とか、懇親会でどうでもいいことを駄弁りたいという方が居られましたら、参加ご検討いただけると嬉しいです。貸し会議室を借りる都合上、参加費500円になってしまったのは心苦しいのですが……。 　 　もくもく会なので、本当に気軽に参加していただければーと思います。あるいは身近にそういう方が居られましたら宣伝いただけると嬉しいです。

おまけ：Claude 3 Opusによる添削結果

以下、添削した文章です。修正点には下線を引いています。
　大阪に引っ越してくる前はKyoto.Mokumokuの方で集まってもくもく会をやっていたのですが、自分の住まいから京都市内まではやや遠いので通いづらくなったこともあり、「大阪市内でもくもく会をやりたい！」と思い、サクッとイベントを立ち上げてみました。場所はJR大阪環状線の「西九条」駅から徒歩2分程度の駅近の貸し会議室です。ちなみに、Kyoto.Mokumokuの運営は既に京都市内にお住まいの方にお譲りしている感じです。
[https://osaka-city-mokumoku.connpass.com/event/318116/:embed:cite]
　大阪市内あるいは近郊にお住まいの方で、対面でもくもく会をやりたい！とか、懇親会でどうでもいいことを駄弁りたいという方がおられましたら、参加をご検討いただけると嬉しいです。貸し会議室を借りる都合上、参加費500円になってしまったのは心苦しいのですが……。
　もくもく会なので、本当に気軽に参加していただければと思います。あるいは身近にそういう方がおられましたら、宣伝していただけると嬉しいです。
主な修正点:

「やりたい」の後に「を」を追加し、文法的に正しい文章にしました。
「居られましたら」を「おられましたら」に修正し、敬語表現を統一しました。
「参加ご検討」を「参加をご検討」に修正し、自然な日本語の表現にしました。
「参加していただければーと」の「ー」を削除し、文章を簡潔にしました。
「居られましたら」を「おられましたら」に修正し、敬語表現を統一しました。

全体的に、文章は良くまとまっており、伝えたい内容が明確に表現されています。細かな文法や表現の修正を行いましたが、大きな変更は必要ありませんでした。

技術イベント「Nextbeat Tech Bar：第一回ライブラリ開発について考える会」を5月24日（金）に開催します！

　プログラマーの皆さんは日々（？）ライブラリを作成したり、あるいは使っていたりするのではないかと思います。しかし、ライブラリ開発やメンテナンスには様々な苦難が伴います。たとえば、継続してメンテナンスするための労力の捻出、バージョンアップの時の互換性の確保、ドキュメントの整備・更新など色々な苦労があるかと思います。ライブラリ開発には様々な苦悩が伴うにも関わらず、これまでそのようなライブラリのメンテナンスについての知見はあまり共有されていなかったように思います。というわけで、5月24（金）19:00-21:00に以下のような技術イベントを開催することにしました。

　ライブラリ開発に苦悩する方々、あるいはライブラリを開発してみたいけど、どうやって開発すればいいのかわからない、など様々なソフトウェアエンジニアの方々の参加を歓迎したいと思います。ハイブリッド開催ですので東京在住でない方はリモート参加もできます（筆者は当日に大阪から新幹線で移動します）。イベントを盛り上げていきたいので、様々な方の参加・発表をお待ちしております！

nextbeat.connpass.com

「プログラミング言語開発」教育用言語MinisにJSONベースの具象構文を付け足してみた

　皆様、お久しぶりです。去る2月10日（土）、2月11日（日）に筑波大学情報科学類にて特別講義の講師をやってきました。といっても、私が全日担当したわけではなくOB一人が一コマを自分の得意分野について講義をするオムニバス形式のものです。

　私はといえば去年やったのと同様、JavaScriptで抽象構文木を「手で」組み立てて解釈・実行するプログラミング言語Minisとその処理系を作るという講義を行いました。講義当日はスライドにミスがあることに途中で気づいたり色々あってテンパりましたがそれはそれとして。

　元々、私が担当した「プログラミング言語作成概論」の趣旨は

プログラミング言語を作るというのはとても簡単な作業なのに、プログラマにすらあまり知られていないのはけしからん。
とはいえ、実際に作ってみせないと実感が湧かないのが人情。
抽象構文木をJavaScript上で組み立てて、それをevalする関数を書くことを通してインタプリタの作成方法を学ぼうじゃないか！

　的なものです。たとえば、以下のプログラムは講義で作ったプログラミング言語Minisのもの（実際にはこれそのものを解析する構文解析機はまだ作ってませんが）です。MinisのことはわからなくてもC系言語を一つかじったことがあればおおよその意味はわかるかと思います。

    a = 100;
    b = 200;
    if(a < b) {
      500;
    } else {
      1000;
    } // 500が返ってくる

　しかし、これくらい単純な構文を持ったプログラミング言語でさえ「構文解析」というプログラミング言語にとって本質でないものが挟まるせいで無駄に行数が増えるのが現実です。ならばということで、以下のように直接抽象構文木を書かせれば（ナイーヴな）インタプリタの本質であるevalの記述に専念できるじゃあないかというのが講義を通して伝えたかったことでした。

    const expression = tSeq(
        tAssign('a', tInt(100)),
        tAssign('b', tInt(200)),
        tIf(tLt(tId('a'), tId('b')), tInt(500), tInt(1000)),
    ); // 上のプログラムをJSの関数呼び出しを通して構築したもの
    expect(evaluate(expression, {})).toBe(500);

　さて、多少プログラミング言語に心得のある皆様ならおわかりのようにこのアプローチは問題なく機能しますが、ただ、せっかくプログラミング言語を作ったのだから構文も設計したいのが人情です。比喩でいえば GUIかCUIかはプログラムの本質ではないけど、GUIの方が結果がわかりやすくていいよねみたいな。

　というわけで今年は具象構文も追加することにしたのですが、しかし、構文解析の話をするには時間もありませんし、概念を理解するのも結構手間です（難しいものではないですが）。というわけで間をとってJSONでMinisの構文を書けるようにしたのでした。たとえば、上記のプログラムをMinisのJSON形式で記述すると以下のようになります：

{
  "type": "seq",
  "expressions": [
    {"type": "assign", "name": "a", "value": 100},
    {"type": "assign", "name": "b", "value": 200},
    {"type": "if", 
      "condition": {"type": "<", "operands": [{"type": "id", "name": "a"}, {"type": "id", "name": "b"}]},
      "then":  500,
      "else": 1000
    }
 }

しかし、見ればわかる通り、元の抽象構文木をそのまま書き下したときより見づらくなってしまっています。

このJSON形式の構文を書き下したのは講義よりしばらく前でしたが、これだとちっとも嬉しくない……というわけで、JSONはJSONでももっと簡潔に書けるように考え直しました。

上記のJSON形式の問題点はすべての式をJSONのオブジェクト（あるいは値）として表現してしまっているせいで、必ずラベルが必要になる点です。しかし、よくよく考えればJSONを使うからといって別にオブジェクトを使う必要はないわけで、以下のように配列形式でいいわけです。

[
  ["assign", "a", 100],
  ["assign", "b", 200],
  ["if", ["<", ["id", a"], ["id", "b"]]
    500,
    1000]]

かなりMinisのプログラムを簡潔に書けるようになりました。と、ここで「それってほとんどS式では？」というツッコミが聞こえてきそうですが、概ねその通りです。強いていうとS式と違ってJSONにはシンボルがプリミティブにないために、余計なダブルクオートが必要になる程度でしょうか。

ともあれこのようにしてJSONでプログラムを表現してあげれば、後は簡単。JSON.parse(str)で入力文字列をJSONとしてパーズした後は、抽象構文木に変換するロジックさえ書いてあげれば既存のMini言語に具象構文を与えることができます。

プログラミング言語Minisはナイーヴなインタプリタや上記のJSON構文を解釈できるものも含め、以下のリポジトリからソースを取得することができます。もし興味が湧いたら触っていただければと思います。単純な言語とはいえどこかにバグがある気もするので、バグ報告も歓迎します。ではでは。

github.com

ネット小説を書き始めて三年以上経って気づいたこと：鯛粗は重要

　元々、幼少期から私は全くもって特に小説家あるいはクリエイター志望ではありませんでした（一貫してたのは学究路線の方）。その一方で、年齢を重ねるに連れて、色々な娯楽を読み耽るほどに「なんでこの終わり方なんだよ！」とか「ここでこのキャラを退場させなくていいだろ」とか「せっかく仲良し方向の路線だと思ってたのに、どうしてギスギスに……」という思いが募っていく一方でした。

　そんなとき、ふと、ネット小説家界隈で言われたことの一つを思い出したのでした。要旨だけを抜きだすと「じゃあその君のモチベーションを軸にして実際に、自分が納得の行く物語を作ってみなよ。もしそれが読者の心に響いたのならきっと読まれるよ」というものです。

　そういう言葉を聞いてやってみるか、やってみないかは当然個人の自由ですけけども、私自身はネット小説「論評」界隈の「読んだことも、書いたこともなく」、どうせなろうってこうでしょうっと論評する一部……でない人たちの不誠実さは好ましく思っていませんでしたから、正当な論評をするためにも、もちろん、自分が好きな物語を作るためにも小説を書き始めてみようと一念発起してアカウントを作成したのが、確か2019年の夏頃でしょうか。

　ちなみに、ネット小説といってもなろう一強の時代はとうに過ぎており、後発のカクヨムはある意味で既になろうを追い越している部分もありますし。他にもアルファポリスなどメジャーな小説投稿サイトはあります。

　さて「とりあえず書くか」とジャンルを決めてなろうに連載を始めたわけですが、読者がとにかく来ない、来ない……。PVを見ると全く読まれてないわけでもないようだけど……みたいな状態が約半年続きました。

　さらに処女作はあまりにもリアリティを重視しすぎてしまったが故に途中で私のほうでスクラップにすることになってしまいました。作者になってみるとわかるんですが「キャラクターが動いてくれない」って心理的に本当につらい。この初作での苦い失敗経験はそのリバイバル版というべき作品でだいぶ改良されることになるのですが、それはともかく。

　処女作はそんな感じで無惨に終わりを迎えましたが、その次に思いつきで書いた数十話程度の長編（中編？）小説は一部の熱心な読者が毎話コメントつけてくださったおかげで、無事に主人公たちにきちんとハッピエンドを迎えさせてあげられました。今でもその読者さんは私の作品に「いいね」を入れてくれたり、場合によって感想書いてくださるのですが、彼（彼女？）のコメントがなかったら挫折してただろうなーと思うと思い出深いものです。

　こうして（心情的な意味での）処女作はなんとか無事ハッピエンドを迎えることができました（カクヨムで★160以上、最終話PVが1217なので、心情的な処女作としてはなかなかものかもしれません）。ちなみに最終話PVは最終話「だけ」読んだ人がカウントされる可能性があるので注意ですが、最終話直前あたりで1154PVなことと他の話数でのPVを考えると、1000名近い読者の方が読んでくれたことになります。

　ネット小説の世界というのは消費が非常にはげしいので「流し読みしただけの人」たとえば、1話1分でほんとうに「あらすじ」だけ見るような大味な読み方をした人もカウントされることの留意しないといけませんが、ともあれまあまあだったのではないかなと。

　心情的な意味での処女作はまずまず成功しましたが、そうすると次も書いてみたくなるのも人情というもの。詳細を書くと色々バレそうなのですが、次ではもうちょっと思春期っぽい話を70話超で描いてみることにしました。ヒロインの特徴とか描いちゃうとこれまた割と簡単に検索でヒットしそうなのでぼやかしておくと「方言」が一つのキーワードと言えましょうか。

　こちらの作品はまた、前とは別の、すっっっごく熱心な読者さん（＋前作でついた読者さん）がどんどん応援コメントや応援レビューくださったこともあって、ラスト数話は睡眠時間を削って完成にこぎつけました。こちらはカクヨムで★230以上、最終話PVが1200くらいでしたが、読者さんの熱量という意味では（SNSからの反応も一部に）圧倒的にこちらが上でだいぶ自信がついたものでした。

　応援コメントで「続きが読みたいです」が割と真剣に多かったので実際に後日談を別作品で作ってしまったくらいです……。

　ともあれ、そうしてだらだらと創作活動を続けて三年以上になります。

　長編も10話以上完結させて、短編も多数生産して（短編は生産数が多すぎて、他の作者には見られない異常な数値を叩き出しているので、書くとやはりわかりそうなので控えます）。カクヨムでは★100くらいは普通に（下記始めの頃は、★100もらえるくらいの作品を書くのが最初の目標とも言えました）、なろうの短編でもジャンル別日間ランキング５位以内にはうまくやれれば（１位に入ったことも）入れるくらいには書き慣れてきたのかなと思うところです。

　正味の固定読者数は推計ですが、なろうの方で少なくとも約300（逆お気に入りの数から推計）、カクヨムの方はもうちょっと感覚的ですが200～300名くらいはいそうな感じです。そんな中、気づいたことがあるのでちょっと書き留めておこうかなと思ったのでした。

　たとえば、ネット小説の、特になろうでの小説執筆が普通の小説執筆と違うところに「ランキングバトル」という側面があることです。「小説家になろう」では読者が読んだ小説についてポイント形式で投票できるのですが、それにもどついて「総合」「各ジャンル別」について1～100位以内のランキングを一日三回更新されます。そのランキングで上位に上がれば読者の目につきやすくなり、つまるところより読んでもらいやすくなり、ますます評価が得られやすいという好循環が生まれるわけです。私も一時期、短編小説でいかにして日間ランキング5位以内に入るかの手法を考えるのに腐心していた時期があり、ある意味射幸性のあるギャンブルチックな側面ともいえるかもしれません。

　また、ネット小説は特に供給量が豊富な故に、タイトルとあらすじの付け方がまずいと、いくら本文が良かろうが致命的に読まれないということも重要です。仮に恋愛小説を書くとして「僕と彼女のヒトナツの恋」などという平凡なんだかちょっと気取ったのかわからないような題名は言語道断と言っても過言ではありません。

　何故かというと、読者は皆忙しいので、本文を読むべきか切るべきかをできるだけさっさと判断したいからす。半分過ぎてから、これじゃないんだよなと思って時間を無駄にしたくないのです。「僕と彼女のヒトナツの恋」というけど、彼女は病気でこの世を去るのか？それとも、単純に夏に出会った相手との恋なのか？などなど、男性向け恋愛小説について読者が特に知りたいヒロインについての情報量がほとんどこのタイトルが含まれていません。タイパ世代という言葉が頭をよぎりましたが、データ上は世代を問わずに見受けられるようなので、まー人間、娯楽が溢れればそうなるさってことかもしれません。

　いい「タイトル」というのも曲者でして、なろうだけでなくカクヨムでも、結局「タイトルだけでおおまかな内容を連想できるくらいには長くなっていないといけない」という原則は基本的に変わっていません（長文がmustなのではなく内容が連想可能がmustなのがポイントです。これを利用すれば短いタイトルでもうまくハマるのも作ることはできます）。ここで「美しいタイトル」をつけたいと思う、普通の作者の美意識や願望と「いやでも読まれないと意味ないしな」という現実主義との葛藤が生まれるのです。これを読んでる読者の方々、なろうなどの小説における長文タイトルは別に作者が好き好んでそうしたわけではなくて、そうしないと小説が生き残れない、より正確には読まれずに放置されるだけになるという前提条件があるのだと思えば、少しは理解できるのではないでしょうか。それでもなお、私には葛藤が残りますが。

　あとは「あらすじ」もですね。ここでの「あらすじ」は本来の意味でのあらすじとは違うのが曲者で、いわゆる煽り文の類である必要があります。リアル書店に並ぶ書籍は、編集さんが帯のコメントなど色々考えてくださるわけですが、ネット小説家だとこの部分も当然ながら全部自分でやる必要があるというわけです。この「タイトル」と「あらすじ」が重要というのは、ある意味多くの読者に読んでもらうときの記事の書き方の基本みたいなものであって、小説を書き始めてから以前と違う観点で文章を意識するようになった……気がします。

　他にも、なろうのランキングで上位に入ると途端に荒らし感想が増えてくるとか、カクヨムはなろうに比べればだいぶ平和だなとか他にもありますが、今日はとりあえずタイトルとあらすじが重要ということで。

結論は同意できても途中の論理展開がおかしい記事の話

　おはようございます。朝から非常に微妙な気持ちになる記事を見てしまったので、ちょっとそれについて書いてみたいと思います。対象は、

toyokeizai.net

というとても残念な記事です。本題に入る前に常日頃から思うのですが、結論自体は著者と別の理路から同意できなくもないが、途中の論理展開が破綻してる記事って多過ぎません？あくまで感覚ですが、ネットの一応まともな出版社の記事でも、1/10くらいの確率で誇張でなくそういう残念な記事に出会ってしまう気がします。今回の記事もそのような残念な記事の一つです。

　さて、この記事の主題は、昨今蔓延している古文不要論へのカウンターパートとして、

「現代の文章や言葉を理解するために、古文を勉強する必要がある」（原文より引用）

　ということにあります。筆者の気持ちはわかります。私自身、古文が全く役に立たないとは思っていないし、実際問題として、古文だけでなく歴史など「一見役に立たない」学問をバカにして、「実学」だけに偏った人が往々にして社会に関する無知をむき出しにしてしまう光景を私自身多々目撃しているからです。

　しかし、この主題を訴えるための例示が極めてまずいです。著者は言います。

しかし、この前提は間違っています。古文を勉強するのは、昔の文章を勉強することで、現代の文章を読んだり、日常会話で不便しないようにするためにやっているものです。

　この主張が正しいかはともかく、可能性としてはありえそうな話です。ただ、現実問題として「現国不要論」などというものが叫ばれていない、というかむしろ論理国語の道入とか含めて重視の風潮になってきていることを考えると（物語読解については不要論が根強くありますが、まあ別として）、例示するなら、現代文でなく古文を勉強していないとダメなものであるべきです。

　しかし、本文を見るとため息が出るばかりです。最初の例を見ましょう。

例えば、一つクイズを出しましょう。

現代において、物事が終わる時に「けりをつける」という言葉を使うことってありますよね。「Aさんとの関係にけりをつけてきた」みたいな感じで使いますね。

では、この「けり」って一体どういう意味なのか、みなさんは知っていますか？

これは実は、キックという意味の「蹴り」ではないんです。古文を勉強したことがある人なら、助動詞で「けり」という言葉があるのは知っているはず。古文の勉強でもよく、文章の中には、「〜にけり」のように、言葉の終わりに「けり」をつけることで「文の終わり」を示しているものがあったはずです。

　えーと、古文にその起源があるのはそうでしょうけど、別に現代文を普通に勉強していればわかる話ですよね。私自身、古文は熱心な方ではなかったし、「～にけり」みたいな話はすっかり忘れていましたが、別に「けり」の意味を知らなくても「Aさんとの関係にけりをつけてきた」は普通に「Aさんと縁を切ってきた」とかいう方向で普通に解釈可能ですよね。あるいはズブズブした男女関係だったら、別れ話かもしれません。いずれにしても関係に「決着をつける」という方向なのは見ればわかるでしょとしか言いようがない。現代でもちょくちょくは使う言い回しなのでなおさらです。

　また、別の話として、古文の「けり」を知っていたからといって、それが現代文の「けり」と同じかは一般には別問題です（当たり前ですが）。古文は現代文と各種文法が異なっているから古文なのであって、古文の解釈をそのまま現代文解釈に適用できると思っていたらむしろまずいでしょう。繋がっているのもあれば古文にはあるが廃れたものもあるわけですし。

　いずれにしても、この例示は「古文を勉強すべき」に説得力を与えていないのは確かです（現代文読解すら不要と主張する論者なら別かもしれません）。

　次の例を挙げましょう。

また、たとえばみなさんは、「あなたは小学生ですか」と言われたら、どのように解釈しますか？

まず考えられる解釈としては「質問」があると思います。12歳くらいの親戚の子供に対して、「ねえねえ、君は小学生かな？ 中学生かな？」ということを聞いている場面で、「あなたは小学生ですか」と聞くと思います。

もう一つ、考えられる解釈があると思います。例えば会社で、ミスをした自分を上司が怒ってきています。「こんなミス、小学生でもなきゃしないだろう！」という意図で「あなたは小学生ですか」と言うことがあるでしょう。このような、答えがわかり切っているけれどあえて疑問のように聞くことで、強く相手にメッセージを伝える用法のことをなんというか、みなさんはわかりますか？

正解は、反語です。古文でも漢文でも、反語表現というのはよくあるものです。

正解は反語ですと書かれているわけですが、この用例でもっと多いと思われる「皮肉」という解釈がすっぽり抜けていますよね。いや、注意するという文脈なら反語かもしれませんが、上司が部下の能力について嫌味な悪口を言うなんてのは珍しくもないわけで（幸い、そういう会社にはいなかった、わけでなく……就職して最初の会社だけはそうでしたが）、社会でよくある話としては「皮肉」の方が多いんじゃないかなとすら思います。用例としても極めて多いですし。

いやまあ、反語か皮肉かは本題じゃないのでおいといて「反語」は現国で習いますし、皮肉は……習ったか忘れましたが、社会で普通に生きてりゃわかるでしょう。古文関係ないじゃん、と。むしろ現国で十分じゃない？という印象すら与えかねません。

一応、

この反語という表現をきちんと理解するためには、古文の勉強をしておいた方が頭に入りやすいです。

とは書いてありますが、現国で「反語」の意味を教えるのだと不十分だという根拠にはならないですよね。筆者にとってはそうだったのかもしれませんが。

最後の方に至ってはもうさっぱりわかりません。

何が言いたいのかというと、現代語の方が、古文より難しいのです。昔はしっかりと助詞や助動詞を使って表現されていた言葉が、今はもうそれを使わなくても表現できるようになってしまっていて、昔より日本語が難しくなってしまっているのです。

ここで一つ、想像してみてください。もし、古文の勉強を一切しないで、現代の言葉だけを勉強していて、「質問の形になっている表現で、答えがわかり切っていることを聞いて、『〜だろうか？ いやない』なんて訳す場合がある」と習ったとして、使いこなせるでしょうか？ おそらくは、多くの人は使いこなせないと思います。（ちなみにこの「使いこなせるでしょうか？」も反語です）

普通に使いこなせますがという回答しかないなと思うわけです（ちなみに私の古文の成績はまあ真ん中くらいでそんなに出来の良い生徒ではありませんでした）。周りの中高時代の同期に聞いても、確信できますが同様でしょう。そもそも、反語や皮肉的な表現なんて現代でいくらでも登場するわけで、それらの理解が抜けてたら社会で生きていくのにむしろ困るじゃないですか。

例えば人から「本当にそう思いますか？」と言われた時に、「はい、本当にそう思いますよ」なんて答える人っていますよね。

多くの場合、「本当にそう思いますか？」というのは反語で使われていて、「本当にそう思いますか？ あなたは、本当には、そう思っているはずがないですよね？」という意図でつかわれています。

それはそうですが、このような「会話における含意がわからない」は発達障害（ASD）を語るコンテキストで出てくる話だし、勉強熱心な発達障害的な特性を強く持つ人がこの類の反語がわからない（言葉どおりに取ってしまう現象）は実証されている話でもあるので、古文を勉強してればそれがわかるというのはまずありえないでしょう。

このように、古文の勉強を疎かにしてしまうと、現代語の解釈がうまくできなくなってしまうのです。

このように、古文の勉強を熱心にしていても、読者に対してツッコミどころ満載の文章を書いてしまうことはあるのです。と皮肉を書いて締めにしたいと思います。

このブログの中ではとびっきりにトゲトゲしい批判の仕方になりましたが、商業に流通するメディアに記事を載せる人は最低限の説得力をもたせる文章を書いて欲しいと願うばかりです。それに何が必要かはわからないのですが、個人的な感想で言えば「論理」ではないかなと思います。この文章だって見直すときに、自分の書いた例示が主題をサポートする（つまり例示から論理的に主題を導き出せる）かを検証できていればこうならなかったわけでして。