このアカウントは、notestockで公開設定になっていません。
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
「ちゃんと」ﾎﾟﾖｸﾞﾔﾏとしてやるつもりなら C から逃げてはいけないと思うけど。
C より先に Rust をやるのは……理屈のうえでは十分可能だと思うけど、 C からやった方が早いと思うんだよな
Perl, Python, Ruby が並べられていたの、たぶん「*nix 環境ならだいたいどこでも使える (あるいはインタプリタが容易にｲﾝｽｺできる)」と「単独のスクリプトもｳｪﾋﾞｱｯﾌﾟﾘｹｯｼｮﾝも書ける」あたりじゃないかなぁ
や、 PHP でも CLI スクリプトは書けるけど……たぶんﾈｲﾃｨﾌﾞなｴｸｽﾍﾟﾘｴﾝｽにはならない気がするのよね
「ちゃんと」ﾎﾟﾖｸﾞﾔﾏをするわけではないがﾎﾟﾖｸﾞﾔﾐﾝｸﾞを真面目に学習するルートとしては、数学系とかから関数型にやってくるなどがある
ｳｪｯﾋﾞ系をやるなら……どうかなぁ。結局メモリまわりの感覚をある程度ちゃんと持ってないとどこかでﾊﾟﾌｮｰﾏﾝｽとかの問題に引っ掛かりそうだし、それを直すのって結局メモリの扱いわかってる人じゃない？ (しらんが)
ちょっとまてよ、もしかして Rails 以前から Ruby って相応に有名だった？ (日本にいるとそれだけでバイアスかかるからわからん)
なぜ初手で Rust するより C 経由した方が早いと思うかというと、 Rust って「制限を増やしていくことで言語が豊かになる」というタイプのものなので、「機能を増やしていくことで豊かになる」とは真逆なのよね。
もっと具体的には、 C だと「一部言語機能だけを使えるサブセット」みたいなものを容易に定義できるしいろいろ書けるけど、 Rust だと「一部の検査だけを使えるサブセット」みたいなのはサブセットになってない (本物の Rust でコンパイル通らない) のであまり役に立たない
結局、その「制限」の部分が本質的にコーディングや挙動にどう影響するのかを把握するには、制限の少ない環境で何ができるか (できてしまうか) をわかっていた方が早いわけで、それが Rust より先に C をやった方がいいと思う理由
C のポインタがわからなくて Python や JS や Lisp が十分わかるというの、ありえなくない？ と思ってしまうわね。それ絶対わかってないよ
このアカウントは、notestockで公開設定になっていません。
ポインタが明示的でない言語 (あるいは tracing GC が言語機能に入っている言語) って「透過的な参照」という概念を扱っているので、ポインタが明示されるより絶対にややこしいよ
https://mastodon.cardina1.red/@lo48576/105989982881427387
これは deep copy と shallow copy についてのボヤき
C みたいにポインタが明示されていればデフォルトが deep copy でもその走査がポインタで切れるのは自明なのに、参照と値そのものを透過的に扱おうとするから解釈が厄介になる
Java か何かの文脈で「参照の値渡し」みたいな謎概念を発明してる人々を見るとｱｯ……という顔になる
低レイヤの挙動からボトムアップに理解しようとする人と、下のレイヤは完璧に隠匿されているものとして上位の抽象からトップダウンに理解する人が居て、これはもう個人差なのでまあ
ところで、現代の計算機は PDP-11 の発展版では決してないため、C を学んでも low-level が本当に理解できるかは怪しい。
C Is Not a Low-level Language: Your computer is not a fast PDP-11.: Queue: Vol 16, No 2 https://dl.acm.org/doi/10.1145/3212477.3212479
逆に、 Python や JS での変数の書き換えについての諸々の挙動をちゃんとできる人だったら、絶対そのまま C やったらポインタで躓かないと思う
Lisp のコードをみたとき、函数適用の列に見える人と、C like な linked list の列に見える人がいる
Lisp の (begin) とかを見てすごく微妙な気持ちになったのを思い出した。
ちなみに Haskell の do の内実を見てめちゃくちゃスッキリした
Scheme も Haskell も碌にやってないけど、個人的には Haskell の方がしっくりくるんだよな
たぶん Scheme の破壊的変更を活用していくところがスッキリしないのだと思う
このアカウントは、notestockで公開設定になっていません。
やれるならいくらでも下に行くべきだと思うけどね…… (ﾜｲ自身は論理回路からなので、そのくらいから始めるのは実際おすすめ)
論理回路から順番に上がっていけばさすがにポインタ程度で躓かないよ
このアカウントは、notestockで公開設定になっていません。
ハンドコンパイルできる程度に単純で、ある程度の抽象ができるような、構造化プログラミング言語…… C の他に思い当たらない
BASIC は……正直微妙かなぁ。いや BASIC をリッチにすればできるのかもわからんけど、それって単に C の文法を挿げ替えただけみたいな感じにならへん？
「CPU の声が聞こえる」じゃないけど、素朴にハンドコンパイルできる程度に素朴でありながらそこそこリッチな言語が欲しいんだよな
むしろ C がそのくらい素朴 (なものとして捉えることもできる) だからこそ、アセンブリ言語をやらなくても C で “履修免除” されるという感覚がある
このアカウントは、notestockで公開設定になっていません。
なんだっけ、 Featherweight Java とか実は学習向きだったりしません？ (しらんけど)
その理論でいくと Pascal も P 言語とスタックマシン、みたいなかんじでいけるのでセーフ
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Lisp 処理系、NScripter 上の実装などもある。『魔法言語 リリカル☆Lisp』をやろう。
治安が悪い界隈に長居しすぎて、 Pascal を書かない本物のプログラマの話かと思ってしまった
『本物のプログラマは Pascal を使わない』邦訳が掲載されたりした『bit』誌は全巻 Kindle で発売中なので買いましょう、ちなみに『本物のプログラマは Pascal を使わない』は 1985 年 4 月号のはず。
Frequently Appudated Questions
ヒープアロケーションなしの実装とありの実装でのコード共通化を試みているけど、これ疲れる……
まあ本質的に疲れるのはヒープアロケーションなしでの文字列操作そのものであって、共通化とかは実はそんなに大したことない説はある……
念の為と思って分割しておいた関数に想定外の場面で使い道が生えてきたので、めちゃくちゃ気分が良い (micro optimization)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ｺｲﾝﾊｲﾌﾞやクソ広告などの問題にも本質的に関係のある部分で、根が深い
新実装でテスト回してみたけど、 ../../../g を http://a/b/c/ に対して解決したら http://g になった……
テスト書いててよかったー！！！
とりあえず書き直す前と同等の機能が動くところまで来たけど、テスト込みで352行だったコードが794行になってる……
これはメモリアロケーションの極限までの削減と釣り合うのだろうか？
コードを読むときの勘を発生させて数時間前の自分をボコボコにしているときが、プログラミングで一番満足感がある
やちんを入れるとできるのが入居
おちんちんを入れることができるのが巨乳
https://datatracker.ietf.org/doc/html/rfc3986#section-2.4
> The only exception is for percent-encoded octets corresponding to characters in the unreserved set, which can be decoded at any time.
で、ピリオドって unreserved なんだけど、もしかして %2e%2e/baz を scheme://host/foo/ に対して解決したら scheme://host/baz になったりします……？
https://datatracker.ietf.org/doc/html/rfc3986#section-5.2.4
remove_dot_segments ルーチンが %2e や %2e%2e を . や .. として認識する必要があるかということです
うーん、ひとまず考えなくていいかという気持ちにもなっているが、確信を持てないのでちょっと嫌だなぁ……
でもなぁ、 remove_dot_segments って . と .. のセグメントを全部なくす前提だから、それを迂回して .. を残せるというのはセキュリティ的にマズい気がするんだよなぁ。
無視するには悪用しがいがありすぎる
2022年1月と2月のアプリの仕様変更「カードを使った入金機能の変更」と「カードを使った送金およびすべてのアカウントからの送金に対応」に関する事前のご案内 - Kyash お知らせ
https://www.kyash.co/information/20220106
あーあ
オワ
今更送金できるようになっても、もう近隣のオタクみんなKのこと見捨てたあとだよ……
最初からカード送金可能のままにしてくれていれば、喜んで布教したんだけど……もう遅い
カードリンクなくなると言っても、要は Suica のオートチャージみたいな指定額自動入金になるっぽいという話なので、残高が残ってしまうことを許容すればべつに普通に使えそう
残高を下回ったときの入金額が指定額とは書かれていないのが不気味だけど
async trait のやつ、便利なんだけど元のシグネチャが cargo doc から分かりづらいのがやや難ありなんだよな
むしろ doc の方が本来のシグネチャなので問題ない (?)
async trait 側で勝手にコメント追加とかできないんかな、
original signature is below:
.....
みたいな感じで
doc comment、 #[doc = "..."] のシンタックスシュガーなので、属性足せるなら問題ないし、実際足せたはず
https://datatracker.ietf.org/doc/html/rfc3986#section-2.3
> However, URI comparison implementations do not always perform normalization prior to comparison (see Section 6).
> For consistency, percent-encoded octets in the ranges of (中略), period (%2E), underscore (%5F), or tilde (%7E) should not be created by URI producers and, when found in a URI, should be decoded to their corresponding unreserved characters by URI normalizers.
もしかして、 URI を resolve する前に normalize のフェーズを通すのが望ましいぞと言っている……？
normalize→resolve したら %2E%2E/bar の解決は ../bar の解決と同じ結果になるよね
慌てて家のエアコン遠隔でつけたけど焼石っぽそうだなこりゃ
encoding - A url resource that is a dot (%2E) - Stack Overflow
https://stackoverflow.com/a/24867425
だよなぁ……
一般的なユーザが思想でソフトウェアを選ばない話、ﾏｽﾄﾄﾞﾝがﾌﾞｰﾑになったとき「思想から入るソフトは流行らない」みたいなことをしたり顔で言ってた人々を思い出しちゃうなぁ
まあ流行りしか評価基準がないなら、それで合ってるんじゃないですか
や、内心では %2E は remove_dot_segments 前に . に置換するのが正しいのだろうという解釈の側に振れているんだけど、世界のソフトウェアがそのような実装になっていないことに関して interoperability とかの問題をどうするよという悩みが
Re: File URIs, home and relative paths from Matthew Kerwin on 2016-06-08 (uri@w3.org from June 2016)
https://lists.w3.org/Archives/Public/uri/2016Jun/0002.html
> Since '.' is an unreserved character we can't even use "%2E" to smuggle it through the remove_dot_segments algorithm.
このスレでも %2E が remove_dot_segments で解釈されうるという話は否定されてなさそう
このアカウントは、notestockで公開設定になっていません。
ホイールが 3 つあるということは拡縮・上下スクロール・左右スクロールが片手でできるということ……
