政治と経済の無相関性：歴史的視点からの考察

 これまでの主要な経済事象を振り返ると、政治が経済に与える影響は極めて限定的、あるいは皆無であることがわかります。

• 高度経済成長（イザナギ景気）

戦後ゼロからの再出発において、成長は必然的な流れでした。これは社会構造の復興によるものであり、政治の功績ではありません。

• バブル崩壊

市場の過熱とその終焉は経済サイクルの一環であり、政治的コントロールの枠外で発生しました。

• 震災と民主党政権

福島第一原発事故や東日本大震災という未曾有の国難、そして「悪夢」と評された政権下においても、株価は停滞しつつも極端な反応を示さず平行線を辿りました。この事実は、政権交代や重大な政治事象が市場の本質を動かさない証左です。

• アベノミクスによる30年の停滞

多種多様な政策が打たれましたが、結果として待っていたのは「失われた30年」の継続でした。金利操作の限界から外国人投資家の反応も限定的であり、株価の上下動はあったものの、実体経済と政治施策に直接的な因果関係は見出せません。

• サナエノミクスと現状

金利上昇による住宅ローンへの打撃や、1300兆円を超える国債赤字が露呈しています。かつて技術的コアコンピタンスを誇った企業の低迷を見れば、政治主導の技術投資も無意味であることは明白です。

結論

以上の歴史的事実から導き出される結論は一つです。政治は経済に対して実質的な影響力を持っていません。

「経済対策」と銘打たれた数々の政策が、実際の経済動向に寄与した例は皆無であり、経済は政治とは切り離された独自の原理で動いています。

【考察】異世界転生ブームの構造：ドラクエを共通言語とした救済

1. 宗教的機能の代替

現代の異世界転生作品は、かつての宗教が担っていた「現世の苦難からの解放」という役割を引き継いでいる。

• 救済の構図: 現実での挫折や閉塞感を、死（転生）を境界線としてリセットする。

• 報酬: 努力の積み重ねではなく、転生時に付与される「能力（チート）」によって即座に成功と承認を得る。

2. 信仰対象の不在と派閥

この現象には、特定の神や教祖が存在しない。

• 信仰ではなく共有: 読者は特定の対象を拝んでいるのではなく、提示された「都合の良い設定」を各自で利用している。

• 派閥の性質: 「悪役令嬢」「追放」などのジャンル（派閥）は、個人の好みの違いであり、教義の対立ではない。

3. 土台としての「ドラゴンクエスト」

作品群の根底には、ドラゴンクエスト（JRPG）が定着させたルールが共通基盤として存在する。

• 共通ルールの利用: ステータス、レベル、魔法、魔王、ギルドといった要素は、説明不要の「周知の事実」として扱われる。

• 効率化: 世界観の説明を省略し、読者が最も求める「成功体験」の部分に物語を集中させることを可能にしている。

結論

異世界転生ブームとは、宗教に代わり、ドラクエ的な共通ルールを道具として用いることで、誰もが手軽に「自分が報われる物語」を消費できる救済の仕組みである。

 JSで作ったLISPライク言語

実は少しバージョンアップして、Switch-CaseやFillRectのみですが描画命令を持たせました

これにより、マンデルブロを描画できるようにしてみました。

是非ご観覧ください

https://www.yachiyo.tech/tool/JSLisp/

https://github.com/ChaosReadman/JSLisp

独自WEBフレームワークAlbion

 https://github.com/ChaosReadman/Albion

XQueryの完全実装をやめ、必要な機能のみ実装

どこがどう違うのか、開発哲学もREADMEに記述

XQueryに存在しない更新系クエリも実装

もはやwiki、レシピサイト、ブログなども作ることができますが、まだ脆弱性に関する設計を置き去りにしていますので、現状のまま使わないでくださいね

まだまだ変わります

独自WEBフレームワーク（FUSEやめました）

FUSEを使うのをやめたらめちゃくちゃ早くなりました。

2秒ちょいかかっていたのが、0.5秒かからなくなりました。

これなら実用速度です。

double, int, stringへのキャストにも対応しましたので

以下のような書き方もできます。

where xs:double($book/@price) >= 10.5 order by xs:int($book/@price)

order by xs:string($book/@price)

独自WEBフレームワーク

再び独自フレームワークを作り始めています。

あるアイデアのもと、Fuseを使い、XML Dataをファイルとフォルダ構造で置き換えています。

そしてSwiftによってResftfulAPIを作り、

リクエスト先にquery.xqyを配置

リクエストが来た時にquery.swiftを作成し、コンパイルし、実行します。

二回目からのリクエストでは、実行ファイルができている状態なので、コンパイル等の時間はかかりません。

デモでは食品データベース（２４７７種類）を使用しています。

JSで実装したLISPライク実行環境（マンデルブロも描画できるよ）

 LISPを眺めていて、これはJSONで書けば、LISPの処理をJavaScriptで書けるのではないかと言うアイデアが浮かび、AI使ってコーディングしてみました。

動作例はこちら

https://www.yachiyo.tech/tool/JSLisp/

Gitはこちらになります。

https://github.com/ChaosReadman/JSLisp

描画命令でfillRectも実装し、マンデルブロ描画も出来るようにしました。

わたしはスーファミのプログラムをしていた時、HAL研究所のC言語コンパイラに助けられました。

スーファミのアセンブラは少しクセがあったのと、わたしは当時そこまでアセンブラに明るいわけではなかったのですが、そのコンパイラはC言語からアセンブラへ変換してくれて、アセンブルする事でスーファミのバイナリが出来上がりました。

聞けば、コアはLISPだそうで、どんなCPUにでもアセンブラが出力可能とのことでした。

当時わたしはEmacsを使い、LISPは知らない訳ではなかったのですが、その話を聞いてもさっぱりわかりませんでした。

今回、自分でLISP関数を作っていて実感し始めた事があります。

C言語からS式が作れたら、LISP関数の世界になります。その関数からアセンブラコードなどを吐き出せば、、、

C→S式→LISP関数→アセンブラコードと言う事が出来そうです。

最近のプログラマは、動画、検索、AIなどで途中に覚えるべきことを全部飛ばしている事を危惧していましたが、わたし自身がLISPの自作をすると言うことを飛ばしていたため、ずっとHAL研コンパイラが理解できないままでした。

今回、本当に作ってみてよかったです。

そして、もっと大事なことにも気がつきました。

実はCからアセンブラだけの話ではありません。

他の言語から、他の言語への変換がかなり楽になると言う事です。

実は、ある特殊な言語を、GoやSwiftに変換したいと思い、LEXとBISON、Boost Spirit、ANTLRをずっと研究していたのですが、実はその言語、S式にかなり近い物です。

他のどの方式よりも、今回の方式の方が最短距離です。

リニアレール化したらTLMその後

 最近は、寒くなってきたのでなかなか活用できていなかったTevo Little Monsterですが、冬の間にレイズドベッドの準備がしたく、作り始めています

連結用の部品もデザインしていて、このデザインみたいにオーバルではなく、真四角なレイズドベッドにしようかと思っています

リニアレール化したTevo Little Monsterは本当に音が静かで、Precision Piezo Orionによるベッドの計測もさらに安定し、ノズルもESD Revoにしていてかなり快適で使っています

Goでオブジェクト指向は「呪い」だ：シンプルなはずの言語が複雑になる理由

最近、世間で話題になるGo言語のライブラリを見ていると、どうにも「オブジェクト指向の呪い」が残っているなと感じることが多い。

Goの設計思想はC++の複雑さや、不必要な派閥争いを避けるために生まれたはずなのに、結局、多くのコードがまたあの「うんざりする」OOP的な慣習に引きずられているのです。

Goが目指したもの：モジュール指向への回帰

Goの作者がC++に対して感じた「なんか違う」という違和感は、不必要な複雑さと硬直した設計へのフラストレーションです。

• Goの哲学: Goは、継承を排除し、「構造体（データ）」と「インターフェース（振る舞い）」を分離し、小さなパッケージを組み合わせるモジュール指向を推進しています。目的はただ一つ、コードをシンプルにし、大規模開発でも保守性と生産性を維持することです。

これは、わたしがスーファミの時代に「アセンブラでのVSync割り込みプログラム」という最小の制約からすべてを自作し、効率と簡潔さを追求した開発哲学と完全に一致しています。

なぜ「オブジェクト指向っぽい」コードが生まれるのか？

しかし、現実のGoライブラリには、まだ古い時代の「慣性」が働いています。これがわたしが感じる「呪い」の正体です。

1. カプセル化の過剰適用:

OOPではデータを隠蔽するために Getter/Setter や ファクトリ関数（NewClient() など）を使うのが定石でした。Goでは小文字で始めるだけでフィールドは隠蔽できるのに、わざわざ冗長なラッパー関数を作ってしまう。これは、Goのシンプルさを犠牲にして、OOPの習慣を無理やり守ろうとしている証拠です。

2. 巨大インターフェースの乱用:

Goでは「小さなインターフェース」が推奨されています。しかし、既存のOOPの抽象クラスのように、複数の機能を詰め込んだ巨大なインターフェースを定義してしまうと、使う側は必要のないメソッドまで実装させられることになります。これは、柔軟なはずのGoの仕組みを、硬直したOOPの階層構造に逆戻りさせている行為です。

3. データと振る舞いの不自然な結合:

Goはモジュールとして関数を分離しやすいのに、多くの機能的なロジックを構造体のメソッドとして過度に定義してしまいます。結果として、「その構造体なしには何もできない」というOOP的な依存関係が生まれてしまい、モモジュール指向の利点が失われるのです。

結論：呪いを解き、本質に立ち返る

Go言語は、既存の「派閥」や「複雑な慣習」から解放されるために生まれた、非常に合理的な言語です。

にもかかわらず、ライブラリが「OOPの呪い」に囚われているのを見ると、エンジニアの思考が、ツールの裏側にある物理や数式ではなく、流行や抽象化された設計思想に縛られている証拠だと感じます。

わたしは引き続き、Goの真価であるシンプルさ、モジュール指向、データへの明確なアプローチを追求していきます。そして、既存の常識や派閥に惑わされることなく、常に「なぜこの仕組みが必要なのか」という本質に立ち返って、コードを書いていくだけです。

以上、終了。

リニアレール化

 Tevo Little Monsterのリニアレール化を行いました

結論から書きます

やってよかったです

• 音が静かになった
• 造形がシャープになった
• ベッドレベリングの精度が上がった

基本中の基本かも知れませんが

精度を少しずつでも上げていけば

全体の質が上がります

3Dプリンタはまだまだ未完成の領域であるため

ユーザーは自らの手でカスタマイズすることが必須です

それはたとえBambooLabであろうとPrusaであろうと同じです

以下作業の流れです

治具がThingiversrにあったので、それを光学造形のSonicMiniでプリントし、電動ドリルで穴あけとネジ立てし、3ミリのネジで締めまくりです

なんと、光学造形が少し歪んでて、レールが多少斜めになってしまいました

しかし、1ミリもズレて無いので大丈夫でしょう

ファンアダプタも作りました

少し横幅が大きかったので、小さくした部品も作りました

今度何かのタイミングで取り付けようと思います

ZプローブはPeecisionPiezoOriobを使っています

これはピエゾ素子で、ノズルの先端に衝撃が加わると、それを検知します。

つまり、誤差ゼロでプロービングできるわけです。

しかも、スイッチと違い、繰り返し精度もめちゃくちゃ高い物です

わたしは出始めの頃からずーっと愛用しています

また、とっくの昔にマザボはDuet6HCとラズパイ4の組み合わせに変えており、加速度センサーをつけてあります

これでヘッドの急な動きを抑止できます

あと、試しに赤外線センサーのエンドストップを除去し、モーターのストールデテクションを試しましたが、どうも精度がよくありません。

仕方なく、赤外線スイッチに戻しました。

あと、0.9度モーターに変えていたのですが、

どうも脱調しまくりです

カレントを上げればよかったかもしれませんが、

その前にモーターが信用できなくなり、1.8度モーターに戻しました

他にもあれやこれややりまくり、ようやくうちのプリンタも完全復活したと思います

しかし、穴あけとタップは疲れました

接着剤や両面テープで止めてやろうかと思いました、、、

任天堂さん、、、

https://automaton-media.com/articles/newsjp/nintendo-switch-20250908-356797/

わたしは任天堂の社長だった岩田さんとは面識があります

ハル研究所の頃出会いました

当時任天堂は、ゲーム会社が売れるゲームを作っても、思ったほどの量を出荷することに同意してくれず、あちらこちらの会社からは儲け損なったと批判が出ていました

その任天堂の社長になった経緯をわたしは間近で見ていました

（ここで当時のことを詳しくは書きません）

岩田さんが社長になられてからは任天堂も変わり、わたしの中ではアタリショックをよく知っているメーカーとして、きちんとしたコンテンツを提供することに力を割いているため、ダメそうなゲームの生産に同意しなかったのだなと納得していました

ですが、昨今の様子はどうなのでしょうね

わたしはゲームとはゲームでしかないと思います

このニュース記事のように、ハードやソフトの自由を奪うことに注力するのであれば、横井軍平さんのワンダースワンのように、ワンダーウィッチがあれば誰でも開発できるという開いた開発環境が必要だと感じています。

ところで、わたしが作ったゲームが最近Switchで販売されましたが、わたしには一文も入ってきません

もちろん当時のプログラマは（今もでしょうが）自分の書いたコードの著作権を会社に帰属させているため、一文も入ってこないのです。

わたしはプログラマのために、JASRACのような組織が必要だと感じています。

わたしが情熱をかけて作り上げたゲームを、権利を引き継いだ会社が勝手に販売している

わたしにはおかしな光景に映ります