はてなキーワード: 引数とは
プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が「俺もパソコン1台で凄い技術者になって…!」とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで「お前らは絶望的にプログラミングに向いてないからやめろ」なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。
近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。
開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のものが出回っている。Eclipseとか今考えるとよくあんなので開発できてたな。
いまや小学生からおばあちゃんまでアプリ作りに熱中し、高校生はIoTとかやり始め、大学生は商業レベルか?ってレベルのものをネットで発表し、私はウェブアプリのスマホでのレイアウト崩れひとつすら直せず静かにエディタを閉じてnoteで過激タイトル記事を書いている。
掛け算に順序があると思っているような知能の下級雑用係(自分のことを教育専門職だと思い込んでいる)ですら「小学生にプログラミングを教えるぞ!」と意気込んでいる。やめろ。お前らには無理だ。無理だからマジでやめろ。考え直せ。無理だって。掛け算に順序つけないと相手に教えられないレベルのやつがプログラミング教えるのマジで無理だって。算数とは次元が違うって。「ピーチ姫いつも簡単に誘拐できるし今度はベヨネッタも誘拐してみるか」ぐらいの無謀さだって。やめとけ。マジでやめろ。
まあそんなこんなで入り口はめちゃくちゃ広く、入門するのはマリオカートより簡単である。話逸れるけどSwitchのマリオカート、運転アシスト機能ついて初心者でもコース完走できるようになったから心折れちゃった人ももう一度チャレンジしてみてね。
それとは特に関係ないんだけど、大学行ってた時ティーチングアシスタント(TA)っていう授業のお手伝いさせられたのよね。ちゃんとお金出るやつ。
学部の3年か4年から始まって、院の1年か2年までやってて、途中で休学挟んだから、ええと、あー、うん、数年間TAやってたんよ。数学とプログラミングのコマ。CとOctaveとかいうやつ。Cのほうは情報学科で、Octaveは違う学科。JavaとかC++のコマはTA入れさせてもらえなかった。
プログラミングの実習は週2コマ(連続)あって、情報学科なら必修科目。なのでサポートは相当手厚く、先生とTAが絶え間なく机間巡視し、わからないことがあればセンパイがなんでも答えてくれるというわけだ。授業外でもサポートはしており、わからなければ先生や研究室にいる学生に好きなだけ聞きにいっても良いということになっていた。必修だから落とされたら困るしな。
2コマだから3時間 * 15回で、45時間。そして私の時は2年まででC/C++/Javaと必修だった(今はなんの言語かは知らない)ので、その3倍、135時間は最低やることになる。プログラミング実習以外にもプログラミング触る授業多いから実際はもっと多い。宿題やる時間もあるので実際はもっともっと長くプログラミングに触れることになる。卒論書く時期に入ると、テーマによっては書く人はさらに書くので、もっともっともっともっと長い。
これだけ時間をかければほとんどの人がプログラミングできるように……ならない。むしろできない人の方が多い。なんで。why。教えて。
会社になるとさすがにプログラミングできるできないは死活問題である。
「今日から入ったxxでーす。業界未経験ですがよろしくおねがしまーす。さっそくなんですけどPythonのここわかんないんですけどどうすれば……あっそうすればいいんですね。次はここなんですけど……なるほど!ありがとうございます。じゃあまた明日ー」
いやー社会人にもなると熱意が違うね。学生なんかわかんなくてもほとんど聞きに来ないのにな。こりゃガンガン伸びますわ。私も社会人1年生でPythonなんて3秒ぐらいしか触ったことないから適当答えてるけど。
「ちょっとお時間よろしいですか?」「いやちょっと今忙しいから後になっちゃいますわ。すんません……」
そんなこんなで1週間ぐらい放置してしまった。やべー絶対嫌われる。どこまで進んだかな……?えっまだそこ?進んでなくない?
もしかしてこれ全部教えないとダメなやつか。そりゃ大学4年間プログラミングやったやつでもプログラミングできないんだから、そうか。よく考えると当たり前だよな。
プログラミングをやめろ
大学4年間と大学院2年間プログラミングやったやつでもできないし、会社で毎日8時間を数週間プログラミングについやしてもできないやつはできないし、そもそも人類というのはプログラミングできない可能性がある。
少年少女たちに「プログラミングはいいぞ!自由にものが作れて達成感がある!頭が良くなった気分にもなれるし!」と吹聴してまわんのもいいけど、6年間情報科学について勉強したようなやつの大半がプログラミングできないんですよ。それもごくごく初歩的な部分。
野球とかサッカーなら、まあ友達との試合には参加できなくてもごく稀にバットにボールを当てたり、ボールを1回あらぬ方向に蹴ったり、ぶっちゃけ周りとのレベル差で楽しくなくてすぐやめちゃうだろうけど、なんとか基礎の一部ぐらいはできるじゃないですか。
ピアノとかダンスでも、猫踏んじゃったをごくごくゆっくり弾くぐらいはできるかもしんないし、学芸会の振り付けを10秒ぐらいは踊れたりできるかもしれない。その後やっぱ周りのレベル見て諦めちゃうかもしんないけどさ。
プログラミング、6年やってミットを頭にかぶってるバッターとか、鍵盤蓋の上から殴って音鳴らそうとするやつとか、まずそういうレベルのやつが大量発生するんですよ。だいたい7割ぐらいの率。どうすんだよこいつら。私の教育の問題か?マジで?本当に?
プロが練って考えて凝縮した本や授業、センパイたちによる指導。それらを結集して得られるはずのものが7割ぐらいどっかに消し飛んでる。無駄だろこれ。
今からプログラミングやろうとしてるやつ、お前は確実に向いてないからさっさと諦めて刺身にタンポポ乗せる仕事に戻ってくれ。参加しても鍵盤蓋叩き割るやつと同じ病室に入るだけだ。
プログラミングをやめろ。
ぼくはこう思うんですよ
そもそもなんで大の大人がそんな両手にバット持ってセカンドに立ったりゴールの方をボールのところまで動かす奇行に走るんだろうな。わかんねえや。
綺麗な分析はできないけど、いわゆる「できない」やつが共通して言ってたフレーズがある。
「ぼくはxxxだと思ってるんですけど、動かないんですよ」
うん、そうだね。そう思うんだ。でも動いてないじゃん。じゃあ違うんじゃない?モニターに「にらみつける」やってもバグは取れないし防御力下がるだけだぞ。
まず根本的に考えと事実が違ってるって結果出てるじゃん。じゃあもう考え変えちゃえば早くない?
名言の引用は好きではないけど、「プログラムは思った通りには動かない。書いた通りに動く」って言葉がある。実に名言だと思う。次点で好きなのが「ある問題を解決しようと正規表現を使うと問題が2つに増える」かな。
お前が何を思っているかはプログラミングにおいて一切影響しないんだよ。お前が何を書いて、コンピュータがどう処理したか、それが全て。
深く考えないことについてぎゃーぎゃーいうやつもいるけどプログラムなんてまず最初は動けばいいんだから何も考えずに次試せばいいだろ。んで3回ぐらいは自分で思い浮かんだの試して、全部ダメだったら調べるとか先生に聞いてみるとかさ。逆に1発で通ったら自分の思考見直して理解深めるとかさ。
ドキュメントとかあんまり理解できない初心者のうちは、とにかくお試しと修正のサイクル回すの重要で、「これがこうだから動くはず」というカードを3種類ぐらい作って全部片っ端から試すのが早いと思うよ。モニターをにらみつけるな。
お前がどう思ってるかよりも、まずはお前の書いたプログラムがどう動いているか(どう動いていないか)を確認するのが先だ。動かなかったら考えが違う、はい次のプラン、はいその次のプラン、はい次。
この「ぼくはこう思ってる」が出てくるの、なんの教育の成果なんだろうね。お前の気持ちなんてどうでもいいって現国でも数学で散々教えられただろ。
Error: variable 'a' is undefined, line 24
↑のエラーは架空のエラー文(英語下手でも許して)だけど、エラー、出るよね。プログラム組んでたら。んでやっぱいるのよ。エラーを「にらみつける」やつ。解決しねえって言ってんだろ。
「エラー出たんですけど、どうすればいいんですか」
「エラーにはプログラムがなぜコンパイル通らないかの原因がそのまま書かれている。例えば今出ているError: variable 'a' is undefined, line 24は、24行目の変数aが未定義ということを示している。事前に変数aを定義していないか、打ち間違えてsになっているとかではないのかな?」
だいたいが「腑に落ちねぇー」みたいな顔する。まあ、一気に喋りすぎたしな。疑問点1個1個潰していくか。
「何か疑問点ありそう?変数ってなにー、とか、定義ってなにー、とか」「ないです。わかりました!」
わかったのか。よかった。またモニターをにらみつける開始。なんでだよ!!!!「お前顔にチョコついてるぞ」って言われたらチョコ拭き取るだろ。変数aが未定義ですねって言われたら変数a定義すりゃいいだろ。
でもプログラミングド下手なやつ(全人類の7割ぐらい)は、エラーをにらみつけてる。ずっとにらみつけてる。防御力下限まで下がったかな。にらみつけてて何が変わるんだよ。
「英語読めなくて……」
いや「a is undefined」なんて「He is Superman」ぐらいの英語だろなんで読めないんだよ。お前この大学どうやって入ったんだよ。たしかどの入試方式でも英語あっただろ。単語わからんかったらググれ。
「aが未定義って書いてあるんですけど、ここのfor文の私の考えが間違ってるのでしょうか」
いや24行目のaって書いてるだろ。まずなんでそこ無視するんだよ。お前がfor文で使ってんの教科書通りのiだろ。24行目ってわかるか?for文あるの40行目あたりだよな?aとiが違う文字ってわかるか?
「さっきのエラー直したら新しいエラーが出たんですけど、どうすればいいですか」
千尋!贅沢な名だねえ
変数に名前をつけろ。関数に名前をつけろ。クラスに名前をつけろ。全てに名前をつけろ。
C言語の古い教科書だと「a」とか「b」とか「i」とかで書いてるけど、そんなの人間が読めるわけねえだろ。冷静に考えろ。「input」「output」「index」とかにしとけ。
2重for文の変数名i, jにしたら絶対途中で打ち間違えるだろ。お前は打ち間違える。そういうやつだ。2重ループなんてどうせ行列計算の課題だろ。rowとcolumnにしとけ。これで打ち間違っても気づくし、それぞれに意味が付いてくる。
ちなみに同じ長い名前にも優劣がある。「result」よりも「sum」のほうが強い。「result」はなんの結果かわからない(全ては結果であるので)が「sum」は合計値であることがわかるからだ。「password」と「plainPassword」なら「plainPassword」が勝つ。暗号化されていないパスワードであることがわかるので、情報量が多いからだ。
ただし例外はいくつかある。「tmp」は一時変数であることが(プログラマにとって)明らかだ。「dir」はディレクトリであることがわかる。「src」「dist」あたりもよく使われる。このあたりは短くていいんじゃねーかな。
でも、この前温度センサ扱うプロジェクトで「tmp」って変数名使って温度(temperature)と脳内で混線してバグって発狂してた同僚いたけど。そういうときは名前長くするか別の名前使おうな。
関数の名前なんて「calcAverageFromArray」ぐらい長くしていいから。「myFunc」とかしなくていいから。「fetchJsonDataFromUniversityInternalServer」とかでいいから。マジで。いやこれ本当に。
そもそも今時ディスプレイでかいし、識別子なんて先頭数文字打ったらエディタが補完してくれるし、短くするメリットがない。
それでも名前が長いと感じる?関数がでかすぎるんじゃないか。細かく処理を分けるとかしてみろ。「combineArrayAndFindMax」関数は「combineArray」と「findMax」に分割したらいいと思うぞ。名前が長いと思っても名前を削るな、機能を分割しろ。自然と名前が短くなる。
それかシンプルでかっこいい名前を見つける。「convertEvilHtmlToPeacefulText」は「sanitize」に置き換えることができる。イカす名前だ。
プログラミングできない奴はマジでこれらのことをやらない。ずっとaとかbとかzとか使ってる。お前それ自分で読めんのか。読めねえだろ。myfuncってなんだよ何するんだよ。お前自分で理解できてんのかそれ。
それでも頑なにaとかbとか使う。なんでだよ。
動作原理わからず書き散らすな。動作原理っつってもそんな深いところじゃなくて言語表面上レベルの動作な。
リテラルは値を作成して、代入は値に名前をつけている、とかその程度のレイヤー。メモリがどうこうとかはいらんと思う。あっでもポインタのときはいるか……。めんどくせえな。
まあ動作原理っていうか自分が何やってんのか理解してくれって程度の話になるんだが。
例えばfor文で処理50回まわすとき、「50回分の処理を行なっている」ではなく「ループ開始時に変数を初期化。条件判定して成立していれば文の中を実行する。条件変数の値を変化させてまた条件判定からやり直す」ぐらいの粒度で捉えててほしいかな、という気持ち。
これはfor文で詰まる人がやたら多かったからだ。彼らはfor文をアトミックな操作だと思っていた。つまりfor文はひとまとまりの命令であり、長いfor文とprintfの間に粒度の違いはないと思っていたらしい。
つまり、「for文の中でエラーが起こる」という事象がほぼ理解できない。forはアトミックであり、内部など見えないのだから。じゃあお前が今書いたfor文の中身はなんなんだってやんわり聞くと「さあ…?」みたいな反応が返ってくる。はあ。
関数についてもなかなか誤解が多かった。関数「sum_array(a, b)」と関数「average_three_numbers(a, b, c)」は全く別の原理で動いているのだと。ここでの「全く別の原理」というのはシグネチャが違うとか実装が異なるとかそういう意味ではなく、コーラを飲んでゲップが出る原理と糸電話で声が伝わる原理ぐらいの全くの別、という意味である。
彼らは関数ひとつひとつについて「新しく原理を学習」していたのだ。マジかよ……。どうやったらそんな発想に行き着くんだろう。そりゃ時間かかるわな。
そのため、関数が値を返す(または返さない)ということも理解できておらず、「関数の戻り値と関数の戻り値を足す」とか「関数の引数に関数の戻り値を直接渡す」とかやりだすと大パニックになる。メソッドチェーンとかやった日には大学潰れると思う。ただ、これはC言語が悪い部分もあると思う。配列とかいじりだすと、初心者が書けるレベルの関数だとあんまり値返さないしな。
たのむ、他のはできなくてもこれはできてほしい。自分が何をやりたいのかは理解してほしい。流石にお前のやりたいことなんて他人にはわからんぞ。
「配列の中の数値の合計値を求めたいんです」とか「名前と身長と体重をひとつにまとめた構造体が作りたいんです」とか。簡単なのでいいから。
「いま何やろうとしてどこで詰まってる?」って聞いても「……?」みたいな反応されたら困るんだよ。
例えば「キーボードから数値を10回入力し、それぞれの値を配列に格納して、最後に配列の値を逆順に表示せよ」みたいな問題が出てきたときに、「キーボードから値を入力する」「10回繰り返す」「配列に値を格納する」「配列の値を逆順に表示する」に分解できると思うんだけど、自分が何やりたいのかわからない奴はまずこれができない。
彼らには「キーボードカラスウチヲジュッカイニュウリョクシソレゾレヲハイレツニニュウリョクシテサイゴニハイレツノアタイヲギャクジュンニヒョウジセヨ」に見えている。
かろうじて「キーボード」「ハイレツ」あたりの単語は拾えるらしく、標準入力から値とったり配列を作ったりはしてるんだけど、そこから先に進まない。モニターにらみつけてる。またにらみつけるかよ。
あれだ、算数の文章題できなくてとにかく文章に出てくる数値足したり引いたりするやつ。あれのプログラミング版。文章が読めない。
こういう人にはメモ用紙取り出して、まず文章が何について言ってるのか、どういう工程に分けることができるのか、今後も同じことが起こったときにどうやって分けるのか。みたいなのを教えるんだけど、大抵あんまりしっくりこないらしく、成功したことは皆無。なんとかうまく教えたいんだが。
もうこのあたりになってくるとプログラミング関係なくね……?ってなるんだけど、意外とそういうプログラミング関係ないところで詰まる人めちゃくちゃ多いよ。
今すぐプログラミングをやめろ
いいえ、関数の引数が多すぎる(「Too Many Arguments」)問題の解決策としてConfigクラス(またはパラメーターオブジェクト)を使用すること自体は、一般的にアンチパターンとは見なされていません。
関数の引数が多すぎる状態は「コードの臭い(Code Smell)」の一つとされており、Configクラスなどの単一のオブジェクトに引数をまとめることは、その問題を軽減するための一般的な解決策です。
| メリット | 説明 |
| 可読性の向上 | 長い引数リストはコードを読みにくくしますが、関連する引数を一つのオブジェクトにまとめることで、関数シグネチャ(定義)が簡潔になり、何を受け取っているのかが明確になります。 |
| 引数の順序間違いの防止 | 位置引数が多いと、呼び出し側で引数の順番を間違えるリスクが高まります。オブジェクトとして渡せば、プロパティ名でアクセスするため、この種のエラーを防げます。 |
| 変更容易性の向上 | 新しい引数が必要になった場合、関数のシグネチャを直接変更する代わりに、Configクラスに新しいプロパティを追加するだけで済みます。これにより、関数の呼び出し元すべてを変更する必要がなくなり、マージの競合も減らせます。 |
| 引数のグループ化・関連付け | 論理的に関連する引数(例:`name`, `lastname`, `city`, `country` → `Address` オブジェクト)をまとめることで、その意図やコンテキストが明確になります。 |
このような引数をまとめるためのオブジェクトは、Data Transfer Object (DTO) やParameter Objectとも呼ばれます。
Configクラス自体が問題なのではなく、そのクラスの使用方法や、そもそも引数が多いという事実がより深い設計上の問題を示している場合があります。
引数が多い関数は、しばしば単一責任の原則(Single Responsibility Principle / SRP)に違反している大きなクラス(Large Class)や長いメソッド(Long Method)の兆候であることがあります。
Configクラスを作っても、根本的な問題は解決しない: 引数をクラスにまとめただけで、関数やクラスが多くの異なる責任を持ちすぎているという根本的な問題は解決しません。
対処法: この場合、Configクラスを作成する前に、関数が実行している処理をより小さな責任を持つ複数の関数やクラスに分割することを検討すべきです。
Configクラス自体が、もはや数十のフィールドを持つ巨大な「すべてを持つクラス」になってしまっている場合、それは設計上の問題です。
対処法: その巨大なConfigクラスのフィールドを、論理的なサブグループ(例: `DatabaseConfig`, `NetworkConfig`, `LoggingConfig`など)に分割することを検討します。
引数が数個(例: 2~3個)しかない関数に対して、引数をまとめるためだけにConfigクラスを作成すると、不必要なオーバーヘッドと複雑さが増すだけで、メリットが薄い場合があります。
対処法:Configクラスの使用は、引数の数が多すぎて(一般的に5個以上が目安とされることが多い)管理が難しくなった場合に限定するのが賢明です。
結論として、関数の引数が多すぎる問題をConfigクラスで解決するのは、有効な設計パターンです。
ただし、その解決策を適用する前に、「なぜこの関数はこんなに多くの情報が必要なのか?」と自問し、それがより大きな設計上の問題(SRP違反など)の単なる症状ではないかを確認することが、クリーンなコードを書く上で最も重要です。
-----
httpxが遅い件を確認してみた
https://b.hatena.ne.jp/entry/s/gfx.hatenablog.com/entry/2025/09/27/134421
プロファイルを取ってみると遅いのはconnection_pool.pyの_assign_requests_to_connections
302行目以下のループが曲者で、コネクションが割り当てられていないリクエスト数*生きてるコネクション数のN*Mループがあるのでリクエストが滞留してくると著しく遅くなる
httpx.AsyncClientにhttpx.Limits(max_keepalive_connections=1)を設定することで劇的に早くなるが、これはmax_connections=無限なのでやめた方がいいかなと思う
(httpx.Limitsの引数で省略された値は無限扱いであり、max_connectionss=無限となることから、全てのリクエストに無制限にコネクションを割り当てることでN*Mの片方がなくなって速いってこと。余談だがこのオプションもあまりいいものではないね)
一気にリクエストを投げつける使い方をしないと体感しにくいのではないかと思う
(その点では指摘者のユースケースはぴたりとハマってる気がするねw)
10代の頃って、「世界」というクソでかいものをよくわからないまま自己の中に組み込みがちだ。
結果的に当然処理しきれず、圧倒的な「世界」に降参することになる。
リリイシュシュのすべてを読んで、マジで最低な話だと思ったし、吐き気すら覚えた。
結局、ナルシスト的な被害者意識に閉じこもっていた自分から卒業しなきゃいけないってことだ。
世界と自己を同一視して「俺の世界=俺の苦しみ」みたいに抱え込むのは、構造的に破綻している。
まぁそれが美しいし、このリリイシュシュのすべてはその自己のなかに世界を抱え込むことによって生まれる気色悪すぎるけど美しすぎる世界を描いてるんだろうけど。
だから世界と自分を分離する。世界で何が起きても「へえ、そんなのもあるんだね。でも俺は俺だから」って言える距離感を持つ。
隕石が明日降ってきても「そっか、じゃあね世界」で済ませられるくらいに。
俺はエーテルというのは関数のようなものなのではないかと思った。
いじめられている子にとっての世界とは「自分をいじめるもの」でしかない。
けれども、自分と世界を分離することで、世界の中には「いじめるもの」もあれば「助けてくれるもの」「助けないもの」「何もしないもの」とてもたくさんのものがある。
たくさんありすぎて困るんで俺ら青春を情報科学とかいうドブに間違えておっことしちゃった人間には馴染みのある関数にして一般化してみる。
それは場合に応じて自己が持つ変数を引数にreturnを持つ動的な関数である。
自己: xの時、世界: f(x)でありいじめが起きた時、「司法に頼る」みたいな突拍子もない自己に世界を持っていたら思い付かないような閉ざされたアイデアを世界の引数に対して入力できる。
俺と世界は別であって、世界に対して俺は自由な入力を与えられる。
だからある時のxに対する世界: f(x)に執着する必要はない。
あるときf(x)が「いじめ」という最悪のyを返したとしても、それが世界のすべてじゃない。
別の入力x2を試せば、y2=f(x2)という全然違う出力を得られるかもしれない。
重要なのは「fそのもの」であって、個別のf(x)じゃない。俺たちは世界の像に絡め取られるけど、ほんとは関数自体の抽象的な存在が唯一の「世界」なんだ。
しかし関数という抽象化概念を人間とかいうクッソ低脳な猿が理解できる訳もないので、代わりにリリイシュシュがそれをエーテルとして表現した。
んで主人公の雄一や青猫は10代特有の自己と世界を同一視する世界観によってリリイシュシュの音楽を自己と同一視することで、そのエーテル=f(x)を自分自身と重ねる。
俺たちオタクは「自律・自立」に憧れつつも、そうはなれない人間的な弱さに対する「執着」だ。
自己と世界をごちゃ混ぜにして精神が参ってる10代の世界観は魅力的だ。
見苦しいオタク像は、脱毛をしないとか、オシャレじゃないとか、女の子に気配りができないとか、生理的に受け付けないとかそういうものを表現しがちだ。
けれども本当に俺らオタクが醜いのはそういった幼い世界観にいつまでも縋って、挙げ句の果てに世界を受け入れることができないことを知って、美しい世界だけを選び始めたことだ。
中途半端に世界から距離をとりつつも、自己の中に世界を組み込むことに固執している。
つまり可愛い女の子がイチャイチャしてる萌え〜なアニメを好んで選びその世界と自己を同一視して酔いしれるということだ。
てか、世界を選ぶ余裕があるってことは、その裏にある関数的な世界の構造を半分理解してるじゃないか。
そうだよ(便乗)ずっと俺らは知ってたのに知らないふりしてただなんだ。
ソースコードをいくら見てもそのソースコード作成者が想定してるエンジン側の実装なんて推測できんだろ。
ちなみにその「細かいこと」が気になった発端は初歩であるはずのコードの挙動の理解につまづいたからだけどな。
setTimeout(() => { console.log("A"); }, 1001); setTimeout(() => { console.log("B"); },1000); console.log("C"); 上のsetTimeout()の各第二引数の大小関係をどのように調整しても常に第二引数により小さい数が指定されたもののコールバック関数が先に実行されます。 これはどういうことですか?先にsetTimeoutと書かれたもののコールバック関数からキューに登録され、キューへの取り出し方はjsの場合fifoが採用されているので、上記のコードのような場合は、()=>console.log("A")の方が先にキューに登録されたものとして第二引数に無関係に()=>console.log("B")より先に実行されるのではないのですか?-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250908192456# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaL6u+QAKCRBwMdsubs4+ SAtwAP49XRX8yOJwd/XLSKjjP1TASfuVR29t/NIhuLSNb0vr2AD8CtGJTYMzavjS i9TuxJTV/DSYuwhuBLnKkd0lsJOldQI= =wm4J -----END PGP SIGNATURE-----
なら、settimeoutの第二引数の値はキューから取り出して実行するまでの待機時間ではなく、キューに登録するまでの待機時間だったって知ってた?
あとsettimeoutとかとプロミスじゃ入れられるキューの種類が違うというけどそもそもプロミスとsettimeoutは組み合わせて使うことが多いのであってその場合どういうフローでキューへの出し入れが行われるか明快に説明できる?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250908185341# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaL6npwAKCRBwMdsubs4+ SDmQAQDrOl1re7j2l6y55njYUqKdzCekEEPOiml4lmbi8Jd7vQEA/FNHVRyqpgCv Qxma+GrzVTZAKpTs3XMeK3ugthXwcAc= =5veI -----END PGP SIGNATURE-----
settimeoutの第二引数の値はキューから取り出して実行するまでの待機時間ではなく、キューに登録するまでの待機時間だったのか。
今まで前者の方で勘違いしてた。教科書はもっとこのあたり念入りに誤解されないように書くべきじゃないの?
独習jsでは「settimeoutを通じてコールバック関数がキューに登録される」というふうにしか書いてなくて、これだとsettimeoutが実行された瞬間に登録が行われると解釈されて仕方がないのでは。
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250903180046# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaLgDwAAKCRBwMdsubs4+ SBLAAP9Q43nJkJN5+gh1/ivCKSbCXezSj5wSftzmnJsSuRT/iAD/faSuVx09Gn/w /8GyJywKGTUkA8txtJI4+GFHAWLplQw= =qIYl -----END PGP SIGNATURE-----
彼が指摘するのは、可読性の問題だ。彼によれば、同じ処理を (a << 16) + b と直接記述すれば、プログラマは a が上位16ビット、b が下位16ビットを構成することを一目で理解できる。ビットシフトと加算という、コンピュータサイエンスの基本的な演算によって、処理内容が自明になるからだ。
「対照的に、make_u32_from_two_u16(a,b) と書いた場合、引数の順序がどうなっているのか、さっぱり見当がつかない。言い換えれば、物事を悪化させているだけだ」
https://b.hatena.ne.jp/entry/s/xenospectrum.com/linus-torvalds-rejects-google-risc-v-code-garbage/
今時点の使えそうな Sonnet4 を使ってコード生成とか業務でやる時に Typescript は案外うまくいかないことが多い。
UIとかシンプルなものであれば結構うまくいくけど、graphql, prisma みたいなところになると、token数すごくなるし結局完成しない。
この辺りが、なんとも小骨がひっかかるから。Typescriptの型ってやっぱりあれなのかと思って調べてもらったんだ。
↓↓↓↓↓↓↓
## ソフトウェア工学から見たTypeScriptの3つの根本課題
Web上の専門的な議論や論文では、TypeScriptの課題は主に以下の3点に集約されます。これらはすべて、JavaScriptという土台との不適合性に起因するものです。
1. 不健全な型システム (Unsound Type System)
ソフトウェア工学において、型システムの**「健全性(Soundness)」**とは、「コンパイル時に型エラーがなかったプログラムは、実行時に型エラーを起こさない」という保証を指します。
TypeScriptは、この健全性を意図的に放棄しています。
設計目標の不在: TypeScriptの公式ドキュメントには「健全であること」は設計目標ではないと明記されています。これは、JavaScriptとの互換性や開発者の利便性を優先した、根本的なトレードオフです。
具体的な不健全さ:
配列の扱い: string 型の変数に (string | number) 型の配列を代入できてしまうなど、配列の扱いに不健全な部分があります。これが原因で、実行時に数値を取り出してしまい、string型のメソッドを呼び出してエラーになる、といったことが起こり得ます。
any型と型アサーション: any型の存在や、開発者がコンパイラに「これはこの型で間違いない」と強制する型アサーション(as構文)は、健全性を根本から破壊する「抜け道」です。
関数の引数(Bivariance): 関数の引数の型チェックが、他の多くの言語(反変)とは異なり、より緩いルール(双変)になっています。これも実用性を優先した結果、理論的な正しさを犠牲にしている例です。
学術的な観点では、この「不健全さ」はTypeScriptの型システムが持つ最大の弱点と見なされています。
2. 構造的部分型(Structural Typing)の罠
TypeScriptは、クラス名などによらず「構造が同じなら同じ型」とみなす構造的部分型を採用しています。これはダックタイピングが主流のJavaScript文化に合わせた賢い選択ですが、ソフトウェア工学的にはいくつかの罠があります。
意図しない互換性: 全く異なる目的で作られた二つのオブジェクトが、偶然同じ構造を持っていたために、型チェックをパスしてしまうことがあります。これにより、ドメイン(業務領域)の意図とは無関係にコードが結合してしまい、予期せぬバグを生む原因となります。
過剰なプロパティの許容: const config: { port: number } = { port: 8080, host: 'localhost' }; のように、変数経由で代入すると、型に定義されていない余分なプロパティ(host)がエラーになりません。これは仕様ですが、開発者の意図しないデータが紛れ込むことを許容してしまい、セキュリティやバグのリスクに繋がります。
これは「TypeScriptの型は、データの『形状』を記述するが、その『意味』や『文脈』を保証しない」という根本的な限界を示しています。
3. 「漏れのある抽象化(Leaky Abstraction)」としての本質
Joel Spolskyが提唱した「漏れのある抽象化の法則」に倣えば、TypeScriptはまさにその典型例です。
TypeScriptは「静的型付け」という抽象化レイヤーを提供しますが、開発者は常にその下にあるJavaScriptの泥臭い現実(undefined, null, thisの挙動など)を意識し続けなければなりません。
抽象化の不徹底: 型を書いているときも、最終的にそれがundefinedになりうることや、thisが何を指すかを常に考えなければなりません。抽象化レイヤーが、下位レイヤーの詳細を隠蔽しきれていないのです。
摩擦コスト: この「漏れ」が、これまで議論してきた「Union地獄」や「境界での型変換の手間」といった、開発上の継続的な摩擦コストを生み出しています。
## 結論
ソフトウェア工学的な観点から見ると、Web上の専門家の議論は我々の対話の結論を強く裏付けています。
TypeScriptの課題は、個別の機能の優劣ではなく、「健全性を犠牲にしてでも、JavaScriptという動的な土台との互換性を最優先した」という、その成り立ちそのものにあります。その結果として生じる「不健全さ」「構造的部分型の罠」「漏れのある抽象化」といった問題は、この言語を使い続ける限り、アーキテクトが向き合い続けなければならない、本質的なトレードオフなのです。
進法や引数の《選択》は主観によるのは仰る通りです。それはそのかたも言っていて、自分も10進法は指の本数と同じで都合が良いからと認めています。
でも、片手で数を数える時は10進法的に指を曲げて数えるよりも、2進法を使えば折る指の形に重複がなく片手で31まで数えられるよ、と実演して見せて、進法の選択は自分の都合(主観)だけど数えてる数字は変わらず客観的でしょ、と説明しても、その方は理解を出来ていないようでした。
そのかたはメートルやフィートやインチなど単位が変わると計測可能な長さも変わると認識されていたので、単位の変換(置換)が出来ない、つまり、ありがとうとThank You(ママと母)が同じであるという例も踏まえて、抽象的な思考が出来ない人なんだと自分は判断しました。
自身で分数の徐算が出来ないと言っていましたので、恐らく1/2を0.5とか50%とか変換もできないのだろうと自分は予想しました。
自分もゴリゴリの理系ではありませんが、ifとThenの間に無限の可能性がある、と書かれるよりもx(y)の方がわかりやすいと思うタイプなので、純粋理系じゃないからこそショックでした。
例えば、万葉仮名がありますよね。あれは漢字の意味じゃなく漢字の発音と形だけを借用して日本語を表現してる文章ですが、【あ=安/阿/亜】など同じ音でも違う漢字である場合があります。
今我々が使っている日本語も、名詞や形容詞には《お》を使いますが、助詞には《を》を使いますよね。厳密にはOとWoで発音が違いますが、現代人の我々は発音を区別せずに、しかし役割は違うものとして運用しています。
進法やメートルも同じで、無限に代替可能だけど約束(定義)があるから前提知識が必要で難しくても頑張れば今の人でも読めるもので、夜露死苦なんてのも、その応用で、万葉仮名の漢字は主観(環境依存)の選択だけど、万葉仮名の法則は客観的なんだよ、と説明してもわかってもらえませんでした。
一度投稿したうえで別タブを開いてプログラム的(fetch)に送信してその別タブが閉じられる仕組み。
// ==UserScript==
// @name PGP未署名検出と別タブ自動編集
// @namespace http://tampermonkey.net/
// @version 1.0
// @description PGP署名がない投稿を自動編集ページへ誘導
// @match https://anond.hatelabo.jp/*
// @grant GM_setValue
// @grant GM_getValue
// @grant GM.openInTab
// ==/UserScript==
(function () {
'use strict';
const body = document.getElementById('entry-page');
if (!body) return;
const titleText = document.title;
if (!titleText.includes('dorawii')) return;
const pgpRegex = /BEGIN.*PGP(?: SIGNED MESSAGE| SIGNATURE)?/;
const preElements = document.querySelectorAll('div.body pre');
let hasPgpSignature = false;
for (const pre of preElements) {
if (pgpRegex.test(pre.textContent)) {
hasPgpSignature = true;
break;
}
}
if (hasPgpSignature) return;
const editLink = document.querySelector('a.edit');
const childTab = GM.openInTab(editLink.href, { active: false, insert: true, setParent: true });
})();
// ==UserScript==
// @name 編集ページ処理と自動送信・閉じ
// @namespace http://tampermonkey.net/
// @version 1.0
// @description 編集ページで署名処理と送信、タブ自動閉じ
// @match https://anond.hatelabo.jp/dorawii_31/edit?id=*
// @grant GM_getValue
// @grant GM_xmlhttpRequest
// @grant GM_setClipboard
// @grant GM_notification
// @connect localhost
// ==/UserScript==
(async function () {
'use strict';
const shouldRun = await GM_getValue('open-tab-for-edit', '0');
const textareaId = 'text-body';
const textarea = document.getElementById(textareaId);
if (!textarea) return;
const content = textarea.value;
const pgpSignatureRegex = /-----BEGIN PGP SIGNED MESSAGE-----[\s\S]+?-----BEGIN PGP SIGNATURE-----[\s\S]+?-----END PGP SIGNATURE-----/;
if (pgpSignatureRegex.test(content)) {
console.log('[PGPスクリプト] 署名が検出されたためそのまま送信します');
return;
}
const httpRequest = (url, data) => {
return new Promise((resolve, reject) => {
GM_xmlhttpRequest({
method: 'POST',
url: url,
headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
data: `value=${encodeURIComponent(data)}`,
onload: function (response) {
resolve(response.responseText);
},
onerror: function (error) {
reject(error);
}
});
});
};
// textarea の値を取得
// 1. 現在のページのURLからURLオブジェクトを作成
const currentUrl = new URL(window.location.href);
// 2. ベースとなる部分 (例: "https://anond.hatelabo.jp") を取得
const origin = currentUrl.origin;
// 3. 'id' パラメータの値 (例: "20250610184705") を取得
const idValue = currentUrl.searchParams.get('id');
// 4. ベース部分とIDを結合して、目的のURL文字列を生成
// idValueが取得できた場合のみ実行する
let newUrl = null;
if (idValue) {
newUrl = `${origin}/${idValue}`;
}
// 5. 生成されたURLを変数に代入し、コンソールに出力して確認
console.log(newUrl);
const valueToSend = newUrl;
try {
const signatureText = await httpRequest('http://localhost:12345/run-batch', valueToSend);
console.log('バッチ応答:', signatureText);
if (!signatureText.includes('BEGIN PGP SIGNED MESSAGE')) {
alert('PGP署名がクリップボードに見つかりませんでした。');
return;
}
const newText = content.replace(/\s*$/, '') + '\n' + signatureText + '\n';
textarea.value = newText;
console.log('[PGPスクリプト] 署名を貼り付けました。送信を再開します。');
const form = document.forms.edit;
const newForm = form.cloneNode(true);
form.replaceWith(newForm);
newForm.addEventListener('submit', async (e) => {
e.preventDefault(); // HTML標準のsubmitをキャンセル
const bodyText = textarea?.value || '';
// reCAPTCHA トークンの取得
const recaptchaToken = await new Promise((resolve) => {
grecaptcha.enterprise.ready(() => {
grecaptcha.enterprise.execute('hoge', { action: 'EDIT' })
.then(resolve);
});
});
// POSTするデータの構築
const formData = new FormData(newForm);
formData.set('body', bodyText);
formData.set('recaptcha_token', recaptchaToken);
formData.set('edit', '1');
try {
const response = await fetch(newForm.action, {
method: 'POST',
body: formData,
credentials: 'same-origin'
});
if (response.ok) {
console.log('送信成功');
window.close();
} else {
console.error('送信失敗', response.status);
}
} catch (err) {
console.error('送信中にエラーが発生', err);
}
});
// プログラム的に送信トリガー
newForm.dispatchEvent(new Event('submit', { bubbles: true }));
} catch (e) {
console.error('バッチ呼び出し失敗:', e);
}
})();
const http = require('http'); const { exec } = require('child_process'); const querystring = require('querystring'); const server = http.createServer((req, res) => { if (req.method === 'GET' && req.url === '/ping') { res.writeHead(200); res.end('pong'); } else if (req.method === 'POST' && req.url === '/run-batch') { let body = ''; req.on('data', chunk => { body += chunk.toString(); }); req.on('end', () => { const parsed = querystring.parse(body); const value = parsed.value || 'default'; // 値を引数としてバッチに渡す exec(`C:\\Users\\hoge\\Desktop\\makesign.bat "${value}"`, { encoding: 'utf8' }, (err, stdout, stderr) => { if (err) { res.writeHead(500); res.end('Error executing batch: ' + stderr); } else { res.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' }); res.end(stdout.trim()); } }); }); } else { res.writeHead(404); res.end('Not found'); } }); server.listen(12345, () => { console.log('Batch server running at http://localhost:12345/'); });
@echo off setlocal enabledelayedexpansion :: 署名するファイル名 set "infile=%~1" set outfile=%TEMP%\pgp_output.asc :: 以前の出力があれば削除 if exist "%outfile%" del "%outfile%" :signloop :: AutoHotkeyでパスフレーズ入力(gpgがパスワード要求するダイアログが出た場合に備える) start "" /b "C:\Users\hoge\Documents\AutoHotkey\autopass.ahk" :: PGPクリア署名を作成 echo %infile% | gpg --yes --clearsign --output "%outfile%" :: 署名が成功していればループを抜ける if exist "%outfile%" ( goto postprocess ) else ( timeout /t 1 > nul goto signloop ) :postprocess powershell -nologo -command ^ "$header = '>|'; $footer = '|<'; $body = Get-Content '%outfile%' -Raw; Write-Output ($header + \"`r`n\" + $body + $footer)" powershell -nologo -command ^ "$header = '>|'; $footer = '|<'; $body = Get-Content 'signed.asc' -Raw; Set-Clipboard -Value ($header + \"`r`n\" + $body + $footer)" endlocal exit /b
#Persistent #SingleInstance ignore SetTitleMatchMode, 2 WinWaitActive, pinentry SendInput password Sleep 100 SendInput {Enter} ExitApp
動けばいいという考えで作っているので余分なコードも含んでいるかもしれない。
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250613185036 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaEv1FQAKCRBwMdsubs4+ SHHkAQDUOLgBcdji2T6MJ7h/vlMdFfGlWAzNdXijjE1gIuEPywEAiMNMZqhrMmtl c7UqRuggNJ/UTa5xTIcKp622+7jJQQg= =Lgkl -----END PGP SIGNATURE-----
プログラミング言語のC++に暫く離れていたが便利そうな機能が出来ていたんですね。
自分が調べても色々理解しきれていないのでここの紹介で間違いがあったらすみません。
異なるクラスを代入して保持するものであり、例えばunionのような機能を実現できるらしい。
武器として使う場合は攻撃力変数は必要でも守備力変数は必要なく、
鎧として使う場合は守備力変数は必要でも攻撃力変数は必要ない場合らしい。
このような使わない変数を隠蔽しバグを作ってしまうことを回避できるらしい
例えば、boolで実装する場合は、関数戻り値をboolで成功か失敗かを返し、欲しい値を関数の引数のポインタに返す・・というプログラミングになると思う。
std::optionalでは戻り値として欲しい値と失敗かどうかを一緒に返せるらしい。
メモリの動的確保だが自分でdeleteしなくて良いのでメモリ解放忘れを防いでくれる。
スマートポインタは前からあったが現在の推奨はstd::unique_ptr
(C++20以上と記載していましたがC++11とのご指摘を受けたため修正しました。すみませんでした。)
列挙クラス
列挙型だが従来の列挙型と異なり変数名が外部と衝突しない
nodiscard属性が付いている関数は戻り値の受け取りが必須となる。
ちなみにstd::optional<std::string> obj;のように<>内に書かれているのは昔からあったテンプレート機能のようです。