  |
はてなキーワード: コンパイラとは
新しい政策を考えたり、実装したりして、少し先の未来がどうなるか把握できるようにする。
国が統計取っているけど、数値データの実装先がそのままコンピュータ上にない。
ないから、ガバメントデータとして公開されているが、スクレイピングで取ってくると前処理が必要か、新しいデータが出てくるたびにしなくちゃいけない。
（役所の人もコンパイラがエラーがエラー吐いてくれるようになればチェックできるが、今は目でのチェッカーだろうし）
SNSで色んなことを言う人が出てきて、賛否を論争するが、意思決定に必要なデータ開示方法となっていない。
海外と比較してこうすればいいと提言を受けても、日本国内事情が違うことを現場の人しかわからないので出来ないというのも解決できるのではないか。
★
ソートがまさにそうだけど、バブルソートの特異領域N=1,Bigがそうだけど（例示）
ソートアルゴリズムも１つじゃなくて、テキストでもあれだけ教えている。
現場ではどうするか？といえば
採択されたものがソースコードに書かれる。それいがいはブランチに合ったりする。
これらがあるので、いわゆるバイナリやリバースからはソースコードの複雑さは推し量れないし
こういう膨大なテストがあったりするので（俺の場合は少ないが）
リバースだけから学ぼうとするな、ソースコードとアセンブリ結果から学べ
というのはそういうこと
いくつかいったけど、コンパイラの最適化を期待したりしてソースを書いたりするので
そういう書き回しをまなんでいくことも重要
ソースだけになｗ
バケツソート（バブルソートを含むとする）のような単純なソートプログラムを例にとっても
N=1,Bigのときは例外となる。プログラム教育ではこういう例外は良くおきるので準正常系のようなものだが、慣例的に例外と呼ぶ
どうように１，１，１，１、のような偏りの大きいデータにたいしてもソートプログラムは特異な処理時間を必要とする。
ソートは、そのデータの量や質、大きすぎる、小さすぎる、偏りが大きすぎる、小さすぎる
などによって、一般的に言われている特性とはことなる特性を示す。
データや偏りが小さいときはコンパイラなどの最適化により、さらに異なる特性を示すことがある。
一般的にはコンパイラの最適化は気にする必要がないが、こういう例外にはなりやすいので、納品などがある場合は１度確認しておいたほうがよい（アセンブラレベルでコード確認など方法は任意
何かの参考とかにしたらダメです。書き始めて半年経つんだけどこっからどう直したらいいんだか（何をゴールにしたらいいのか）わからない。。
追記：合流性とか強正規化可能性とか停止性とか、全部チューリング不完全で、事前の静的解析で使うメモリの最大量が確定できる、とかそういう風に読み替えられる人を増やしたいのです、数式の添え字とΣと∫にびびらない人を増やしたいようなもので
数理論理学の一分野である証明論から成長した、数理論理学と理論計算機科学の境界領域の研究領域である型理論(type theory)は、大規模なプログラムの内的な整合性のチェックを行うための方法論を必要とする情報処理技術の分野で関心を集めている。
そもそも「型」(type)とは何か。プログラミング言語は一般的にはレコードや関数といったプログラムを構成する「値」(value)の定義をする道具である(*1)。その言語のコンパイラ作成者はこれらレコードや関数などの値、もしくは第一級の対象(first-class object)の種類を区別する型システム(type system)を必要とする。抽象代数学の観点からすると、「型」とはこれらの値もしくは第一級の対象が属する高階の対象(higher order object)としての空間(space)ないし代数系(algebraic system)で、型システムはそれら「型」とそれら相互の関係(relation)つまり型のなす順序構造(order structure)ないし束構造(lattice structrure)であるといえる。
プログラムを構成する値すべてに型が付くためには、曖昧でない(*2)こと、自己矛盾していないこと、悪循環を含まないこと、それぞれの値の内容をチェックするために無限の時間を要しない(*3)ことなどが必要で、これらを満たすなら、プログラムは有限時間で実行を終え、停止する。手続き型言語では無限ループ、型無しラムダ計算では無限再帰によって型付け不能なプログラムを書くことができるが、型理論はこれらのチューリング完全な計算機を意図しない停止しないプログラムから守る装甲でもあり、再帰やメモリ確保で好き勝手をさせないための拘束具でもある。型が付くプログラムには単に停止するというだけでなく、可能な実行経路（訂正：経路→方法）のすべてで同じ結果を出すなど種々の良い性質がある。
1)この定義は現実に使われているプログラミング言語の特徴を覆い切れていない、狭い不満足な定義だが本稿では都合上この定義に立脚して限定的に議論する。例えば変数(variable)というものを持つプログラミング言語もあり広く使われているが、これについてはレコードや関数と同じように性質の良いものとして扱うことが難しい。難しさの原因は次の注の内容と関連する。近年は変数を扱うかわりに値の不変のコピー(immutable copy)やその参照に名前を付ける機能を持つプログラミング言語が増えている。
2) 現実の情報システムでは、COBOL言語のレコード再定義やC言語の共用体、一般的な関数ポインタやVisual Basic言語のvariant型変数のように、同一領域に異なる型の値が共存する共用型(union type)の値がしばしば必要となる。共用型の値はgoto文を排除した構造化／オブジェクト指向プログラミングにおいて条件キャストやクラス分岐などによる実行経路の複雑さの主要な原因になるが、これは和型(sum type)すなわち相異なる型の非交和(disjoint sum)として定義することで曖昧さなく定義できる。
3) ゲームプログラムやネットワークサービスにおいてしばしばみられるように、入力として無限リストや任意に深い木のようなものを想定する場合には明らかに（条件を満たさない限り）停止しないことが正しい動作となり、この場合は最外周のループを（←どうする？）メモリリークを起こさないなど別の考慮が必要となる。
int i=3+4;
こんな命令は
コンパイル時にi=7
に最適化されることがある。是非はある。良い場合と悪い場合があるからなんともいえないけれど、
コンパイラが最適化することがある、または、最適化してしまうことがある（バグの原因になる）というのは覚えておく必要がある。
普段はある一定の範囲はコンパイラが最適化してくれるということに頼って、・・・まぁ、マニュアルの自動車オートマの自動車みたいな感じで
10/28 に行われたGo言語のカンファレンスに参加してきました。
いつからGo conferenceが行われているのかはよくわかりませんが、例年春と秋に開催されるのが通例のようです。
今回私は、Wantedlyが行う「学生応援支援プログラム」という枠組みの中で参加することになりました。学生応援支援プログラムというのは、学生に対してカンファレンスへの参加に伴うチケット代や、会場までの交通費を全て負担してくれる制度です。詳しくは https://boards.greenhouse.io/wantedlygoscholarship/jobs/4459011002 を参考にしてください。
Go conference 2019 autumnに限った話だと、Wantedlyの他にも同じようなプログラムを実施している企業がいくつかありました。
今後もそのようなプログラムが実施されることがあると思うので、学生に限った話ではありますが、興味がある人は応募してみるといいと思います。
ここからは私が今回のカンファレンスに参加しての感想を書いていきます。
私は、大してプログラミングの経験があるわけでもなく、技術力も高いわけではありません。Go言語に関しても今回のカンファレンスに参加する半年ほど前から触り始めたというレベルでした。それでも、そのくらいの経験値の人が特定のプログラミング言語をテーマとするカンファレンスに参加して何か得るものは有ったのか、みたいな視点で書いていきます。
今回参加して良かったと思えたことの１つは、Go言語そのものに限らず、幅広い知見が得られたことです。カンファレンスの各セッションで触れられる話題というのは、コンパイラやアセンブラなどの低レイヤな話から、テストや設計に関する普遍的な原則、また比較的新しい技術スタックを使用したプロダクトを開発・運用していく中で得られた発見など、かなり多岐に渡ります。そのため、Go言語をテーマの主題としつつも、普段であれば自分から能動的に掘り下げない分野・領域についての話を聞くことができます。
これは、私にとっては特に嬉しいものでした。私は、Go言語を使ってAPIサーバのバックエンドを実装したり、簡単な CLIツールを作ったりしたことがあるのですが、その時に自分で調べることは、あくまでも目の前で分からないことがあって、それをどうすれば解決できるか、という狭い範囲についてでした。
そのような狭い範囲の探求を繰り返すことも開発を進めていくためには重要ですが、自分が経験したことの無い領域、また自分が詳しくは知らない領域について学習することも大切だと考えています。しかし、そのような領域についての学習は自分の中での優先順位が低く、かつ調べるためのキーワードすら分からないので何をすればいいかもよく分かっていない、という状態でした。
そのような一種の停滞状態を打開するものとして、今回のGo conferenceは絶好の機会でした。
これは、今回のGo conferenceに限った話ではなく、他のconferenceや技術イベントについても言えることだと思いますが、自分の知らないor詳しくはない領域についての学習を続けることで、技術に対する新陳代謝(?)のようなものを常に保っていくための機会は大事なものだと思います。
TypeScript（TS）がJavaScriptの代わりになるだと？確かに型を使えるのは良い。意味不明なオブジェクトを操作しまくって意味不明な動的型付けするJSに型が追加されたら、そりゃバグも減るだろうよ。でもそれは意味不明なオブジェクトを操作し、再代入を繰り返すレベルの低いJSerの責任だ。コーダーの責任なんだよ。Pythonも意味不明なオブジェクトを操作しまくるが、JSほどはひどくならない。Pythonも型ヒントなんてものが導入されたが、誰が使うんだこんなの。果てしなく冗長になって糞だ糞。DocStringを充実させるのと型ヒントを充実させるの、どちらがどれだけメリットが有るっていうんだ。DocStringで十分だろ。全員アホだ。話をTSに戻そう。
散々文句を言ってしまったが、型が使えるのにはこしたことはない。TSを始ようじゃないか。TSをインストールしよう。Node.jsをまずインストールして、TSをインストールしたぞ。ついでにgulp、webpackもいるのか。おいまてよ、ts-loader、webpack-cli、webpack-dev-serverもいるのか。何が何のために必要なのかよくわからないが、node_modulesはすでにパンパンだぜ。tsconfig.jsonを設定してsrcとdistを決め、ECMAのバージョンも決めたぜ。webpack.config.jsってファイルもあるじゃないか。これも設定が必要なのか？俺はいつになったらHello Worldを書けばいいんだ？なめてんじゃねえぞ！！！なんかに似てるんだよ！これはCだ。C言語でプログラムを書こうってときに、コンパイラが必要でインストールして、パスを通して、謎のおまじないを書いて、それでよくわからないままHello Worldを出力したあの頃の思い出がフラッシュバックしたぜ！いや、TSはそれ以上に糞だ。なにせ設定ファイルばっかいじってまだ一行もコードを書けてないくせに、ファイルサイズは70MBを超えてるんだからな。「TS コンパイル」で検索したら、なんで「次にgulpをインストールしましょう」なんて記事がヒットするんだよ！糞か？いや糞だお前は！
プロジェクトに必要なツールをインストールするのは当たり前だって？偉そうなこと言ってんじゃねーぞ！どうせお前なんか先達がすでに準備してくれたプロジェクト環境に後でアサインして、「これとこれが必要だからインストールしてね」って言われてそのまんまインストールしたクチだろうが！どのツールがどのシチュエーションで最適なソリューションなんかわかってねえに決まってら！どのツールがどのシチュエーションで最適なんか誰もわかってねぇんだよ！インターネットに情報は適当に転がってて、お前の先達もDevelopers.IOの記事を読んでなんとなく良さそうだからインストールしてんだよ！全てを正しく把握してるやつなんか日本で3%いたら多いほうだろ。少なくともお前も俺も理解してねぇよ！PHPがRubyを駆逐するって言われて何年たった？今でもPHPは現役で、RubyはPHPの後ろを歩いてるじゃねえか。jQueryが消えるって？同じ理由で消えねえよ！一生やってろばーーか。JavaScriptも消えねぇよ。ECMAのアップデートに従って生で書けば十分だろ。こんなコード書くまでにうんこ行きたくなるような設定ファイルばっかいじらせる言語にとって代わるわけねぇだろ。消えるのはお前だばーか。
