このアカウントは、notestockで公開設定になっていません。
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿 
このアカウントは、notestockで公開設定になっていません。
https://mastodon.cardina1.red/@lo48576/113084191914250734
ハンロンの剃刀についてはこの気持ちしかない
コンシューマ向けのｴｰｱｲってやつびっくりするほど魅力を感じなくて何なんだろうと思っていたけど、たぶん「ガチャガチャやることで特定実装に最適化する行い」だからかもしれない
「こういう原理と思想で作られているから、こうすれば最高の結果になるはず→確かになりました」みたいな仮説で先にある程度わかるものではなくて「いろいろやってみたところ、これとあれがいけました」みたいな数撃ちゃ当たる系のものにしか見えないというか。
しかも目的も結果として得られる知恵もべつに普遍的なものではなく特定バージョンの特定実装に特化していて、しかも対象実装がプロプライエタリでブラックボックスで永続的でないところも、魅力を感じる要素が欠片もなさすぎて逆にすごい
それで言うと特定のゲームのおもしろバグを見つけるのとかも似たようなものだと思うんだけど、あっちは面白かったりするんだよな。何故なのか
ゲームのバグは再現性を高めようとするし、バグの原理と機序の記述も試みられているし、実装が (オンライン専用でなければ) 手元に保存できるから？
ゲームはそのものがコンテンツだから古い版でも価値が保存されているという違いもあるか
このアカウントは、notestockで公開設定になっていません。
何らかの知恵をエキスパートシステムへと「コンパイル」するような試みとかは激アツだと思う、知らんけど
まあｼｬｶｲと人間ってやつだいたい私の嫌いなものでできているので、そういう意味ではいつも通りのｼｬｶｲが相変わらずそのままの特質でそこにあるなぁという感想ではある
https://mastodon.cardina1.red/@lo48576/102607389891249288
エキスパートシステムのいい話です
このアカウントは、notestockで公開設定になっていません。
（一瞬普通に読み流しそうになってしまったけど、いや、それよりも今からでもアドバイザリを公開するべきなのでは）
このアカウントは、notestockで公開設定になっていません。
考えてみると、楽曲を扱う実装や規格においては文書ほどストリームをヒエラルキー的に整理する発想が浸透していない
track gain と album gain もアルバム単位までの2階層だし
offensive な言及をしそうになったが括約筋で耐えた
現状のリスクを内心ではわかっているものの対抗する術を持たない (あるいは手段があってもリソースを確保できない) がゆえに目を逸らし、むしろ問題を指摘する人をリスクと同じ側に置いて責めたてるみたいなの、めちゃくちゃ人間的だなと思う
まあ人間らしいからといって味方したいかというのは全く別の話ですが
このアカウントは、notestockで公開設定になっていません。
まさにそういうときのための自由ソフトウェア思想なのだから、ﾊﾟｿｶﾀのオタクばかりでなくむしろ自分でリバースエンジニアリングできない一般ユーザこそそういったライセンスやベンダーロックインには敏感であるべきなはずなんだけど、どうにもねぇ
対抗馬欲しいよなあと思いながら、現代的なアーキテクトで作ろうとすると専門性が高すぎてとてもその辺から出てくるような代物じゃないし、出てもコミュニティが育つかは別だから辛すぎて、何も口出しできないんだよな〜
そこで日和ると「黒船」と呼ばれる概念に全てを壊されるというのがお決まりのパターンですね……
結局、足掻くのかそれとも破滅を粛々と受け入れて日々を過ごすのかという選択の話でしかないといえばそうなのかもしれないけど (どうでもいい)
ﾋｭｰﾏﾇ・ﾄﾞﾗﾏ本当にどうでもいい。どうあっても決断と行動に対して状況に応じて結果があるという程度の抽象化に落ち着くため
マイグレーションをリポジトリに積み上げることで DB スキーマを管理する手法、理想的に運用されたなら複数バージョンを一気に飛ばしても問題なくマイグレーションできるはずなのに現実には必ずしもそうではないという汚さも気になるし、それはそれとして DB スキーマ以外に「設定ファイル」でも同様の手法が使えるはずなのではないかという全く別のアイデアも気になっている (手は出していない)
設定ファイルのスキーマねえ…… (人間に読み書きさせる設定ファイルを JSON で書くのは虐待 (?))
任意のバージョンからの差分が欲しいという要件は確かにあり、それはそれとして最新のバージョンのスキーマを一発で知りたいしスキーマに対して single source of truth が欲しいという要件もあり、これらを合わせると「現在から過去へ遡る方向で (一方向あるいは両方向の) 差分を積み上げる」あたりが妥当なのではないかという気はしないでもない。
ところで現在のスキーマのスナップショットは空スキーマからの差分積み上げで再現できるはずだから「一発でわかる」ようにスナップショットを含める時点で既に single source of truth になってない……
エディタでリポジトリを開くだけで全てがわかるように、みたいな前提がもう駄目ということなんだろうなぁ。諸々のファイルはツールで生成して、それらを読める前提で事を進めるべきと。
でもそうなると read only でリポジトリを閲覧するような状況でつらくなるんだよなぁ
このアカウントは、notestockで公開設定になっていません。
未だにデフォルトの結合 (空白) が子か子孫か覚えられず都度ググってる
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
それはそうといえばそれはそうなんだが、ヤバさの本質は「空白が構文を整理する何かではなくひとつの独立した演算子である (ただし他の演算子 (> など) がある場合を除く)」というハチャメチャ構文にある
セレクタの結合子として // と /\s+/ と /\s*>\s*/ を使い分けるというのは、 sane な文法には思えない
このアカウントは、notestockで公開設定になっていません。
「せや！ 子孫結合はよく書くから楽に書けるようにしてやろう！」みたいな大いなるお世話をしないよう、構文設計者は自らを強く戒めるべき。「書くことが少なくて書きやすい」は「読みづらく一貫しない文法」の別表現だから
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
詳細度が階層化された数値列でなくスカラーだからオーバーフローさせられる話、あまりにもカスで好き (きらい)
詳細度 - CSS: カスケーディングスタイルシート | MDN
https://developer.mozilla.org/ja/docs/Web/CSS/CSS_cascade/Specificity
あれ、ベクタ使ってるっぽくなってるな。どこかのバージョンで整理されたのか？
What is the rule behind "CSS 256 Classes Override One ID"? - Stack Overflow
https://stackoverflow.com/questions/12002845/what-is-the-rule-behind-css-256-classes-override-one-id
まさかとは思うけど、ベクタ表現をそのまま整数として扱おうとしてオーバーフローする実装があるみたいな話だったりする？wwww
0-0-1 が 1 で 0-1-0 が 256 で 1-0-0 が 65536 になってるみたいな……
Ryan Seddon | Extreme specificity overriding a CSS ID with 256 chained Classes
https://ryanseddon.com/css/extreme-specificity/
本当にそうっぽいwwwwww
なお悪いわという気持ちと、現実的な妥協点として理解はできるという気持ちと……
感覚的には空白はあくまでも区切り文字で、p.hogeはクラス名が必ず.で始まることに依拠した特殊な解釈をされる1トークンだと思っている
擬似セレクタとかの存在を考慮すると、空白で区切られた単位のセレクタも内部的に構想を持つ (しかもネストされうる) ので、やはりあれは構文木におけるノードではあるけどリーフではないと思う
いやネストについては :has() が悪い説はあるが、それを抜きにしても [attr op expr] タイプのセレクタもあるので何にせよトークン扱いは少々無理がある
Chinese PCB manufacturer、みんなスパムメールで営業しているものだと思っていたけどスパムメール以外の手段も使うんだ (?)
ガチモンのフィッシングメール以外のスパムに占める Chinese PCB manufacturer の割合は異常だった。アンチスパムのフィルタ弄りまくった結果近頃は受信しなくなったけど
このアカウントは、notestockで公開設定になっていません。
任意の銭ゲバ宗教や洗脳宗教への当たりを強くすれば一貫した態度といえる (そうか？)
このアカウントは、notestockで公開設定になっていません。
そういう側面もあるけど、整形用の空白も同じ部分に存在しているという点で一線を画している
foo>bar ではなく foo > bar でもいいのに foo.cls を foo .cls にしてはいけないとか、同じセレクタ内でも [attr="foo"] は [attr = "foo"] でもいいとか。
もちろん特定のノード内でサブの文法があって〜という形で構文自体は真っ当に定義できるはずだけど、人間にアピールしてくる空白の用途というか意図が一貫していない
このアカウントは、notestockで公開設定になっていません。
空白を別の文字で代替する用途はその文字が概ね識別子の一部として使えるという点で文字の振る舞いが安定しているので (たとえば C でアンダースコアを見て演算子だと思う人はまずいない)
逆にそこが一貫していない文法があったら CSS と同様の気持ち悪さを感じると思う
「特定部分でだけサブ文法が存在する」みたいなのが良くないという気持ちは結構あるな。
たとえば markdown の行頭でだけエスケープが必要な文字とか。
もちろんそれ (行頭以外でのエスケープ省略許容) によって「書きやすく」なるのかもしれないけど、そういうイレギュラー文法を「書きやすさ」で正当化することに疑わしさを強く感じている
たとえば XML なんかは (CDATA section という切り札はあるけど) 属性内でもテキストノードでも DTD 内でも「&」が entity reference や character reference を示唆していることが明らかかつ一貫していて、そういう一貫性こそが読みやすく扱いやすい文法であると個人的に思っている
このアカウントは、notestockで公開設定になっていません。
その言い方に合わせるなら、「構文解析器に食わせる前に破棄できるトークンが少ない (あるいは不規則である) のが不満」と言うべきか。
字句解析器が空白でトークンを切って構文解析器が空白トークンを無視する、みたいなのは字句解析器が文法に関係なく (まあ "" 内とかではモード変えるだろうけど) 空白ノードを切れるし構文解析器にそれを渡さないことすらできるけど、「特定の文脈でだけ空白が無視されない」は構文解析器が空白ノードを常に受け取って明示的に無視しないといけないから、「早い段階で無視できる部分」が減ってしまいパースするときの負担が大きくなる
トークンの間引きを構文解析の遅い段階まで認めない (あるいは別の表現をすれば、文脈に依存する複雑な条件を課す) というのは、早い段階で認める (文脈に依存しない簡潔な条件を課す) 文法よりも、客観的に “複雑” であるといえると思う (少なくともそういう次元が文法の複雑性に存在する/定義できると思う)
字句解析と構文解析という機構を内面化しているといえばそうなのだろうけど、この文脈においてその価値は「無視できるパーツが解釈の早い段階で明らかになる」という性質にあり、たぶん字句解析と構文解析で納得しやすいというのはその性質から自然と生えてくるボーナスなのではないかという気がする (確証はない)
たとえば行頭、たとえばコードブロックの中、たとえば特定のコマンド実行後、そのような追跡の必要のある「条件」が解釈における後ろの方の段階まで引っ張られれば引っ張られるほど、一貫性が弱くなっていき、同時に認知への負荷が高くなる。
ふーむ、つまり私は「文法が簡潔で一貫していること」が「意味に関係ない部分を認識から切り離す工程の負荷が小さいこと」と同義であると言いたかったわけか。なるほどね。
ちょっとすっきりした (それはそれとして CSS は嫌だが)
"redesign" が脳内で red-e-sign に分解されて esign って何……となった (電子署名？)
消費者庁、「パソコン工房」に措置命令 「今なら」のはずがその後も特典変わらず
https://www.itmedia.co.jp/news/articles/2503/27/news228.html
このアカウントは、notestockで公開設定になっていません。
前株と後株が共存できるの、そうできる理屈はわかるとしても制度設計として本当にそうするのはあまり納得いかない
このアカウントは、notestockで公開設定になっていません。
旧Twitterだと日本語でElmに言及するとElmユーザのコミュニティの人たちがエゴサ（誤用）でやって来て怖いけど、Fediverseなら来る気配がないのでブリッジさえ切っておけば安心（？）
べつにﾍﾃﾞﾊﾞｰｽもｺﾞｯｺﾖ検索とかに引っかかってしまえば大差ないからなぁ、埋もれやすいだけで。まあ埋もれやすいことこそが重要という話もあるけど
唐突かつ得るもののないリプライは「何やお前」の精神で無視ないしブロックする (している)
