そういえばAdaの例外ってどうなってるんだろう？＞＜
-- 本の虫: C++に提案されている静的例外 https://cpplover.blogspot.com/2018/07/c.html
そういえばAdaの例外ってどうなってるんだろう？＞＜
-- 本の虫: C++に提案されている静的例外 https://cpplover.blogspot.com/2018/07/c.html
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
clamp - OpenGL 4 Reference Pages
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/clamp.xhtml
GLSL にはある(一般の言語ではないけどw)
そういえば、なんでmathって名前がついてるような数学な標準ライブラリ、どの言語のでもほとんど(？)、maxとminはあっても、最大値と最小値を両方指定してその範囲にカットする(？)って無いっぽいんだろう？＞＜
特にGUIでは使う場面が結構あると思うんだけど・・・＞＜
壊れてるかも許容型？＞＜(null許容なるべくやめようって潮流のなかでは流行らなそう＞＜；)
それオレンジの最初の「壊れてるかも」モデルに壊れてるかもインタフェースを標準化して追加したらほぼそれのような・・・＞＜(nullは「壊れてる」ではないけど、null流用で言うならnull許容型っぽさ・・・＞＜)
そもそも「もしかして壊れてる○○型」と「壊れてない○○型」を両方作るのって明らかに重複多くて無駄なので、
「○○型」と「もしかして壊れてる表明」だけ用意して、「もしかして壊れてる<○○>」を使うと、新たな型をいちいち名付けたり定義せず使える
インタフェースの仕組みはそれはそれで静的だけど、ダックタイピングっぽさの名前つき版(名前つきなんだから全く逆の発想だけど)っぽさがアレだけど＞＜；(でも便利＞＜；)
話が無限に広がっちゃうけど、継承がないと、さっきからの例のような、壊れれない版と壊れてる版を作る時にも、ツリー状に関係を表現できなさそうで謎＞＜；
壊れてない型を継承して、壊れてるインタフェースをくっつけた壊れてる型を作れば、「これって壊れてる型？(＝壊れてるインタフェース持ってる？)」って型チェックもできるかも・・・＞＜
(限定的な)多重継承できる言語、例えばC# (のインタフェース)ならば、IBroken(？＞＜；)みたいなインタフェースを標準化して、壊れてる版はそれを混ぜた派生クラスを作ればエレガント・・・？＞＜
そうなったとき、一番基本になる型は「必ず○○である」という制約を表明できる型であって、そういうものを作る。これを組み合わせて制約を弱くすることは簡単だし
型でも同じようなことをやってほしくて、「なんでも単一の型を用意してドキュメントで補足するよりも、 Result とか Option とかその他『意味だけを表明する容れ物』を利用して意図する型を作る方がよい、という感じです
たとえば「なんでも goto を使うより while や for や iterator を」とか「なんでも再帰を使うより map や filter や fold を」みたいなのと同じで、高階のものとパラメータを組み合わせることで制約を人間にとってわかりやすく、かつ機械が理解可能な状態で表現するということが可能になります
ていうかRustとか的発想(？)で言うならば、「なんとか型」と「なんとかが壊れてる型」を作って、後始末に必要なものはどちらにも持たせるってすれば、オレンジの発想に近い？＞＜
「壊れてるかもしれない」ってモデル、かなり楽な考えだと思うんだけど＞＜；
URLだとあれだけど、URLの型の変数を作ろうとして準備してしまった何らかのリソースを失敗した結果好きな順番(環境上の都合に適した順番)で後始末したいって発想がある＞＜；(小さなもの(？)なら例外の所から逆に破棄していけばなんとかなるけど、そうじゃない何らかのハードウェア上の都合とかがある場合に・・・＞＜)
Rust の話になってしまうけど、エラーも結局単なる型と値として扱われるので、特になにかフローが滅茶苦茶になったりすることはないです
あと例外のフローについては、それは単に例外の扱いが悪い言語に慣れているのではみたいな気持ちです
あとは「URL として正しいことが既に確約されている」という、特徴というか情報を型に持たせているという意識がある
私は「Url 型の値として存在させる」こと自体が「URL として不正でないものとして扱っている」と見做しているので、その辺りか
壊れていても壊れていなくても後始末はしないといけないので、壊れてるって状態もあるモデル(という普段オレンジが物事を考える時に使う発想)が、ちょうどそれにぴったりかも的なアレかも＞＜
(なので、逆に「状態なんてバグの原因にしかならない」って発想から見たら、状態なのでバグの原因かも＞＜)
基本的にはURLとして不正な文字列を内部に持つUrlは存在しない方がいいかも＞＜ なので不正ではないかのように扱おうとした瞬間に例外をはいてほしいんけど、
ただし！＞＜；宣言や、コンストラクタを呼ぶ場面だけは例外出されて後始末の流れがぐちゃぐちゃになるのがいやなので、そんな変な事に＞＜；
1. String → Url
2. Url に対してなんらかの操作 (たとえば path を得るなど)
のどちらでエラーが出るかという話はわかるんですが、 URL として壊れた文字列の扱いについての言及がよくわからない
オレンジ的にはURLはURLであって(さっきの例に限って言うのであれば)文字列ではなくて、不正な文字列から作られたurlは、urlを作りたかったけど失敗してぶっ壊れたもので、文字列は明示的にrawな文字列として取り出す場合以外では、例えば文字列型にキャスト出来るのであれば、その時にも例外を出してほしいかも＞＜；
たとえば「文字列を URL にしたい」が失敗したとき出てくるのは「URL にしたかったけどできなかった『文字列』」であるわけで、であればこれは Url 型で表現できなくても文字列型として表現できるわけで、「正しい状態しか表現できない」というのはそういう程度の話です
「正常でない」にも複数種類あるわけで、いわゆる異常系と正常系みたいな話になるけど……
返す時に例外だしてもよくない？＞＜(もちろんエラーはなるべく早く出したいので、チェックは明示的に(＞＜；)早くやるべきだけど、忘れてたら返す時に最後の砦として的な＞＜)
「壊れているかもしれない値を生で返すな」というお気持ちですね
std::sync::PoisonError - Rust
https://doc.rust-lang.org/stable/std/sync/struct.PoisonError.html
mutex を持ったスレッドが解放しないまま死んだ場合、 mutex で管理されている値が不正状態になっている場合があるので、それを表現するために PoisonError<T> でラップされている
オレンジの物事の発想が「世の中は全て、機能と状態の集合で出来ている！＞＜」って発想で、その延長で、ある型のものの状態にも「正常である状態」と「正常ではない状態」があるかも＞＜って発想で、物事を考えてるかも・・・＞＜
不正な値でありうるか否かというのも、 Result とか Option とかによって型で表現されてほしい
panic が実質そんな感じの挙動だけど、まあ panic は panic するために使うものであって、復帰はできるけどそういう仕組みは常用されるものではない
https://doc.rust-lang.org/stable/std/string/struct.String.html#method.from_utf8
たとえばこの String::from_utf8 みたいな感じで
同時に、戻り値型が Result であることで、「必ずしも構築できるとは限らない」という表明にもなっている
そこで、例外でなく Result (Haskell なら Either) などを使うことで、正常値と異常値を値として扱えるようにすることで、コードを整理できるわけです
このアカウントは、notestockで公開設定になっていません。
ある意味null安全に近い話なのかも？＞＜；(オレンジは、内容が不正であることのフラグとして(手抜きで)null許容型を使うこともたまにある＞＜；)
C++ も (iostream 辺りは歴史的事情か例外のパフォーマンスの事情かアレな感じだけど)、基本的に「不正な状態のオブジェクトを作らず、 ctor で例外を投げろ」という感じになっているし、「正しいものしか存在できない」という感じの世界を作りたさが感じられる
理想的には型チェックが通った時点で、表明されていたあらゆる制約が満たされていることを確認したいわけで、「URL として妥当であるか」というのは「Url 型のオブジェクトとして存在できるか」と一致してほしい
なんでこんな謎方式にしたいかと言うと、宣言時に例外が出ると後始末がぐちゃってするのが嫌で、それを回避できるならチェックするのは分けたいし、毎回チェックする手間が増えてもって感覚がある＞＜；
Url 型のオブジェクトが出現したその瞬間から死ぬまで、ずっと Url は URL として valid な値しか持てないでほしい (型を妥当な値の集合として考えれば) ので、 new からの url.Check() で例外を飛ばすのは、ちょっと型の意味が弱すぎるかなぁという気持ちがしますね
さっきのURLの処理みたいなの、オレンジの好みの架空言語ならば・・・＞＜；
ReadOnly StringUTF8 url_string = "example .com";
Url url = new Url( url_string );
url.Check();
//不正な文字列なら例外
bool urlDanepposa = url.IsInvalidURL;
//不正かどうかのプロパティ
bool urlDaijoubupposa = url.IsValidated;
//ポジティブとネガティブもどっちも要るよね！＞＜；
C でもブロックを明示すれば同じことはできるので、よーするに Rust ではブロックを暗黙に作ってくれるというだけのようなもの (あと Rust ではブロックも式であり値に評価されるので、この解釈とは相性が良い)
let foo = 1;
let foo = "foo";
bar(foo);
というのは、実際には
{
let foo = 1;
{
let foo = "foo";
{
bar(foo);
}
}
}
のようなことをやっているわけで、 shadow された変数が消えるわけでもないし破棄されるわけでもないし上書きされるわけでもない、あくまで shadow されて「名前で」参照できなくなるだけ
あと Rust の shadowing は redeclaration ではないと思います
monad の do 記法を以て再宣言可能とするのは大嘘では？？？？
Pascalなんて途中で宣言がそもそもできない＞＜ Pascalすばらしい＞＜(そこはちょっとめんどくさいと思ってました＞＜；)
同一スコープ内での同名変数の再宣言とシャドウイング｜Rustでは再宣言が可能 https://qiita.com/aimof/items/01911a187d7351c8313c
"別の言語ではどうなるか？ その2：再宣言できる言語"
"Haskellでは、再宣言可能です。ちなみにHaskellの変数（と呼ぶのが適切かはわかりませんが）はimmutable（不変）です。"
めっちゃくちゃ変化してるじゃん？＞＜；
右辺で型が自明じゃない記述にしか見えないし、そもそもシャドーイング？で何がうれしいのかさっぱりわからないかも・・・＞＜
ただ、この方式だと lifetime あたりの問題があって、たとえば
let name = read_line(); // 所有権ありの文字列
let name = name.trim(); // 旧 name の一部を borrow しているスライス
みたいなことができない (旧 name の生存期間が新 name の生存期間以上でなければならない) ので、万能ではない
@tacostea オレンジもライセンスわかんないかも＞＜； 気温下がったらチャレンジしてみるかも＞＜
たとえば
let age = read_line();
let age = age.parse::<u32>().expect("Invalid age");
みたいにすれば、あるべき型の age にしかアクセスできなくなるので、 age_str と age_int が共存するよりも望ましいと考えることができる
あと、シャドーイングをすると、たとえばこの例だと「2回目の束縛以降で、不正でありうる文字列型の URL データにアクセスできなくなる」という利点がある (URL でなく文字列として取り出したければ、明示的にそういう操作を行うべき)
たとえば
let url = "https://example.com/"; // ここで文字列
let url = Url::parse(url).expect("Invalid URL"); // ここで Url 型
みたいなシャドーイングしたい場合があって、これもまあ賛否分かれるかもしれないけど、あくまで変数の意味を扱ってロジックを書きたいならこれもアリだと思いますね
オレンジのC# のコード、
double hoge = 1.0d;
みたいな、冗語法みたいな記述がわりとある・・・＞＜；
例えば(架空の言語として)
//これは整数になります
let hoge = 1;
みたいな記述でも、なんか「・・・＞＜；」ってなる＞＜；(極端に言うとサフィックス必須とかにしてほしい＞＜；)
Rust は関数のパラメータと戻り値について型を指定しなければならない (変数や式では省略できる) ので、その辺り結構バランスが良いと思っている
や、高階関数とか多用すると型変数ばかりになって大して嬉しくないようなことはあるんでしょうけどね
関数型言語の入門記事で型推論使いまくってるの読むたびに「(こんな文化圏の言語なら使いたくないかも・・・＞＜)」って思ってめげてやめちゃう＞＜(型記述原理主義者的発想)
そういえば、関数型言語文化圏の人々って「型を！」「型ありきの発想！！」って言うわりに、「自明なら書かなくてもいいよね」って型推論多用しまくる人が多い気がするのすごく謎かも＞＜
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
写ってる缶、どんな飲み物だろう？＞＜ってググったらビールだった・・・・＞＜
これで言うある種のミニマリストの発想って「ブルータリズム」って言うらしい＞＜(つい最近知った＞＜)
https://mstdn.nere9.help/@orange_in_space/100371977033749683
マストドンにわりと十分に大規模な鯖(ある種のミニマリスト的発想基準で)が必要なの、どう考えても設計が豪快すぎるのとRubyで豪快に書いてるからだと思う・・・＞＜ 富豪的にもほどがある的な＞＜
マストドンのハッシュタグ、どこまで届いてどこまで拾えるのかさっぱりわからなくて、フォロー関係ある範囲＆LTLでの話題(具体的に言うとマインクラフトの連絡事項)にしか使ってない・・・＞＜
HTLへの誘導、オレンジならどうデザインするか前に書いて反応少なくて凹んだけど、
HTLの流速が遅い時に、速度が一定以上になるようにLTLやFTLや既知のインスタンスから適当にtoot拾ってきて混ぜ混むというデザインが＞＜(「この人がおもしろそうと思ったらフォローしよう！」みたいな説明つきで、さらにちゃんとランダムに持ってきたものだとわかるように工夫して＞＜)
もちろんオフにしたり細かく設定できるようにすべき＞＜
閉じた環境で話をしたいのならDiscord(という大きなものが守ってくれる環境)ってたしかにだけど、
Discordって複アカできない上に、オンライン状態を全員に公開するか誰にも公開しないかしか選べないという豪快な仕様のせいで、パブリックなグループとプライベートなグループのどちらかにしか使えないという問題が＞＜；
.socialのpawooブロックも、法律が壊れてる(←github上で欧州の人曰)って話をおいておくと、お一人様インスタンス推進って発想であれば「まるごとブロックしたいのであれば自分でインスタンスたてれ！」って話になるし、自分で見るものを決めるって発想と逆の行動である事にはかわりないかも＞＜ twitterのペナルティの強制ミュート？と変わらない＞＜
件の人がいう、ツイッターのようなものを求めるという話での「盛り上がり」と、そのいくつか前のtootの「Mastodonの勢い」って何がどう違うんだろう？＞＜
公開されたくない話、気持ちはわかるがそりゃ無理よとしか思わないし、「どうしても秘匿したくば自分でそれ用のサービスを持て」としか
それを言ったら、個人サイトだろうが商業同人問わず出版だろうが演説だろうが、いかなる言論の場においても、完全な匿名でない限りは別の場所から横槍が入るわけで、そんなものは今に始まったものでもないし、この問題について ActivityPub が特筆すべき何かを提供しているわけではないのも、それはそう
ていうか、なのでインターネットで「見せない」って対策は基本的に無駄かも＞＜ 大きいものに守ってもらう(例えばツイッターの鍵アカとか)のではなければ＞＜
このアカウントは、notestockで公開設定になっていません。
LTLにこもるのはよくないけどFTL(を充実させてそこ)にこもる(ユーザーが増える)のはいいのかって点がわりと謎＞＜(フォローしてHTL使おうよって話はどこへというか、FTL(/LTL)からHTLへ誘導するデザインを作る方が先じゃないのか感)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
それ(LTLだけになっちゃう問題)はなんというか同意ではあるけど、ただしそれの解消は啓蒙ではなくソフトウェアのデザインによって誘導しないと無理かも＞＜
このアカウントは、notestockで公開設定になっていません。
オイゲン氏が言う過去のSNSの失敗が、ツイッターの統治や引用の扱い等のソフトウェアの振る舞い等を指しているのだとしたら、ユーザーは別にそれ以外の面ではツイッターに居た時と同じ振る舞いをしてもいいのでは？＞＜(極端に言うと「世界からはBANされない」という点だけでも違うでしょ？＞＜ 件の人が書いてる通り＞＜)
全員お一人様インスタンスになるべきって考えならそれはアレだけど、オイゲン氏はそこまでは言ってないっぽいし、件の人もお一人様ではないインスタンス運営してるっぽいし＞＜
このアカウントは、notestockで公開設定になっていません。
(定義難しいけど、雑に)自由である事を重視して、GPLの理念にも同意してマストドンのインスタンスをたてるのであれば、説明文の
"あなたは人間であり、商品ではありません
Mastodon は営利的な SNS ではありません。広告や、データの収集・解析は無く、"
って、第零の自由の発想におもいっきり反してる記述は削除して使うべきだと思う＞＜
(オレンジはGPL嫌ってるので問題ないです！＞＜； BSDLの方が真の自由に近いのです！＞＜；(ジョークは別としても、インスタンスたてるとしたらその辺りのGPLと矛盾した記述全部書き換えるけど＞＜))
オレンジは技術的理由以外では基本的にブロックしない主義です＞＜(基本的ではない例外としては、議論せずにブロックしまくってるような人はブロックしてる＞＜(おふがお とかみたいな＞＜))
オレンジが言う直接突っ込んでいい人悪い人って、そのまま議論する人しない人で、議論しない人ってだいたい「礼儀を」とか「ブロックする権利がある」って言うのでそういう言葉を使う人には直接つっこまない事にしてる＞＜ ツッコミ入れても話を聞かずにブロックされるだけなので＞＜
少なくとも、件の人が言うようなOStatus/ActivityPubの発想と(ついでに言うとGPLの発想とも)、オイゲン氏の考えって(残念な事に)相容れないと思うんだけど＞＜；
オイゲン氏リバタリアン嫌いっぽいし＞＜；
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
クライアントアプリから見たAPIの話なのか、WebUIのUXの話なのか、「TwitterもActivityPubを話すべき」みたいな話題の事なのか・・・＞＜(あとなんだろう？＞＜)
少し辿って読んだけど、何をどう互換って話なのかさっぱりわからない・・・＞＜
このアカウントは、notestockで公開設定になっていません。
電源アイコンとか飛行機のアイコンとか気象アイコンとか閉じるボタン？とか、組み込みGUI用に便利そうな外字がたくさん入ってて、組み込み用に使ってね！って説明通りに組み込み用に便利そう＞＜
エアバスが作ったオープンソースのフォント、ほんとに飛行機用に作ったものそのままらしくて、ゼロがASCIIのゼロに相当する部分(U+0030)は斜線無しで、斜線入りのゼロはU+E007に割り当ててあって、そのままだとゼロとオーが見分けつかなくてプログラミング用には使えないかも・・・＞＜(誰か割り当てを逆にした派生フォントファイルを作ってくれたら・・・＞＜)
@cheesekun オレンジは他の人が何かを調べるのをお手伝いするけど、オレンジがなにか困っても手伝ってくれる人は全然居ない・・・＞＜
オレンジ的には、ボーイングのコクピットの(ディスプレイでは無く)パネルのフォントってFuturaらしいけど、エアバス機のコクピットのフォントはどれだろう？＞＜
って調べてたら、それはググりまくってもわからなくて、代わりにさっきのフォントみつけた＞＜
よくわかんないけど、エアバスがコクピットのディスプレイ用にパイロットの意見も聞いて実験込みで開発したフォントでモノスペースフォントもあるって事は、プログラミング用にも向いてる・・・？＞＜
ていうかなんで全く話題になってないの？＞＜；
-- B612 – The font family http://b612-font.com/
よくわかんないけど、エアバスがコクピットで使うフォントをオープンソースで作ったって事？＞＜
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
デザイン＞＜ -- 駅の出口はだいたい黄色 ～JISがつくる風景～ - デイリーポータルZ http://portal.nifty.com/kiji-smp/180712203381_1.htm
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
電話機としての携帯電話機、LifeTouchNOTEくらいまではデカくても良くない？＞＜ ていうかLifeTouchNOTEを畳んで受話器みたいに持って通話できたら良くない？＞＜って思ってる＞＜
(奇妙さで言うなら、たった十数年前でも、ただの板みたいな物体を持って電話するのも奇妙だったんだし、イヤホンマイクでの通話も今でも不気味って言う人居るしアレかも＞＜)
オレンジの家古すぎてあちこち違う方向に斜めに傾いてるけどあんまり気にしてない＞＜(不均等に傾いた結果、数十年前に既に壁にひび入ってた場所とかあってそれはヤバそうて思ってたけど、3.11でもひびは増えたけど倒壊しなかったから気にしなくていいのかも＞＜；)
オレンジ的にはスマホを極端に薄くしたい理由がわりとわからない・・・＞＜(厚めのケースと薄めの差よりも小さい程度の差なら厚くてもよくね感(薄いケース選んだりケース使わなければいいじゃん感))
オレンジは頑固なので「バッテリーはユーザーが簡単に交換できるべき！＞＜」って面も考慮してGalaxy Note 3にした＞＜
ていうか、この記事の外装交換キットみたいなのがあるなら、バッテリーも昔ながらのユーザーが気軽に交換できる電池パック方式にする改造キットとかも作れそうだけど、無いのかな？＞＜ -- iPhone5s の電池が膨らんできた - ejo090の日記 http://ejo090.hatenadiary.jp/entry/2018/07/14/042350
はてなブログに投稿しました
iPhone5s の電池が膨らんできた - ejo090の日記 http://ejo090.hatenadiary.jp/entry/2018/07/14/042350 #はてなブログ
謎の野菜が届かないレベルまでに過疎化してる田舎なら、自治会も別に入らなくてもというか孤立してもだいじょうぶそうというか、誰も居ない場所に住もうとしてるならあんまり関係ないよね＞＜；
なので転入者の方々、そのブログの後悔してる人にかなり近い心境なんじゃないかと＞＜； 山奥ほどでは無いけど排他的だし、古くからの人と新しい人とで分断があるし、古くからの人でも農家はさらに農家だけでかたまってるし＞＜(農家は家系3件くらい？の親戚なのである意味親戚繋がりで、別にそれは嫌な感じでは無いし、古くからの人にはその中の話も別に内緒ではない感じ)
ていうかこの辺、ここまでは酷くはないけどかなり近いものがあるかも＞＜； 転入者はある程度居る一方で地元民は高齢化という、東京近郊エリア文化と田舎文化の境目的な＞＜；
僕の田舎に若者が移住して3年！彼は"失敗した"と後悔中だよ - トレトラ - FXトレードしながら旅するブログ http://yukihiro.hatenablog.com/entry/2015/12/02/210501
クソ田舎はなあ ある程度栄えてる地方都市ならまあみたいなのはある
