  |
はてなキーワード: プログラミング言語とは
なるほど確かにその通りですね。
意固地になって謝罪を固辞し続けて大変申し訳ございませんでした。
僭越ながらわたくしめがフェミニストを代表して土下座で謝罪させていただきます。
その方法として古代中国より伝わる「三跪九叩頭の礼」で謝意を表させていただきます。
なお、冗長した記述を避けるためにプログラミング言語「COBOL」を用いることを予めご了承ください。
IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
MAIN.
PERFORM 3 TIMES
DISPLAY "GUI"
PERFORM 3 TIMES
DISPLAY DOGEZA-CNT "KOUTOU"
DISPLAY "CHI"
END PERFORM.
DISPLAY "CHIRAI"
END PERFORM.
STOP RUN.
END PROGRAM SANGUIKIUKOUTOU.
御清聴ありがとうございました。
大変申し訳ございませんでした。
フェミニストの皆様の名誉を毀損したこと、誠に申し訳ございません。
その方法は、中国より古来から伝わる「三跪九叩頭の礼」をもってして深き謝意を表させて頂きます。
なお、表記を簡潔にするためにプログラミング言語で記述させていただきます。
The Prostration and Obeisance
Act I: The Ritual.
Scene I: The Preparation.
[Enter The Counter and The Inner Counter]
The Counter:
You are as brave as the sum of your fat little stuffed misused dusty old rotten codpiece and a beautiful fair warm peaceful sunny summer's day. You are as healthy as the difference between the sum of the sweetest reddest rose and my father and yourself! You are as cowardly as the sum of yourself and the difference between a big mighty proud kingdom and a horse. Speak your mind!
[Exit The Inner Counter]
Scene II: The First Prostration.
The Counter:
You are as brave as the sum of your fat little stuffed misused dusty old rotten codpiece and a beautiful fair warm peaceful sunny summer's day. You are as healthy as the difference between the sum of the sweetest reddest rose and my father and yourself! You are as cowardly as the sum of yourself and the difference between a big mighty proud kingdom and a horse. Speak your mind!
Let us return to Scene II.
[Enter The Inner Counter]
The Inner Counter:
You are as vile as the sum of a cursed old rotten buried smelly half-faced plague-infested contaminated toad and a beautiful healthy honest trustworthy noble golden-hearted angel. Speak your mind!
You are as cowardly as the sum of yourself and a pig. Speak your mind!
You are as vile as the sum of a stinking foul infected curse and a beautiful healthy honest trustworthy noble golden-hearted angel. Speak your mind!
Let us return to Scene II.
[Exit The Inner Counter]
Let us return to Scene II.
Scene III: The Second Prostration.
[Repeat Scene II, replacing "First" with "Second"]
Scene IV: The Third Prostration.
[Repeat Scene II, replacing "First" with "Third"]
Scene V: The Rising.
The Counter:
You are as good as the sum of a happy brave sweet gentle peaceful honest trustworthy noble golden-hearted king and a rose. Speak your mind!
[Exeunt]
御清聴の程有難く存じます。
はい、JavaScriptによるコーディングはコンピュータサイエンスの一部と見なすことができます。コンピュータサイエンスは、情報とその処理に関する学問であり、プログラミングはその重要な要素です。JavaScriptは、ウェブページを動的にするための主要な言語の1つであり、ウェブ開発の分野で広く使用されています。したがって、JavaScriptを学び、それを使用してコードを書くことは、コンピュータサイエンスの実践的な応用の一部と言えます。しかし、コンピュータサイエンスはプログラミングだけではなく、アルゴリズム、データ構造、ネットワーク、データベース、人工知能など、より広範なトピックをカバーしています。それぞれが特定のプログラミング言語やツールを使用して探求されることがあります。JavaScriptはその一部であり、特定の問題を解決するためのツールとして使用されます。それはコンピュータサイエンスの一部であり、その全体ではありません。それでも、JavaScriptをマスターすることは、コンピュータサイエンスの重要なスキルを習得するための素晴らしいステップです。それはあなたが複雑な問題を解決するためのロジックとアルゴリズムを理解するのを助け、あなたの思考を開発するのを助けます。それはまた、あなたがウェブ開発の世界に足を踏み入れ、あなた自身のウェブサイトやアプリケーションを作成するのを助けます。だから、はい、JavaScriptによるコーディングは確かにコンピュータサイエンスの一部です！
はい、ブラウザの実装は確かに**コンピュータサイエンス**の一部です。以下に、その理由をいくつか挙げてみます：
1. **アルゴリズムとデータ構造**：ブラウザは、効率的な検索、ソート、データの格納と取得など、多くのアルゴリズムとデータ構造を使用します。
2. **ネットワーキング**：ブラウザは、HTTPやHTTPSなどのプロトコルを通じてインターネットと通信します。これらのプロトコルの理解と実装は、コンピュータサイエンスのネットワーキングの分野に直接関連しています。
3. **レンダリングエンジン**：ブラウザのレンダリングエンジンは、HTML、CSS、JavaScriptなどのコードを解析し、それをユーザーが見ることができる視覚的なウェブページに変換します。このプロセスは、計算理論、グラフィックス、プログラミング言語の理解を必要とします。
4. **セキュリティ**：ブラウザは、ユーザーのデータを保護するために、さまざまなセキュリティメカニズムを実装します。これには、暗号化、サンドボックス化、同一生成元ポリシーなどが含まれます。
これらすべての要素は、コンピュータサイエンスの基本的な概念に基づいています。したがって、ブラウザの実装は、その「サイエンス」の部分を明確に示しています。ブラウザの設計と実装は、これらの理論を実際の製品に適用するための実践的なフレームワークを提供します。それらは、問題解決、効率的な設計、そして最終的にはユーザーに価値を提供するための方法を探求します。これが、ブラウザの実装がコンピュータサイエンスである理由です。
とある雑記ブログを7年ほど前に見つけて、年に数回ほど訪れている
役に立つとか面白いなんてのは一切ない
あまりにも拙い内容なので俺しか読者がいないから不憫に思っているだけだ
そのブログは「ポケストは任天堂関連だから京都に多い」という意味不明な解釈を垂れ流して炎上していた
リリース直後だとしてもお粗末すぎる記事なので当時話題になっていたと思う
その後も知能指数が低いこたつ記事を連発したり、アンチや社会への不満を似たような文面で何回も投稿するなど、ちょっと不憫にも思えるくらい情けない記事ばかり書いてる
カテゴリーもその時の瞬間的な流行に乗っているだけにすぎず、特に深いものはない
唯一読まれていたのは遊戯王の記事だったらしいが、それも飽きてやめてしまっている
それなのにブログ自体は今年で9年目となり月1投稿は欠かしていない
そこは素直に良い点だと思う
問題は筆者の能力が著しく低く、せいぜい炎上記事でしかPVを伸ばせないことだ
びっくりするがあの文章力で短編小説家を目指しているといまだに言っている
何が目標かテーマは何か何ができるのか一切わからない、本当に謎なブログと筆者だ
どういう内容書くつもりだよ
改行する
＜br＞
右から左に動かす
おいHTML構文かよ
どこかの記事のコピペをしないだけましだけど、それでもプログラミングと題してHTMLなんだよ
今日日、小学生が授業で習うような超初歩的なことしかないていないし、しかも内容が超絶古い
しかもmarqueeって俺も知らんぞってググッたらとっくに非推奨扱いの化石じゃねーか
なんで古の手打ち掲示板でしか通用しなさそうなことをこの令和に？
炎上狙いだとしても、もっとこうさ、ちょっとバズりそうな要素を含ませるとかしようぜ
これがある程度PV稼いでいるブログに書いた珍記事だったら面白いけど、おまえのところの読者なんて俺くらいしかいないだろーが
センスのかけらを獄門疆に封印してきたような君がいくらやってもPV伸びんわ
かつてのポケゴーは題材がビッグネームだったからバズっただけで、プログラミングなんてものでどうにかなるもんじゃねーよ
はあ、というわけで俺しか実質読んでいない超低レベルブログをよろしくな
「AIを使えばやりたいプログラミング言語のコーチがタダでしてもらえるんだぜ！」
くだらん。
昔のグーグルだったら「[プログラミング言語名] 勉強 やり方」でググったら最高にイカしたページにたどり着いた。
作りたいシステムがあっても「[言語名] [やりたいこと] コード」でググれば欲しかった情報がドンピシャでガッポガポ。
そんな黄金時代があった。
ADSLが世界をつなぎ始めた世界、ネットの海が光速で流れていなかった穏やかな時間。
あの頃、ネットの海から求めていた知恵を引き上げるのは今よりずっと簡単だった。
今のネットは汚れきったヘドロの塊であり素のまま飲めば猛毒となる巨大な汚水、まるで東京湾だ。
AIがやっていることはネット上に溢れた有象無象を濾し取って、少しだけ昔のインターネットに近づけるだけの作業でしかない。
昔はほんのちょっとした言葉の組み合わせでたどり着けた知識が、今や何百文字ものプロンプトを指定してようやくたどり着けるようになった。
「AIは賢いものとそうでないものの格差を広げるだろう」と語るものは物事の一面しか見えていない。
正解は「かつて、インターネットという空間は誰しもに開かれた無限の智慧が内包されていた。その知恵が一部の人間に独占される時代がやってきた」だ。
誰しもが賢く慣れる世界の方がいいに決まっている。
生まれついたIQの高低を義務教育を終えて十年二十年それ以上経ってもいつまでも擦り続けるような哀れな者達の戯言のなんと醜く濁ったことだろう、まるで東京湾だ。
fx趣味なもんでpinescriptとMQL4っていうプログラミング言語は分かるんやが、こいつらとは勝手が違いすぎて諦めた。いずれにせよ、英語は分かってた方がスムーズに打てて良い。
プログラミング言語で動的言語を嫌って静的言語こそ至高みたいな主張の人って結構みかけるんだけど、なんでみんな偉そうでマウント取ろうとしてるの？
パフォーマンス面での優位ならまだわかるけど主張は基本型がないことをディスってる
頭が良ければ脳内で整合性の取れるコードを書けるわけだから、コンパイラのサポートがなくても書けるほうが優秀なのは自明のはず
コンパイラにサポートしてもらわないとまともなもの書けないよというほうが能力としては劣ってる
劣っててコンパイラのサポートがほしいならそれでもいいんだけど、なぜ自分が無能だということを偉そうにアピールできるのかがわからない
自分頭悪いので静的言語じゃないと書けないんですーとか言われたらじゃあそういう言語使うかとなるけど、
動的言語とかゴミ使う価値ないとか、◯◯言語は消えるべき、とか言われたらお前の頭が悪いだけなのになぜそれに合わせる必要があるの？としか思えない
コーンフレークじゃなくて、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ちゃうがな」
ボケ「そやねん」
ツッコミ「先ゆえよ 俺がラムダ計算の説明してる時どう思っててんお前」
ツッコミ「ホンマに分からへんがなこれ どうなってんねんもう」
ボケ「んでオトンが言うにはな」
ツッコミ「オトン？」
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、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は、なんらかの経験を前提せずとも、形式的な理解(つまり文法的理解)から正当化可能であるがゆえに必然的(=非偶然的、または前経験的)なのですね～
そして例えば上記二種の文とは別の有意味である文「無職の緑色のジャージを着た男性が猛烈に眠る」であったとしても、まず文法的理解が先に行われたあと、その意味解釈を行うことができるがゆえに有意味なのですね～
プログラミング言語だって、まずどれが変数で、その変数に何が割り当てられているかといったセマンティクスよりも先に、シンタックス的分析が行われますよね～
だから、数学の必然性は実は人間の前経験的な言語分析能力によるものなので、言語能力が異なる地球外生命体と遭遇した時、数学的語彙が共有できない可能性ももしかしたらあるのかもしれませんね～
なぜなら我々の理解する必然性とは、我々の言語分析能力に基づくものであって、よそから来た宇宙人にそれが期待される理由がないからですね～
