眠すぎて死ぬ

++age;

眠すぎて NEMS 《Nano Electro Mechanical Systems》 になった

雑なオタクとしてはﾍﾛｰﾜｰﾙﾖなんかより if err == nil { return err; } がどうなるかを見たいんだよな (超適当)

これ != の間違いじゃん
これだからｺﾞｮｰは駄目 (？)

@omasanori ひどい (ひどい)

このアカウントは、notestockで公開設定になっていません。

現代でも cat に対して dog や bat を実装する人々などがいて、文化が受け継がれている感じがする (?)

そういえば more の類似実装が less なの、某建築家の名言 “less is more” 絡みなのかと思ったこともあったんだけど、べつにあまり関係なさそうな雰囲気

ルートヴィヒ・ミース・ファン・デル・ローエ - Wikipedia https://ja.wikipedia.org/wiki/%E3%83%AB%E3%83%BC%E3%83%88%E3%83%B4%E3%82%A3%E3%83%92%E3%83%BB%E3%83%9F%E3%83%BC%E3%82%B9%E3%83%BB%E3%83%95%E3%82%A1%E3%83%B3%E3%83%BB%E3%83%87%E3%83%AB%E3%83%BB%E3%83%AD%E3%83%BC%E3%82%A8

> 「Less is more.」（より少ないことは、より豊かなこと）や「God is in the detail（英語版リンク）」（神は細部に宿る）という標語で知られ、近代主義建築のコンセプトの成立に貢献した建築家である。

このアカウントは、notestockで公開設定になっていません。

スタジオとプラットフォームにほぼ同じ名前使っとったんか……

このアカウントは、notestockで公開設定になっていません。

職場が絶妙に眠気を誘う弱い明るさでヤバい

ごぼう系のおやつ、つい食べすぎて腹痛に苦しむことになるので油断ならない

大域的な評価関数を認められるかの価値観差みたいなところはあると思う。「少数の開発者が苦労することで多くのユーザが救われる」みたいなのにどこまで加点できるか。

まあそもそも雑スクリプティングでもなければ、多かれ少なかれソフトウェア開発ってそういう側面があるはずと思うんだけど

今日のハイライト: notepad.exe でCとアセンブリ言語のソース読んでた

ﾋﾞｽﾞｭｱﾙｽﾄｩﾃﾞｨｵとか卒業したんで✋

？

情シス氏、はよ VS のライセンス寄越してくれ〜

や、どうにか WSL ｲﾝｽｺできたので明日からは vim 使っていきますが

このアカウントは、notestockで公開設定になっていません。

例のルービックキューブの解き方の話してます？

このアカウントは、notestockで公開設定になっていません。

コンパイルの長時間化、よほどヤバい言語仕様 (refinement types とか) でもなければ大半は最適化とリンク (あるいはリンク時最適化) なので、その辺りをバッサリ省略してやれば相対的にかなりマシになるし、あとは incremental build とか並列リンクとかいろいろアグレッシブなやつも突っ込めばそれなりには収まる

Module testing result and manufacturing progress – Ultimate Hacking Keyboard
https://ultimatehackingkeyboard.com/blog/2021/02/01/module-testing-result-and-manufacturing-progress

3月後半まで待たされるのか……てことは日本に届くのは4月以降だろうなぁ

最適化のバグはね……

あとはまだ安定版に降ってきてないけど、 cranelift で実行効率は落ちるがコード生成はドチャクソ早くなるバックエンドを用意することで手元環境での使い勝手を上げようみたいな試みも進んでいる

もちろんそれはそうで、でも逆に「コンパイラのバグや未定義動作を前提にした挙動を発見できる」みたいなのがあって (gcc と clang でコンパイルして比較できるみたいなもの)、その場合むしろコードの一致が保証されない (不一致に気付きやすい) のは言語や処理系を健全に保つための重要な性質にもなる

まあ多様性なんじゃないですか。言語を向いている人もコンパイラを向いている人も小規模プロダクトを向いている人も大規模プロダクトを向いている人もいるし、でも結局どこの人もコンパイル高速化できるならそれに越したことはないと思ってるよ

言語仕様側でも、文法を LL(k) に抑えると複雑性とか IDE / Language Server あたりで嬉しいから云々みたいな話があったりするので

あるいは別の話だと……極端だけど、昔は rust コンパイラの C++ 実装が「コンパイル時検査は不完全だけど、正しいソースを入れると正しいバイナリが出てくるよ」みたいな感じでやってなかったっけ。 C/C++ からのブートストラップに使えるとかで。 (名前が思い出せない……)

thepowersgang/mrustc: Alternative rust compiler (re-implementation)
https://github.com/thepowersgang/mrustc

> mrustc works by compiling assumed-valid rust code (i.e. without borrow checking) into a high-level assembly (中略).

> This works because the borrow checker doesn't have any impact on the generated code, just in checking that the code would be valid.

まあこれは高速化とはまた別の動機だろうけど、目的に合致していればそれもまた手ではあるよね (製品の生成に使えないのはそれはそうだけどw)

Liquid Haskell も Haskell の外側に追加の検査レイヤーを付けてやる感じだし、「正しさが確認できるなら、それが必ずしもバイナリの生成時である必要はない」というのもひとつの答え

(まあ検査・推論とコード生成が一体の方が最適化はガッツリできるだろうけど、当然遅くなるので)

今と全く同じことを高速でやりたいと思うからトレードオフとかフリーランチを待つとか金で殴るとかになるわけで、規模や開発のフェーズ次第ではワークフローとか運用を調整していくのも視野に入れるべきよね (当然そうはいかないプロジェクトもあるけど)

このアカウントは、notestockで公開設定になっていません。

iota 言語は実際任意個の0と1を並べると実行可能なプログラムになるチューリング完全な関数型言語だよ (？)

このアカウントは、notestockで公開設定になっていません。

rune とかいう概念全然わかってなくて (触れる機会がないので)、 codepoint や grapheme cluster とはまた別の概念なのかな……

ﾏｯｼﾞで

同じ概念に別名つけたのか……