眠すぎて死ぬ
眠すぎて NEMS 《Nano Electro Mechanical Systems》 になった
GitHubのhomeに流れてきた、な、なんだ…
ExaScience/slick: The Slick programming language is an s-expression surface syntax for Go.
https://github.com/ExaScience/slick
雑なオタクとしてはヘローワールヨなんかより if err == nil { return err; } がどうなるかを見たいんだよな (超適当)
ちなみに ITS は昼間説明 Prof. Fernando J. Corbató による Time-sharing system へのユーモラスで付けた名前だけれど、これはどういうことかというと F. J. Corbató の TSS は Compatible Time-Sharing System; CTSS という名称だったので、MIT はこれをパロディして Incompatible Time-sharing System; ITS と名付けた。頭字語のアルファベットを反転させたり逆の意味の言葉を使ったりする GNU のユーモアはここから来ているのである。
このアカウントは、notestockで公開設定になっていません。
more に対する less、SCCS(世界初の VCS)の GNU 実装は CSSC で PGP の GNU 実装は GPG、といった具合
現代でも 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で公開設定になっていません。
大域的な評価関数を認められるかの価値観差みたいなところはあると思う。「少数の開発者が苦労することで多くのユーザが救われる」みたいなのにどこまで加点できるか。
まあそもそも雑スクリプティングでもなければ、多かれ少なかれソフトウェア開発ってそういう側面があるはずと思うんだけど
このアカウントは、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月以降だろうなぁ
Rustのコンパイルは遅くしようと思って遅くしているわけではなくて、rustcの高速化のために相当な労力をこれまで払ってきたという点はわかってほしいところ。
そもそも Rust はウチのコンパイルは遅いが遅くてもいい、なんて主張してない気がする。日々速くする努力もあるし、こういうの https://blog.kodewerx.org/2020/06/the-rust-compiler-isnt-slow-we-are.html もある。
blogwerx: The Rust compiler isn't slow; we are. https://blog.kodewerx.org/2020/06/the-rust-compiler-isnt-slow-we-are.html
あとはまだ安定版に降ってきてないけど、 cranelift で実行効率は落ちるがコード生成はドチャクソ早くなるバックエンドを用意することで手元環境での使い勝手を上げようみたいな試みも進んでいる
さっき私が Chrome を例にしたのもまあそういうことで、Google がわざわざ kati や ninja のようなビルドツールをかなりのコスト割いて開発するぐらいにはみんなビルドを速くしたい
もちろんそれはそうで、でも逆に「コンパイラのバグや未定義動作を前提にした挙動を発見できる」みたいなのがあって (gcc と clang でコンパイルして比較できるみたいなもの)、その場合むしろコードの一致が保証されない (不一致に気付きやすい) のは言語や処理系を健全に保つための重要な性質にもなる
まあ多様性なんじゃないですか。言語を向いている人もコンパイラを向いている人も小規模プロダクトを向いている人も大規模プロダクトを向いている人もいるし、でも結局どこの人もコンパイル高速化できるならそれに越したことはないと思ってるよ
言語仕様側でも、文法を LL(k) に抑えると複雑性とか IDE / Language Server あたりで嬉しいから云々みたいな話があったりするので
rustcが遅いと最初に被害を被るのはrustcの開発者なので、rustcの開発者がrustcが遅くていいと主張するかなという疑いは大いにある。
あるいは別の話だと……極端だけど、昔は 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を並べると実行可能なプログラムになるチューリング完全な関数型言語だよ (?)
インタプリタならTじゃなくてI字の図をよく描きます。下に実装に使った言語、上に解釈する言語。
iOSDC Japan 2018 「圏論とSwiftへの応用」発表スライドメモ - Qiita
https://qiita.com/inamiy/items/3e0c10d5eaf234b41c3d
コンパイラといえば、そう、圏論ですね?
A「コンパイラといえば圏論」
B「コンパイラといえばグラフ理論」
C「コンパイラといえば充足可能性問題」
このアカウントは、notestockで公開設定になっていません。
rune とかいう概念全然わかってなくて (触れる機会がないので)、 codepoint や grapheme cluster とはまた別の概念なのかな……