はてなキーワード: 機械語とは
今も昔も結局動くのは機械語に沿ってじゃないの?
低級言語や機械語、もっと言えば半導体中のエネルギー準位やドリフトが根本でそこからボトムアップという考え方がそもそも視野が狭い気がする。
実用的なコンピュータが登場する前からある種のプログラミングやアルゴリズムは存在したはず。
名前が残ってるような黎明期の有名人は軒並み「コンピュータに勝てた」的なエピソードがあるレベル。
ノイマン型コンピュータなんて筆記用具と同じ手段でしかないよ。
「ある世界(自分の望む世界)の理を限定的にエミュレートできる道具のローカルルールに仕方なしに合わせてやってるんだ」ぐらいの感覚でいた方が良い。
なんで中身の構造のうちで、IFとWHILEで組み立てられているロジックという
特定の階層の構造までを知らなければならないと考えるのですかか?
なぜ高級言語を成立させている機械語の構造まで理解しないのか。
なぜ機械語を成立させているCPUの論理回路まで理解しないのか。
なぜCPUの論理回路を成立させているトランジスタ特性まで理解しないのか。
なぜトランジスタ特性を成立させている物理法則まで理解しないのか。
なぜあなたは、フレームワークの中身まで理解しなければならないと考えるのに、
物理法則の中身までは理解しなくてもよいと考えているのですか?
プログラマだけど、これに関していつも思うのはそもそもプログラミング言語が英語ベースなのがよくないということ。
機械語が人間にわかりにくいから自然言語をベースにしたんだろうが、そうじゃなくて「人間にわかりやすい機械語」を開発すべきだった。
自然言語だとどうしても害しかないイレギュラーな文法の弊害に遭う。たとえばモデル名は単数形・テーブル名は複数形みたいな規約が多いけど後者は単語によってsだったりesだったりそのどちらでもなかったりとルールが違ってややこしい。その辺自動で生成してくれるフレームワークとかあるけどそのためにわざわざ不規則変化する単語の辞書持たせてんだぜ。そもそも単数形・複数形って何だよそもそも言語に必要なのか?日本語にはないぞ。
こういう自然発生した事故みたいな自然言語のクソ仕様に振り回されながら機械に指令を出すってアホらしくない?俺はもう老害だから若手はこの辺21世紀内に解決しろよ。
以下、プログラミングは出来ない俺の認識が間違っている場所があったら教えて下さい。あと、疑問2つを教えて下さい。
【俺の認識】
1. コンピューター(というかCPU)が実行する命令は【機械語】で書かれている。たとえばx86CPUの場合、0x04ならば『imm8をALに加算する』命令、0x90ならば『何もしない』などである。
2. 流石に機械語のままでは人間がプログラムするには不便なので、機械語をそのまま人間にも意味が分かるように1対1対応で書き直した【アセンブラ言語】というのがある。0x04ならば『ADD AL, imm8 』、0x90ならば『NOP』と表記される。
3. アセンブラ言語のように機械語と1対1対応している言語を【低級言語/低水準言語】と言う(この呼び方、4で書く高級言語が出来てから生まれたレトロニムか?)
4. アセンブラのままでプログラムするのも困難である場合が多いので、機械語と1対1対応していないプログラミング言語もある。このような言語を【高級言語/高水準言語】と言う。
5. 高級言語で書かれたものはそのままではコンピューターには実行できないので、【コンパイラ】というソフトによって機械語に変換している。
6. 高級言語で書かれた状態を【ソースコード】と言う。このソースコードをx86用のコンパイラでコンパイルすればx86で動くソフトになり、SPARC向けにコンパイルすればSPARCで、PowerPC向けにコンパイルすればPowerPCで動くソフトになる。
【疑問】
a. 認識6が正しいのであれば、(サポートするファイル形式の問題などを置いておけば)windowsとmacは現時点では同じCPUを使っているのだから、同じコンパイラでコンパイルしたソフトはwindowsでもmacでも動くのではないか?
これは昔からあったんだが、
コンピューターのC言語などを使うコンピュータープログラムという分野はマルチメディアと呼ばれる学問や、映像、表現技術ではなく
電子工学と電気工学の違いは、ものすごい大雑把に言うと、デジタルとアナログということも不可能ではない。
電子工学というのは電子デバイスつまり大雑把には半導体のことでありCPUなどのプロセッサなどの学問であり、コンピュータープログラミングを内包している。
他方、映像分野からきたひとからすると、メディア系学問でも当然プログラムは習うのだが、そりゃならうだろうが、学問的に分類するとC言語などのプログラミングは電子工学なのである。
Manycoreという技術そのものはIntelもだしてる。さらなるManyはGPGPUでやってる。
他方シングルコア性能は上がってはいるが4Gぐらいで、議論を呼んでる。
今議論を読んでいるのは、コンパイラの最適化と、マイクロコードの最適化
そこはかなり疎結合だからな。インタプリタで言うエンジンの最適化ではないが
CPUでどう最適化されるか?をインタプリタがもうすこし制御すればインタプリタのスクリプトコードをもう少し効率的な生成にできるのではないか?というアプローチがJava的ではなくPython的にあらわれはじめていて、けっこう、興味深い
デフォルトのPythonとコーダーが機械語の変換について学習させてあるPythonという考え方はとてもポケモン的で面白い
https://b.hatena.ne.jp/entry/s/jp.quora.com/hotondo-no-puroguramingu-gengo-de-kansuu-no-return-ga-1-tsu-shika-deki-nai-no-ha-naze-desu-ka を呼んだんだけど、回答・ブコメともにとんでもないことを書いている人がたくさんいてびっくりした。本質的に多値返しは直積型の返しと同じで、これはタプル・構造体と本質的に同じ、というのは多くの人が指摘している通りではあるのだが…。
動的型付け言語に慣れてらっしゃる方が多いのかもしれないけれど、配列というのは「同じ型をまとめた型」であるべき。動的型でいろいろ突っ込める配列は本質的には「直和型の配列」と思った方がいいよね。多値返しという意味では(記憶領域の面で)余分なコストがかかりうる直和型を選択する意味はないですよね?回答でもなんか配列返しに言及している某有名人がいたが、あれれ?という感じ。
もっとも、immutableな配列をtupleと呼ぶPythonという言語があるせいで引っ張られている感は否めないけども、配列とは本質的に異なる型が存在しているのは明らかですよね?配列と構造体って違うよね…?(言葉の定義の問題と言われそうだけれど、型システムの分野での言葉の定義は存在しているわけで、反論になっているとは思えない。『俺は明日からこのわんわんなく動物をネコと呼ぶから』と言っているようなもんでは。)
確かにナイーブにはレジスタに入れて返すのが素直だというのは同意するけど、でもそれ構造体と一緒だよね?昔のCではこれはできなかったというのは知らなかったので勉強にはなりました(未検証だけど)。
あと構造体返しの関数がどう機械語で実装されているのか知らなさそうな人がいるのにはちょっとびっくり。それでなんでレジスタがどうとか言えちゃうのかしら。構造体の値を返す関数ならばポインタは返さないですよ。そのポインタはどこを指してるんですか。実装しづらいとか何とか言ってる人たち、ちゃんとアセンブラ読んだことあるんですか…?本質的に何の困難もないです(ちなみに少なくともlinux amd64ではスタックに領域を確保してそのポインタを関数の引数の一部として渡します。まあヒープに置く場合でも余計なmoveが出ないようにしたいとかあるかもだけど、そんなでかいデータは普通無名構造体では扱わないでしょう)。
確かに、返り値の型が(A, A)のような場合はドキュメント読まないとわからなくなってしまうので可読性が下がるし構造体を使うべしというのは(ほぼすべての場合において)同意(多値は使いづらいというのは構造体は使いづらいという意味ではないですよね?)。でもさ、某有名人もgoで挙げているけれど多値って普通(A, B)みたいに違う型の値を返したくなることの方が多くないですか。この場合どっちがどっちかは自明だよね?ただの無名構造体だよ。多値返しは設計が甘いとかわけわからんことを言っている人もいたけれど、なんかこちらが不安になってきた。
…本当に意味不明で驚いた。id:megumin1氏が言っているように、tupleのパック・アンパックに余分なコストをかける必要はない(まあアドレス渡しになるから複数本のレジスタで返すのと比べたら余分なmovが入りうるという話はあるけど、この人が多値返しというので何を想定しているかわからないので何とも。)。何遍呼んでも多値返しとtuple返しの違いが判らなかった。おそらく前述のようにimmutableなlistのことをtupleと思っているのかな?と予想はするが…。
はてな界隈ってエンジニア的な印象があったんだけど、ここら辺の話ってそんななじみないのかな…?てか某有名人氏も型システムとかあんまりご存じないのかな…?むしろこれは増田が無知なんだろうか…?