  |
はてなキーワード: アセンブラとは
親父様は酒と野球とギャンブルが大好きなクズだったが、浮気と無職と借金だけはしない洗練されたクズだったので最低限の生活は保てていた。
鼻水を垂らしたまま何も考えず中学生になった僕は、そのまま何も考えず地元の底辺工業高校に進学した。
大学進学率0.3%未満の絵に描いたような地域密着型就職支援高校だった。
バカ、貧乏、次男坊のフルコンボを駆使し田舎を出て神奈川の大きな工場に就職した。
「僕ぁ、こんな事をする為に高校でプログラムを覚えたわけじゃないんですよねえ」等と同期のヤンキー達に吹聴してたら流れ的に辞めるしかなくなった。
とはいえ、ホントはプログラムなんか言う程できたわけじゃないので、どっかの会社に応募して落とされたら、周りも納得するかーなんて軽い気持ちでテキトーに選んだ会社に応募したら内定きた。
その会社でアセンブラとかいうミトコンドリアみたいに原初なプログラム言語を叩き込まれた。
おかげで、CだろうがCOBOLだろうがC#だろうがJAVAだろうがハイソサエティだよね、て気持ちになれた。
結局そのままいろんな会社を転々としつつもプログラムの仕事を今でも続けられ、不自由なく暮らしていけてる。
僕の未来予測では35歳になるまでに、能力的に限界がきて、pepperくんに仕事を奪われ、飲んだくれた挙句、アル中で手の震えが止まらずキーボード打てなくなり、プログラム以外の仕事もできず、部屋に引きこもりxvideosばかり見てたら奥さんに愛想をつかされ、底辺高校に行かせるのがやっとの長男と、承認欲求をこじらせてニコ生やらツイキャスやらで裸体を晒す娘を連れて出ていかれるハズなのだ。今頃。
だが、現実はどうだ。
天海祐希似の奥さんと、映画やCMとかで使われるくらい良ロケ高校に通う長男と、部活に汗する健全な娘に囲まれ、それなりにシアワセに生きている。
小学校時代に道端で座り込んでた奇妙な婆さんに「お前さん、34で死ぬよ」と言われ、なるほどですねーと過ごしていたが、既にそのＸデーから十年以上経過しても元気に生きている。
たぶん、何十回か別の世界線で死んでるよね？僕。
じゃないと、そろそろ変な死に方しそうで怖い。
結論から言うと型を欲するのは成長できた言語のみに許された特権である。
どんな言語も最初から厳密な型チェックをアピールしてしまうと開発を阻害するばかりで流行らない。
増田の理屈だと最初から全部C++かJavaで作ればいいじゃんとなるが、
現状を見るにそうはなってない。
web黎明期のフロントエンドを支えたのは紛れもなく型チェックのゆるい言語だ。
パソコン黎明期の一般向け主力言語はBASIC（あるいはアセンブラ）だったわけだが、
時代が進むにつれて型チェックの厳しい言語を求めるようになるのは理由がある。
それはプログラムの規模だ。
言語が出た当初はライブラリも少なく、できることも少なかった。
時間が経過してライブラリやノウハウが蓄積し、マシン性能向上も相まってできることが増えてくると
プログラムの規模も増えてくる。
すると、厳密な型チェックを取り入れないと全体を統制できなくなるのだ。
個別具体の退職理由はいろいろあってそれらは後述しますが、退職を決めた基本的な理由は、個人的なキャリアパスの設計と会社の方針のミスマッチ、労働観のミスマッチ、技術投資の考え方のミスマッチの三点に集約できると思っています。
ソフトウェアエンジニア(を目指す人間)にとってソニーと言えば、"自由闊達な理想工場"、エンジニアが自由に活躍できる会社、日本のメーカーなのにソフトウェアもちゃんとつくれる会社、などのイメージがあるかと思います。私もそう思っていました。
実際会社は説明会などでそういった説明をしましたし、そういったイメージを前提に私はソニーを選び、「エンジニアとしてプロフェッショナルになる。品質が高く、お客の求める体験を作り出せる人間になる」というふわっとしたゴールを設定し、いわゆる"プログラマ 35 歳定年説"をガン無視した一生エンジニア型キャリアパスを描いていました。
しかし、会社の求める人材像、少なくとも自分が配属された事業部で求められる人材像、キャリアパスは、上記と全く異なるものでした。
昇進の段階としては、現場業務(エンジニア)は基本的に常にマネジメント業務(中間管理職)に対して格下に位置得付けられており、一部オーバーラップする部分があるものの、昇進する = エンジニアをやめてマネージャーになるという状態でした。退職の原因になった上司からも「君は優秀なんだから、プログラミングみたいな低俗なことは早く辞めて人を動かせるようになれ。私が引っぱりあげてやる」(意訳)といったようなことを言われ、自身の「エンジニアとして生きる」というキャリア設計との相違は明らかでした。
もちろん、組織としてスケールするために、エンジニアが経験を活かしてマネジメントに移行することは否定されることではありません。ですが端から、エンジニアリングをマネジメントになるための踏み台として"しょうがなくやるもの"として扱うことには強い違和感と嫌悪感がありました。
退職の際の送別会で、部署の中でもエンジニアとしてレベルが高いと感じていた40代の先輩が、「ソニーではエンジニアリングは評価されない。俺はその方向に進んだけれど、給料は最近下がる一方だよ。君はいい選択をした」と言っていたのが、未だに記憶に残っています。
私はいわゆるライトなオタクで、アニメやゲームが好きでコンテンツを消化する時間が無限に足りないと感じていたり、自分で何かを考えてものを作るという絶望的に時間を食う行為も好きだったりして、ともかく余暇の時間の確保が人生の重要課題です。
もうご推察されたことと思いますが、ソニーでの私の労働時間はそれなりに長かったです。企画・ビジネスユニット主導のスケジュールに開発部隊は圧殺されて、長時間労働が常態化していました。私も残業時間が 90 〜 100 時間程度の月が 3 ヶ月ほど続いたこともありました。部署の先輩には、残業時間の"平均"が100時間という方もいましたし、月の半ばで法規制が許す残業時間を"使い切ってしまう"ため月の中盤以降は"定時に帰ったことになっている"デバイス系の同期もいました。正直に告白すれば、私もチームリーダーに「打刻してから席に戻ってこい」と言われたことがあり、そのチームリーダーは次の日悔恨の表情で「昨日言ったことは忘れてくれ」と言っていましたが、数カ月後に突然辞めました。
前述の通り、趣味の時間が人生の意義になっていた私にとって、これは体力的だけでなく精神的にも非常にダメージの大きいものでした。上司からの「君のチームが他のチームに比べて残業時間が少ないので、(労使交渉で通常の上限の)60時間まで残業時間を埋めてほしい」という指示が決定打となり、退職を決意するに至りました。
昨今の、シャープ・東芝等のニュースで明らかになっているとおり、大企業だから安泰ということはもう過去の話です。そのため、自分の市場価値を高めておく必要があると私は強く感じています。
しかし、会社はエンジニアリング軽視であり、またその昇進先であるマネジメントについてもお世辞にもプロの仕事とは呼べないものであり(残業100時間を続けないといけないマネジメントとはなんでしょうか？)、ソニーで働き続けることは私の「労働市場で自分の市場価値を高める」という方針にとってリスクでしかありませんでした。
人事担当者に、現在のキャリアパスについて不安があるという相談をしたときにも「増田さんがソニーで(定年まで)働き続けることを考えると〜」のような発言をしており、会社がなくなる / 現状の待遇が維持されなくなるというリスクは全く考慮されておらず、いかにただただ嵐が過ぎるのを耐えるかという発想しかありませんでした。
エンジニアリングについても、昨今の汎用チップにスペック的に見劣りする高額のカスタムチップの開発、そのカスタムチップを使いこなすための C / アセンブラによる手動の最適化といった"職人芸"に対する信仰、大量のテスターを雇っての人力テストなど、エンジニアとしてのセンスとしてやや疑問符がつく、ともすればレガシーな開発手法がまかり通っていたりと、この技術・職場に適応したとして、その人物は一般的な問題に対応できるだろうか？その人物を市場は評価するだろうか？という疑問が拭えませんでした。
また、業務時間がまるで足りないからとコードレビューすらろくにできないので知見がたまらない、時間がないので勉強もできない(しない)、もちろん職場で最新の技術に対するディスカッションどころか雑談すら成り立たない、という状況で、私がこのような職場で業務に忙殺されている間にも、世界のエンジニアは勉強し技術力を高めているのかと思うと、相対的に自分の市場価値を毀損されていると感じ、焦燥感にはちきれんばかりの思いでした。
こういった不安・不満があり、また会社の期待にも応えることが難しいということで、先ごろ無事ソニーを退職し、新しい職場で働き始めています。新しい職場は上記の 3 要件についてよくマッチしていると感じており、心穏やかに働けています。幸い年収も多少増える結果となりました。
色々書きましたが、これらはソニーが悪い会社だと言う話ではなくミスマッチだと思っています。上記の内容はすべて私の価値観を元にした一面からの評価になっており、他方でここで挙げたような会社の考え方(マネジメント優先・仕事優先・安定優先)に同調・納得できる方もいると思います。残念ながら私とはミスマッチだったというまでです。
また、あくまでこれらはソニーという(さらに言えば自分の配属された事業部という)組織に対する評価であり、尊敬できる先輩・同期もたくさんいましたし、そういった方々と出会えた、幸いにして現在も仲良くしていただいているということは、本当にありがたいことです。
みんながしあわせになるといいな。
内定もらった時の風景は今でも覚えていて、友人と一緒に出かけていた先で内定通知の電話がかかってきて、本当に2人で喜んで、とても嬉しかったのを覚えている。どうしてこうなっちゃったんだろうなぁ。
ものつくりの現場で、エンジニアリングをバカにされたのは悲しかったなぁ。私がいる間だけでも、ものが作れなくなっていってるのが感じられたのも悲しかった。
大企業や銀行で、昔から動いている基幹システムは、大抵メインフレームにCOBOLの組み合わせである。
それをここ十年くらい、リプレースでx86系サーバにJavaという構成に変更することが多い。
しかし、ハードが汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。
ぶっちゃけCOBOLはCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは？と思うのだ。
その理由はこうだ。
COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。
勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOLの文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである。
そういうモノが既にある企業や銀行の文化において、当然発注側は担当者からお偉いさんまでCOBOLer系フローチャート脳だし、新しいシステムの設計でもそれを踏襲しようとする。
というか踏襲すること前提じゃないと設計書をレビューできない。
UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。
というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法の設計書で処理を組み上げざるを得なくなる。
そうなると、実装もフローチャートの設計を基にコードを書くわけだが、こういう設計はハッカー文化で発展してきた言語(Fortran→C/C++→Javaという流れと、PerlからPython・PHPというインタプリタ系の諸言語)との相性が最悪である。
設計とは実装を楽にするために書くのに、これらの言語において、フローチャートの設計は役に立たないどころか、邪魔でしかない。
だからFortranしかなかった頃から、本物のプログラマ達はフローチャートをdisってきたわけである。
ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である。
しかし、「普通の人達の普通の思考」からはかけ離れ過ぎているという意味で、「普通の人達の普通の仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。
…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLかアセンブラを選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。
というわけで、自分はCOBOLからのリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。
例外ってあるじゃろ。tryしてる間にthrowされたのをcatchするアレじゃ。あれは、たしかに有用な仕組みじゃ。何かの関数に失敗したとき、本来の値のかわりに特定の値を返すのもダサいし、参照型の引数で成功したか否かを返すのもダサい場面、というのは確実にある。そもそもプログラマは怠惰で忘れっぽい生き物なので、例外という仕組みがなければ、関数で失敗したことにすら気づかないかもしれない。
だがな。例外は魔物じゃぞ。昔は、gotoというものがあってだな。好きなところに処理を飛ばすことができる。あまりに、いろんなところに飛ばせるので、邪悪だと言い出した奴がおって、今ではあまり使われなくなった。なぜgotoが邪悪と呼ばれたか。gotoというのは、順接、分岐、反復という、プログラムを組む上で最低限必要な制御構造から逸脱した、どっかからどっかに飛んでいく、という行為が容易にでき、それを多用したコードはまともな人間には読めなくなるからであった。そして、例外は、まさにその「どっかからどっかに飛んでいく」を容易にするための仕組みなのじゃ。
例外は、順接、分岐、反復による基本的な制御構造があった上で、あくまで対処を要するアブノーマルな状況に使われるべきものであり、例外というのは、制御機構として使ってはいけない。値を返す目的で例外を使ってはいけない。一体どこから来て、どこへ行くのか分からない、そんな、流れ星のような例外の使い方をしてはいけないのじゃ。例外を使うなと言うつもりはまったくない。じゃが、例外は制御構造を壊しうるものだと認識し、例外を悪用していないか、それによってコードが追えなくなることはないか、と、考えてから、使ってほしいのじゃ。
イベントの悪用も見た。イベントは非常に有用な仕組みだし、GUIなんかだと、もはや必須とも言える。なので、イベントを使うことは有用なことだ。けれど、イベントは、いつどこで発生するか予想が付きづらいものが多く、また、スレッドなどを使って非同期でイベントが処理される場合(今時は、多くがそうだろう)は、マルチスレッドと同じく、リソースの排他制御を行う必要があるかもしれない。複数の処理が同時に動くというのは、恐ろしいことなのじゃ。いつの間にか、変わってないと思ってた変数が途中で変わるやもしれない。「まー、滅多に起こらないし、ええじゃろ」って判断の上、何も対策しない、という手もあるが、ええじゃろで済むのか済まないのか検討するくらいは必要じゃわな。C# なんかだと、言語レベルでイベントが実装されておる。じゃから、イベント必要ないじゃろと言いたくなるような場面で、イベントが使われていたコードを見た。
便利な仕組みがどんどん出てきて、新しいものがどんどん古くなる今のコンピュータ業界。新しいものを追いかけるのもいいが、基本は基本として、しっかり押さえて欲しいのじゃ。今更、アセンブラでゲームを作れるようになる必要なぞ、微塵もないが、自分のコードがどのように動くのか、興味をもってほしいのじゃ。わしのような新しいものに不勉強な老害は、最近の若いものが基本的なことを不勉強だからこそ、居場所があるのじゃ。じゃが、わしももう長くない。若いもんは、新しい仕組みの表面だけでなく深い部分に触れて、学んで、わしら老害を追い出せるくらいになってほしい。わしからは以上じゃ。
社長がiPadをどこからかもらったけど、使い方が分からなくてぜんぜん活用してないらしい。
オレに「今度教えてくれよ」とか言ってた。
この前知り会った女の子も、iPadを買ったけど難しくてぜんぜん使ってないとか。
Nexus7がでたころに同僚に「PC使えない年寄りでもタブレットなら使えるんじゃない?」みたいな話をしたら「え？タブレットのほうが難しいでしょ」とか言われたこともあった。
オレの親みたいに、ガラケーの電話番号登録も自分でできないレベルだったらiPadが難しいのは分かる。
でも、社長はPCでExcelを使ったりメールを使ったりしてるし、若い頃はアセンブラのプログラマーだったらしい。
女の子のほうは、iPhoneで動画を見たりSNSを使ったりしてる。
iPadなんて、iPhoneが大きくなっただけなのに、どこに難しい要素があるのか。
PCを使ってるけどiPadは難しいみたいな人に、具体的にどこらあたりが難しいか聞いてみたいけど、増田にはそんな人いないか。
まだまだ一部のエンジニアにとって、という話だよね。
少なくとも英語の読み書きができないと最新のテクノロジー情報をキャッチアップできないとか、stackoverflow読めなくて問題解決できないとか、オープンソースにコントリビュートできないとか、これはまさにその通りだよな。オレもオレなりに英語力の不足を痛感する機会は腐るほどある。
でも日本にいる80万人以上のITエンジニアのうち、そうした能力を必要とされないエンジニアがこの日本の大部分だ。
なぜならSIerみたいな受託開発・運営がソフトウェア業界の売上高6兆ぐらいのうち半分以上で、かつ彼らの大部分は日本語ドキュメントが充実してる枯れきった技術を使い続けるから。
枯れた技術で安定性を担保ってのはわかるが、公式のサポートが終わってるJava4~6,PHP5.0~5.3を使ってんだよ。保守じゃなくて新規案件だよ。COBOL,アセンブラみたいな化石言語を保守し続けるところもあるがあれはもっと別の世界から来たナニカって感じだな。そっちはよく知らん。
オレは新卒で入った受託ソフトハウスや大手SIerで計8年働いて、6年ぐらいはwebアプリのプログラマ・SEとして色んな現場みたが、オレも含め一緒に仕事する人は誰も英語なんて求められてなかった。英語読むより怪しいExcel仕様書なりソースコードのコメント読むなり顧客のメール読むなりして汲み取るのが大事だし、コーディングで困ったら日本語でググればまずヒットする問題ばかり。
コーディングで英語を使うと可読性が下がるから変数名・メソッド名・データベースのテーブルやカラム名もヘボン式ローマ字表記で書けってわけ。顧客マスタは「KOKYAKU_MASUTA」だし、担当者は「TANTOUSHA」と「TANTOSYA」で表記ゆれ、笑えるよな。
とにかく言いたかったのは、docker1.12だとかRails5だとか機械学習の新しいフレームワークだとかそういう話題でワイワイやってる層とはまったく別の層がいて、そいつらに英語は全く必要ないしこれから先の何年も求められずにやっていくだろうっていうこと。
悲しい愚痴、以上。
いくら仕様がアップデートされたって、生JSでDOM弄るのjQueryで弄るより辛いでしょ?
機械語を人間にわかりやす書くためにアセンブラがあるのと、生JSでDOM弄るの"人間にわかりやすくするためにjQueryがあるのって、似てない?
個人的な考えは以下の通り。
そもそもコンポーネント指向のライブラリだから、チュートリアルからして構造化を基本において書かれてるのが入門用にこそ適していると思う。
だって、初心者の頃jQueryで場当たり的にコード追加していって九龍城みたいになったこと、あるでしょ？
もちろん自分で間違いを犯してその痛みを知るってのも方法論としてはありかもしれんけど、
DOM操作を抽象化したライブラリから入って、徐々に具体的なところに落とし込んでいくのが効率的じゃない?
ライブラリ自体が構造化を念頭に置いてるから、自然とパーツごとに作るようになって、
その次の段階として自分の作ったパーツの再利用を考えられると思う。
jQueryってホントに何でも出来るからキチンと扱える技術を既に持ってる人には良いだろうけど
しかもその振れ幅が広くて、どの方法論もそれなりに意味がある場合が多い。
正解が沢山ある問題をいきなり解かせるんじゃなくて、
まずは答えがある程度決まってる問題から入って、徐々に馴らしていくべき。
ある程度経験を積んだプログラマーこそが手を出すべきと言うか。
どんなに抽象化が高度になっても、裏でやってるのはDOMの直接操作なんだから。
でも、大事な基礎技術だからといって、それだけで済ませて技術の革新を放棄するべきではないでしょ
むしろ、抽象化の高いところから入門して、基礎技術に触れる必要が出来てから触った方が理解が早いと思う。
と、私は考えます。
師匠「プログラミングとは深淵なる神の御業（みわざ）。あらゆることを可能とし、あらゆることが不可能であると知る。」
師匠「当然だ。」
師匠「ところで弟子よ。お前はプログラミングを覚えて何をしたい？」
弟子「今はIT技術者が少ないといいます。この未曾有の危機にエンジニアとなってこの町を、この世界を自分の手で守りたい」
弟子「師匠のもとでC#プログラミングを学び始めて1年。if文だとかwhile文とかどうでもいいクソ知識を覚えて参りましたがやっぱり何の役にも立ちません。」
師匠「そうであろう。考えてみろ。お前は日本語を話せるが、アナウンサーにも小説家にも程遠いだろう？プログラミング言語を覚えるだけで何かできるようになると本当に思っているのか？」
弟子「そんな・・・だったら英語覚えて、おとといskypeで話しかけてきたカウガールとキャッキャウフフしてた方がマシじゃないか」
一般人はWindows PCとAndroidスマホを使う。*nixだのpicマイコンだのasicだのとは違う。
その時点において、かつて王道だったC言語を学ぶ意義はパンピーには無い。
ひっきりなしに飛んでくる他人からのメッセージに反応することを強要される毎日。
師匠「文字、数字から初めて、基本的な文法を覚えるだけで1年かかるか……そりゃつまんねーよな」
師匠「関数とスコープを覚えて、ようやく構造化プログラミングが学べる」
師匠「だが……学校じゃ文法やって終わりってんだから、CRUDも構造化もやらずに何ができるかってんだ。副作用とかどうでもいいことばかりは教えるくせによ」
師匠「機能の抽象化、モジュールの疎結合が重要だろう。そのためのオブジェクト指向だろう。」
師匠「なぜ抽象化と分割統治をしたいかと言えば、人の短期記憶は5チャンクが限界だからだ。つまりは頭の小さな人間が巨大なシステムを理解するための知恵だ。
師匠「HSPでプログラムを書いていて、500行くらい書いたらもう頭がごちゃごちゃになって限界を感じるあの感じ（個人の乾燥です）」
師匠「HSPの名誉のためにも言っておくが、500行以内であれば簡潔だし、絶大な威力を発揮するツールだ」
師匠「逆にCは3行書いたら、その関数の非力さに頭が痛くなる(個人の乾燥です)」
師匠「アセンブラに至ってはmov 1, $ax とか書いた時点で発狂する。なんでintel構文じゃないんだ！と」
師匠「つまるところ、プログラミングとは自由を勝ち取るために、人間の限界と戦うことだ」
師匠「創意工夫をこらして、今できないことをどうやってできるようにするのか。どんな可能性があるのか」
師匠「構造化プログラミングをすればバグが出なくなるわけじゃない。OOPでプログラミングがうまくなるわけでもない」
弟子「覚悟ｗｗｗｗｗ。少年漫画の見すぎなんだよ。何か奇声あげたら変身してパワーアップてかｗｗｗ？おめでたい奴だな。貴様は師匠として利用価値がなさそうだ。このあたりで成敗してやる。カラオケで女の子とデュエットしてやる」
だとしても、ジョブスの、そして欧米の「API経由でしかハードウェアアクセスを認めない」ってスタイルは、成功だし正義としか思えないけどな。
日本の「ハード直叩きでスペック出す」ってのは職人的／天才的プログラマーを育てるけれどそれって才能依存だし少数だ。欧米のマニュアル化、規格化は70点のプログラマしか育てないかもしれないけどそれを数百倍の人数で量産できるわけで。戦略的な判断としては物量で勝つという第二次大戦と同じじゃないか。っていうか、第二次大戦に負けた日本は、またしても少人数の職人技術で物量に挑むってやって負けただけの話でしょうが。
ましてや現在ハードの性能が上がって、アセンブラレベルでの高速化が無意味になりつつある時代なんだから、それを見越してたとしたら余計に欧米判断が正しかったと言わざるをえない。
訳あって、ある法律とその関連法の条文を生まれて初めて隅から隅まで読んだ。
なんだこりゃ。ひたすらスパゲッティのようにクソのような日本語が絡み合っているだけじゃないか。
こんなクソみたいなものを更にクソにするためにパッチを作成したり、
クソの内容を解説することでカネを得る職業に、日本最高峰の頭脳集団が浪費されているのか。
しかも法令データ提供システムとかいう国が提供するレポジトリでは改正履歴が閲覧できないときた。
履歴が見れなきゃ頻繁に改正される法律の意図や目的がわからんではないか。
