This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
ActivityPub/ActivityStreamsの文書がわけわからんのって私だけじゃなかったのか
Activity Streams 2.0
https://www.w3.org/TR/activitystreams-core/#collections
> The items within a `Collection` can be ordered or unordered. The `OrderedCollection` type MAY be used to identify a Collection whose items are always ordered. In the JSON serialization, the unordered items of a Collection are represented using the `items` property while ordered items are represented using the `orderedItems` property.
それは Vocabulary でなく Streams の方で言及されている (なんじゃこのガバ規格は)
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
マジで ActivityStreams は悪い意味での web 界隈のガバさを十全に引き継いでおり、まあ静的型付き言語マンとしては最悪
静的型付けで扱うのがしんどい = プログラムで扱いにくい では???
つまり死
RE: https://mstdn.maud.io/users/kb10uy/statuses/105702436331495849
そもそも JSON-LD や類似形式がプログラムで扱いやすいわけがない (まあ ActivityPub は名目上は JSON-LD 処理系がなくても使えることになっているけど……)
TypeScript の型が複雑すぎるっていう例の記事、正直自業自得やぞ以外にかける言葉がない
コンパイルが遅くてプロジェクトから追放された静的型付き言語。今さら既存コードに型を付けてくれと言われてももう遅い #適当
だいたい gradual typing なんてただでさえ普通の静的型システムより複雑なのに、静的型システムを満足に扱えない人が活用できるかどうにも疑問
外部データは信用できないから型は意味ないみたいな言説、稀に見るんだけど本当によくわからんのよな……
検査済かどうかを型で区別するのであって、信用できないなら信用できる型とは別で用意して失敗しうる型変換を定義すればよかろうに
まあインタプリタは外部からヌッとプログラムを差し込むのが本当に楽で (たとえば PolicyKit で ECMAScript を使えるみたいな話)、あれをコンパイル型の言語でやろうとすると ABI をガッツリ固定する必要があるので、進化を遅くするか long term support を用意するかという代償が発生してしまう
Rust はまだまだ「みんな欲しがってて実装も進んでいるけど完成まで長そう」みたいな機能がかなり多いので、仮にここで機能を固定して国際標準にできたとしても「標準には欲しい機能がない」みたいな話になりそう
そもそも言語仕様も処理系実装も、基本的に委員会とかでなくコミュニティベースだからねぇ。まあその辺りは私が知らんだけで他に前例はあるのかもしれないけど
This account is not set to public on notestock.
開発側とか規格策定側に入るの楽しいけど、言及できる範囲が狭まるのがつらいときもあるよねー。正解を知らない立場であればこそ噂話が自由にできる。
/* Undocumented */
/* Don't call this function */
This account is not set to public on notestock.
__SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED
そういえばと思って確認したら、玄関前にクソでかいダンボールが置いてあってワロてる
下手したらこれ1日以上放置されてたな……
インターホンの電源を落としているのと、ドアノック無しで置き配になりがちな傾向があるため
よくわからないままよくわからない事言うけど、オブジェクト指向な方向の言語なら静的な型付けでもこんな感じのデータ扱うの別に困難では無くない?><
継承をフル活用すればマシになるのは間違いないんだけど、たとえば AcitivityStreams では普通に菱形継承的なものも表現されており、ハイ
あと「String または Link オブジェクトまたは Object オブジェクトまたはそれらの混合配列」みたいなクソみてえな型をネイティブに持っていくのはどう足掻いてもつらい
どこかの部分で表記が煩雑になるか実行時オーバーヘッドが発生するか、もしくは両方か、選ぶしかない
やればできるのは自明なのでどうでもよくて、向いているか向いていないか、もっと言うと実装の読み書きと利用が快適で無駄がないか否かの話をしています
実装すればできるのは本当にその通りだし実際そうする人々もいるんだけど、完全に個人的な観点で趣味としての話をするなら、そんな気合が必要になる時点で敗北ですよ (メンテしたくない)
……まあ FBX で似たようなことやってつらい目に遭ったわけですが
fbxcel_dom::v7400::object - Rust
https://docs.rs/fbxcel-dom/0.0.6/fbxcel_dom/v7400/object/index.html
これとか本当に実装していて嫌な気持ちになったからね……
それでも FBX は (動的拡張が許されているにせよ!) 型が無数にあるだけで一応型っぽいのは付いているのでマシなんだよなぁ。
ウェッビ系の「必要に応じてフィールドが動的に増えます」みたいなのは本当の地獄
https://github.com/lo48576/fbx-viewer/blob/9af8805557d19c18cc41ee6d083b6520f6ca9225/src/fbx/v7400.rs
クッソ面倒だけどボイラープレートを沢山用意したおかげで一応使い物になる API は用意できたし、まあ良い経験にはなったね。
メンテしたくはないが。
問題解決を試みるプログラマが複雑な問題を抽象化したうえで不可避な本質的複雑さに適切に対処する必要があるというのは真実なんだけど。
同時に、データ構造や制約を定義する人々は本質的でない複雑さを排除する責務と能力を第一に負うのであって、そこで「†オブジェクト指向最高ォ〜! クラスの継承に全ベットします!」みたいなことをやってしまうのはあまり良質な判断ではないでしょう、と思ってしまうわけです
あとはもっと純粋に、規格を書くならちゃんと構造をフォーマルに定義してくれとか、そういうテクニカルライティングレベルの話もあるけど。
ぐちゃっとしそうではあるし程度の違いはあれだけど、なかに何が入るんだかわかんないし現時点では想定されてない新しいものが入るかも知れず、それは配列かもしれないし子をもつかもしれないみたいな状況、GUIツールキットや簡素なHTMLレンダリングエンジンを作る場面ではそこそこ出てくる場面では?><
これは特定の具体的フォーマットについての言及ではない (しかしありがちではある) んだけど、「文字列または文字列の配列」を見て「これは本質的には文字列の配列だな」と思えるか、みたいな話なわけですよ
単なる「文字列の配列」を敢えてもっと複雑な定義で表現するのであれば、そうするだけの根拠と利益が説明できるべきなのであって
まあ「人間が書きやすいから」みたいな話もあるけど、だったらそれを正規化するアルゴリズムくらい定義すべきなんじゃないのみたいな話よ
そもそも継承とかいうのだいぶ欠陥が洗い出されてきたので、今更そんな構造にプライマリに依存しないでほしいというのもある
ていうか、型がツリーになる構造では無くどういう風にGUIツールキットを作る場合ってどうなるのか普通に謎><
そもそも「操作の一部を共有する」と「内部データの一部を共有する」を区別できない時点でガバいというのはよく言われている話
あと継承の木構造が一方向なのに対して共変・反変の2種類の包含関係をうまく扱えますかとか
あるいはそうでなくとも、 HTML のタグなんかはタグ種そのものは木構造で定義されていない (いや厳密にはそうとも言い切れないところはあるかもだけど……)
例えばWindowsのウィンドウシステムではボタンもテキスト入力ボックスもウィンドウじゃん?><
見かけ上ツリー状にしたりインタフェース(正しい用語わからない)のような仕組み自体を否定したら「ボタンはウィンドウであるべきではない」みたいな事になるじゃん?><
でも実際にはGUI部品はGUI部品として振る舞って欲しいし、一律で扱える方が都合がいいじゃん?><
「ボタンがウィンドウであるべきでない」と「ボタンもウィンドウも GUI 部品として振る舞うべき」は普通に両立しますよね。
レガシー言語ではそれを継承 (もっと言えば仮想関数テーブル) でしか表現できなかっただけで。
ボタンやテキスト入力ボックスがウィンドウであるのは完全に GUI toolkit の設計思想の問題であって、そこに必然性はない
Windowsでの用語そのまんま使っちゃったからあれだけど、オレンジのその文脈上は GUI部品=ウィンドウ><
(Windowsの世界ではGUI部品の事をウィンドウって言う><(少なくともプログラミングWindows第5版辺りの時期の用語では))
まあそれも結局「特定インターフェースを持っている」とか「型消去できる」とかの性質が求められていて継承がその実装手段の一例であるに過ぎなくて、他の言語でそのように実装する必然性があるわけではないと思う
それでももっと昔の記述に比べれば nullability みたいなのが明示されるようになったりとか、多少は改善されたのよね……
限りなくGUI部品の種類が限られるのであれば、バラバラ個別対応でも成り立つかもだけど、種類が多かったり増えたりすればすぐにスパゲティ化するかも><
「スパゲティ化させないために継承でコードを共有する」が本当に正しいのか疑問視されている、と主張したい
「○○である」という人間向けの意味付けも引き継ぐし、内部的に持っているフィールドも全て引き継ぐし、インターフェースも (大雑把に公開・非公開を調整できるとはいえ) 引き継ぐし。
その辺り別々に扱って細かく制御できる方が仕組みとして上等じゃないですか
HTML で ul と ol の DOM が必ずしも共通の基底「リスト」型を持っている必要はない。 ul と ol に共通のインターフェースを持たせたいなら、継承がなくとも多重定義なり (Rust の用語で言う) trait 実装を与えるなり和型を用意するなりで可能なわけで
継承でアになる例、ベースクラスからボタンを継承で作った後に「クリックできない以外にも挙動の違いがあるボタン」とかどうすんねんみたいな
「中身がスクロールできるボタン」とかどうしたいですか、みたいなお気持ちは実際ある (まあそんなものを作ることが望ましいかは別の話)
できるものを理由付けして禁じていくのは、単に実装の問題でできないだけなのとではだいぶ違う
修論はもちろん提出後に誤記や抜けを発見しました (電子メール提出だったのでお詫びするとともに訂正して再提出した)
ボタンから継承して変なボタン(?)作るの、DelphiのVCLの世界では普通の事だったので、逆に何が不思議なのかわからない><
(あやふやだけどたしかより正確には、直接標準のボタンクラスからどうこうするんじゃなく、VCLは「標準のボタン」クラスの親に各々好きにボタン作る為のボタン抽象クラスみたいなのがあって、それを元に作る感じの構造だったような記憶ある><(あやふや))
やりたいことはわかるし不思議ではないけど、単にそれ以外の選択肢があるし継承が最適解か疑問視されているというだけの話です
gtk::Box - Rust
https://docs.rs/gtk/0.9.2/gtk/struct.Box.html#trait-implementations
この
impl IsA<Foo> for Bar
の山をな……
C (w/ OOP) や C++ と Rust のギャップについて考える度にこれを思い出すんだよな
もちろん言語ネイティブで idiomatic なインターフェースを注意深く設計すれば使いやすいものはできるのだろうけど、それが FFI boundary を越えて使いやすいものであるかは全く別の話になってくるので、その辺りもう一段階抽象が欲しいなぁの気持ちがある
型理論は湧き出るモチベーションなかったら本当に死んでたと思う (まあおかげで幼稚園児みたいな研究になったけど (?))
ポヨグヤミン言語系の研究、マジで他人に説明するときどうすればいいんだ……という感じなんだよな
「型ってなんですか」とか言われたらもう何もかもを諦めてお気持ちだけで闘うしかない
エーアイとか制御とかの人はその辺りかなり説明しやすそうだなぁと根拠もなく思っていた
人生、なぜか 3D モデルローダを自前で実装することになりがちなんだよな
こんだけ人類いるんだからもうちょっとどうにかなるはずなんだけど、気付くと何故か自分で書いている
FBX を例にとるなら「(Maya|Blender) でエクスポートして (Unity|Unreal Engine) でインポートする」だけでもそれはそれは楽しい挙動の違いが見られますよ(たのしくない)
そもそも近現代の GUI toolkit は関数ポインタと引数ポインタなどを利用してウィジェットが発するイベントを特定の関数呼び出しにフックするみたいな形で実装されることも多くて、そのスタイルだと継承の木構造がどうとかは割とどうでもいい。なぜなら挙動はイベントと関数 (or 匿名関数) の紐付けによって定義されるものであって、型に紐付いた関数の実装によって定義されるものではなくなるから
もちろんそのイベント (特定フレームワークのように slot と呼んでてもいいけど) をどうウィジェットから提供するかはいろいろな設計が考えられるし、そこでやっぱり継承を使おうという判断も不可能ではないけど、それにメリットがあるかというとそうでもないはず
下手に既存の中間フォーマット挟むぐらいなら独自形式と SDK をセットで提供するというのは妥当だしゲーム開発系だとだいたいこれだと思うんだよな
.blend はアプリケーション固有の形式なので Blender 以外のアプリケーションから使うべきでないみたいな警告をどこかで読んだような記憶がある
だからこそ「交換用の中間形式」としての COLLADA が発明されたわけだが、 SCEェ……
COLLADA Overview - The Khronos Group Inc
https://www.khronos.org/collada/
結局 2008-04 にリリースされた COLLADA 1.5.0 で止まってるな
それでも COLLADA の敷居が高いの、やっぱり情報を失わない代償としてデータ形式がハチャメチャ面倒になってしまったというのはある
エクスポート、中間形式になるときにどのように情報が失われどのように補完されるかというのを考えるのが最もしんどいのでこれを最小化したい
Maya はその問題に対して「Maya と UE を両方起動しておいて Maya から専用のエクスポートコマンドを叩くと直で UE 側に反映される」みたいなウルトラ密結合ソリューションを提供していた記憶がある
COLLADA 処理系の実装を試みたことがあるオタクとしてもな (何故か XML のパースから実装してた) (断念した (かわいい女の子のモデルがほとんどなかったので))
あのときはコンパイル時 CRC32 計算とかマクロによる黒魔術メタプログラミングとかいろいろ遊んでいて楽しかった
GTK でのイベントハンドラ的なやつの実装の成果として libsigc++ というライブラリがあって、これなかなか面白かった。まあ modern C++ 時代から見るとそこは……というのはあるだろうけど
libsigc++
https://developer.gnome.org/libsigc++-tutorial/stable/
Unable to import fbx from blender 2.79/2.8 · Issue #2 · lo48576/fbxcel · GitHub
https://github.com/lo48576/fbxcel/issues/2
⚓ T71729 Lack of null record on Properties70 node by FBX Exporter
https://developer.blender.org/T71729
思い出してしまった
ちなみにこの2019年11月という日付ですが、ワイの卒業が2020年3月であることを考慮すると……
This account is not set to public on notestock.
ピッポパプの API って GraphQL じゃなかったっけ。簡単なクエリなら curl とその他コマンドでどうにかできそうだけど、ちゃんとクエリ発行数で最適化しようとすると簡単にはいかなそう
This account is not set to public on notestock.
This account is not set to public on notestock.
ファイザーのワクチン 接種6回の予定も採取は5回分のみ 厚労省 | NHK政治マガジン
https://www.nhk.or.jp/politics/articles/statement/53415.html
「口座残高足りなくてクレカの引き落とし失敗したで」とメールが来たので昼に2万円振り込んだつもりだったんだけど、どうやらミスって2千円だけ振り込んでいたらしい……
This account is not set to public on notestock.
This account is not set to public on notestock.
https://mathtod.online/@cmplstofB/105707097258384534
土地でなく「地名を訪れる」と表現しているようなものか。たしかに違和感あるな
「{{特定の URL}} を訪れる」は「{{特定の地名}} を訪れる」と対応するので、まあおかしくはない
「余人をもって代えがたい」を理由に調整役の老人が跋扈するという(https://www.itmedia.co.jp/business/articles/2102/09/news046_4.html )ので,「おじさんは「誰に情報を渡して、誰に情報を渡さないか」というところで仕事をコントロールしている」という数年前の記事(https://xtech.nikkei.com/atcl/nxt/column/18/00087/00031/ と https://ix-careercompass.jp/article/982/)の話を思い出した
https://gnosia.info/@ncrt035/103954508577025724
なるほどシステムのアイテー化が反対されるわけだ。情報の共有と可視化が強力で優位性を奪われるから。
これオブ・ザ・イヤー候補だわ…
「あまり世代間論争にはしたくないのですが、40代以上の世代には「コミュニケーション=利害調整」と捉える人が多いですね。情報の流れをコントロールして、組織を円滑に回そうとする。その結果、意図的に情報を隠したり、情報格差をつくったりします。つまりコミュニケーションは人心掌握、説得、コントロールの術であって、正しい情報を伝えることがゴールではないのです。
ですが、それ以下の若い世代では「コミュニケーション=課題解決」と捉えている人が多い。今は、一人では解決できない、複雑で、答えのない問題を解かないといけない場面が多くあります。課題解決につながる正しい情報が何かは誰にも分からなくて、全部が重要だし、全部が重要じゃないかもしれない。だからこそ、「課題解決のためには情報を共有すべき」という感覚を、彼らは持っているように思います。」
This account is not set to public on notestock.
https://mstdn.jp/@humanity/105707203113374114
「差別に賛成したら黒人になるんですか?」と書きそうになったけどあまりにアカンのでやめた
まあ真面目な話をすると「名誉男性」なるおもしろワードが特定界隈で使われていたりするわけで、過激派の界隈は本当にわからん……
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
公知になった後も再発明されつづける「独自暗号」もあるんですよ!!(?)
数学含め科学では過去に発見された法則がしばしば「再発見」されていたりするので、まあそういう意味では長期的なスケールで見ればというのはある
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
Making WebGL Dance
http://acko.net/files/fullfrontal/fullfrontal/webglmath/online.html
これ全人類に一度は見てほしいスライド (?) 資料