  |
はてなキーワード: 高級言語とは
世間ではコード書くのがプログラマのやりたいことだと勘違いされてんのかね？
実際はコード書くことはただの手段で、できれば書きたくないし読みたくない。だから高級言語やフレームワークや糖衣構文というものが作られる。念じるだけで思い通りのソフトができたらいいと思ってるのが大半だよな
(じゃなかったら、今頃みんなアセンブリで楽しく遊んでるはずだよな？)
全部AIにやってもらったら万々歳だわ。要件定義と設計に専念できる。AIがやる？無理だろうね。支離滅裂で何を言いたいか分からんクライアントの話を掘り出して掘り出して正確に要件定義してくれんなら助かるが、そんなに頭は良くならなそうな雰囲気があるんだよな
たとえばユークリッド幾何学での直線は「幅をもたず、両側に方向に無限にのびたまっすぐな線」だそうですが、これも「幅」とは？「(幅を)持つ」とは？両側とは？「方向」の定義は？「無限(限りが無く)」とは？そもそも「限り」って何？「のびる」とは？「まっすぐ」とは？「線」と結論づけるのは循環論法じゃないの？
と突っ込む人にとっては厳密ではなくなっていませんか？
ここで、これらの言葉の意味は、国語辞典に載っている意味と同じものだよなどといおうものなら、それこそ数学の厳密性を否定したようなものになってしまっていると思います。
たとえば「方向」を調べたら「向くこと」とでます。これを調べると「物がある方向を指す」というふうに出ます。これは循環論法に陥ってますし、「物の正面があるものに面する位置にある」という別の語釈もありますが、物とは？正面とは？面するとは？位置とは？となります。これを繰り返せば結局どこかで循環論法に行きつくでしょう。
そもそも数学の根幹部分を支える論理学の重要な概念である「否定(そうでないこと)」にしても、厳密に定義することは可能なのかと思います。
「～でない」というのは、そうであることがないということ、と言ってみたところで循環論法。
そうであるのになぜ上記のような定義や公理が厳密なものと認識されているかといえば、「さすがにここまで平易な単語の組み合わせで書けば、これらの単語については私が常識として理解してる意味と同じ常識を、相手も持ってるはずだから同じ理解をするよね？」みたいな態度に立っているんだと思います。
結局相手も同じ常識を持っているという不確かな信念によりかかっている、甘えている点で、数学の記述もまた完全に厳密で一意というわけではないのかなという気がしてくるのです。
そもそも「方向」なんていうような概念は、言語によって定義されたものを知っているというよりは、幼少期に言語を習得していく過程で、それが話されるシチュエーション、つまり五感などあらゆる感覚の総体とセットでそうした言葉が使われているという環境に身を置いているなかで理解しているにすぎません。理解内容が各個人で全く同じである保証はどこにもないと思います。
どんなに高度な数学の表現も究極的には自然言語に還元されるはずで(どんな高級言語も機械語に置き換えられて処理されるように)、自然言語の各単語に対する人々の理解は原理的には五感に根差した感覚的なものなのだから、数学の記述が厳密で一意というのは、結局はほかの記述の仕方に比べた程度問題(つまりは誇張表現)なのかなと思うのです。
感覚によらない「証明」をすることに価値を見出す人が数学をありがたがることがありますが、数学もまた根源的には感覚ありきの理解に基づいていると思うわけです。
この考えは間違っているでしょうか？そうであればどうして間違いなのか、どこがどう理解を誤っているのか知りたいので教えてください。
ちなみにたとえば「否定」というのは、根本的には、やはり言語で理解が完結しているものではなく、現実の状況としての存在非存在にそれぞれ直面して、それぞれに対して「○○がある」「○○がない(なくなってる)」と言われてる場面を経験したうえで、その状況から理解した内容のさらなるアナロジーとして理解してるに過ぎないと思います(理解のあり方が、言語的ではなく、観念的直観的)。
数学が他よりも他者と厳密に同一な合意が常に成り立つ、その工夫として、抽象度を高くしているのがその工夫にあたるのではないかという人がいました。↓
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14293524459
しかし抽象度を高くすることは、合意内容のずれを減らすという点で「有効でもあり逆効果でもある」のではないかと思いました。つまり諸刃の剣なわけです。
有効である理由はリンク先に書かれているのでそこに説明を譲るとして、逆効果であると思う私の説明を書きます。
つまり、抽象度が高い概念は、抽象度が低い概念や直接的な事物に比べて理解が難しい傾向があるのがまずあるわけです。
また定義者の提起する定義をそれを発信される側が期待通りに理解しているかを確認するのも、抽象度が高い概念ほど困難な傾向はあると思います。
これ自体ある意味で抽象そのものなのでたとえが悪いですが、たとえば「左を向いて」という発言に対して、「左」を向く反応をすることで、この人は左について正しく理解してそうだなという確認(いや原理的には推定というべき)することができます。
抽象度が高くなるほど具象と結びつけたこのような正しく理解してるかの評価、確認テストをすることが難しくなるでしょう。
といってもそもそもわれわれは相手が自分の言ったことを期待することと厳密に一致した内容で理解してるか確認することは原理的に不可能です。
頭をパカっと割って理解内容を覗きみるということはできないですから。
対象となる言葉に関連したその人の発言や反応をみて、理解の結果としての発言や反応として、その人がある部分で正しく(定義者の期待通りに)理解してるだろうということを推定するしかありません。
しかも全体ではなく一部だけの理解が正しくても、発言や反応には異常が見られないということもあるでしょう。
反応や発言をいくら調べても、概念全体を期待通りに理解してるかのテストには無限通りのパターンが必要と思われ、原理上不可能と思います。
哲学的ゾンビにも通じそうな話ですが、日常の範囲内で「理解に齟齬があるような反応が返ってこないなら」そんな「理解が完全同一でないかもしれない」という可能性上の話を心配する必要はないというのはその通りでしょう。
ただ場合によってはそれが表出したように見える一例が、あれの原因がこれだとは言いませんが、望月新一がＡＢＣ予想を証明したという論文での紛糾みたいなことが起こる一因にはなりえると思います。
あれだけ理論として抽象的な概念を積み重ねた先には、定義者とそれ以外のその定義を見た人とでの理解のずれは、反応や発言として顕在化してくるほどになっても不思議ではありません。(定義者の解釈が正しいという優劣の問題ではなく)
とはいいますが、そもそも「矛盾」とは何か？「論理」とは？「範囲」とは？とは、といくらでも曖昧でしょう。
たとえ矛盾を記号論理の表現で記述して定義した気になったところで、じゃあその記号の定義ないし意味は？とどこまで突っ込まれても感覚に頼らない定義が可能なんですかね？と思います。
数学に限らない話じゃんっていうのはまあその通り。
でも定義について「厳密で一意」であることを(得意げに？)標榜してるのは数学(＋論理学)とそれベースの客観的であろうとする学問ぐらいだから、別にエントリ名詐欺じゃないよね？
a＝b、aはbだ。「は」って何？「だ」って何？「英語的にはどっちもisという語に集約されてるけど、じゃあisってなんだよ」ってところから概念の共有をしてない前提に立った時、その概念を非感覚的で厳密に共有することは可能なのか、それが「完全に」できたと確かめるのにはどうすりゃいいって話よ。
言葉という形式が従で、それに乗るべき内容が主であることは百も承知だが、形式言い換えれば入れ
物抜きに内容を厳密に伝えられるのか、入れ物の存在に無関係な、内容の厳密な伝達というテレパシーじみたものを考えることはそれこそ論理的に正しいのかという話でもある。
非言語的なテレパシーは論理的に矛盾してるので存在しえないのではないかとは思っている。
イデア論かな哲学書読めばってブコメついたけど、順序が逆なんだよね。
イデア論とか学校で習って本読んだりして教養として知ってるからこそ、改めてその考え方を自分なりの具体的な考察対象にあてはめて思索したくなるわけよね。
先達の哲学者たちがいなかったら俺はいまだにブルアカで抜くだけの毎日だわ。むしろ哲学者リスペクト100パーセントなんだよね。
語彙力ないので語弊ありそうなのは百も承知だが、哲学って考え方の基幹部分のオリジナリティーはそんな求められてないんだよ。
むしろ先人から受け継いだ考え方をどう今の時代の具体的な問題に適用して考察を広げるかが大事なので、ちょっと哲学かじったような素人目には過去の論文の焼き増しに見えてその存在意義が理解できないような論文はごまんとあるんだよね。
ああいうブコメつける人って「方向性とかみたいな意味でベクトルという言葉を使ってる人は横文字使いたがりの格好つけ」と言ってる人みたいな人を性悪説的にとらえるクレーマー気質が高い人間に感じる。
ちなみに俺はベクトルという言葉を使う人は「周りがベクトルという言葉を使ってるから、リアルタイム性を要求される会話でとっさに出てくる言葉がベクトルだから、それをそのまま使ってる」ってだけだと思う。
ワークフロー管理ツールからはキックするのはPythonやRuby、場合によってはJavaとかの高級言語想定だね。
自分が想定してた許容できるシェルスクリプトはコマンド呼び出すとか１行程度の物だね。
他に呼び出したいシェルコマンドとかがあるんであれば高級言語内から呼び出したほうが良い。
多くの高級言語では契約プログラミングとかデータの整合性とかを検証するコードを書きやすいから、コマンドとかの出力結果を信頼できるデータとして後続処理に送ることができる。
（もちろんシェルスクリプトでも書けるが律儀にやっているとものすごいことになる）。
そんな事無いよね。Linuxサーバの保守とかでパッチノートとか読んだこと無い？
インストールし終わったらほとんどアップデートしてない凄まじい運用してるんならあれだけど
これだとどう？
命に関わらないシステムを動かしてるWeb系の業界想定ならRustで書くのが非生産的なのは同意だけど、なんで危険になるのか知りたいね。
噛み合わないポイントはここらへんにあるかもね
横からだがシェルスクリプトで使用してるコマンドとオプションの仕様を把握するのなんて高級言語で使用するAPIの仕様を把握するのと同じぐらい基本的で当たり前のことだよ。manっていうコマンドを使ったり、より簡易的には--helpのようなオプションで確認できるよ。
君が論理的じゃないとしているところは筋が通っていると思うよ。
検証というのはプログラム開発におけるテスト工程だけでなく無数の利用者が継続的に使い続けていることを指しているよ。それを含めるならPOSIX準拠のシェルコマンドよりもよく検証されているプログラムなんて世の中に存在しないんじゃないかと思うよ
標準ライブラリのすべての関数のありとあらゆる引数に対する挙動を把握している？
標準コマンドは標準入出力を通してプログラム同士で連携することを想定して作成されており、
入出力の破壊的変更を気軽にコミットしようとしたら秒でハネられます
「ゾウリムシよりも蟻は大きい」を「蟻は大きい」で切って引用するのはやめましょう
規模が大きくなると信頼できない、その場しのぎ的な技術であるのはpythonなどのスクリプトの実行環境も同様です
すべての処理、すべてのプログラムをRustで書くような行為はきわめて非生産的ですし、シェルスクリプト以上に危険です
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
論理的じゃないよね
メンテナの数、レビューする人数、実際に動作している環境etc
横からだがシェルスクリプトで使用してるコマンドの仕様を把握するのなんて高級言語で使用するAPIの仕様を把握するのと同じぐらい基本的で当たり前のことだよ。manっていうコマンドを使ったり、より簡易的には--helpのようなオプションで確認できるよ。
例えば、ファイルをあっちからこっちにコピーして一時的に待避するだけならシェルスクリプトでcpコマンド書くのがコスト最小でしょ。現実のシステム運用では費用対効果を考えていろんな仕組みを使い分けてるんだよ
シェルスクリプトに使用したコマンドのすべての挙動を把握している？
使用予定のオプションだけでも出力結果のすべてのパターンを把握している？
人が手て使うことを想定された曖昧さの残るコマンドと、高級言語の機械が使うことが前提の曖昧さの少ない機能だと全然違うものだと思うが
そんな事無いよね。Linuxサーバの保守とかでパッチノートとか読んだこと無い？
インストールし終わったらほとんどアップデートしてない凄まじい運用してるんならあれだけど
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
論理的じゃないよね
別に高級なスクリプト言語でも標準ライブラリやインタプリタのバグは踏むときは踏むし
マイクロタスクな標準コマンドは高級言語のインタプリタほど頻繁なセキュリティアップデートは必要ないので使うバージョンはだいたい決まってるし
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
バッチ処理は大抵2,3の条件分岐と数行のコマンドでできているので検証も難しくはありません
「これで素人でもソフトウェア開発が簡単にできる、プロのエンジニアはもはや必要ない」
の歴史なのよ。
実際は素人でもソフトウェア開発ができるようなったわけじゃないけれど。
バイナリを入力する代わりにアセンブラを書くようになって、高級言語を書くようになってGC等リッチな機能を持つより便利な言語やフレームワークを使うようになり……
AIを使って顧客の要望を実現するのがIT屋の仕事になるだけじゃね？
真に
「これで素人でもソフトウェア開発が簡単にできる、プロのエンジニアはもはや必要ない」
が実現された時、その時はもはや万人が働く必要がなくなっていると思ってるしね。
ITではそれまで人間が一生けん命やってた作業をプログラムにやらせて開発効率が上がって
絵師をIT屋に置き換えるとキーパンチャーや精々コーダー辺りなのよ。
で、コーダー見たいな人もいてるけれど、一生コーダーしかやらない人は多くは無くてある程度仕事をしてたら、少しずつ設計のレイヤが上がっていって要件定義やったり要求分析やったりするようになるのよ
直接手を動してデザインを描く作業より、デザインを決める、デザインを説明するetc.なんかの上位レイヤの能力が重要になっていくだろうって言ってたし
デザイナー（not 絵師）の仕事は絵を描くのが仕事では無く顧客の要望をデザインで実現するのが仕事だよって言ってたし
お仕事に複数レイヤあるのが分かっててより上位のレイヤに行くなど市場価値のあるスキルセットを適宜学習し続けるのが当たり前の人たちか
ただ、パソコンでやるから着席したら好きなタイミングで始めろ ・ 制限時間はあるがその前にすべて解き終わったらさっさと帰って良し ・ 試験終了押した瞬間点数表示って点はハイテク〜って思った。他の資格試験受けたことないから知らんけど。
あ、あと試験前にググってたら「試験中飲み物持ち込めないし休憩時間でも所持品ロッカー開けるの禁止だから水分補給無理だぞ」って書いてるブログ見つけてビビったけど別にそんなことなかった。持ち込むのは無理だが休憩時にロッカー開けて飲み物飲んでいいか聞いたらOK言われたし。
科目Aはストラテジ系の対策ほとんどしてないのと高級言語しか触らんので低レイヤーの知識なくてギャーってなったけどなんとかなった。
なので(？)自分は科目Bの方が点数高かった。
聞いていた通り独自言語？だったがとくに読みづらくもなく。普段コード書いてる人ならすんなり読めると思う。
で、今日、たまたまはてブをダラダラ見ていたら「ちゃんと教える人がいても、教わる人が大卒の人であっても一定率プログラミングを理解できない人がいる」という記事を見て、あー科目Bはそういう人じゃないかどうかを判別する為にあるんだな…って思った。たぶんだけど。
俺は大学行ってないがある程度コードの読み書きができる。やったぜ。勝ったぜ。まあ学歴で負けてるからそこをカバーするためにわざわざ基本情報取ることにしたんだけども。
んでんで、結果はいけたっぽい。でも次の応用情報が年に2回しかない(基本情報は今年度？からほぼ毎日できる)とか、常時受付になってから合格率上がってハードル下がったなんて言われてるだとかでちょっとへこんだ。
元不登校くん、頑張ってるぜ。
