このアカウントは、notestockで公開設定になっていません。
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
逆ポ記法は機械には優しいかもしれないが人間がゴミだということを失念していて、人間はそこまで深くスタック (正確には長い演算の切れ目)を記憶しておくことができないので、木構造を上から潰したようなシリアライズであるところの中置演算子はその点で脳に優しいと言わざるを得ない
中置だったら「オペランドはここから右と左」というマーカーとして演算子を使える (そして括弧まで到達すればそこで終わり) んだけど、 RPN だと括弧不要なのでオペランドがどこからどこまでかがぱっと見でわからない
【速報】2019年7月18日に京都アニメーション第1スタジオで発生した放火火災の分析
http://www.dpri.kyoto-u.ac.jp/contents/wp-content/uploads/2019/08/Analysis-of-Kyoto-Animation-Arson-Fire_20190802-1.pdf
普段使いのRPN電卓として RPN calculator おすすめです（HPの電卓を模したような大量のボタンが無くてシンプル） https://play.google.com/store/apps/details?id=com.ath0.rpn
このアカウントは、notestockで公開設定になっていません。
構文が普通の例外と同じだとか、例外機構そのものがrewindなどの関係でパフォーマンス落ちるとかかな？
rewind あたりのあれこれもあると思うし、あとは検査例外を指定するとき結局直和型みたいに列挙する感じになるのにそれに名前を付けたり nonexhaustive にして future-proofing できなかったりするのがいけないという気持ちもある
直和型みたいに名前を付けられれば、「今度からこのタイプのエラーも発生することになったからw」みたいなエラー種の追加を互換性を損なわずできる (少なくとも、そういう設計にすることはできる)
例外が飛んだらとりあえずダミー値を突っ込んで処理を続けるか、ダミーは入れられないので自分も例外投げて死ぬかの二択で、例外の型は検死するときまで使わないので、とりあえずcatch(Exception e)でええやろというのが最近のマイブーム
このアカウントは、notestockで公開設定になっていません。
あと catch だとパターンマッチが難しそうというのもあったな。まあそもそもマトモなパターンマッチができる言語でなければ論外なので終了なんだけど
一応複数の型の catch を同時にできるような言語の話は聞いたことある気がするけど、パターンマッチしたいとき気にしてるのは中身であることも多いので
これだと型レベルでどの例外が発生しうるか表現されてないので NG
glGetError() とか、 GL で発生しうるあらゆるエラーコードを内包するエラー情報を返すので本当に険しくて、こういうことをしてはいけない
の投稿
prime@mstdn.poyo.me
このアカウントは、notestockで公開設定になっていません。
そもそも何らかのエラー型が特定の意味を持つなら、その意味が定義時点で表現されていて然るべきな気がするので、選択肢を書かずに済むのをあまりメリットと思えない
の投稿
prime@mstdn.poyo.meこのアカウントは、notestockで公開設定になっていません。
「だったら成功判定とリザルトコードを一緒に返せばいいではないか」とえらいひとが考えた結果、別の意味で大惨事になったのがHRESULTであり、VBの操作が正常に終了しましたエラーでもある、という理解
だいたいエラー起こしたらFALSEがいいのかTRUE返すのがいいのかという根源的な問まで遡る
エラーを boolean で表現するのやめて Result<(), ()> とか Result<(), SomeError> (ただし SomeError は1つの値しか持たない unit struct) とかを使うの、完全に正解という感じがして、生きている実感が湧く
alloc::str::ParseBoolError - Rust
https://doc.rust-lang.org/nightly/alloc/str/struct.ParseBoolError.html
これとか
どうせ異常系なんていくつかのリトライしたい動作以外は全部死ぬしかないみたいな扱われ方されるから、型で網羅できててもねぇみたいな気持ちになるときはある
failure あまり好きじゃないし、それはさておいて入らないと思う
failure のステキ機能だった backtrace とかが std::error::Error に互換性を壊さず入れられそうだということが判明しており
Kotlinはsealed classとwhenでexhaustive matchingを要求する直和型（仮）が作れるから……
このアカウントは、notestockで公開設定になっていません。
@kb10uy Result<(), Box<dyn std::error::Error + Send + Sync>>
なお + Send + Sync はお好みで
std::boxed::Box - Rust
https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#implementations
impl<'a, E: Error + 'a> From<E> for Box<dyn Error + 'a>
と
impl<'a, E: Error + Send + Sync + 'a> From<E> for Box<dyn Error + Send + Sync + 'a>
があるよ
std::error::Error - Rust
https://doc.rust-lang.org/stable/std/error/trait.Error.html#method.downcast_ref
あと安全な downcast 系のものも用意されているので、 Box<dyn Error> から &E を (E の候補を知っていれば) 取り出すことができるよ
Swiftのエラーハンドリングはなぜ最先端なのか - Qiita https://qiita.com/omochimetaru/items/c30f7a021fb9b8f0fa92
Rust がよくやっていると思うのは、例外という特殊な機構を排して、単純でありふれた戻り値型という仕組みでうまくエラーを表現したところにあると思う
構文糖衣も Try trait とか From trait を使ってエラーに限らず利用できるようになっているし、エラー関係の表現力を損うことなく言語コアの仕様を小さく納めている点はとてもよくできている
まあ Rust だと panic は unwind その他いろいろ発生してアレなんだけど、 panic はそもそもカジュアルにユーザが復帰を試みるものではないので unwind あれこれのコストがかかりまくるということもなく
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
一般保護違反とぬるぽとの違いを説明するよう言われて「一般保護違反は『ぬるじゃないぽ』もありうる」と一言で済ませたのを思い出した
このアカウントは、notestockで公開設定になっていません。
一般保護例外 ‐ 通信用語の基礎知識
https://www.wdic.org/w/TECH/%E4%B8%80%E8%88%AC%E4%BF%9D%E8%AD%B7%E4%BE%8B%E5%A4%96
> 原因は様々であるが、ビジータスクへのスイッチ、許可されているメモリー領域外へのアクセス、トラップや割り込みの条件の不正、タスクスイッチ時の特権レベルの不正などが挙げられる。
このアカウントは、notestockで公開設定になっていません。
というより、GPFがよりCPU寄りのローレベルな割り込みによる例外処理のことで、SEGVとかがOSが関与し仮想化された例外である、と理解してる
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
InitCommonControlsEx function (commctrl.h) | Microsoft Docs
https://docs.microsoft.com/en-us/windows/win32/api/commctrl/nf-commctrl-initcommoncontrolsex
kb10uy 氏が好きそうな WIN32API 関数です
京アニ犠牲者 身元公表は35人中10人「らき☆すた」武本監督も…（スポニチアネックス） - Yahoo!ニュース
https://headlines.yahoo.co.jp/hl?a=20190803-00000120-spnannex-soci
> ▼お断り 京都アニメーションの放火殺人事件で、実名公表を了承した遺族のうち1人から、京都府警を通じて匿名希望に変更するとの連絡がありました。事件・事故報道は共同通信が原則実名で報じており、本紙も共同通信に準拠して実名で報じます。
「我が社だけ隠しても他社がどうせ公表するんだから意味ないやろ、なので我が社も実名公開します」という責任の循環参照を作って責任逃れする姿勢は端的に言ってクズだけど、「オメー (悪いこと何もしてない人) は何もしてないけど俺らは実名公開することにしてるからするわw」というのはそれ以上だわ
これ共同通信はどう反応するんでしょうね (スルー含め)
最近、逃げられないタスクが発生すると部屋の掃除ではなく OSS へのプルリクなどを書きまくるようになってしまい、社会性の高まりが発露してしまった (適当)
緊急地震速報（警報）よりも低い基準で通知鳴らすアプリを使うのは本当に急を要する通知か見誤るので宜しくない気がしている
サーバ監視のログで false positive を出しまくることで本命の攻撃をログに埋もれさせて発覚を遅延/回避するみたいなﾃｸﾆｰｸを思い出した (だから何)
人間は慣れてしまう生き物なので警告の頻度もほどほどがよいなという話です
このアカウントは、notestockで公開設定になっていません。
ActivityPub でも中央集権はできるので、ちゃんと分散したいわね
このアカウントは、notestockで公開設定になっていません。
ｲｯｼｭﾘｽﾄは名前付けてほしい (マジで誰かわからないとお返しに困るので)
https://www.amazon.co.jp/hz/wishlist/ls/3PH9NUZKANS9K/
使おうとすれば使えなくもないけどそれはそれとして要らねえプレゼントリストです
ご活用ください
このアカウントは、notestockで公開設定になっていません。
ご指摘はごもっともだが、このような世界は作りたくないと感じている。理由は以下の通り
・同じ名前のツールでローカライズされている場合の取り扱い
・開発の国際化が困難になりかねない
・開発者の慣れ
「プログラミング＝英語」という状況は正しくない。多言語でコードを書ける世界が求められている https://wired.jp/2019/08/04/coding-is-for-everyoneas-long-as-you-speak-english/
「プログラミング＝英語」という状況は正しくない。多言語でコードを書ける世界が求められている｜WIRED.jp
https://wired.jp/2019/08/04/coding-is-for-everyoneas-long-as-you-speak-english/
ﾎﾟﾖｸﾞﾔﾑの自動変換ができるとか簡単に言うけどさ、それ本質的変更がないのにコードの表象だけ弄るってことやで？そういうのは言語やソフトウェアのソースコード上じゃなくて IDE とか user-facing な環境側でやってくれ
あと EXCEL の IF が多言語対応してるとかいう話で日本語ベーシック思い出したよね。
シキ。ヲヨベ。ニイケ。
記号的にせよというだけの話ならまだわかるけど、訳せたところで何やねんという気持ちがある。
プログラミング言語はそれ独自のシンタックスとセマンティクスを持っているわけで、単語だけローカライズしたところでマトモに見えるわけでもないし開発者フレンドリーになるわけでもないと思う
むしろコードよりもドキュメントを自然に多言語化することを考える方が1047483648倍くらい価値があるわ
ところで人間はいつになったら自然な多言語ドキュメント形式を発明できるの (翻訳メモリの話はしていない)
すでにシステム部分がローカライズされているプログラミング環境としてはScratchとかがあるけど、まああれも中では何らかの言語で表記されてるのをフロントのIDEで誤魔化してるだけなので、結局翻訳機能付きIDEみたいなのができるんじゃないですかね
https://mstdn.rinsuki.net/@rinsuki/102559178936646727
これ、つまるところ (もし英語を使わないなら) ソースコードはバイナリ的形式になるということで、それプレーンテキストとしての良い性質を損なってまでやるべきことなのかという気持ちになる
(なので https://mastodon.cardina1.red/@lo48576/102559157883507390 ここでは環境側でやれという言い方になった)
どうせ表示・編集環境側で調整されるのであれば、それこそ生のソースコードが英語でなくすべき理由もないよね。
ちょうど MS WORD みたいな WYSIWYG で HTML 文書を編集するとき HTML の語彙が不要なように。
このアカウントは、notestockで公開設定になっていません。
広めようとするのは自由だし、それを批判するのも自由なので
いやべつに否定はしないけど使い物になる気はしないので、本当に素晴らしいものであるというなら是非実物を見てみたいものよね
各言語でライブラリに関わるドキュメントを用意しろというのには同意する。日本語の翻訳を機械翻訳を基本としたMS、許さんぞ (人力翻訳も訳がおかしいというツッコミは無視する) https://mastodon.cardina1.red/@lo48576/102559171995353396
思い出すシリーズ:
本の虫: しないでマイクロソフトのスタイルガイドライン準拠の翻訳
https://cpplover.blogspot.com/2018/07/blog-post.html
開発で必要なコミュニケーションは英語でするし、事が済んでからのﾌﾞﾖｸﾞとかでの情報発信は日本語でする
このアカウントは、notestockで公開設定になっていません。
自然な英語とのギャップに驚く言葉ランキング:
* Abort
* Execute
* promiscuous
promiscuous とかﾎﾟﾖｸﾞﾔﾐﾝで使ったことないけど
このアカウントは、notestockで公開設定になっていません。
一応言語学者と言うからには CJK 含め世界の言語には諸々の多様性があって多言語対応は大いに問題になりうることはわかっているのだろうと仮定していたけど、どうなんだろう
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Hacker's Wisdom: The Unix Guru's View of Sex
https://www.ee.ryerson.ca/~elf/hack/ugvs.html
唐突にこれ思い出したわ >界隈の英語
#!/bin/ssh
# The Unix Guru's View of Sex
unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep
https://mastodon.cardina1.red/@lo48576/99253049260166801
UNIX ジョークだとこれとかも滅茶苦茶好きです
> コンピュータリテラシの授業の時、先生が「ユニックスはマンはあるけどウーマンはないからユニセックス」って言ってたけど当時は何もわからなかった。
> 今思うとめっちゃ面白い。
https://mastodon.cardina1.red/@lo48576/101629476149010282
妹エクスプロイト
https://novel18.syosetu.com/n2670fi/
界隈の用語モノのえっち小説です (適当)
