  |
はてなキーワード: コンパイラとは
女とコンパイラは意外と似ているのではないだろうか
おめー、セミコロンが文末にないやろ、とか言いがかりをつけられても、
文法はどこも間違っていなくて、
よくわからんが、MSのコンパイラはUTF-8のソースコードも勝手にShift-JISに解釈するらしくて、
Visual Studioは「ビジュアル」なはずなのに、
わざわざプロパティーダイアログ開いて、コマンドラインに書くオプションをそのまま書かされて、
なんか不満をもらしたり、言いがかりをつけてきても、
女も客とか上司とかも、本音の部分はどこか別のところにあって、
わざと本音を隠してるのなら人として？まだ分かるのだけど、
意外と多いのは、本人自身も不満の原因の場所をちゃんと理解しておらず、
頓珍漢な場所について文句をたれるので、そういう人はほんとに困る
でも、意外と多い
わざとはぐらかすにしろ、自分で自分自身を理解できてないにしろ、
まあ、わざとだろうが不愉快だが、わざとの方はまだ頭がいい
分野横断的な人材を育成するということだが、マネジメントやコンサルティングの立場が近い。
制御工学や最適化と言った工学の基礎分野は抑えているが、演習もなく、定着しづらいと思う。数理的な面での基礎を学びたいのであれば計数工学の方が適している。
プログラミングもプログラミング言語演習の他、アルゴリズムや計算量理論などの基礎は教えるが、OSやコンパイラ、ネットワークを深く掘り下げることはしていない。演習の難易度は低い。
エンジニアとして技術を学びたい人よりは、プロジェクトマネージャーやITコンサルタントになりたい人向きだろう。
巨大なシステムを扱うため、数理的に扱いづらいのか、テストではなく、小論文のレポートの講義が多い。
社会人になると、技術以外の立場から問題を捉える重要性は理解できるが、大学の講義の中でそれを習得できるようにすることは難しい。
私も工学を製造業以外の分野に広げていく必要がある、経営学やマーケティングの知識をエンジニアが持つべきであると考えているが、エンジニアの技術習得との両立が難しい。
新しい社会に立ち向かおうとする熱意ある人材が集まってくると思うが、方向性が違っていたりすると悩むことになると思うので注意して学科を選択した方がよい。
カリキュラムはもっと情報学、数学、統計の講義を増やすべきだと思う。データ処理の重要性は今後増々伸びていくだろうから、これらの知識もより重要になるだろう。
計数工学科と似てくるという問題はあるが、それらをツールとして扱う立場から学ぶということで差別化していくのがよいとだろう。
いろいろしくじってきたが、その後のことも考えると、人生で一番大きなしくじりだったと思う。
を検討していた。
コンピュータと人工知能に関心があったということが候補を選んだ理由だった。
当時、LinuxやFirefoxなどのオープンソース活動に興味を持っていた。
また、脳科学や認知科学、人工知能など人間の知能に関する分野にも興味を持っていた。
研究分野としてはOS・コンパイラなどのコンピュータの基礎研究という印象を受け、
工学の方が自分の嗜好に近いと考えて工学部の学科を検討することにした。
工学部機械情報学科はロボティクスを中心とした情報を扱っていて、
ロボットのハードウェアへの興味が低かったことから優先順位を下げた。
そして、
を候補として考えた。
機械系のカリキュラム・研究も含まれていて、2つの学科が扱っている分野が共通していた。
違いとしては、システム情報工学では応用物理系の内容を中心に扱い、
知能社会システムでは機械系から社会工学・経済工学まで扱っているという違いがあった。
そして、次の理由から知能社会システムコースを候補として考えた。
私は教養学部での講義からゲーム理論やシェリングの分居モデルなどの話題に触れ、
また、当時行動経済学や経済への物理学の応用などの書籍を読み社会科学系にも興味を持っていた。
人工知能やマルチエージェントや進化計算などの複雑系にも興味を持っていた。
また、自分の関心がある講義が他学科にも分散していたことから、
講義を取りやすいことも良いと考え、自立して科目を選択できると考えた。
また、製造業や電器メーカーの不調から従来の工学系学科に進んでよいのかと悩んでいた。
できて数年の学科だということで新しいことができるのではないかと無根拠に考えていた。
そうして工学部システム創成学科知能社会システムコースに進むことにした。
そうして、システム創成学科知能社会システムコース(PSI)に進学したが、
思うようにはいかなかった。
幅広い分野を扱いつつ、講義数が少ないということで全体的に内容が薄く、未消化気味だった。
また、講義間の関連性が薄く、体系的に学べることが少なかった。
などの工学の基礎となりうることは扱うのだが、基礎に留まっていた。
また、講義を受けてのレポートが中心で理工学の演習は少なかった。
工学部だから機械や電気ではなくても理数系を基礎として扱うのだろうと考えていたが、
予想とは違い少なかった。
統計は理工系でも社会系でも重要なものだからもっと力を入れて欲しいと思う。
そのため、ディスカッションやプレゼンテーションなどの機会があったが、
幅広い分野を扱っているということもあり、学生層が広かった。
その分、興味が合いそうな同級生を見つけにくかった。
カリキュラムが少ない分、就職活動を頑張って学部で外資などに就職しようという
学生も多かった。
全員が全員そうだということはなく、修士も進むことを考えている学生もいた。
他学科聴講は思ったよりもできなかった。
受けたいと思った講義の時間が被っていたり、前提知識が不足していたりして、受講が難しい場合があった。
学科での講義に関心が持てず、モチベーションが下がっていたということもあった。
研究室には学部3年後期に配属される。カリキュラムの少ない分をそこで補う想定らしい。
しかし、私が所属していた研究室では、学部就職する学生が多く、
他大学からの院生やポスドクが中心であまり教育が受けられなかった。
システム創成は機械情報学科や計数工学科と違い、情報理工学系研究科ではない。
進振り時点ではそこまで差を考えていなかったが、講義の内容やPCなどの設備が違っていた。
大学院でより専門性を高めたいと考えて情報理工学系研究科に進んだが、
実力の不足から、大した実績を上げることができなかった。
学部では幅広い内容を身に着けて、大学院で専門性を高めるということを考えていたが、
他の研究室に進学するならば、その研究室と密に連絡を取って、院進学前から
必要な勉強・研究計画作成をしないと、講義や就活で研究に必要な時間が取れなくなる。
このようなことから、大学院では成果を出せず、就職活動もあまりうまくいかなかった。
振り返ると、それまでの人生で初めて大きな意思決定をする機会だったが、そのことを十分に認識できていなかった。
取捨選択するということができず、幅広いカリキュラムがあるということから選択肢がありそうな道を選んでしまった。
安易に考えず、具体的にメリット・デメリットを書き出して、検討すべきだった。
それまでどれかができるということではなく、どれもできるようになろうとしてきたことがあり、
立花隆さんの影響を受けていて、文理ともに学ぶことに憧れていたが、
その難しさを分かっていなかった。
意思決定をするために必要な情報を集めて、裏を取るということができていなかった。
まあ、サークルに工学部の先輩がほぼいないという事情もあった。(普通工学部は忙しいからな。)
もう少し聞けていれば、進学先を再検討していたと思う。
自分が目指すような幅広い分野を学ぶということを行うのであれば、基礎を幅広く身に着けることを
念頭において進学先を選ぶべきであった。
そう考えると、情報科学科や計数工学科に進むことを考えるべきだったと思う。
理学部情報科学科については小中高からプログラミングを扱っている人が多いと聞いていて気遅れしていた面もあった。
独学で学ぶようにはしていたが、学科に進学した方が教育や同級生など成長できる機会は多かった。
学部で情報系の基礎を身に着けて、大学院で応用に広げることも十分考えられたが、当時はその想定ができなかった。
あと、当時情報科学科や電子情報学科が進振りの最低点(底点)が非常に低く、避けた方がよいかなと思っていたところもあった。
進振りで高い点のところを目指していたわけではないが、つい点数に左右されてしまった。
今の機械学習やディープラーニングは自分が当初やりたかったことに非常に近かった。
大学院でそちらに進もうとしたが、実力不足から挫折してしまった。
情報科学科や計数工学科に進学していれば、その分野に進むチャンスが大きかったと思う。
教養学部時代に自分がやりたいことについて、教授に相談したり、一般書籍ではなく学会誌を読むなどしていれば、
進路を明確に決めて、進振りでの失敗も避けられたのではないかと思う。
進振りでは点が足りなくて進学できなくて失敗したという話を良く聞くが、
これは進学先の選択を誤ったという話である。その分、あの時選んでいればという後悔が大きい。
システム創成について、自分の失敗から悪い面ばかり記載してしまった。
私の進振りでのしくじりを具体的に書くことで何か参考になればということで書いたものである。
自由度が高い分、自分で計画を立てて行動できる人にとっては良い面もあると思う。
私自身は進路・キャリアを良く決めないまま進学してしまったため、うまくいかなかった。
など学科の色がはっきりしてきて、その方面に目指す人にとっては良い学科と思う。
(カリキュラムはあまり変わっていないらしいという話も聞くが。)
失敗したと思っても、将来どうなるかは分からない。
現に情報系学科は過去は非常に底点が低かったが、今は高騰している。
システム創成ではないが、大学院で他分野に進んで研究者として業績を上げている知り合いもいるので、
あまり後悔せず、前を向いて進んで欲しい。
Scala や Elm と Lisp やら Haskell と OCaml に SML と関数型のプログラミング言語を勉強したけど、これらが命令型言語に劣る理由を解説しよう。
これは、SQL も同じ問題を持っているが、関数型言語は「こういうふうに動いてね」という解釈をインタープリターやコンパイラが「推測する」必要があるのだ。つまり、書いているときにパフォーマンスをプログラマーが想像できない。
それが、現実的に厳しいのだよ。マジでコンパイラ関連は金にならない領域になってきたので、関数型言語のための独自コンパイラを作る持続可能な組織が無い。確かに、LLVM を使えば x64 や arm といった最新のアーキテクチャに対応できるかもしれないけど、フロントエンドのレベルすら応対が辛い。よって、関数型言語は C言語にてチューリング完全な同等なコードだと「いくら最速に書いても」遅いのである。
例えば if と書いたら、関数型言語は else が必須ですが、命令型言語は else 無しでも動いちゃうのですね。文系の連中が数学的な背景を加味して要件定義できると思うか？違うだろ。毎回、上に else のことについて聞いたら、プログラマーの生産性は下がるだろ。関数型言語は、上が文系だとますますだが、分岐もきっちりとおさえる必要があるから、生産性は命令型言語に劣るよ。
自分の仕事としては案件進めているうちに出てくる課題とか機能追加とかバグ修正とかを設計してIssueとして作って他の人に振ったり自分で作業に当たったりと色々なんだけど、
最近とあるプログラミングスクール出身の同僚エンジニア(最近同じ部署になった)が自分の案件にアサインされた。
内容としてはとあるテーブルの特定カラムのバリデーション処理が漏れているから追加してもらって、なおかつユニットテストを修正する、というもの。まあ簡単な奴。
Issueを振ってからしばらくすると同僚エンジニアから質問が来た。
「ん？」と思った。いや別に特殊なことなんて何もないIssueだし似たようなテストケースもリポジトリ上に山程あるしどうにでもなるじゃんって。
まあ特に考えず1個のテストケースを例として自分で作ってみて、「残りは○○の場合とXXの場合と△△の場合のテストケースを網羅してください」みたいな返信をした。
しばらくするとまた質問が来た。「△△の場合のテストケースの実装方法がわかりません。」
いやいや、そんなん頭使ってどうにかこうにか考えろよって。案件特有のビジネスロジックのことを聞かれるならわかるけどこんなレベルの対応どの企業のどの案件で振られても同じことやるだけやん。
この質問してるのが未経験の入社1ヶ月目の新入社員なら自分は笑顔で答えるけどこのエンジニアは俺よりキャリアが長いらしい。
その同僚エンジニアはわからないことがあるととにかく素直に「わかりません」と言ってくれる人だった。
成果物についても指摘事項があまりにも多く、自分(というかその人以外)がやったら10分くらいで終わる対応に数時間以上かけて説明して修正してもらうという感じになった。何のための仕事をしているのかよくわからくなっていた。
自分はITエンジニアが「わかりません」という言葉を使うのは例えばどうしても再現性がなくてログにも何も残ってない謎の不具合とか、コンパイラやインタプリタレベルの不具合で現時点で解消方法がどこにも載ってない奴とか、そういうマジで「参りました」的な状況だけかと思ってた。
こんな公式ドキュメントとデバッグツールだけでどうにでもなる状況で「わかりません」を使う人に遭遇するのは初めてだった。
その人はとにかく「わかりません」が多い。
レビューの指摘の意味がわからない、指摘内容はわかっても修正方法がわからない、影響反映を洗い出してほしいと言ったら影響範囲の洗い出し方がわからないと言われる。何ならわかるのか教えてほしいくらいだった。
うっすら評判悪いのは知ってたけど実際に仕事してみると尋常じゃないほど酷かった。
こっちもいろいろ対策を考えた。
Issue振るときはソース上に「↓ここの○○をXXになるよう修正してください」とコメントを書いてから仕事を振るようにする、「わかりません」が来そうな部分は先手で予想して回答を載せる。
でもダメだ。こちらの対策なんてものともしないように全てを掻い潜ってくる。
もはやその人に仕事を振るのは「この作業を担当してくれたら助かる」ではなく「この作業であれば流石に”わかる”だろう、そして単純作業の量が多いからしばらくは邪魔されないだろう」という感じにできる限り疑問点が少なく時間がかかる作業で”遠ざける”のが目的になっていた。
最低でもあと1年くらいは人事はこの状況らしい。。。
こういう状況ってどう扱うのがいいんだろうなぁ。
令和二年度春季試験に向けて勉強していたら中止になる面倒になったのでしばらく存在を忘れていた。
そして先日メールボックスを整理していたら本年度の春季の申し込み期限と実施が6月中だと書かれていたので、いい感じに知識も温まってるんじゃないかなという根拠のない自信を持って受験することにした。
あと非IT業でプログラミングスキルはPaizaランクでCぐらいです。メインはPHP。
キタミ式を一周してよくわからないところだけ暗記アプリで復習した。
試験三日前ぐらいから過去問道場で計算以外を計算より割合多いだろうからって理由で復習した。
結果：70ぐらい。
全く何も勉強していなかったので6月の頭に受験申し込みした後、選択問題のおすすめをググってそれで受験することにした。
前半は午前が長文問題になっただけと見たので何もしていない。後半のアルゴリズムとコンパイラ言語はちゃんと読めば簡単！とそのブログに書いてあった上に、コンパイラ言語はマニュアルが試験についているから命令とかを覚えていかなくも大丈夫！と書いてあったので結局何もしていない。
結果：80ぐらい。何もしてないけどどうにかなった。
過去問道場で過去問を時間配分を気にしながら勉強すると雰囲気含めて試験対策になってよかったんじゃないかと思いました。
以上。
今更音声なんて、という感じがするが、いざ制御しようとすると調べても出てこない。
世の中に色んなプラグインが出ているが、自然な修正をするのはない。出ているのは機械っぽくするのばかりだ。
論文に関しても探し方が悪いか、サーベイが足りてないのか、出てこない。
そもそもどうして機械っぽい音声になるのか、原因を可視化出来ていない。
AIに関しても、誰かの声を再現するという方向ばかりで、誰でもない声にするというパラーメータや制御方法は出てない。
しかもAIでありがちなアーティファクトが気になって仕方ない。
画像だと回転させたり、縮小したり、切り出したりして学習データを水増しするが、
音声の場合、音を高く/低くするといった制御が不自然になってしまうため、学習データ水増しも用意ではない。
電子工学を最低限やっていて
加算器なりレジスタなりが、コアの中でどういうふうに動くのかを知っていて
コンパイラの基礎理論や、自分自身がインタプリタを作ったことも当然あり
その知識を前提として
Javascriptのデバッグとチューニングをしていて
C++のプロファイラをブラウザに当ててながら、JavascriptやHTML5のチューニングをですね
実務経験として実際にやってHTML5アプリをですねまずは自分で作って売ってみて
当然 後輩たちも 東大だったり慶応だったりを優秀な成績ででていたり
cat filename.jurina
print "Hello world";
public class filename{
public static void main(String[] args){
System.out.println("Hello world");
}
}
と出力するプログラムをjurinaと名付けるとする
cat filename.jurina
int i=1;
print i;
public class filename{
public static void main(String[] args){
int i=1;
}
}
Javaに置き換えて出力するだけのJava プリプロセッサである
言いたいことVMを解析して、OPコードを吐くコンパイラを作ろうとしていたが
