LINQ/stream の話か！？
map.filter.map みたいなコードは書きがちで、これを順番にやってしまうとコピー回数が爆発します。
これは使い方の問題で、ある領域（関数）で閉じて使えば、その関数の中で把握されている挙動なので問題がなくなります。逆に関数の戻り値が遅延評価な Iterable を返すのは、処理が関数内で閉じないので、理由がない限りやめたほうがいいです。
Pleroma の twitter-text 互換挙動嫌いだけど、手を入れるのめんどうなところにあるから無効化できてなくてもっと嫌い！！！！！
C# だと僕はこういう操作をする関数の戻り値の方は IReadOnlyList か ImmutableArray のどちらかにします
Pythonのリスト内包記法 () がジェネレータ（遅延評価）で [] がリスト（正格評価）なので
データフローは大体 Source, Transform, Sink の形をしているので、イテレータを入力してイテレータを出力する Transform らしいインターフェイスをしていればイテレータを返すのは許されますよ
Rust の場合、ライフタイム的にイテレータじゃないと成り立たないのとかあるしね。 drain とか into_iter とか
僕の手札はこういうのですね～
[
[
[
[
[
計算1,
計算2,
計算3,
計算4,
]
for k in range(c)
]
for j in range(w)
]
for i in range(h)
]
for b in range(batch_size)
]
あなたは商品ではない時代が終わり、勝手にbotにされるようになった
C# の async 型を好き勝手できるやつ、関数呼んだ時点で最初の await まで実行されてしまう所為で使い道が狭まった気持ちがある
C# 書いてるとヒープアロケーションを忌避しがちになるのでバランスが大事（System.Runtime.CompilerServices.Unsafe）
著作権の研究用途でうんちゃら、著作物の思想や表現を楽しむことではなく統計データとして扱うという条件なので、その人を模した何かを作ろうとしてしまうと、さすがにわからないよなぁ
MakeGirlsMoe みたいな、オタク絵一般の統計をかき集めるのは OK だけど、ある作者の表現方法を再現しようっていうのを無断でやったらまた話が変わりそう
きりたん歌唱データベースとか、あれは声優の許可は取ってあるので声の部分は自由に使えるけど、曲の許可はない（これが研究目的の例外部分）ので、あれから声の特徴ではなく曲の特徴を、原曲がわかってしまうような取り出し方をして公開したら怒られそう
これ↓、個人的には全部 interface{} になるのが嫌かな……
https://twitter.com/kb10uy/status/1320779355786653696
Go から型が消えたら ♰Lightweight Language♰ になるじゃん！！！
実行時のトラブルを防止できるなら開発時 (コンパイル時含む) のコストくらいなんぼのもんじゃいという傾向は強いね >Rust
これはひとつマイクロサービス化するべき理由かもしれないなぁ。モノリシックなシステムで Rust のライフタイム込みの設計を仕上げるのは困難だけど、クリティカルで小さいサービス切り出したときには良い道具になる
JS でもなんでも書いたプログラムが動いてくれれば割となんでもいいんだけど、 Node というランタイムとライブラリが嫌いすぎる
環境適応を売りにしていきたいので、構文自体にはもう相当なアホな何かがない限り文句言わないことにします。 C の関数ポインタはアホ
リプ対応しなければ GitHub Actions だけで運用できそうとか思ってしまった
