  |
はてなキーワード: アセンブラとは
プログラムを理解させるには？のブックマークコメントを読んでいて。
ブックマークコメントの中に、「資格」とかのコメントがいくつかあった。
既に情報処理試験とかあって、いろんなIT系資格があるのだけど、プログラマーやってる人なら誰でも感づいているとは思うが、資格など何の役にもたたない、という事で。高度情報処理資格を持っているからと言って、プログラム（その他設計やコンサル）が出来るとは限らず、逆に何の資格も持っていないのに、すばらしいプログラムをする人がいる。
まぁ、これら既存のIT系資格にある一定の目安にはなるとは思うけれども、万能では無いのも確か。昨今の不況、ITバブル崩壊で、IT系資格の資格手当が真っ先に削られたのも、記憶に新しい（弊社だけかもしれないが）。
雇う外注のソフトハウスから派遣されて来た人など、だいたい15分も話せば、どのくらい出来るか、使えるかは判断出来る。これは資格では計れないものだ。
仮に、弁護士や行政書士、医師など、士制や免許制はどうだろうか？
車の免許はどうだろう？
プログラマーはどうだろうか？
例えばトイレ。水を流すのに、最近のトイレは、リモコンでスイッチを押すと水が流れるが、あれ、プログラムだよね。
例えば炊飯器。米と水を入れて、スイッチを押せば、ご飯が炊きあがるが、これもプログラムだ。
車。ハイブリットや低燃費車が走っているが、あれは電子制御で動いている。
ロケット。アポロはファミコンにも劣るコンピュータで月まで行ったが、プログラムだ。
先日の中国の高速鉄道の事故も、ATCプログラムのミス（？）による事故だ。
先日の$oftbank携帯の通信障害は、故意に仕組まれた通信障害だった。
どこにでもプログラムは入り込んでいるし、そのプログラムによって、便利になっている反面、人命をも奪い、都市機能を麻痺させる事も出来る。
なんでだろう？
介護について考えてみよう。
ヘルパー資格や介護士とかいろんな資格が必要だが、世間一般的には、ワーキングプア、もしくはそれに近い悲鳴が聞こえてくる。
なんでだろう？
資格や免許を持っていても、それが収入や時間に反映されないいい例だと思う。
「プログラマー」「SE」と名乗るのは簡単だ。「漫画家」「小説家」と名乗るのと同じように。なんだったら、名刺の名前の上にそういう肩書きを書いておけば、「プログラマー」であり「SE」である。
漫画家・小説家と違うのは、漫画家や小説家は「売れなければただの無職」という事だ。あっという間に食えなくなる。自分、アシスタントをやっていたし。アシスタントでは、ちょっと食っていけなかった（アシスタントと作家自身は違うが、それなりに間近で見てはいるわけで）。
プログラマーやSEが個人事業種の人達だったら、その通りになるだろうけど、多分、半分以上の技術者は、どこぞの会社に所属しているサラリーマンだと思う。もちろん、これはこれでメリットがある。営業や経理・総務・庶務等が他の人に分担されている事や、会社などの福利厚生も使えるから。
逆に「金の切れ目が縁の切れ目」が使いにくいというのがある。同僚が失敗したり行方不明・自殺等というのはこの業界日常茶飯事だが、そのリカバリーは必ず誰かがやらなければならない。そして不思議な事に、それをやる人間は決まっている。失敗したマンガや小説を他の作家がリカバリーする、というのはあり得ないのにね。
資格制度・免許制度が万能とは言わないが、有効かどうかと言われると、自分には判断出来ない。しかし、前述したとおり、非常にクリティカルなモノを作る場合も有り、無資格なのはそれはどうだろうか？とも思う。
プログラマーやSEがミスすれば、都市機能は麻痺し、人が死に、医療器具が動作せず、電力が起きず、このインターネットすら動かない。TVもラジオもダメ。第1次産業以外のほとんどが停止する事になる。
そんなクリティカルな仕事なのに、この士農工商穢多非人の非人のような扱いを受けるのは何故なんだろうか？
経営者や管理者からみれば、次から次へとターゲットが蛆のように沸いて出てくる職業であり、使えるだけ使って、あとは使い捨て、という業界だし。
一度、プログラマーやSEは自分のやっている仕事がどういう事なのか、考えてみた方が良いのでは無いだろうか？
考える事は出来ると思うよ？ だって、「完全動作する事を常に考えている」のだから。それが過失・故意にでも動かなかった場合、どういう事になるかは、簡単に想像出来るよね。
絵描きや小説書きや楽器演奏や作曲は、小学校の頃、学校で習うから、分かると思うんだけど、【今の現役世代以上】のプログラマーやSEは、小学校で習わなかった。この差が非常に大きいのだと思う。
どんな無能な経営者や無能な管理者だって、「自分が絵を描けない・難しい」というのは、自分で分かる。なぜなら、義務教育時代にやっていたから。ところがプログラミングやSEはどうか。やってないから分からない、わけだ。
あと、拍車をかけているのが、どこかが発表している「情報技術者何万人不足」という発表。この時点で「質」が考えられていない。そこへ、程度の低い派遣業が入り込んで、エライ事になる。そもそも派遣とは、受け側に技術が無いからその手助けに赴くものであって、人身売買では無い。先日も弊社で「組み込み系の低いレイヤーの部分を作るC言語（かなりアセンブラ寄り）が出来る技術者」を要求したのに、実際ソフトハウスから派遣されてきた人間は「C言語のポインタという概念も知らない」技術者だった（どうやら、Windowsの統合開発環境上においてC#だったら使える、というレベルだったようだ）。もちろん、そんな人員を使えるわけ無いのでその場でお引き取りを願った。こういう、「質」や「ベクトル」に関係無く「頭数」だけでどうにかなると思っている奴らが非常に多い。日本の（少なくとも情報系）派遣や客先常駐の考え方は、間違っていると思う。
そう考えると、ある一定の基準として、質やベクトルを明記する必要はあるのかもしれない、と思う。それが労働時間や賃金に反映されるかどうかは分からないが。
こうした言語の話ってさ、いつもいつも狂信者みたいな人とか、単に引っ掻き回すだけの人が現れて
「高級言語なら簡単なことが簡単にできる」とドヤ顔で言うんだよな。
「簡単なことを簡単に書くために、高度な言語サポートがある」といって「簡単な事では問題が起こりません」って言うんだ。
そして、メンテナンス性とかの話をしてたはずなのに、「言語がカバーしてくれる」とか言い出す。
んなわけないじゃん・・・・ドキュメントの不備ひとつで、どんな言語だろうが難攻不落の砦になったりするんだよ。
それは君が、高級言語の機能を活かした質の良いコードを見たことがないだけだと思うよ。
そうしたコードは、たとえドキュメントが皆無でも実装者の意図を推測するのは難しくないし、メンテナンス性が高く、機能追加も容易だ。
アセンブラでも設計さえ確かなら問題ない。うん、そうだね。これは単純に比較の問題だ。アセンブラで堅牢さを実現できる設計なら、高級言語を使えばさらに堅牢に作れる。したがって、特に理由がない限り、アセンブラやC言語を使う理由はない。
ましてや、常に完璧な設計をすることは不可能だ。また、「完璧」な設計は要求変更に弱い。ならば、なおさら堅牢性の低い言語を使って実装する理由はない。
こうした言語の話ってさ、いつもいつも狂信者みたいな人とか、単に引っ掻き回すだけの人が現れて
「高級言語なら簡単なことが簡単にできる」とドヤ顔で言うんだよな。
「簡単なことを簡単に書くために、高度な言語サポートがある」といって「簡単な事では問題が起こりません」って言うんだ。
そして、メンテナンス性とかの話をしてたはずなのに、「言語がカバーしてくれる」とか言い出す。
んなわけないじゃん・・・・ドキュメントの不備ひとつで、どんな言語だろうが難攻不落の砦になったりするんだよ。
逆言えば、アセンブラだろうがドキュメント（そして設計）さえちゃんとしてれば、全然普通にメンテできる。
カーネルコミッターでも、処理系実装者でも無さそうな人達が、「Cは滅びず！」と叫んでいる不思議な光景。
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5545216280/c
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5603961294/c
Linuxカーネル（せめてPOSIX互換品)を手前が思う言語にさっさと移植すれ。さすればCを滅ぼせん。（ちなみに高機能アセンブラの最適解がCとは俺も思っちゃいない。）
最後のＣの牙城、Linux（ＵＮＩＸ）をＪａｖａなり何なりベターな言語にさくっと移植してくれ。それともgoogleビッグブラザー様がクラウドでＵＮＩX鯖を駆逐してくれるのを祈ってればいいのか？
JavaもC#も，それにPerlもRubyもPythonも，実行環境自体はCで書かれている件。コンピューターが「シリコンを基材としたチューリングマシン」であるかぎり，アセンブラとCは滅びない。
まぁ、タイトルの「レガシープログラマ」とは私の事なんですけどね。
if( foo == TRUE ){
という判定文をよく見かける（fooはいろんなオブジェクトだと思ってほしい）。
個人的には、この書き方、嫌いなんだよね。
if( foo ){
か
if( foo != FALSE ){
と書いて欲しいわけよ。とにかく「TRUEか？」という判定にはして欲しくないわけです。
で、なんでこう書くの？と外注や若い連中に聞いたら、「TUREは1ですから」と必ず答える（断言する）。
あ、あれ？？？自分は「TRUEはFALSEでは無い。確定しているのはFALSE=0という事だけ」だとずっと思っていたんですわ。
古いC言語風に書けばこんな感じ。
#define FALSE 0 #define TRUE (!FALSE)
確かに、実際に値を表示させてみると、昔のVC6だと「1」という結果が出てくるし、VB6だと「-1」という結果が出てくる。これ、当時混乱の元だったんだよね。
新しいC++や規格ではBOOL型というのがきちんと定義されたと思うけど、製品寿命が20年とかいう私の職場では、DOSやC(K＆R)、アセンブラは現役だし、プラットフォームもなにもWindowsに限らない。組み込みマイコンも使う（うちのところはVxWOKSだが）し、UNIXやLINUXも使う。
もちろん、マネージドC++（.netFramework)やC#、JAVA、Parlも私は使うし。でも、どのプラットフォームでどの言語になっても「TRUEか？」という判定文は使ってこなかった。
で、試しに、VC2008のincludeフォルダをgrepしてみたら、
#define TRUE 1
あ、ほんとに「1」だ。
typedef bool int
なんて見かけるから、やろうと思えば「5」でも何でも数字が入ってしまうわけですよ。そこで「== TRUE」なんてやられたら、絶対に成立しないわけで。バグの温床になるんじゃないかなー、と思ってかたくなに前述の姿勢を持っていたわけです。
今（最近の）言語はきちんと「BOOL」型（またはboolという名のクラス）を定義されていて、コンパイルエラーになるか、自動的に補正してもらえるのかもしれないけど、ちょっと気持ち悪い。
最近、ちょくちょく外注や若い連中と意見や話が合わず、「ああ、俺ってレガシープログラマなんだな」と思う事が多くなった今日この頃。ネットワークに平気でリトルエンディアンのデータを流すとか、勘弁して欲しい。LANアナライザでデータが見にくくてしょうが無い。
仰る通り、ハードウェアアーキテクチャについては知らないですね（スタックやヒープがどうとかは表面上わかりますが）。
というのはズバリそこが非常に嫌い（肌に合わない）で、意図的に避けてるからです…。アセンブラの本とかも持ってますが、どうにも読めないですね…。
当然Cは嫌いです…。C++がギリで、できればRやpythonレベルの抽象度で全部済ませたい派です。が、さっきも書いたようにちょっと踏み込むとすぐ低レベルの話が出てきますね…。
最近はGPUだの並列化だのを使いこなさないと生きていけない感じですし。
関数型言語くらい抽象化して数学っぽい雰囲気になってると個人的には嬉しいですねw
残念ながら、その読書履歴だと、ここで言う「原理」には辿り着いてないと思います。挙げられた本はどれも計算に関する抽象概念からさらに上の、アーキテクチャを言語化する部分に関してです。それらも原理と言えば原理なのですが、そこからスタートしてもC言語でのプログラムは書けるようになりません (Rとかなら書けるかもですが)。
ここで言う『原理』すなわち、なぜ char x[sizeof(int)]; がダメなのか、という理解につながる原理は、「レジスタ」「ALU(CPUの中の計算ユニット)」「バス」「メモリ」といった原理です。メモリアクセスやヒープ・スタックの使い方、アセンブラといったような話です。
なんで言語の約束事の上っ面を覚えるのが難しいか、というと、「原理」を理解していないからなんです。原理を理解せずに約束事だけ覚えたって使えません。曖昧で良いので、プログラムを動かしているときにどのようにメモリが構成されどのようにアクセスされるのかを知る努力をして下さい。その上でC言語をよく見ると、いかにCPUアーキテクチャに近い所で記述されているのかがわかるようになると思います(*)。
それだけで、目の前の箱がどう動いているかの理解度が劇的に上がる筈です。
*: 理解したつもりになるだけですが、現実のコンパイラもCPUも、そのさらに7歩ぐらい先に行っています。ですが、この領域は進めば進むほど泥沼なので、「あ、Cって高級アセンブラなんだな」という所で実用上は十分だと思います。てか、偉そうなこと言っている私(某大学博士課程在籍、要は増田で現実逃避中のダメ学生)も、そこから先はちゃんと理解していません…。
単純な例だと
微分積分を習うまで 算数から初めて 633で約10年ぐらい勉強して、その微分積分があって、フーリエ級数展開なんかがあって、そっから、初めて信号解析が始まって、MPEGのCODECの研究なんてのにたどり着き
ようするに、そういう例では 20年近くキャリアを積み重ねてるわけだよね？小学生から。
大規模設計で
ハードウエア使って基礎から設計 サーバーもクライアントも、一体で
ともなってくると、必要な知識だけでも、山ほどあるわけだが？終わるわけないだろ10年ぽっちで。
そういう基礎知識があって、それこそ８０８６のころからアセンブラやってる経験も含めて、ようやく できるようになってきた。まだまだ先は長いって間隔なのに
10年程度でできるようになるって、どんだけプログラムを浅く見てるんだ？
たぶん、一通りできるようになって、一人前ってので30年。 親方クラスで５０－６０年ぐらいだろ。修行は一生。
変な話だが、プログラム的にこう書いて、こう使うのが効率的だから、ハードはこういう風になって、ここにこういう部品を作って基盤作ってくれとか
ハードの知識までないといえないぞ？
逆にハードがこうなってるから、アルゴリズムはコッチ とか ハードの設計見て プログラム組み替えるとか、けっこうな経験がないと無理。
で、さらに、それを指示だしして、経験ないプログラマにある程度やらせて、レビューして・・・
そんな経験積んでいって、10年でできるようなもんじゃないとおもうが・・・
結局 文型10年プログラマーって 数学的知識だったり、たとえば、コンパイラの左結合とかそういう話だったり ついてこれないことがあって、学問的に無理。
ポスドク になって 不良債権化 とか 文系にうっかりは入って就職難民という道もあるので、
大学なら何でも良いという事でもない恐怖。
文学部入って、趣味パソコンでもない奴がIT系とか 業界なめられてるというのもあるが。
なんにせよ。『串打ち三年裂き八年焼き一生 』 10年ぐらいは打ち込みたい物を早く見つけるしかないねぇ。
東大出てフリーターという奴もいれば、高専卒でもチェーン立ち上げて億万長者という奴もいる。
高校受験の時に進学校への判定が怪しくて、家が貧乏で 私立が厳しい ＞ 有名校はあきらめて、スキル重視で高校選び・大学選び
自分が出来そうなこと。食えそうなことに絞って 高校受験から数えると もう20年 この道一筋でやってきて まぁ、それなりに食えてる。
当時の自分の偏差値が20ぐらい下の高校へ行って、あいつは実はバカだったとさんざん言われたけど、設備と教育方針で選んでITの最新設備がある高校へ。以後大学も同じ。
スキルは相当学んだよ。高校でアセンブラとか やってるような奴ばかり集まってたからね。
『あきらめ』なんじゃないかと思うけどね。
東大 早慶の理系か有名校の医学部に入れるかどうかで考えて、無理なら、
自分がこれなら喰える出来そう得意そうという道をさっさと見つけて妥協して、しがみつく。そして、その道に強い大学・専門＞企業を選んでいくしかないと思うけどね。
増田さんの記事、読んだ覚えがあります。→ http://anond.hatelabo.jp/20090929121430 でしょ？
http://anond.hatelabo.jp/20090605202807 とか読み返してあの頃の明日をも知れない感じを私も鮮明に思い出しました。
CiscoやLinuxの設定やってる人間からすると、ファームウェアプログラマには畏敬とかコンプレックスがあるので、これを言う権利が自分にあるのかわかりませんが(いつかMIPSの逆アセンブラでIOSの魔改造できるようになるのが夢です)、おかえりなさい。本当によかった。
「製造側」から「設置側」への転身、ですかね。
仮に教わったと読み取れる文章だったとしてだ。
欧州の工学専攻の学生は、制御システムを作るのにC言語を学ばないらしい。
かつてアセンブラ(低水準言語)で最適なコードや最速のコードを書いていた人達は、
必要無くても、全部じゃなくても、とりあえず中間コードに目を通す。
何故読むのかと聞かれると、根本的な理由は「習ったから」なのではないかと思う。
これが元増田の主題であったわけ。少なくとも俺はそう読んだ。
時には知らないことも効率化の面では重要なのだと。
そして筆者は
と結んでいる。もしそれが必要であるなら、これまでの慣習を捨て、習ったことも忘れて新しい手法で取り組むこともやぶさかではないですよといっている。
これに対してだ。
「じゃあ自発的に学んだ人はどうか？」という話題を振ること自体、
ナンセンスだと思わないか？
欧州の学生がC言語を習っていないことを問題視している文章でもないし、
あまつさえ欧州の学生が学ばない理由について書いてあるのであって、習わない理由についてではない。
重要なのはそう読めるかどうかではない
そこが主題かどうかだろう。
そしてこの筆者に対して、
小学校時代にBASICを自分で調べて使えるようになりましたが何か？アセンブラも独学だし。
基本的に、そういう人は多いけど、
技術屋としては、必要かどうか？なんじゃね？
これがいかに頓珍漢なトラックバックだったかお分かりだろうか。
欧州の工学専攻の学生に比べて必要ないことを学んでいるのではないかという主題の文章なのに、
必要かどうか？なんじゃね？
どんだけ文章読む能力がないんだと。
そう言いたかった訳なんですよ。
そしたらこれだもの。
小中学生の話を持ち出してきたから、小学生時代の話を持ち出したわけだが・・・
申し訳ないんだけど どうして、素っ頓狂なんだかわからないので、説明して。
どうしようもないでしょこの人。
欧州の工学専攻の学生は、制御システムを作るのにC言語を学ばないらしい。
Simulink等のモデリングツールで制御モデルを作って、コード生成や実装は単なる作業として行う。
C言語などの高水準言語のコードは読まない。コード生成ツールを信用しているからだ。
当然、低水準言語のコードも読まない。コンパイラを信用しているから。これは日本人も同じ。
かつてアセンブラ(低水準言語)で最適なコードや最速のコードを書いていた人達は、
必要無くても、全部じゃなくても、とりあえず中間コードに目を通す。
モデリングを始めた人も同じで、必要無くてもモデルから生成されたコードを読む。
何故読むのかと聞かれると、効率が悪い、想定したコードと違うなど、
最終的には「信用できないから」という結論になる。
でも根本的な理由は「習ったから」なのではないかと思う。
小中学生が良く「それは習っていないから」という理由を訴える。
逆にとらえると「自分が習った事」を自分の基準として捕えるという事ではないか。
繰り返すが、欧州の工学専攻の学生は、制御システムを作るのにC言語を学ばないらしい。
それが理由かどうかは分からないが、制御システムを考える環境はモデリング環境である。
トヨタ自動車が自動コード生成を使う事を発表してからもう5年以上経ったが、
日本の自動車業界の制御システム設計がモデリングを当たり前に使うようになったかというと、
間違いなくそうではない。
自分自身もC言語を習い、モデリングに馴染みきれない人の一人だ。
C言語を最初に覚えると、楽は楽だよ。変なクセがつかないから。
全てのC++はCに展開できるし、展開の原理を知っていると、C++でオブジェクト的に組みながら、アセンブラの展開とかを見ながら書いているらチューニングが楽。
メモリの事とかCPUリソースのことを考えずに書かれたプログラムって、チューニングに限界があるから、あとあと苦労する。
そういう意味では、Cから入ると、とっつきにくいが、あとあとまで、ちゃんと生きてくるよ。
今のところの言語のオススメはJavascriptだね。理由は簡単で
１ ブラウザがあれば誰でも試せる
２ ブラウザとの連携で絵や音を使ったサンプルを作れるのでつくっていて楽しい
という点。
さすがに、今時PerlでもRubyでもいいけど、絵や文字ばかりのサンプル作ってもCと同じで楽しくないから初心者向きじゃない
とりあえず、そのへんで楽しんでもらえたら、
プログラムの職人的なチューニングのところが気に入ったのならC/C++に転向すればいいし 机の上で理論や設計を楽しみたいならRubyやJavaをやればいいし
Web系のところが気に入ったのならPHPでもPerlでもいいかもしれない。
大切な事は、プログラムを楽しむこと。プログラムにもいろいろな側面があるので、自分がどういう側面を気に入るのか？というのを早めに掴むこと。
あとは、長く続けられるものを選ぶこと。
まぁ、言語は所詮道具だ。道具の良し悪しを言っても、釣りにバットを持っていくわけにもいかないから、釣りがしたければ釣竿を、野球がしたければバットを選ぶしかないわけで
目的にあった言語を選ぶための最初の言語は、気軽に選べばいいよ。
逆アセンブリ禁止手段がない、という現状だと押さえる手段はないかなあ、と。
出発点がずれてましたねｗ
いいんじゃないかな。
俺が思うに基礎体力を付けるなら、アセンブラからはじめて、時系列でプログラミング言語の歴史を追体験してもらうのがいいと思うよ。
基礎体力を養う意味ではここら辺がいいと思うんですがどうでしょう。
これがわかるとCLRやJVMのインフラ部分もわかりますし、組み込み方面にも強くなります。
C++はマルチパラダイム言語であり、これをひとつやれば構造化プログラミングとオブジェクト指向プログラミングの両方がわかります。
C++はCのほぼ上位互換言語ですので（正しくはC99が制定されるまでは）、プレーンなCしかやらない理由はありません。
嫌なとこも多くある言語で（どうしてEffective C++シリーズやExceptional C++シリーズみたいな書籍が多くでてるか考えるといいよ）、メモリ管理も手動ですが（これは半分嘘。RAIIがあるから半分自動。GCがないから半分手動）、逆に細かいとこに気を配る態度を養うには最適です。
Erlangで並列プログラミングをやるのもいいかもしれません。
Common LispかSchemeで怪しい（でも美しい）世界を爆走するのもいいかもしれません。
これだけやっとけばC#やJava、軽量言語の類はあっさりと料理できるでしょう。
あくまでもプログラミング言語についてはですからね。
Rubyは、純粋オブジェクト指向と評されるHaskellの直系と遇されるのが常だが、私の見解は、むしろマクロアセンブラにより近い、というものなのだ。Rubyにおいて継続すなわちcontinuationの使用はもはや常態とも言えるが、一方のSchemeでは、Algol的な例外機構の残滓により、Unixシグナルに留まっている。
制御構造のみならず、データ構造の観点からも、RubyはSchemeよりはるかにポストモダンと言えるだろう。淵源へと遡れば、マクロアセンブラとPascalの対立の図式へと導かれる。私は、Schemeのデータ構造は、唾棄すべき要因を含むという思いを抱く誘惑に抗いかねるのだ。そうであるならば、民主党の政権交代は失敗であったと結論せざるを得ない。
もとより、アインシュタインの相対性理論からも、明らかにRubyに軍配が上がるだろう。SchemeをSchemeたらしめているブロックスコープ構造にしろ、今となっては決して珍しいものとは言えない。いやむしろ、真に純粋関数型を指向するなら、Schemeへの共用体の導入をこそ今真摯に検討すべきなのだ。演算子オーバーロードですべての問題が解決するわけではない。この実存的な課題をただ黙殺しているSchemeに、私は異議を申し立てる。