  |
はてなキーワード: 変数とは
.txt と .TXT で挙動を変えていた話しがあったやん？
プログラム全体で、TxtFileExt が一カ所でしか使われてないなら、変数にする必要はほぼないけど、
２か所、３カ所になったら、.txt を .TXT に変えるだけでもミスする人でてくる。
.txt を .debug.txt とか .masuda.txt に気分次第で変える時も楽やん
const 〇〇ParamIntMax = 25;
もプログラム全体で、一カ所しか使われてなければ変更ミスは生じないけど、
何カ所にも別れたら、変更時に見落とすやん。
いろんなアプリケーションのメンテ(バグ取りとか細かい機能追加とか)を何度か経験してきた。
主にテキストファイルとかCSVファイルとかExcelファイルとかを入出力するものばかりだったんだが、その大半がファイルの拡張子をグローバル変数化していた。
こんな感じ
const TxtFileExt = ".txt"; const CsvFileExt = ".csv"; const ExelFileExt = ".xlsx";
outFileName = 〇〇 + ×× + "ABCDEFG" + TxtFileExt;
みたいな指定をしなきゃならない。
あと、プログラム言語の標準的なメソッドのあらゆる引数も全部変数で定義されてて、そのまま渡すのは禁止、みたいな規約になってる。
たとえば引数が三種類(true、false(未指定時のデフォルト値)、任意の数値(ただし当該プログラムでは0、10、25以外指定不可))しかないやつはこんな感じ。
const 〇〇ParamTrue = true; const 〇〇ParamFalse = false; const 〇〇ParamIntMin = 0; const 〇〇ParamIntMid = 10; const 〇〇ParamIntMax = 25;
const charCodeSJIS = "Shift_JIS"; const charCodeUtf8 = "UTF-8";
以前関わった改修内容に「××の処理は開始時と終了時にそれぞれUTF-8(BOMなし)形式でログを出力する」みたいなのがあって、普通に文字コード指定する部分に「UTF-8」で直に書いたら、規約に従ってないからとコードレビューで指摘されて差し戻されたんだけど、そもそもこういう規約って何の意味があるの？
「与えられた変数のオーダーに従って、それが許容される計算量のラインのアルゴリズムを探して、それを実装するゲーム」
って理解で合ってる？
難しいところは
・アルゴリズムを探す
・実装する
という認識でいい？計算量がいくら許容されるかは結構すぐわかりそうだし
で最終的には「アルゴリズムを探す」という点に終着する。アルゴリズムがわかれば、実装するというのは比較的簡単だろうしね
この変数のオーダーならO(n^2)でも大丈夫だけど、これはO(logn)のアルゴリズムが必要だ。O(logn)のアルゴリズムで処理したデータはこの程度のオーダーなので......。これを繰り返していく感じ
自分はマジで最初の最初の問題すら実装できないんだけど（AtCoderならABCのA問題すら ChatGPTの解説が必要）
電気料金が複雑化しすぎて、どの電力会社が得なのか計算しきれなくなってるんだけど、どうしたらいい？
たとえば、自分（単身者）の3月の電気料金は、「まちエネ」で20A契約（きほんプラン20A）・124kWh・4016円だった。
4016円の内訳
まちエネから東京電力エナジーパートナーの「従量電灯B」か「スタンダードS」に変えたいと思っているんだけど、変数が多すぎてどれが最も得なのかが分からないんだ（電力比較シミュレーションを使っても燃料費調整額などはなぜか計算されない）。
ちなみに年間で最も電力を使わない月は98kWh、最も使う月は322kWh。
発達障害みたいなバグを量産してしまってチームからの目が痛い。
正直これはPythonのせいだ。
例えば
if is_checked:
この構文、”False"という文字列ではTrueになってしまう。想定外にオブジェクトが入ってしまっても普通にTrueになってしまう。想定外のNoneが来てしまうとFalseになって開発中はなかなか気付かないなんてこともある。基本的にifの後は if hoge == True: と書くべきだと思ってる。linterで怒られることもあるが、それよりもバグに気付けない方が怖い。
if "1" == 1:
これはfalseだけど、これが変数で来てたりすると全然気付かない。
for i in user_list:
こんな構文でuser_listにはリストが来ることを期待していたのに文字列を入れてしまうことがある。
そうなるともうぐちゃぐちゃ。
user_list += user_id
これはuser_idが ["hogehoge"]ならうまくいって"hogehoge"なら["h", "o", "g", "e", ...]が追加されることになる。
これも気付きにくい。
いずれも開発段階では気付かないことが多い。テスト段階になったり、テストないような突貫工事体制だとリリース直前の動作確認で気付いたりする。
リストを入れるつもりだったのに文字列を入れてしまったりbooleanを入れるつもりだったのに文字列が入れられるからこんなことになる。性的型付けしか受け付けたくない。
コーンフレークじゃなくて、Haskellだとして、全体のネタを書き直してくださいっていう指示した結果
ボケ＆ツッコミ「お願いしますー ありがとうございますー」
ツッコミ「あー ありがとうございますー ねっ 今Githubでスターをいただきましたけどもね」
ボケ＆ツッコミ「ありがとうございますー」
ツッコミ「ねー 有り難いですよ ほんとにね」
ボケ「入れておきましょう」
ボケ「いきなりですけどね うちのオカンがね 好きなプログラミング言語があるらしいんやけど」
ツッコミ「プログラミング言語の名前忘れてもうて どうなってんねそれ」
ツッコミ「分からへんの？ いや ほな俺がね おかんの好きなプログラミング言語 ちょっと一緒に考えてあげるから どんな特徴ゆうてたかってのを教えてみてよ」
ボケ「あのー関数型言語で、型システムが強力で、遅延評価するやつやって言うねんな」
ツッコミ「おー Haskellやないかい その特徴はもう完全にHaskellやがな」
ツッコミ「すぐ分かったやん こんなんもー」
ツッコミ「いやそうやろ？」
ボケ「オカンが言うには 将来の夢はそれで書かれたOSを使うことやって言うねんな」
ツッコミ「あー ほなHaskellと違うかぁ Haskell製のOSなんてまだ無いもんね」
ボケ「そやねん」
ツッコミ「HaskellはOSを作るのには向いてへんからなぁ」
ボケ「そやねんな」
ツッコミ「な？ Haskell側もOS開発に任命されたら荷が重いよあれ」
ボケ「そやねんそやねん」
ツッコミ「Haskellってそういうもんやから ほなHaskellちゃうがなこれ」
ボケ「そやねん」
ツッコミ「あれほなもう一度詳しく教えてくれる？」
ツッコミ「Haskellやないかい モナドは確かに難しいねんHaskellの でも俺はね あれはHaskellの良いところやと思うねん 俺の目は騙されへんよ 俺騙したら大したもんや」
ボケ「まあねー」
ツッコミ「ほんであれよー いざ使ってみたらね モナドのおかげでコードがスッキリするねん 俺は何でもお見通しやねんから Haskellのモナドなんて」
ツッコミ「そうやろ」
ボケ「オカンが言うには プロダクションで使うにはまだ早いって言うねんな」
ツッコミ「ほなHaskellちゃうやないかい プロダクションでHaskell使ったら 上司がひっくり返すもんね Haskellはねー まだ研究段階やから実務では使いにくいねん」
ボケ「そやねんそやねん」
ツッコミ「な？ Haskell使ってみたらだんだん罠が見えてくるから 最後ちょっとだけ避けてまうねんあれ」
ボケ「そやねんそやねん」
ボケ「そやねんな」
ツッコミ「Haskellちゃうがな ほな もうちょっとなんか言ってなかった？」
ボケ「学生の頃 なんでみんな憧れるんか分からんかったらしいねん」
ツッコミ「Haskellやないかい 学生の頃はHaskellとOCamlとLispに憧れるんやから あとSmalltalkも憧れたな Haskellそんなもんよ」
ツッコミ「そうやろ」
ボケ「オカンが言うには 関数型プログラミングの教科書に必ず載ってるっていうねん」
ツッコミ「ほなHaskellやないかい 教科書のサンプルコードにHaskellのコードが出てこんわけないやん」
ツッコミ「Haskellはね 関数型プログラミングの王道中の王道やねん」
ツッコミ「Haskellや絶対 ほな ほなもうちょっとなんかゆうてなかったか？」
ツッコミ「Haskellやないかい Yesodとかあるやろ な？ RubyとかPythonの次はHaskellが来るって言われてるねん 俺はそう思うよマジで Haskellや絶対」
ツッコミ「そうやて」
ボケ「オカンが言うには ジャンルでいうたら数学やっていうねん」
ツッコミ「ほなHaskellやないかい ジャンルで数学言うたらHaskellしかあらへんやん な？ Haskellは数学の理論がベースになってるんやで ラムダ計算とか圏論とかな」
ボケ「そやねんそやねん」
ツッコミ「ほなHaskellに決まりやないかい ほなもうちょっとなんかゆうてなかった？」
ツッコミ「Haskellやないかい Haskellは変数が不変やから 変数に感謝するのは当然やねん ね？ 状態変更せんと安心して使えるからな」
ボケ「そやねんそやねん」
ツッコミ「Javaとかの変数は裏切るからアカンねん Haskellの変数は一生そばにおってくれるから最高やで」
ボケ「でも分かれへんねん」
ツッコミ「分からへんことない おかんの好きなプログラミング言語はHaskell もぉ」
ボケ「でもオカンが言うには Haskellではないって言うねん」
ツッコミ「ほなHaskellちゃうやないかい オカンがHaskellではないと言うんやから Haskellちゃうがな」
ボケ「そやねん」
ツッコミ「先ゆえよ 俺がラムダ計算の説明してる時どう思っててんお前」
ツッコミ「ホンマに分からへんがなこれ どうなってんねんもう」
ボケ「んでオトンが言うにはな」
ツッコミ「オトン？」
昨年子どもが生まれ、育休を3ヶ月取った。都内の上場スタートアップ勤務ということもあり、男性育休には寛容な環境で、同僚からはお祝いにおくるみもいただき、前向きに送り出してもらった。
当然だが、とてもハッピーな気持ちで育休に入った。出産に立ち会って自然と流れた涙は、これまでの人生で最も無垢で、言葉にならない嬉し涙だった。仕事と子育てを両立して、より一層充実した人生を送っていくぞと意気込んだ。
しかし、育休中に痛感したことがふたつある。
まず、育休中は仕事をしていないので、育休を取ったからと言って仕事と子育てを両立したとは思えなかった。数ヶ月程度の育休は「特に大変な新生児期を乗り切る手段」であって、「仕事と子育てを両立する手段」にはならないのが現実だ。
そして2つ目に、「両立」と勝手に言っているが、それは自分だけの問題なのかということ。子育ては夫婦の共同プロジェクトだ。義務教育までとしても15年を要する、一大プロジェクト。そのプロセスにおいて、当然、妻には妻の「両立」がある。
育休は子育てのほんのプロローグに過ぎず、その後が本番と言ってもいい。
3つそれぞれの満足度（納得度の方が適切かも）のバランスをどうやって保っていくか。中長期的にはこれが1番のテーマで、もはや、要素がふたつであることを前提にした「両立」という言葉で捉えること自体が、時代遅れに思えた。
妻はメーカー勤務で、仕事好きな人間だ。バリキャリ志向ではないが、自社商品を愛してやまないタイプで、今後もフルタイムでの仕事を望んでいる。彼女が仕事を通して充実感を得ることは、一緒に生きる私や子どもにとっても大切なことだ。
私は会社に働き方の相談をした。フレックスがなく、リモートにも回数制限があるため、せめて後者は緩和できないかと。しかし残念ながらその交渉は実らなかったため、転職を決めた。
次はリモートかつフルフレックスの環境で、幸いなことに年収も大きく上がるオファーをもらえたので、自分自身の問題は解決できたが、これだけ少子化が社会問題になる中でも、子育てと仕事の両立に優しくない現実を突きつけられたモヤモヤは消えていない。
経済合理性が伴う事由や、事業を左右するような外圧がなければ企業は変化しない。女性社員の活躍を進めて社会情勢に応じつつ、男性社員にはこれまで通り仕事にフルコミットさせたい。これが経営者の本音だろう。
しかし、その男性社員に子どもがいるとなれば、しわ寄せはパートナーの女性にいき、どこかで働くその人のキャリアを制限し、家庭の幸福度の総量も減らす。間接的に女性活躍を阻害しているわけだが、大半の企業は「知ったこっちゃない」と言うだろう。
だから思う、男性こそ子育てを理由に転職した方が良い。環境や制度を変えなくても男性社員が辞めないから、企業も変わらない。賃上げだってそうだろう。
厄介なことに、子育ては本当に千差万別。子の性格や体質、家庭の経済力、時間の柔軟性、幼稚園や保育園の環境、本人やパートナーの体力、実家の頼りやすさなど、いろんな変数で難易度が変わる。
カードに恵まれただけだったかもしれないことに想像が及ばず、n=1の個人的な体験談で断じてしまう人もいる。そういう人が上司や経営者の会社にいるなら、すぐに転職した方が良いと個人的には思う。
少子化と人手不足が課題の社会なのだから、共働きで子育てもしようという自分は多少わがままを言ってもいい。自分にそう言い聞かせることで、同僚に迷惑をかけることを頭から消して長めの育休を取り、転職も決めることが出来た。
仕事より家庭、という安直な二元論では捉えていないし、仕事ももちろん頑張っていくが、「仕事=今の職場」ではないはずだ。
繰り返すが、男性こそ子育てを理由に転職した方が良い。それが大きなうねりになれば、いろんな問題が少しずついい方向に向かうように思う。
本屋自体が少なく、あっても技術書の専門コーナーなんてない田舎住まいだったので、
Amazonで専門書を買って勉強してたんだけど、本当に何も知らないので「基礎から」って本を数冊買った。
しかしどの本も全体のうちの半分は「ハローワールド」と「変数の基本的な使い方」と「ifの使い方」で占められ、
そこを超えるといきなり、コード掲載だけが10Pくらい続く本格的なプログラミングを解説なしでやらされるものだった。
知らない命令とか構文がいっぱい出てくるし、それを一々ネットで調べないと進められないので全部挫折した。
更に本を追加で買って、運良く段取り良く進めていってくれる本にあたったことでなんとかなった。
その後、別の言語を勉強しようとする度に、全体のうちの半分は「ハローワールド」と「変数の基本的な使い方」と「ifの使い方」で占められ、る本に当たるし、そこについては大体どの言語でもやり方は同じで、まるまる読み飛ばすことが多い。
今日日、エクセルをちょっと触ってればifくらいは普通に使うものだからパソコンで仕事する人ならみんな知ってると思うし、シリーズとして「ifくらいまでは知ってるところからスタートする入門書」が欲しいなぁと思う。
標準的な経済理論で経済主体の行動を決定するのは、名目変数ではなく、実質変数である。
「賃金と物価の好循環」がなぜ好循環なのか。「デフレを抜け出したいでーす！ピロローン！」ぐらいの根拠しかない。
経済の実質値がインフレによって高まるということはあるのだろうか。
名目賃金と物価が同時に上昇する経済の方が、互いに凍結し合っている経済よりも好循環が起きやすい、という見方を100歩譲って認めるとしてみる。
家計が企業のように、物価・賃金の名目値が上昇する経済が、消費や住宅投資をより増やすかと言われれれば、それはかなり怪しい。
貨幣錯誤はあるかもしれないが、実質賃金が低下し、物価が高まれば消費は減る。当然である。
「賃金と物価の好循環」の正の効果が、他のリスク要因を上回るかというと、断定はできない。
経営者としてお答えしよう
ファック死ね
業務時間を割いてなにかやってるのは知っていが注意すると拗ねてモチベ下げるので黙っているが、管理職には絶対に上げないフラグを立ててるからな
持続可能性
頼むよ、これを意識してよ
仮に５秒短縮が当該業務担当５人、１０回／日だとして年間１６時間。。。
ん？わりとデカいな。
頑張れ
違う違うちがう
どうせ空いた時間は給湯室でくっちゃべってるだけだ
知るかボケ
あのな、頑張って勉強して業務効率化に寄与してくれるのはありがたいが、
オマエ死んだらどーすんの、連想配列が保守メンテできるスタッフ他にいる？
ワークシート上のセル式ならなんとか追いかけられますが、VBAでややこしいことやれたらわかりませーん、だよね？
VBAでゴチャゴチャやられるといざ業務拡大近代化の時に余計な工数もかかるの。
ワークシート上で処理完結してて適度にコメントも書いてくれてたらそれがそのまま要求仕様、ドキュメントになるの。
プログラム化されちゃうと要求仕様はそこから紐解かなきゃならない、そんだけ余分な工数がかかる。
残業して連想配列してるのは分かってるが、さっさと帰って婚活でもして、ブサイクな嫁とアホの子供でも作って、あぁもう迂闊に会社辞められねぇ、ってなってくれたほうが会社はありがたいの。
美しくない？
知るかボケ
どこにどれほどリソース割くべきか
こっちもアホでは無い、経営多変数パラメーターを加味して妥協し方向性と優先順位決めてるんだ
頼むから言う事聞いてよ
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…）
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
１．元となるcsvファイルをエクセルに読み出してシートに格納
２．そのデータは日付が数値型になっているので、日付（数値型）の入った列を文字列に変換した日付（文字列型）列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず（あるいはエクセルのセルオブジェクトを変数のように扱い）、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか？。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列（連想配列）と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
（逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・）
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列（連想配列）で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
（参考）【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
（参考）Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ（VBA）から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列（連想配列）のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある（ローカルウィンドウやDebug.printを使うなど）ので、リハビリに取り組んでほしいです。
（参考）VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
（最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。）
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用（加工用）のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ（VBA）は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
（あと、コマンドプロンプトの真っ黒な画面が怖かった）
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
（そのやさしさが上述したとおり悪魔の罠なわけですが。）
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
数学の必然性は実は人間の言語分析能力によるものなので、言語能力が異なる宇宙人とは、数学的語彙が共有できない可能性があるんですよね～
なぜ数学と言語能力が関係するんだ？と思う人は、以下のノーム・チョムスキーの有名な、無意味な二種の文を見ればわかってもらえるかもしれませんね～
・“Colorless green ideas sleep furiously.”（「無色の緑の考えが猛烈に眠る。」）
・“Furiously sleep ideas green colorless”（「猛烈に」「眠る」「アイデア」「緑色」「無色」）
前者は文法的には正しいが意味が無い文で、後者は文法的に正しくないから意味がない文、ということはわかっていただけるかと思います。
しかし、上記二種の文は、両方とも経験的には何も想起させないがゆえに、経験的には同様に意味の無い文です。
ということは、経験こそが認識の基礎、基底であると考える人にとっては、二種の文の違いを説明することができないのですよね～。
なぜならそのどちらも経験することができず、経験による理解が基底であると主張するのだから、経験的基底において違いのない(意味のなさ、指示対象が存在しないという点において同質という意味)上記二種の文の本質的差異(基底的差異)を指摘することができないのですね～
現代の言語哲学、そして現代論理学の基礎を作ってきた哲学者たちは、数学の必然性がどこから来るのかという問題について、
文の経験的理解よりも前に、文の文法的分析が先に行われる(そして数学的必然性は、文法分析に基づく理解そのものから正当化可能である)ことを示すことによって、
前経験的(アプリオリ)に論理や数学の必然性の正当化が可能であることを証明してきたんですね～
例えば上記二種の前者の文でいえば、経験できないにもかかわらず文法的に正しいことが理解できるのは、まず文法分析が先に行われ、その後意味の解釈に失敗するから無意味なのであって、その逆ではないのですね～
そして数学で扱われる文、例えば2+2=4は、なんらかの経験を前提せずとも、形式的な理解(つまり文法的理解)から正当化可能であるがゆえに必然的(=非偶然的、または前経験的)なのですね～
そして例えば上記二種の文とは別の有意味である文「無職の緑色のジャージを着た男性が猛烈に眠る」であったとしても、まず文法的理解が先に行われたあと、その意味解釈を行うことができるがゆえに有意味なのですね～
プログラミング言語だって、まずどれが変数で、その変数に何が割り当てられているかといったセマンティクスよりも先に、シンタックス的分析が行われますよね～
だから、数学の必然性は実は人間の前経験的な言語分析能力によるものなので、言語能力が異なる地球外生命体と遭遇した時、数学的語彙が共有できない可能性ももしかしたらあるのかもしれませんね～
なぜなら我々の理解する必然性とは、我々の言語分析能力に基づくものであって、よそから来た宇宙人にそれが期待される理由がないからですね～
GitHub Copilotは変数名やメソッド名をちゃんと規則立てて付けてるとめちゃくちゃ優秀に機能する
boolean open
みたいに付けてると微妙なこともあるけど
boolean isDialogOpen
他にも、createDataDayっていうメソッドがあって似たようなcreateDataMonthとかが乱立してるときに実装を共有化したいって思ったときなんかは
function createDataBase
ぐらいまで打ち込むと共有部分だけ抽出してくれる
命名規則だけじゃなくて実装のアルゴリズムがちゃんと整理されて設計されているとこっちがやりたいことを把握して実装してくれる
この辺は例が難しいけれど、なんかCopilotがまともなことを返してこないな、と思う時はこっちの実装が微妙な場合が多い
整理しなおして分かりやすい状態にしておくと綺麗に動いてくれる
Copilot使えねーって言ってる人のソースはほぼ100%こういう最低限のことができてなくて
とか言ってる奴は50%ぐらいの品質の命名規則やアルゴリズムになってる
の具体的になんて本(ネットのpdfでもよい)の何ぺージあたりからが元増田の問いにとって核心なのって話よね
てか、ラムダ計算よりむしろ記号論理学のほうが学問としての領域が気持ち広くなってね？
2. ラムダ項M, Nに対して (M N) はラムダ項。この形のラムダ項を適用（ラムダ適用）という。
(後略)
という定義があるんだけど、これに基づけば(x x)というのもラムダ項じゃないのって思ってた。
でもラムダ式で(x x)なんて形のは見たことないし、違うんだろうなと。
でも論理的にはなぜ違うのか全く納得できてないので(納得感が正しさにとって問題じゃないとはいえあえて言うが)(x x)だってラムダ式でしょって胸を張って言い張れる。
「Aかつ¬Aの証明を得ることができる」に対して、「いいや得られない。お前がそのように見せかけているだけだ」おれの計算(記号処理)手続きこそ推論規則に適っているし正しいと、反論されたら？
また、「そもそもここでいう『得る』とは」どういう意味か？と突っ込まれたら曖昧でなく『得る』ということが『得る結果の具体例ではなく』『どういうことか』記述できるのかという話です。
￢￢Ａ→Ａという規則に基づいた結果が
￢￢￢￢￢Ａ→￢￢￢(￢￢Ａ)→Ａ
なんだよ！と言い張られる。もちろん常識的にはおかしいと思えますが、いまは突き詰めたことを言っています。
一般には、￢￢￢￢￢Ａを書き換えるために、この記号列の一部分￢￢Ａに着目して、規則からＡと書き換えられるから、この結果を￢￢￢(￢￢Ａ)に代入？して、￢￢￢Ａに書き換えられる、という思考プロセスをとるでしょう。
しかしあくまでものとしては、ここで考えているのは￢￢Ａではなく￢￢￢￢￢Ａなわけです。
規則通りに書き換えられてない、言い換えるなら同じ規則を使っていないという主張に対して、そもそも同じ規則が適用できているということ、規則が同じとはどういうことか自体を定義や公理に組み込むことはできるのか。
矛盾や証明ということはまだその概念を記号列で示す余地があるが、規則が同じかどうかという定義もとい「規則」は厳密に定義可能かということです(無定義語として関係性の定義でもよい)。図形が合同か、みたいな合同の概念の定義など比べてもまたレイヤーが一段メタ的になっていて厄介というか。「違うのは自明じゃないか！」といっても、自明は説明できてこそ自明なのですが、ここでいう同じかそうでないかということについてはそれを根拠だてる定義は原理的に無理なんじゃないかと思えてしまいます。
さきほど『得る』という言葉に突っ込まれたら云々ということを言いました。
ブコメには「自然言語の曖昧さで数学をの厳密さ否定しようとしてるだけだ」というのがあります。
別に私は自然言語の曖昧さを問題にしていません。そこは問題の本質ではないです。
むしろこうした言葉は一般に疑いようなく明らかなものです。「左右」とか「これやあれ」みたいな近称や遠称の概念などもそう思われるでしょう。
しかしむしろこれらの概念には一切曖昧さはないという前提に立っても、これもごく単純な話で、曖昧でないからといって、いままでその概念を持ってなかった知性的存在に対して、「これ」や「左右」といった「概念」を、対面やジェスチャーを使えばいざしらず、記号列を用いて一意に定義できる保証はないよね、ということです。定義の厳密さを担保する必要条件が、記号論理学に基づくということにあるのなら、数学を厳密とのたまうかぎりにおいて、当然対面やジェスチャーではなく、これとか同じとかみたいなもっとも原始的な部類の言葉まで全て記号で一意に定義できることを示せなければならないでしょう。
あとあなたが↓のトラバと同一だと言ってくれたら以降↓の方のツリーに返信書いて一元化するのでそのつもりで
https://anond.hatelabo.jp/20240216215810
ちなみに関連しそうな話題として自分自身ラムダ式を勉強した経験があるけど
2. ラムダ項M, Nに対して (M N) はラムダ項。この形のラムダ項を適用（ラムダ適用）という。
という定義があるんだけど、これに基づけば(x x)というのもラムダ項じゃないのって思ってた。
でもラムダ式で(x x)なんて形のは見たことないし、違うんだろうなと。
でも論理的にはなぜ違うのか全く納得できてないので(納得感が正しさにとって問題じゃないとはいえあえて言うが)(x x)だってラムダ式でしょって胸を張って言い張れる。
分かってる人からみれば、そして俺にとっても￢￢￢￢￢Ａ→Aと同程度にバカげた主張なんだが、そのわかってる人にとっても「この規則ならこういうことが言えると思うのに、なんで正解とされてるのと自分が思ってることが違うの？」ってなることはあるはずで、それはこの世で一番数学ができる人であってもありえること。この世で一番数学ができる人さえ規則を正しく適用できていないらしいとき、そもそも正しい適用とはなんだってなりそうに思うんだが。
青年向け漫画の編集者をしていた。といっても若い頃の話だ。都内にある編集プロダクションを辞めて田舎に帰ったのが36の時だから、おじさんの入り口に立った頃か。今では完全なるおじさんである。
働いていた会社というのは、講談社とか小学館とか秋田書店とか、そういう大手出版社ではない。あくまで編集プロダクションである。出版社と編プロがどう違うのかって……ざっくり言うと元請けと下請けだ。出版社が出版事業（今回だと青少年向けの漫画作りや商業展開）の企画をして、漫画家が作品そのものを作って、編プロは雑誌本体を作って、その制作過程で印刷所やデザイン事務所といった専門集団と関係することになる。
イマイチな説明になってしまった。一般社会の例で説明する。民法でいうところの委託(準委任契約)に当たる。公共建築の分野でいうと、公共機関の建築技師が新しい建築物のマンガ絵を作り、建築事務所が基本設計～詳細(実施)設計をして、出てきた成果物を元に大手建設会社が施工監理し、地元にある中小事業者が実際の土木建築作業をする。
自分が勤めていたのは、この例でいうところの建築事務所だ。受益者(国民=漫画読者)の希望に応えたい組織があって、そこから依頼を受けて動いている関係会社のひとつ。そういうアナロジーだ。
出版社との役割分担は、そこまで分離しているわけでもない。漫画編集者といえば、昔の手塚治虫ほかの自伝みたいに、漫画家とアツいやり取りをしているイメージがある。ああいう、企画経営と制作現場の間にあるような仕事は、出版社の社員が直接することもあれば、編プロが出版社(編集部)のオフィスを間借りして行うこともある。
前者の例だと、マガジン、サンデー、チャンピオンなどだ。コンビニや書店にほぼ必ず置いてあるレベルの漫画誌。大手出版社に総合職コースで入社した人が、（編集、取材、制作、資材、宣伝、マーケティング、総務経理人事その他事務）といった多くの部門のひとつである漫画編集部に割り振られて其処に居る。
後者の例だと、大手出版社が出している漫画誌でも、あなたが聞いたことのないやつもけっこうあると思う。そういうのは、編プロが出版社(編集部)の仕事を丸ごと請けて実施していることが多い。自分は、そういう会社で働いていた。職場自体は大手出版社の中にあるが、いわゆる委託先の社員だった。別の言い方をすると、親雑誌に対する子雑誌の関係。
ほかの長文増田の記事を見るに、あまりたくさん書けない仕様のようである。何文字までかは知らないが、文字数制限があると思う。本当は何万字でも書きたいのだが、あくまで自分が書きたいだけであって、あなたが読みたいとは限らない。一万字以内になるよう心掛ける。以下に、自分が関わった漫画家を２人だけ紹介しよう。最後に所感を述べて終わりにする。
その２人(A先生とB先生。どちらも若手)と私は、分水嶺のような関係（追記；わかりにくい表現ですいません。ブクマカのBuchicatさんのコメントのとおりです）だった。ある日、私が担当していた漫画家のA先生が新作の企画提案に来ていて、同じタイミングで別の編集者のところに持ち込みをしたのがB先生だった。その別の編集者が不得手なジャンルだったこともあり、A先生との話が終わった後で、私も一緒にB先生の作品を読んだ。
その後、編集部の責任者を交えた会議で、私が引き続きA先生の新作の担当者に決まった。新人であるB先生の担当になる可能性もあったが、そうならなかったのは、今の漫画界の一界隈にとって幸運なことだった。
A先生は、雰囲気が暗めだった。人間性まで暗いというわけではなく、心を開くと明け透けになるタイプだった。モードに入ると饒舌になる。
弊誌では、読み切りを何度か掲載したことがあった。アシスタント経験あり。小さい賞を取ったことがある。ヒット作はないが、若き漫画家としてはキャリアがあった。
画力が抜群だった。小学校や中学校で、学習ノートにフシギダネの絵とかをソラでゲームパッケージそのまんまに描く子がいただろう。とにかく天賦の才を持っていた。最小限の画量で、それでいて迫力と感情に溢れた1枚1枚を描く。そういう人だった。
難点は、マジメすぎるところか。少し前にやっていたアニメだと、チェンソーマンに登場するアキくんか(少し前……？)。とにかくマジメだった。いや、やはり『直向き』に訂正する。
A先生は、少年誌に見合わない重たいテーマに挑むことがあった。今でもそうだ。彼のマンガには『緩さ』がない。それもいいところなのだが。私は好きだった。はっきりいって。が、読者の傾向に合っているかは微妙だった。
子どもの頃から漫画が好きだったらしい。中学生の頃のイラストを見せてもらうと、俄然キャラクターへの愛に溢れる作画を見ることができた。中学生らしい、プロには程遠いクオリティなのだが、しかし見ていて違和感がないというか、自然にくっきり入ってくる。
私という人間は、具体例で物事を説明する癖がある。上の「中学生らしいイラスト」を別の事例で表現すると……「うるせ～！！知らね～！！FINALFANT ASY」(短縮URL：https://x.gd/L5cc4)だろうか。以前、いつぞやかのid=pptppc2さんのブックマークコメントがきっかけで元ネタを知ることになった。
あの時のA先生のイラストは、ベルセルクのセルピコだったと思うが、力強い表現だったのを覚えている。セルピコがファルネーゼを抱きかかえて、
「申し訳ありません 道案内を頼まれまして 少し席を外していましたもので」
と言うシーンの模写だった。
さて、そんなA先生だったが、ある時これまた重量級のテーマで描きたいものがあるという。先ほどの、編集部での新企画提案の話だ。
その際、A先生からプロットをもらい、私のデスクで拝見させてもらったところ……うちの雑誌では持て余しそうだった。作品の質が低ければ普通に打ち切りになりそうで、作品の質が高くても――弊誌の売上規模だと会社グループ全体の機会損失になりそうだった。私の前でパイプ椅子にかけているA先生は、不安げな面持ちだった。
内部の話で悪いが、例えば「甲」という雑誌の亜流の「乙」という雑誌があるとする。ビッグコミック(オリジナル、スピリッツ、スペリオール)みたいな感じだ。この時、甲と乙に明確な上下関係があった場合、乙誌に掲載された漫画が甲誌に引き抜かれることがある。その際、甲誌の編集部から言われるのが、
「なぜうちの編集部に見せなかった？」
という意見だ。これは、ストレートに言われる場合もあれば、暗に言われる場合もある。だが、事前に上流の雑誌に見せていたとして、多くの場合は玉虫色の返事があるだけだったりする。
話を戻そう。この時の自分は、編集部の自分のデスクのあたりでA先生の次回作を見せてもらっている。確か缶コーヒーを飲んでいた。
自分としては、A先生のマンガを弊誌に載せたいと思っていたが、先ほど述べたとおり、後ろ髪を引かれる思いもあった。社会派の少年漫画というのは扱いが難しい。その作品が「あしたのジョー」の影響を受けているのは明白だった。「A先生であれば、きっと面白い作品にしてくれるのだろうな」という期待はあった。
うーん、大いに悩むところだ。どうしよう。思いあぐねていたところで、別の編集者から声がかかった。要約するとこんなところか。
「持ち込みに来た人がいる。私の専門じゃないので判断が難しい。門前払いにするレベルではないので、あなたの判断を仰ぎたい。上の人間は今出かけている」
要するに、自分の専門外なので判断できないよ、と言っている。ここも会社なので、編集者の上には当然上司がいる。その人達がいなければ同輩に相談するのが基本だ（余談だが私は後輩だった）。こういう原則は一般の会社と変わらない。
その『別の編集者』というのは、儚い感じの純文系が得意なタイプだった。一番わかりやすい喩えは……『はちみつとクローバー』みたいなやつだ。ああいうのが得意な人だった。
その時は、A先生との話が終わったら行くと告げた。それで、しばらくそのまま話を続けた。
「この作品はいい意味で重たいね。ちょっと考える時間がほしい」
と言って、その日は解散した。A先生は、「お願いします！」と言ってパイプ椅子を立ち、そのまま帰っていった。いつもだったら喫茶店でご飯をおごっている。
A先生は、『いい子』だった。あまり感情は出さないけれど、人間に対する愛を持っている。そういう子だった。私が当時、A先生にご飯を奢って、彼がおいしそうな表情で食べている時、私は幸せだった。A先生が幸福だと、自分も幸福だと思えた。A先生が漫画という手段で自らを表現している時、まるで自分もそれに劣らぬような喜びを得ていた。
ヘンな表現かもしれないが、例えば読者がA先生を褒めている時、自分とA先生との区別がなくなっているというか。彼のことが、自分のことみたいに嬉しかった。これは愛なのだろうか。
持ち込み部屋に行くと、別の編集者と、持ち込みに来た子が対面で座っていた（ちょこんと挨拶をしてくれた）。自分が座る席には作品が置いてあった。綴じられていない原稿用紙がある。ページ数にして30枚ほどだった。もっと多かったかもしれない。記憶があやしい。
実際、B先生の作品は面白かった。コテコテの学園ものかと思いきや、登場人物それぞれに適度な制約があって、キャラクターも立っていた。これまでのキャリアを聞き取ったところ、作品が雑誌に掲載されたことがあるようだ。アシスタント経験もある。
絵の方は、自分がこういうのも大変失礼だが、上手な方ではなかった。どちらかというと、脚本や設定、キャラ作りが得手のように映った。当人が情熱を注いでいる箇所はすぐにわかる。キャラ絵が有名漫画家の影響を受けているとか、キャラクターの台詞回しがハリウッド映画風とか、背景や小物を手を抜くことなく全部描いているとか、そんな具合に。
光るものがある作家だった。これを見抜けないようなのはモグリ――そんなレベルで輝いていた。
私は作品を読み終えた後で、「ちょっと待ってね」と自席に戻り、少し残っていた缶コーヒーを飲み干して、思案を重ねつつ持ち込み部屋に戻った（どうするのが最良かわからないケースだった……）。
それで、テーブルではこういうやりとりをした。
私「イイ作品だと思います。特に、セリフ回しにセンスを感じます。掲載ができるとかここでは言えないけど、話は通してみますね」
Ｂ「ありがとうございます」
私「それで、担当はね……縁なので。あなたがするのがいいのでは？」
編「私よりもほかの人がいいと思います。もっと才能を引き出せる人が……」※小さい声で
私「いや、でも恋愛描いてるよ。エンタメだけどいいんじゃない」（こいつ、作家の前でアホなこと抜かしよって）
編「難しいです」
私「でもこれ、縁だよ」（意識が低すぎる……）
編「ほかの作家さんも抱えてるので。いっぱいいっぱいです」
私「わかりました」（トラブル回避のため後で編集長に説明しとこう）
Ｂ「すいません。僕の作品はどうなるんですか？」
私「後日連絡しますね。必ずしますから、それまでは他誌への持ち込みは待っていただけますか」
Ｂ「あの、はい。できればですが、早めでお願いします。一週間くらいでなんとかなりますか」
私「なんとかしてみます」
作品そのものと、作家プロフィールと、付属資料のコピーを取らせてもらって、彼には外で缶コーヒーを奢った。ビルの入り口まで送ったところまではいい気分だったが、正直、身に余る事態だった。
持ち込み作家の才能がありすぎるのも考えものだ。嬉しい悲鳴というやつ。誰が担当に付くかで今後の雑誌の売り上げに影響がある。重大な意思決定ということになる。
最悪、『進撃の巨人』の時みたいに優れた作家を逃してしまう可能性がある。あれも、実際は諌山先生は門前払いではなく、週刊少年ジャンプの担当が付くか付かないかの微妙なラインだったらしい。それで、誰が担当になるかを押し付けあっている間に諌山先生が他雑誌に持ち込んでしまった、という話が業界団体の公的な飲み会で囁かれていた。
B先生についてだが、一週間後に担当編集が決まった。「別の編集者」でもなく私でもない。当時、若手のひとりだった20代の子が任されることになった。編集部のトップを交えてB先生の原稿のコピーを読んだのだが、「若い感性が光る。年齢が同じくらいの人と組ませる方がいいのでは？」という結論になった。
その20代の子は、上の組織からこっちに出向してきている子で、いわば武者修行の身だった。一流大学出で、本社のプロパー社員。いわゆる総合職である。
最初は、私に選択権があった。B先生の担当になる道もあった。だが当時の私は多忙であり、月に何度も会社に寝泊まりするレベルだった。新人は抱えるべきではない。しかし、才能のある子だから迷いがある。
A先生のこともあった。彼のあの作品を世に出してやりたい。もっと有名にしてあげたい。そんな想いがあった。
私が悩んでいるうちに、例の20代の子が手を挙げたのだ。私としても、彼のやる気と知性と直向きさは買っている。諸手を上げて賛成した。
今思えば、正しい選択だった。もし私がB先生の担当になっていたら、面白い恋愛エンタメを楽しめる読者の数は減っていただろう。これでよかったのだ。
以後のB先生は、例の持込漫画のブラッシュアップを続けた。翌年には、晴れて弊誌に第一話が掲載されることになった。さらに以後は、担当編集とともに二人三脚で躍進を続け、イケイケドンドンの勢いを保ったまま、一度も息切れすることなくスターダムに上り詰めた。今では漫画家として世に知られている。
上で挙げたA先生の意欲作は、読者層に合っていなかった。それでも、高い画力とシナリオ構成の上手さがあったのだろう。その意欲作は、連載期間を積み重ねる度にファンの数が増えていった（業界的には、Amazonの第一巻のレビュー数が人気の代替変数になることが知られている）。
今では、A先生は親雑誌で連載を勝ち取るまでになった。去年だったか。彼の作品をコンビニで立ち読みする機会があったのだが、やはり突き抜けた画力だった。週刊連載であそこまでの画力というのはまずない。
2024年現在、私は東京を離れて田舎で暮らしている。地元の町役場にUターン就職して、実家の農業を手伝いながらスローライフに近い生活を送っている。
実は、編集者だった当時、働きすぎて病気になった。ある日、下腹部の辺りに違和感を覚えて、血の塊のようなものが血管を這っている感覚があった。病院に行くと、「遅くても明日中に入院しなさい」という医者からの指導があった。
それなりに重い病気にかかってしまった。一応は死亡リスクもある。数か月ほど入院した後、どうしようかと考えて、考えて、考えて……編集部に復帰後は、労働を最小限にしつつ転職活動をスタートした。
A先生については、幸いだった。彼の意欲作とは最終回まで付き合うことができた。私が退院した後、無事完結を迎えることができた。あしたのジョーに比べればハッピーエンドだった。
入院中に、A先生とB先生がお見舞いに来てくれたのを覚えている。ほかの編集仲間も来てくれた。A先生は、テンションが低めで、何を考えているのかわからないこともあるのだが、人間への基本的な愛というか、思いやりがある人だった。
もう40才を過ぎている。はてなユーザーの中では平均的な年齢か。思えば齢を重ねたものだが、当時の日々は今でも夢の中に出てくる。
若い頃から編集者をやってきた。身体を壊さなければ続けていたのかというと、多分そうだろう。でも、今の生活も悪くないと感じている。自分語りはここまでにして、締めにしよう。
もしあなたが、Webでも紙媒体でもいい。気になる漫画作品を見つけたとする。面白いものを見つけたと感じたら、ひとまず買ってみるのがいい。Webだと１話単位で売っている。
ひとかどの漫画家というのは、自らが産み出すモノを本気で高めにいっている。あなたのフィーリングが合ったのなら、ひとまず１巻だけでも読んでみる方がQOLが高まると思う。ハズレを引くことはあるだろうが、アタリだってちゃんとある。人生は運試しである。