プログラミング経験者なら「差分だけあればいい」って事なのは事実なんですが・・・。
結構ね、初学者だと「どこだっけ?」になりやすい気がします。
フツーの書籍ならね。「ページ数削減する為に」そういう記述法になりますが(笑)。

ここは言葉足らずでした。VSCodeのブロック折畳表示を駆使したらどうか、と伝えるべきだった。
例えば、1-8、1-9の例です。

1-5から、全文が全展開で繰り返し掲載され続けます。
P28など、画像に挟まれて、本文は1行しかありません。
折畳表示で全体を示しながら、注目箇所だけ展開しておけば、見やすくなるのではないか、という意図でした。

少なくともロバート・ウッドヘッド本人は言ってましたね(笑)。・・・とは言ってもYouTubeにその動画が残ってない(苦笑)。

もしかしたら、見つけたかも？

その画像、プロフィールのカバー画像に設定しなよ。

章ごとにスレッドを分けました。
it:tawashenさんも、続きをこちらでやりませんか？

別スレッドで、章から派生した話題を続けることもできます。

読みました。

写経するだけであることを明示し、それに従って読み進めれば、リファクタリングしながら著者の思考に沿って理解できる、あるいはコード表現の根拠を理解できる展開は良いと思います。
解釈の筋道を読者に任せないので、読者が付いてくる限りにおいては、複雑な話題になるほど、筆者の意図を伝えやすいスタイルですね。

その点から、次のことが気になりました。

• P16のfunction prompt、console interface
  コード中の表記と異なる用語なので、コードの中の該当箇所を明示、並記した方が分かりやすいのではないか。
   
• コード中の書換箇所の差分表示
  コード全文はある程度の段階ごとに表示し、それ以外は書換箇所の差分表示、あるいは注目している関数以外を折畳のクローズ状態で全体表示するので十分ではないか。
   
• P19 *6
  これは本当？
   
• P42の8か条
  これは冒頭にも書いておいて、その時点で読者が理解できなくても、これから取り組む写経内容の事前紹介としておくのが良いのではないか。
  訳も分からず写経するよりも、少なくとも8つのうちのどれかをやっている、ことを知る手掛かりになる。

末尾再帰ではなく、whileを用いる理由。

本当は、末尾再帰で書ければ完全な「関数型プログラミング」なんですけどね。ただ、トランポリン関数をこの時点で全くやってないんで(第1章のすぐ後に挿入予定)、苦肉の策(笑)でやっぱwhileと再代入を使わざるを得ない、と(笑)。

新しいパークにて返信しておきました。

”オブジェクトは貧者のクロージャ”だったか、”クロージャは貧者のオブジェクト”だったか…

OOPよりも先にクロージャを理解してもらわなければ

やっていることは同じですが、全体構造を一見したときに理解、把握しやすいのはクラス構文、というのが私の第一印象。
このような感覚を直感的と呼ぶならば～

クロージャ構文を一見しても全体把握の感覚がなく、まず上から順番に読み始めて…となりますね。
私には、こちらは直感的じゃない。

クラス構文

class Member {
    // name / age プロパティの格納先 (プライベートメンバー)
    #name = "";
    #age = 0;

    constructor(name, age) {
        this.#name = name;
        this.#age = age;
    }

    // nameゲッター
    get name() {
        return this.#name;
    }

    // ageゲッター
    get age() {
        return this.#age;
    }

    // ageセッター
    set age(value) {
        // 不正な値は例外をスロー
        if (typeof value !== "number" || value < 0) {
            throw new TypeError("ageは0以上の数値で指定してください。");
        }
        this.#age = value;
    }

    show() {
        console.log(`私の名前は${this.name}、${this.age}歳です。`);
    }
}

const m = new Member("佐藤理央", 25);
m.show();

クロージャ構文

function makeMember(name = "", age = 0) {
    let [thisName, thisAge] = [name, age];
    // nameゲッター
    function getName() {
        return thisName;
    }
    // ageゲッター
    function getAge() {
        return thisAge;
    }
    // ageセッター
    function setAge(value) {
        // 不正な値は例外をスロー
         if (typeof value !== "number" || value < 0) {
            throw new TypeError("ageは0以上の数値で指定してください。");
        }
        thisAge = value;
    }

    function show() {
        console.log(`私の名前は${thisName}、${thisAge}歳です。`);
    }

    const methodTable = new Map();
    methodTable.set("getName", getName);
    methodTable.set("getAge", getAge);
    methodTable.set("setAge", setAge);
    methodTable.set("show", show);
    return methodTable;
}

const m = makeMember("佐藤理央", 25);
m.get("show")();

このような話題をコメントの中に埋もれさせておきたくなかった。
特定の話題を、これくらいの粒度で、単一スレッドに割り当てしたかったのも、新しいパークを作った理由の一つです。

参考

計算機プログラムの構造と解釈　第二版　3.1.1 局所状態変数

Case Studyリリースのタイミングで、話題を整理して活動継続できるよう、新しくパークを作りました。

これまで単一スレッドの下へ、コメントを乱雑に投稿し続けてきました。
新パークでは、話題に沿ったスレッドを作り、スレッドに沿ってコメントを投稿しましょう。

特定の話題を、特定のスレッドや集約させることで、Mouton要約も機能しやすくなります。

pic.twitter.com/y7t3VllsrZ

— braindead.gif (@rightclickdead) October 13, 2026

🖒

ちなみにイタリア料理にもトマたまはあります。

炒めならStrapatsada、
煮込みならeggs in purgatory

作り方は、ほぼ同じ。
こだわり、偏見がなければ、パスタ、トースト、白米、何でもありです。

お昼に食べました。
狩野ジャパンの、麺がチャンポン麺のやつです。

認知機能が衰えてきても発話自体は問題ないことが多く

このようなところが老人と対処するに際し、ややこしいところですね。
例えば、痴呆に起因する問題ではなく、老人性難聴の場合もあり得ます。

• 聞き取りにくくなる → 声量も的確にコントロールできなくなる
• 使っていないのではなく、的確に受信できない結果→情報処理能力が衰える

極端な場合、心筋の衰え → 脳への栄養供給不足 → 脳機能低下、の因果から、心臓にペースメーカーを入れることで脳機能が正常に戻る例もあります。
脳機能低下だけ見ると、一見、老化現象、認知症のように見えて、実は原因は脳ではなく、心臓だった、というのは我が家の祖母の例です。

最後に書籍『図解でわかる高齢者の行動と心理』を紹介しておきます。
高齢者特有の言動についての因果関係を図解しています。

Martin Poggsner pic.twitter.com/6M8ZQMqKAy

— La vida en viñetas (@lavidaenvinetas) September 27, 2026

前回の引越し以降、必要なものを必要なときにダンボールから取り出し、残ったものが使わないもの、を実践し今に至ります。
次回引越しは来月です。そのダンボールをそのまま搬出します。8箱くらいあります。

執着ですね。

そちらの祖父母の事例は、私の実家含め、関連する事柄がありますね。
幸い、私の祖父母は認知症にはならず、祖父は散歩（往復約10㎞、高低差100m）とプラモデル、祖母は煙草だけで何もしない毎日でしたが、祖母の方が長生きだったのが皮肉でした。

閑話休題。

「目・耳・指」を動かすトレーニング、その効果、さらに認知症の話題から離れ、「ソファに座ってずっとテレビを見ていた」について、一つ気になっている論があります。
出典が確かめられず恐縮ですが（確かゼロ年代の本）、このような論があったのを覚えています。

• ポップカルチャー（テレビドラマ、テレビゲームなど）が、人々の認知能力、情報処理能力を高めている。
• 複数のストーリー・ラインが同時進行する
• シーズンすらまたぐ伏線
• 探索、条件分岐、多層的な課題、それらにまつわる意思決定

エピソードを記憶し、それを長期間保ち続け、関連や因果関係を見出せなければ、伏線のあるコンテンツは楽しめず、ゲームにしたところで、複雑な情報処理を経て、意思決定しなければ楽しめず、そのようなコンテンツに日常的に触れることで、現代人の認知能力や分析能力は自ずと高まっている、という話題でした。
要は、ポップカルチャー・コンテンツですら複雑すぎて、高度な脳機能を働かせないと楽しめず、それに対応するように現代人の認知能力が向上している、ということです。

身体を動かさず、じっとしているだけなのは不健康、という論は確かでしょうが、認知能力の維持、向上、改善の点から、ここに挙げた例の様な影響についてはどうでしょう？

あれは、鍋を焼く、っていう調理と聞いたことがあるぞ。
聞いたことがあるだけだから、あくまでも、その人の意見。

煮込み、まではいかず、鍋料理でもない。
うどん含め、具材をまとめて鍋に入れ「焼く」。

ユーモア前提のスレッドなので、何を話ししてくれても良いのだが、
このスレッドの趣旨として求めているのは、

• 目と耳と指を同時に働かせる訓練ってどんなものがある？
• それはタスク特化的な習熟、それとも脳機能の改善的な効果あり？

ってことだから。くれぐれもユーモアは忘れずに。

行きがけの駄賃で、ドラム演奏と認知症の話題
あと、テレビの話題は夜にコメントします。

https://www.rcast.u-tokyo.ac.jp/ja/news/release/20230525.html

ここらで話題が本題のドラフトへ戻ってきた感があります。

そうなんですよね(笑)。だからなるたけ「万人に分かりやすいように」と思考プロセスの提供はしてるつもり

私が、特にこの場で話しているプログラミングについての”思考プロセス”として想像するのは2通りあり、
A．課題に対して考え、記述するコードにつなげる過程
B. 記述されたコードについて考え、そこに至った過程

前者の具体例が、Exercise 4.2の説明文であり、さらにそのプログラムまで含めれば6.2.3の例3など、非常に丁寧に説明されていると思うのです。
一方、ドラフトを離れ、例えばいきなりワンライナーの一行を見かけたとき、その一行に達するプロセスは想像するほかなく、「リファクタリングしろ」「リファクタリングありきだ」とはいえ、元のコードから一行にたどり着くリファクタリングはともかく、逆はかなり難しい、ということですね。
そして、人によってはそこが挫折のきっかけだったり、かなりムキにさせられるところだったりで、結果

90%以上の人には受け入れられないだろう

に通じるところへ転じるのでしょう。

ハッキリ言うと、商用の本を狙ってたら最初っから大失敗作でしょう(笑)。Web公開のフリーな文書を狙ってるから出来る無茶と言える(笑)。

だから、きちんと完成させましょうね👍
そして、このようなイベントで発表しましょう！

スティーヴン・ホーキングに言わせれば「数式を一つ入れる度に本の売上は1/2」らしい

関数型プログラムでは避けられないところだと思いますよ。Rも同じ。
主な適用場面がそう言うところでしょうから。

1行の方がRobustnessから見ても優秀ではあるんだけど、なんか書く方の「感覚的なもの」~
本質的にはワンライナー愛好者

この”感覚的なもの”、特にそうしたくなるところ、は確実にありますね。
その目的がデータ加工、処理が連続し、その結果を出力させる場面です。
RでのTydyVerseがまさにこの感覚で、パイプすることが前提、むしろワンライナーになる書き方が正しい使い方なのでしょう。
そうならない書き方は間違いではないにしても、Tidy前の時代から抜け切れていない。

TydyVerseは”自然に”ワンライナーになる仕掛けが感じられる一方、メソッドチェーンは論理と記述の合理性が行き着いた先、のように感じます。
見た目はワンライナーではありますが、ドットでつながったネスト構造、の感覚…可能な表現の中から、あえて選んだ一つ、書き方は自由、みたいな意思の帰結を感じます。
シェル芸同様、それがリファクタリングの結果ではなく、思考プロセスの自然な反映であれば、思考が的確に言語化され、期待した出力へ滞りなく至るプロセスですから、それは確かに爽快感に通じるだろう、ことも理解できます。まさに「あの快感」ですね。

JavaScriptでのオブジェクト指向を説明する際
関数型プログラミングの文脈でOOP語るなら

『JavaScript本格入門』を読んで”教えてもらった”ことの一つが、クロージャとオブジェクトの関係性でした。それまで考えたこともなかった。

ノートに記録したレベルで、実感を伴う理解はありませんが、「言われてみればなるほど」という感覚がありました。
こういうところは、豆知識やコラムではなく、真剣に説明する人がいて良いところではないか。正しい表記は分かりませんが、”オブジェクトは貧者のクロージャ”だったか、”クロージャは貧者のオブジェクト”だったか、そういうこと言う人がいるでしょう。その納得、理解の説明を読んでみたいところでした。

既存OOPファンには総スカン

”教義”になると、”信者”が生まれ、排他的になります。
解法は一つじゃない、というのは万人に共有されている前提なので、一つの方法として”受容”まではいかずとも、”そういうのもある”的に認知すれば済む話だと思うのですけどね。
脱ドグマや寛容ではなく、メタ認知ですね。

しかも多分、類書の中で「非破壊的OOP」に言及するのってはじめて、なんじゃないですかね、多分。

きっと、きちんと完成させましょうね👍

pic.twitter.com/PD5jeW0hTY

— bootleg_images_bot(twee!:void(0)-+**** (@chronic_clinic_) September 3, 2026

演奏家やタイピストはみんな頭が良いわけではなさそうなので、どうかしらという気がしますね。

そんな風に思いますよね。
一方、的確な身体操作（指だけとは限らない、例えばバイオリン奏者）は熟練の結果であると同時に、優れた脳機能の所産とも解釈できるわけです。
他にも、

• プロテニスプレイヤーの相手選手とボール位置の先読み
• 同時通訳者の聴覚ワーキングメモリ制御と発話
• 外科医の感覚延長（道具の先端が身体感覚の一部）
  などなど

こちらで認知能力維持、向上の観点から、＜＜冗談半分＞＞に語ってみてください。

FPSは文章術 部門

先日、板坂元『考える技術・書く技術』（初版1973年）を読んだ。ケンブリッジやハーバードで日本文学を教えた著者が、海外生活で身についた「日本ばなれ」した見方・考え方を交えつつ、コミュニケーションの手練手管を語る、”文章の上手な書き方というような本”だ。

その第1段階「脳のウォームアップ」に、次のような一節がある。

頭のよしあしなどというものは、つねに変化するもので、自分の身辺にいくらでもトレーニングの手段は転がっている。よしあしは、その手段を見つけてトレーニングをマメに実行するか老朽化にまかせるかによる。

ここで言うトレーニングとは「符号と道具を使って目と耳と指を同時に働かせる訓練」であり、楽器やタイプライターが挙げられている。

振り返れば、

• 的確な身体操作: 歩行、太極拳、書道……（身体は思っているほど正確に動かせていない）
• 発話と耳のフィードバック: 外国語の発音練習……（自身の発話の意識的矯正）
• 日常的な調理: 計画、段取り、並行作業、および精密な身体操作→高度な脳活動の産物

といった行為が、認知能力の維持に有効だとは、様々に語られている。

ならば、情報の知覚と意思決定を伴うボードゲーム、さらに「指の精密な身体操作」を伴うテレビゲームやラジコン（ドローン）操縦、さらにはキーボード操作を要求されるFPSなども、認知機能の向上に資するのではないだろうか。――もっとも、これは文章作成の本なのだが。

さて、”目と耳と指を同時に働かせる訓練”と言って、諸兄はどんな活動を思い浮かべるだろうか。

それらは現代の視点から見て、認知能力の維持という点においてはともかく、その向上、引いては「頭のよしあし」の改善に通じるのだろうか。あるいは、単なるタスク特化の特異的な習熟にすぎず、脳の構造的なストレッチには何ら寄与していない（全般的な知能向上とは別物である）と解釈すべきだろうか。

スラド諸兄はどう思う？

実際に消したことのある人は限られていますからね。

nice try!

先日読み終わった、板坂元『考える技術・書く技術』に関連する記述があったので情報共有。
ちなみに初版1973年の本です。

頭のよしあしなどというものは、つねに変化するもので、自分の身辺にいくらでもトレーニングの手段は転がっている。よしあしは、その手段を見つけてトレーニングをマメに実行するか老朽化にまかせるかによる。

ここで言うトレーニングとは「符号と道具を使って目と耳と指を同時に働かせる訓練」で、楽器やタイプライターが挙げられています。
現在だと、キーボード操作を伴うFPSか！？

要注意。

消せるのは、自分しか投稿していない間だけ。
管理者、モデレータ以外の投稿があった時点で削除不可。
荒らし、SPAMで削除された投稿があっても削除不可。

iPod touchの終売

これは突き詰めて考えるほどのことではないけれど、

１．毛髪が薄くなっていき、どの段階でシャンプーを諦めるか
２．それでも頭皮を洗うか。洗うとすればシャンプー、洗顔料、石鹸など、どれを使うか
３．洗顔と頭皮洗いに、それらを使い分けるか
４．使い分けるとすれば、どこから顔で、どこから頭皮か

気になり解消したいことの一つですね。

Good morning and happy Tuesday 😊 pic.twitter.com/Ww2jPbB9Bd

— karen still says (@andrews58753) October 6, 2026

もしかして、気付かれてないのではないか？と再掲です。

はてなパークス・フィルタです。

スレッド、コメント表示のフィルタします。
指定キーワードで絞り込み、除外ができます。
ホーム、新着スレッド、タイムライン(β)、マイタイムラインで機能します。

ドラッグして自由な位置に移動、配置できます。

ブックマークレットなのでモバイルでも動作します。

javascript:(async%20function()%7Bvar%20e=%60?t=$%7BDate.now()%7D%60,b=%60https://cdn.jsdelivr.net/gh/espio999/Hatena-PARKS-Filter@main/panel.css$%7Be%7D%60,g=%60https://espio999.github.io/Hatena-PARKS-Filter/panel.html$%7Be%7D%60,a=document.getElementById(%22parks-filter-panel%22);if(a)a.style.display=a.style.display===%22none%22?%22block%22:%22none%22;else%7Bdocument.querySelector(%60link%5Bhref=%22$%7Bb%7D%22%5D%60)%7C%7C(a=document.createElement(%22link%22),a.rel=%22stylesheet%22,a.href=b,document.head.appendChild(a));try%7Blet%20c=await%20fetch(g);if(!c.ok)throw%20Error(%22HTML%5Cu306e%5Cu53d6%5Cu5f97%5Cu306b%5Cu5931%5Cu6557%5Cu3057%5Cu307e%5Cu3057%5Cu305f%22);%0Alet%20h=await%20c.text(),f=document.createElement(%22div%22);f.id=%22parks-filter-panel%22;f.innerHTML=h;document.body.appendChild(f);b=k=%3Enew%20Promise((l,m)=%3E%7Bvar%20d=document.createElement(%22script%22);d.src=%60https://cdn.jsdelivr.net/gh/espio999/Hatena-PARKS-Filter@main/$%7Bk%7D$%7Be%7D%60;d.onload=l;d.onerror=m;document.head.appendChild(d)%7D);await%20b(%22panel_compiled.js%22);await%20b(%22filter_compiled.js%22)%7Dcatch(c)%7Bconsole.error(%22%5Cu30d5%5Cu30a3%5Cu30eb%5Cu30bf%5Cu30fc%5Cu30d1%5Cu30cd%5Cu30eb%5Cu306e%5Cu30ed%5Cu30fc%5Cu30c9%5Cu30a8%5Cu30e9%5Cu30fc:%22,c)%7D%7D%7D)();

「ゾンビランド」観たことないの！？
続編もある、コメディ系ゾンビ映画だよ。
スレチなので、ここで〆。検索してみて！

まさにそういう映画がありました。
そこではCARDIO＝有酸素運動、ですが。

僕の書いてる文書だと「なるべく式だけを使って極端に簡潔に」を意図してます。

これの意図するところも分かるのです。
-1行が完結→（見た目の）ロジックがシンプル
-タイプは少ないほど労力もかからない
-タイプするだけミスが増えるなら、ミスも少ない

などなど
不思議で、かつ困難なのは、短いほど理解も容易いはずですが、そのシンプルな結論に達する経緯が分からないので、それを補う+αが必要なことがあるのですね。
幾らシンプルでも、同じレベルの人でないと理解困難になる。
そして、その1行がいかに短かろうが、その1行にたどり着く労力はまた別…

「Microsoftが作ったから」ってのに物凄い「悪い」バイアスかけるんで~
一方Appleは無批判に受け入れるんですよね(笑)。

90年代～ゼロ年代初頭のMSのビジネス・スタイルも確実に問題ありだったのですが、それはおいても、これの理由の一つとして、技術はともかく、それで作られたモノの出来が…でモノではなく、技術がdisられた一面があると思います。
あまり公然と語られないことですが、この一例がVisual BasicとHyper Cardだったと思うのです。前者をけなす人は多いのですが、後者をけなす人を見たことがありません。
どちらもフォームやボタンにコードを埋め込むようなスタイルでしたが、用途の特性が異なりました。
Hyper Cardはインタラクティブ・アートのようなトイ・プログラムからアプリケーションまで様々ありましたが、VBはほぼ業務システム中心でしたからね。特に後者は落ちたり、遅かったり、文句が集まりやすい環境で運用されていましたから。

BASICは「簡単だ」

もう、今となっては他の言語の特性に慣れてしまったので「簡単」とは言えませんが、私の場合、当時はBASICが唯一だったので、VBですら難解でした。まず、プログラムがどこからスタートするのか分からなかった。
それを教えてくれたのは新卒入社の研修でした。

「手抜きするトコロは徹底的に手抜きする」。そして手抜きをするための努力には手を惜しまない(笑)。

それは三大美徳の一つの実践ですからね。教義に忠実、その実践みたいなものです。無理もない。

当時は「コンパイラ」でさえ信用されなかった(笑)。
その「自動化」をもっとも信用しなかったのが当、伝統的プログラマだったわけで(笑)。

そう、今となっては生成AIが、このコンパイラに相当する役割なはずなのですが、そうはなってませんよね。一周回っているのではなく、螺旋を一回りした感覚です。

「面倒な事は全部コンパイラ任せ」
「富豪の時代」のプログラミング観

これは実感を持って納得ですね。コンパイラがsyntax errorを見つけてくれるレベルから、今や書いてるそばからIDE、エディタでさえ、書き方が古いと指摘するわ、書き方を提案してくれるわ、ブラウザ統合の開発者ツールですらローカルSMLとやり取りできる時代ですからね。

Microsoftってインタプリタ開発のノウハウさえもそもそも~対話的環境」って程の性能はない。

結局MSは、.NET FrameworkでOfficeその他を書き直すことはできず、社内一級言語にRustが加わります。
一方、OSSに取り付き、広げられるだけ手を広げたのですが…インタプリタ系は生き残れませんでした。

• IronPython → 撤退。素のPythonへ転向
• Microsoft R → 撤退。Excel対応頓挫、SQL server対応は2019まで
• VBScript + WSH

Microsoft ASP（JavaならJSP）初期の成果物は、HTMLの間にコードが挿入される、見た目だけはNotebook的な記述で開発されていたのですが、ここから業界が学んだのはMVC的なシステム設計で、インタラクティブな開発スタイルへの展開はありませんでしたね。

イオン行って歩き回ることをイオンウォーキングって呼んでる人もいます

これのことですね。

私もzramとzswapが気になって、メモを取ったことがありました。

ああ、再販本の。

さすが、よくご存知！連載だったのかは分かりませんが、サイエンス社ソフトウェアライブラリ＝３『初めての人のためのLISP』の加筆、補筆版と巻末に掲載されています。

M式が成功してたら見た目はこんなカンジになって

S式、M式的構成を意識したことはないですが、例えで比較されているJavaScript member関数的定義の方が、自然に見えまえすね。括弧以外に、適宜挿入される半角スペースが見た目の窮屈さを緩和することで、見やすさに通じているのではないか、と思います。
Visual Basicはいろいろ言われる言語ですが、その一つが冗長さです。私の場合、自然言語としての英語を読むのに近い感じで「読める」のが気に入っていました。なぜそうなったのかの本旨ではない箇所鴨pしれないが、見た目が生み出す「読み書きしやすさ」という特性もあると思いますよ。

最適化?それは人間の仕事じゃなくってコンパイラの仕事だろ?

なんで人間様が最適化を考えなアカンのだ(怒

これは同感の一方、作業は機械が担当しているものの、そのロジックは誰か（人間）が考えたもの、という意識もあり、この件に限らずですが、このような事柄は突き詰めると、自身のご都合主義に行き着くので…
加えて、「最適」を期待するにしても、先日のgoogle-closure-compilerの話題のように、”理解はできるけども”という最適化もありますし。
最近のAI事例になぞらえれば、事細かな仕様を提示してエージェントが最適な出力を返すか、「全部やって」の一言で済ませて何らかの出力を得る、「人間」にとっての最適＝都合をのすり替え、みたいなこともあるでしょうから。

REPL前提の環境を作れるのが、今の今までEmacsしかなかった

Emacsも名前しか知らないので、事情を知らずに話すのですが、Notebook的なREPLが求められていなかった？あるいは必要がなかった？
例えば、暗黙にコンパイル前提の言語しか使わないという前提があったとか。

過去絵 #ファンアート ✨
乗り物シリーズ#ファッションイラスト #illustration pic.twitter.com/zhEp6QVRT6

— gata (@atelier_gata) August 31, 2026

はてなパークス・フィルタのメジャー・アップデートです。

1. 参加中パークの自動フィルタ生成→「参加中のパーク」に表示されます。
2. 「参加抽出を付与する」チェックをオンにすると、フィルタ入力無しに、自動生成フィルタが適用されます。

マイタイムラインの登場に伴い、フィルタの使い方を再検討しました。
意図しているのは、

• 参加していないパークの情報を取得しやすく、
• その上で、アドホックにフィルタを適用する。

参加中パークの情報だけを参照したければ、フィルタを利用することなく、マイタイムラインを使えばよいです。
タイムライン (β)は、参加していないパークの情報を見るために利用します。
自動生成フィルタだけで「除外」すれば、参加していないパークの情報だけが抽出されます。
その上で、投稿者、コンテキストへ最小限のキーワードを入力してフィルタします。

この機能はホーム、新着スレッドでも機能します。参加中のパークについての注目、新着を絞り込みできます。

「参加抽出を付与する」チェックをオフにすれば、はてなパークス・フィルタは、従前通りにも機能します。
スレッドとタイムラインの違いは、スレッドはツリー、タイムラインはリストという、コメント表示の違いです。単一のスレッドでもリスト表示したければ、

最新のブックマークレットはこちら。

javascript:(async%20function()%7Bvar%20e=%60?t=$%7BDate.now()%7D%60,b=%60https://cdn.jsdelivr.net/gh/espio999/Hatena-PARKS-Filter@main/panel.css$%7Be%7D%60,g=%60https://espio999.github.io/Hatena-PARKS-Filter/panel.html$%7Be%7D%60,a=document.getElementById(%22parks-filter-panel%22);if(a)a.style.display=a.style.display===%22none%22?%22block%22:%22none%22;else%7Bdocument.querySelector(%60link%5Bhref=%22$%7Bb%7D%22%5D%60)%7C%7C(a=document.createElement(%22link%22),a.rel=%22stylesheet%22,a.href=b,document.head.appendChild(a));try%7Blet%20c=await%20fetch(g);if(!c.ok)throw%20Error(%22HTML%5Cu306e%5Cu53d6%5Cu5f97%5Cu306b%5Cu5931%5Cu6557%5Cu3057%5Cu307e%5Cu3057%5Cu305f%22);%0Alet%20h=await%20c.text(),f=document.createElement(%22div%22);f.id=%22parks-filter-panel%22;f.innerHTML=h;document.body.appendChild(f);b=k=%3Enew%20Promise((l,m)=%3E%7Bvar%20d=document.createElement(%22script%22);d.src=%60https://cdn.jsdelivr.net/gh/espio999/Hatena-PARKS-Filter@main/$%7Bk%7D$%7Be%7D%60;d.onload=l;d.onerror=m;document.head.appendChild(d)%7D);await%20b(%22panel_compiled.js%22);await%20b(%22filter_compiled.js%22)%7Dcatch(c)%7Bconsole.error(%22%5Cu30d5%5Cu30a3%5Cu30eb%5Cu30bf%5Cu30fc%5Cu30d1%5Cu30cd%5Cu30eb%5Cu306e%5Cu30ed%5Cu30fc%5Cu30c9%5Cu30a8%5Cu30e9%5Cu30fc:%22,c)%7D%7D%7D)();

最後に、ブックマークレットがブートストラップ式になりました。
基本的に諸機能は全てサーバーから取得しています。
今後のマイナー・アップデートはブックマークレットの更新無しに、自動適用されます。
パネル最下部の日付がヴァージョン番号です。
アップデートされると日付が変わります。

この投稿時点での情報は、はてなパークスが最新。
GitHub、ブログはこれから更新。

こんばんは
以前読みかけて積読へ復帰した『初めての人のためのLISP』をまた開きましたよ。

カッコだらけのS式の見にくさはいつまでたっても一般から問題視され続けた。

むしろそれをLispの本質と考えている。逆に、Lispを使わない人々はS式をLispの最大の欠点だと思っている。

私はLispを使いませんが、最大の欠点というよりも、それがLisp表現の本質的特性、と解釈しています。
本質的に木構造なのだからネストが避けられず、括弧で表現するのだから、括弧も増える。仕方ないですね。
そして、次の前提に基づいて、こう続きます。

• 言語→一次元の文字列
• S式→二次元化→言語の構造化

S式は言語以前の言語、前言語である。

抽象化された内部表現として解釈すれば、その表現を他の言語にも応用し得る、言い換えると、他の言語の抽象概念が前言語としてのS式、ということだと解釈していますが…無理とは言わずとも、その「他の言語」を直接理解する方が、最早、労も少なくて済む時代だと思うのです。

データ作成が簡単に出来る言語

そして書籍の入れ知恵から、おそらくそれはprogram as dataのことを語っているのでしょう？
プログラムとデータが同じ形式で、S式を通じれば、相互に立場を変えることができる、すなわち、

• プログラムとして記述されたS式→処理データ
• データとしてのS式→プログラムとしても解釈可能

一方、関数型プログラミングでは副作用なくデータを複製するので、不要メモリ回収のためにGCも意識する必要がある…ところまでは理解できても、意識することがないんですよね。
ただプログラムを書くだけなら、意識する必要性がないですからね。また話題を広げれば、ロジックのメモリ消費よりも、ローカルLLMやRAM高騰など、桁違いの脅威とも隣り合わせの時代ですから。

もちろん、console.logをまだ扱ってないから、

Notebook形式で段階ごとに実行する前提では、printデバッグは使いませんからね。
R + notebookなど、まさにその感覚です。Notebookを使うと、自ずと順番に具合を見ながら書き上げるので、全体を動かしながらprintデバッグするスタイルにはならないんですよね。

なんかこっちの方が流行ってるみたいで(笑)。

書き方が古い、とGeminiなどが指摘するとき、代替案として提示するのがそのスタイルですね。

「津波」だよ。

地震によって生じる津波：seismic wave
潮の満ち引きによって生じる波：tidal wave

Tsunami

• 地震によって生じる以外（例：海底火山、隕石衝突）の津波も含む、
• しかしtidal waveは含まない。

下記1.3を参照

寿司や天ぷらのように、日本語が英語として定着したのとは違うのです。

pic.twitter.com/3O88qo4Adz

— Black Lodge Cult (@BlackLCult) September 21, 2026

Pythonの内包表記は、表記自体を書き下し的に解釈せず、例えば慣用句の如く、ある程度定型的な表現として解釈できるようになるかもしれません。
一方、Lispの様に括弧が深くネストするのは、慣れれば読める、というのも一理ありますが、例えばif文やfor文の多重ネストのように、認知負荷を無用に高めている一面もあると思いますよ。
あるいは、それすら慣熟すれば慣用句的に解釈できるようになる？

その経験で、関数型言語にも抵抗がないのかな?

私の場合、これまでの経験故、言語が違えば、書き方も違うのは当たり前、という意識が最初にあります。ある言語の書き方がOOP、関数型のいずれにせよ、その書き方は指向性の反映ではなくて、言語特有の特性、そういう書き方をする言語、という意識があるのです。それ故、OOPも関数型も後付けの理屈みたいなもの。

数年前にRをやりました。それとは別に、関数型の本を読んでも理屈を理解できませんでしたが、文中にR的な記法を見つけ、すでにRで関数型をやっていたことに気づいた、ということもありました。
SML#のYouTubeを見て、話していることは分かるよ、という程度に馴染みはありますが、実際のところ理解はしてないのです。

年初からJavaScriptに触れる機会が増えました。生成AIに書き方が古い、と指摘されて以来、関数型の書き方を取り入れる機会も増えてきました。

残念ながら、今「Smalltalkを学ぼう」って言ってもマトモな本なんざないでしょ。

確かに書籍の有無による影響は大きいですね。
最近は開発環境やコンパイラが、書き方が古い、と指摘してくれるので、最新版を反映した書籍でなくとも、あるいは初版以降の出版がない古い本でさえ、あるだけ学習しやすいでしょうね。
または大学ゼミのwebサイト、特に学生向けに講義資料が公開しているところから拝借するか、ですね。
Rとかね。

去年はIntel Clear Linux、
今年はDeno、
最近ツイてない。

汁をあえて多めに残して、ごはんやうどんにもかけちゃってください！

エビチリ同様、パスタにもイイよ。

『ガールズ＆パンツァー 最終章』第5話

あくまで個人的な感想ですが、

第4話は、訳が分からないまま勝った、いわゆるレバガチャで勝った、的なアトラクション・ムービーぽさが目立ち、相対的に5話が良く見えます。
4DXを意識してるんだろうな、と思わせる映像が多めでしたが、 第4話よりは断然良かった。

しかし”劇場版”は超えられてない。
第6話が劇場版相当になるのか、さらにその後、卒業生チーム対在校生選抜みたいなイベント試合をアンコール劇場版的にやって盛り上げるんだろうか。

DenoがCloudflareへ。
肝心なのはここ。

We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.

つまるところDeno runtimeの月次リリース、セキュリティ・アップデートは来年いっぱいで終了。
その後オープンソースとして維持されるものの、開発はcontributer次第。

木须柿子と西红柿炒鸡蛋ってちょっと違う料理かも

肉じゃがにも汁気のないもの、あるものがあるように、ここは料理人次第です。
加えて、日本だけなく、韓国でも料理されています。
中国語名でYouTubeを検索すると一目瞭然に分かりやすいです。

スレチなので、ここで終わります。
パーク「中華料理」もよろしく。

pic.twitter.com/wbXK1AneUO

— 三島芳治 (@kiroku0000) October 4, 2026

知ってる知らないに関わらず、電文の報告や何かのコピペでなく、
自分で考えて話をするのは良いじゃない👍

でも、もうおやすみです。