  |
はてなキーワード: LLVMとは
Scala や Elm と Lisp やら Haskell と OCaml に SML と関数型のプログラミング言語を勉強したけど、これらが命令型言語に劣る理由を解説しよう。
これは、SQL も同じ問題を持っているが、関数型言語は「こういうふうに動いてね」という解釈をインタープリターやコンパイラが「推測する」必要があるのだ。つまり、書いているときにパフォーマンスをプログラマーが想像できない。
それが、現実的に厳しいのだよ。マジでコンパイラ関連は金にならない領域になってきたので、関数型言語のための独自コンパイラを作る持続可能な組織が無い。確かに、LLVM を使えば x64 や arm といった最新のアーキテクチャに対応できるかもしれないけど、フロントエンドのレベルすら応対が辛い。よって、関数型言語は C言語にてチューリング完全な同等なコードだと「いくら最速に書いても」遅いのである。
例えば if と書いたら、関数型言語は else が必須ですが、命令型言語は else 無しでも動いちゃうのですね。文系の連中が数学的な背景を加味して要件定義できると思うか？違うだろ。毎回、上に else のことについて聞いたら、プログラマーの生産性は下がるだろ。関数型言語は、上が文系だとますますだが、分岐もきっちりとおさえる必要があるから、生産性は命令型言語に劣るよ。
この程度でも600万は稼げるという夢を持つか、こんなのでもちょっと何かが違うだけで600万稼げるか否かが分かれてしまう業界に闇を感じるか、600万程度で何ドヤってるの？と思うかはご自由にどうぞ（外資系ってもっと稼げるの？）。
歳は30台前半。学部卒。BtoB向けのパッケージ製品の開発プロジェクトで、設計、コーディング、テストあたりを担当している。仕様について発注元との折衝もやっている。
業務で使う技術のうち、自分自身がそれなりに習得しているものだけを書く。プライベートでしか習得・使用していない技術は別。
以上。
PythonもgitもDockerもkubernetesもAnsibleもCIツールもAWSもGCPもRuby on Railsも知らなくてもなんとかなってしまっている。業務でこれらのスキルを要求されることは（今のところは）ないから。
楽でいいと思う一方、このままだと将来ヤバいとも思っている。いざ転職となったときに詰みそう。
でもいざとなったらググっていくらでも独学できるだろうとたかをくくっているので焦ってはいない。
というか「その他」のところに書いた能力が高ければ世の中大体はなんとかなるんじゃないの。知らんけど。
ちなみに自分は構築できないというだけで、プロジェクトではJenkinsとかgradleとかbabelだかwebpackだかでビルド環境は整えられている。
あとプライベートで、単純な仕様の独自言語のコンパイラフロントエンドをC++とLLVMで作っている（これで金が稼げるとは微塵も思っておらず、完全にただの趣味）。
近年，人格障害者の関係していると思われる事例をネットで見かけることが多くなってきた．例えば
また一見すると分かりにくいが以下の比較的有名なプロジェクトにも人格障害者の関わっている痕跡を読み取ることができる
gentoo linuxの昔のドキュメント（もう残っていないらしくリンクを見つけることはできなかった）には，gentoo linuxの前身となったFreeBSDがベースになっているプロジェクトが，人格に問題のある人が開発に関わった結果，頓挫した話が記載されていた．
このドキュメントは人格障害という言葉が一般に知られるようになる前に書かれていたため，人格障害について明確に記述されてはいないが，どう見ても人格障害者の関わった事例であった．おそらく人格障害について広く知られるようになってから削除されたのではないかと想像する．
ここで人格障害について知らない人のために解説をしよう．人格障害という言葉が広く一般に知られるになったのは，この本が原因ではないかと思う
Stop Walking on Eggshells) Paul T. Mason , Randi
Kreger (2006)]
この本（以下ではSWEと呼ぶ）は医者ではなく人格障害者と日常生活で関わってしまって苦労した著者が，なんとか苦痛に満ちた生活の原因を探すため調べた情報がわかりやすく記述されており，専門知識がなくても豊富な役立つ情報を学ぶことができる名著である．この本が出版される以前に，小さな町の本屋で人格障害に関する本が目立つ場所に平済みされていた記憶はないため，おそらくこの本がブレークスルーであったと自分は想像する．SWEは人格障害について知らない人が最初に学ぶ入門書としてもとても良い本なので，多くの人にぜひ一度読んでみて欲しい本である．
SWEでは（境界性）人格障害(BPD: Borderline Personality Disorder)の様々な定義が紹介されているが，ここでは以下の定義を紹介する．
Borderline Personality Disorder)と呼ぶ
自分の手足は動かしすぎると疲労するが，他人の疲労を自分は感じないので，疲労なく無限に動かし続けられる自分の手足＝他人 となっているので周辺の人間はとても苦痛を感じることとなる．近年話題になる長時間労働問題の原因はこれではないかと自分は考えている．BPDの本人は日常生活に何の苦痛も感じないが，周辺で「手足」となっている人はとても苦痛を感じることとなる．この周辺の人はnon-BPDと呼ばれる．SWEの特に重要な点はnon-BPDという言葉を一般人にわかりやすく解説し紹介した点にあると思う．
non-BPDはBPDについて調べる重要な検索キーワードにもなっている．BPD本人は何の苦痛も感じないためネット上に書き込みをするのはnon-BPDの人達である．
non-BPDで検索するともっと具体的で生々しい事例をいくつも見つけることができる.
BPDよりもよく知られた人格障害でサイコパスというものがあるが，ネット上のサイコパスという単語は本来の意味からかなり外れたある種のバズワードとなっており，サイコパスという単語でネットを検索しても実生活で役立つ情報を見つけることは難しい．
以下のBPDの定義を思いだしてみよう
疲労なく無限に動かすことができる便利な道具として最も良く知られたものはコンピュータ（ロボット）だろう．つまり他人をコンピュータと認識しているのがBPDであると言っても良い．これが多くの長時間労働問題の原因と考えられる．ここで以下の面白い話題を紹介しよう．
人間＝獣と違う論理的なもの から 人間＝コンピュータと違う感情的なもの
への変化は，Windows95が発売された1995年から2010年ぐらいまでに少しずつ起きたように思う．これは，この（長い）時期に放送されていたSF映画であるスタートレックやスターゲイトを見るとわかる．
これについては後で詳しく解説する．とにかくコンピュータは人間の認知にとても大きな変化をもたらした． https://trends.google.com/trends/explore?date=all&geo=US&q=BPD:title=google
trandでBPDを検索してみると] 2004年から2012の間に倍になっている．上昇は緩やかな単調増加で減ることはほぼない．これは他人からコンピュータとして扱われる人が毎年増えてきていることを示している．
BPDの本人がBPDについて検索することはない．本人は自分は普通の常識人と認識しているからである（SWEなどの人格障害について解説する本では，人格障害者の多くは自分を普通の人と認識していることが述べられている）．
SWEではBPDの原因の１つとして幼児期の過剰な甘やかしを挙げている．幼児が泣いて両親がすぐに何かしてしまうと，泣けば自動的に世話してくれる自分の手足の延長として他人を認識してしまう，というものである．
この状態のまま大人になると他人は自分の世話をするのが普通という認識が固定される．大人の場合は泣いたりできないので，かわりに嘘や脅しで他人を（手足として）操作するようになる．嘘つきというのは人格障害の肝となっている．
人格障害者の見分け方として嘘を誤魔化すためにさらに嘘をつくのは人格障害である，とSWEなどの人格障害について解説する多くの本では述べている．ちょっとした嘘なら誰でもつくが，さらに嘘を重ねるのが人格障害の特徴である．
本人は当然と思っている「他人が自分の世話をする」状況を維持するために「普通のこと」＝嘘や脅しを日常的に行うため，周辺の人間は苦痛を感じることとなる．本人にとっては当然の普通のことをしているだけなので普通に日常的に嘘や脅しをするのである．
この時，コンピュータ（ロボット）という本当に自分の手足の延長になってしまう道具という概念が存在していると，さらに悪い状況が生まれると私は考える．エクセルの関数機能やプログラミング言語について少しでも知識があるならば最悪である．
仮にwindows95がなかった（誰でもコンピュータが安く買える）1995年より昔はnon-BPD（コンピュータとして扱われる人）は少なかったとして，しかし，そのはるか昔から存在していた人格障害としてサイコパス（BPDと行動はよく似ているが内的心理状態は違うらしい）がある．サイコパスについて解説している（おそらく一番読まれている）本である
https://www.amazon.co.jp/dp/4794219296:title=- 良心をもたない人たち , Martha Staut
(2012)]
には，エスキモーにはサイコパスを殺してしまう慣習（クンランゲタ）があったことが述べられている．現代に置き換えるなら長時間労働で殺されるぐらいなら殺してしまおうという感じだろうか．そのため昔は，人格障害者は（殺されてしまうので）少なかったと解説されている．しかし現代ではnon-BPD（コンピュータとして扱われる人）は増えている．
BPDやサイコパスなどの人格障害について解説する本のほぼ全てでは，人格障害者からは「逃げろ」というアドバイスをしている．不運にもなんらかの人格障害者が隣に引っ越してきたら，自分も引っ越して逃げるしかないし，
職場にいた場合は辞めるしかない．ただしサイコパスの事例では辞めた後も嘘の責任追及などで追い込まれる事例も紹介されているので，安心はできない．先に紹介したgentoo linuxの事例では，FreeBSDベースのプロジェクトをうまくデコイとして使うことでなんとか逃げ切ったようだ（うまく逃げ切ったから今のgentoo linuxがある）． 自分が想像するにgentoo linuxもFreeBSDと同じ「再攻撃」を受けたはずであるが，うまく乗り切っているようだ．non-BPDの多くの人達は「人格障害者と一度かかわるとある種の直感が鋭くなる」と言っている．直感で事前に危険を察知して予防できるようになるそうだ．最初に述べたlibavやsystemdに人格障害の関わりがあるという根拠も実は私の直感であってうまく説明できない．ただ，オープンソースと人格障害の両方の知識があるならば，みんな同じ判断を下すだろうと思う．SWEも「良心をもたない人たち 」でも直感の重要性について述べている．
BPDやサイコパスなどの人格障害について一般向けに解説する本の多くは事例の紹介が中心になっている．人格障害者本人が普通と思っている状況を維持するためにつく嘘や様々な行動は，工夫が凝らされており完全犯罪に近い．
普通は思いつかない工夫に満ちた方法が使われるため単純に類型化できないのもあり，個別の事例を紹介するしかないからだと思われる．とはいえgoogle trandの傾向からわかるように，BPDについて知っている人は増加傾向にある．
人格障害とみなされない（見破られない）ためにさらに巧妙な手段が近年は必要となってきている．ここでも人格障害を見破るために重要となるのは直感である．ここで直感というのは具体的には「良心をもたない人たち
」では「何かが変」と感じたら騙されている可能性が高いと言っている．
ただ直感でかたずけられてしまっては．なかなか気が付けない人も多いと思うため，ここでは近年巧妙になった人格障害者の手口について自分の気が付いた範囲で述べていこうと思う．
(と思ったけど気力切れ)
先に紹介した有名なオープンソースプロジェクトについて解説しよう
(と思ったけど気力切れ)
カトラークラスのエンジニアが数十人、数十年かけて磨き上げた Linux カーネルにかなうわけねーだろ。
もはやFreeBSDは人手不足で、Meltdown, Spectre にも満足に対応できない有様。
カーネルがごちゃごちゃしてたのは v3 初期までで、その後、徹底的な抽象化・#ifdefによる機能の分離化、CPU依存の排除をしたおかげで、configでオプションを最小化したら恐ろしいまでに小さいサイズのカーネルになる上に、オレオレCPUへの移植もそれほど大変でなくなった。LLVMのSSAなどの技術をBPFが取り込んだおかげで、カーネル内のモニタリングも perf関係からの置き換えの目処がたったら、そのあたりの余計なコードも削ぎ落とせる夢がある。
おかげでconfigオプションが数千にもなってしまったが、ディストリビューションも多様化してくれたお陰で、自分の用途に合わせたカーネルの選択に困ることもあまりない。WindowsやMacでも Linux システムコールラッパがほぼ完全に動くようになり、「Write Once, Run Anywhere」をVMを介さないで実現する POSIX以来の夢がいま正に実現しようとしている。
いままで3回転職したけど、うまく行ったこともあるし行かなかったこともある。いままではわりと気軽に転職先を決めてしまっていたのだけど、そろそろ慎重に行かないと後がないなという危機感を覚えたので、とりあえず今までのことを振り返って気をつけるポイントを書いてみようと思う。
これまで何をしてきたか、これから何をするつもりなのか、会社の強みは何なのか、今後考えられるリスクをどう捉えているのか。上場企業ならばIRという形で外向けに情報を発信しているので、それを読むのはかなり大事。
で、具体的に書いてなくてよくわからないところが絶対あるはずなので、それを面談で聞く。ピンと来なかったらその会社は駄目だ。
公開されているコードがなければリスクは跳ね上がる。もちろん公開していないすばらしい技術というのはあるのだけど、会社の評価という点では使えない。
GitHubに会社のアカウントがあれば分かりやすいが、それ以外でもがんばって探そう。OpenJDK, Ruby, LLVMなど大きなOSSプロジェクトのコミッタがいればちゃんとコミットをいくつか読もう。GitHubも個人リポジトリはなくても別のリポジトリにコミットしているかもしれない。
社長はエンジニアを信頼しているか。CTOがいる場合は、CTOと社長に信頼関係があるか。
技術は手段に過ぎない、ビジネスへのビジョンが大事。確かにその通り。ただしそれは、経営陣の技術者に対する信頼があればの話。
技術を目的にするな。確かにその通り。しかしいまどきSVNを使い続けていたりデプロイを手動でやっているのはさすがにヤバイ。ついでにOSSを利用することへの意見も聞いとけ。
もしそういうダメな状況を変えるために自分を雇うのだということであれば、上層部がそういう技術的なアップデートをどのくらい必要だと考えているかを聞くこと。社長が「エンジニアを君とあと何人か雇って、一年それに全力を注いでいいからバージョン管理やインフラなどの下回りを一新したい、既存の社員にも納得してもらう」というのであればいいかもしれない。権力のある人がそういう強い決意をもってないと改革は難しい。
この話は技術者ならば誰から聞いてもいい。もし面談の過程で技術者がでてこなければ、その会社は諦めよう。
ここでいうデザインは「サービス設計」のことね。デザイナー出身のマネージャーがいれば、その人と面談してデザインをどうやってしているかの具体的な流れを聞けると最高。あるいは、エンジニア・デザイナ・企画の三者がどうデザインに関わるかを聞くのでもいいかもしれない。
企画、デザイン、プロトタイピング、開発、リリース、改善、このサイクルを具体的に聞こう。直近の成功例と失敗例を聞けると最高にいい。
これは現役の技術者から聞こう。実際に自分が体験することになる日常になるのだから。
外注管理することになったらとにかく最悪だ。そうでなくても、君がもし生粋のエンジニアなら、外注にはなるべく関わらないほうが幸せだろうと思う。
以上。
"見出しでエンジニアと書いているのにプログラマの事しか書かれていない。それもソフトハウスへの転職。" という指摘をうけたのでタイトルだけ変えた。
二種類のレイヤが混ざってる。あと、スクリプト言語のレイヤは要らない。例は突っ込みどころが多すぎるので触れない。
コンピュータ上で動作するもの全て、システム周りの低レベルプログラムを含めてアプリケーションとして括るのはちょっと乱暴。
OSを書いてる人間から見ればユーザープロセスは全部アプリケーションだし、twitterから見たらAPIを叩くものは全てアプリケーションだろう。
基本的には外から持ってきたソフトウェア基盤の上に作るものを総称してアプリケーションと呼ぶのがより実態に近いと思う。
だいたい合ってる。ただ、高級言語より上にあるのは変。スクリプト言語は高級言語に含まれる。
だいたい合ってるが、自然言語云々は余計。例えばS式は自然言語のアナロジーではない。単に比較問題で抽象度が高いかどうかだけの区別でしかない。
OS云々は関係ない。OSもミドルウェアやライブラリーは使う。一般には自分が書いてないソフトウェア・コードをライブラリと呼び、何かと比較してより低いレイヤにあるライブラリをミドルウェアと呼ぶ。
問題ない
ここが一番まずい。まず、中間コードはコンパイラが内部的に処理の段階を分ける仕組みであって、出力ではない。
また、インタプリタはソース言語を逐次実行するのではなく、正確には中間コード（抽象構文木そのもを含む）を逐次実行するものだ。
他のプログラムで実行するコードを生成するものがコンパイラ、自分自身でコードを実行するのがインタプリタ、という区分けがわかりやすいと思う。
ただ、現実的にはインタプリタは内部的にコンパイラを持つし、コンパイラも最適化の過程では内部的にインタプリタを使う。
昨今はLLVMみたいに、コンパイラなのかインタプリタなのかコンテキストによって変わるものもあるので、正直区別しても意味がないと思うけど。
こういう記事が上がって
それへの反応
記事の最初のカッコの省略だけど、世界的に評価されて広く使われてるようなプロジェクトのコードを見ると、案外{}が省略されていたりしてそんなことは気にしてない。(たとえばlinux, apache, postgresql, mysql, chromium, netbeeans, eclipse, llvm, jruby, android)
で「こんなコードを書くヤツは夜道に気をつけろ」「八つ裂き」みたいな大げさな反応してるのって、どういうコードを書いてるかよく分からないような人たち。
自転車置き場の議論的な、素人でも分かりやすいポイントだからこのツッコミって人気あるのかね。
―――――↓見てないかもしれないけどブクマとかへの返信を追加―――――
2chあたりでコーディングスタイルの議論になったときは、俺様基準じゃなくて実際に成果を出してる人たちが採用してるコーディングスタイルを基準にしようぜってことで、誰もが認める成果を出しててソースを見れるオープンソースのコードを引き合いに出すことが多いんだけど、そうするとよくある反論が二つある。
みたいなの。
さすがにはてなやツイッターじゃ、前者のような「お前は20年前からタイムスリップしてきたのか」みたいな認識の人はいないみたいだけど後者のような人は何人もいるね。
高度なコードを書いてる人とITドカタのコーディングルールは違うってなんなんだろうね。
「高度なコードを書いてる人は低レベルなケアレスミスなんてしない、だからカッコを省略しても平気なんだ、レベルの低い連中はケアレスミスをするからカッコが必要なんだ」って認識なのかね。
まあたしかに「viは一晩で書かれた」みたいにハッカーが複雑なコードを一気に書きあげてバグがなかったみたいな伝説ってあるけど、素人じゃないんだからそういうハッカーのイメージで高度な人たちをとらえるのはやめよう。
集中力が高度でケアレスミスをしないとか、今どきのソフト開発の「高度」はそういう意味じゃありません。
高度なソフトを開発している人たちは、おおむね読みやすさや保守性にセンシティブです。そのらのSIerなんかに比べたらはるかに。
で、そういう人たちが、カッコを書くか書かないかなんてどうでもいいって認識だからカッコを省くコードが書かれてるんです。
昔ハンガリアン記法がコードの質を高めると信じられてたときとか、if (100 == n) のように比較で定数を左にもってくるのが流行ったときも、そういう流儀の人たちは自分らは安全側に倒してるから正義だって信じて主張を全然曲げなかったですね。
というかなー、自動車の開発競争でLLVMという単語を持ちだして、自動車会社の人たちがどれだけ理解してくれるかを考えたら
みんな頭痛いでしょ？
同じく、政治家の人がLLVMぐらいわかるか？ということを考えると、
まず、理解してもらうだけで一苦労。理解させる必要性があるか？というと、いや、そのぐらいまで踏み込まないと、もっともっと深い議論にこれからなっていくんだがと。
全員がわかれとはいわないが、分かる人が少ないと、説明コストで開発が遅れるだろうね。
そもそもLLVMは半導体まで話が行くからな。深く掘っていくと。で、LLVMの話を突き詰めていくと、じゃぁ、日本独自LLVMという話が出てきて、なんでそれじゃだめか？という事を説明するのにLLVMの知識がないと説明もできん。
よくわからないけど、日本独自の方式を！というゴリ押しに対抗できる理論なんかないから。
LLVMわかれというより、技術トレンドをわかってほしい。という意味だけど。トレンドな技術を知っていてくれないと何も説明できん。だから、嘘を言うことになるんだけど。
無い。C言語（＋＋含む）の開発能力で開発競争をしていては、開発が間に合わない。
その言語を介して、おそらくLLVMを通してネイティブへのダイレクトなコンパイルになると思われるからOSの壁はわりと超えやすい。
その関係上、OSに要求される機能はRTOS程度の機能になるだろうが、RTOSその物は余程の性能でない限りLinuxでもユーザーランドとドライバで解決可能。
それに、よく要求されれる機能はLinuxにパッチ当てても可能。
結果論として、OSその物の高機能化勝負にはならない。勝負になるのはOSのエミュレーターというか開発環境。
より開発しやすい環境を整えたほうが勝つ。正確には、自動車が要求する水準までのサービスの開発とテストを高速化して支える技術。カバレッジとかね。
OSその物は限られた天才が作るだろうが、その天才の質は日米共に大差は付かない。もしくは買ってきても構わない。
問題は、その下に必要な大量の普通のプログラマーと、そのプログラマーが作ったものを天才が書いたものと遜色ない品質まで持ち上げるシステム。
要するに、日本刀ではなく、火炎放射器やマシンガンのように普通の兵隊をどこまで強化できるか？という競争になる。
ただしまぁそれは、今の自動車メーカーが考えているようなものではないから、そこの開発装置の競争でGoogleにボロ負けするだろ。
JavaScriptを殺せなかった（Ajaxで生きながらえさせてしまった）のは
今世紀最大の失敗だったと思うわ
TojiCode: A Tale of two Web Technologies
http://blog.tojicode.com/2013/06/a-tale-of-two-web-technologies.html
コメント欄など見てると、もう駄目だよこれ＼(^o^)／ｵﾜﾀ
JavaScriptの置き換えも改善も期待しないほうがいい。
DartもPNaClも政治で潰される。asm.jsはどう考えてもLLVM→asm.jsの変換時間やマルチスレッド対応で躓く。
ウェブはJavaScriptと心中だ。
つかBrendan Eichの老害っぷりがぱない
というより、あれこれ理由をかこつけて自分が作ったJavaScriptを守りたいだけなんだろうけどさ。
JavaScriptやasm.jsに疑義を呈するブログやツイートに片っ端から突撃してくる必死っぷりが心底うざいｗ
そろそろHTML/CSS/JavaScript全部スクラップにして
第二のウェブを作ることを考え始めてもいい頃合いではないかと思う。
野心ある人はもう取り組んでいるかもしれん。
[更新]新型MacBook Airと旧型MacBook Airを徹底比較！気になる性能は？ | ガジェット速報
http://ggsoku.com/2013/06/macbook-air-2012-2013/
新しいMacBook AirはあろうことかGeekBenchスコアが低下（6128→6013）
私達はこういう時代に生きているのだということを
よくよく考えなければならないのだけどね。ほんとに(´・ω・｀)
The LLVM Compiler Infrastructure
ttp://iiyu.asablo.jp/blog/2007/10/07/1840679
やっぱ、やってる奴は地道にこつこつちゃんとしたことをやってますね。
こういう連中がどれくらいいるかが、国力、底力の差になるんだと思う。
日本はもうプロセッサの研究もコンパイラの研究も放棄してますもん。みんな、そんなところよりアプリケーションやサービスのほう、いわゆる日本でい うIT企業がやってるようなこと、それが付加価値が高くて儲かるなんていって、そっちに流れたもんね。
でも、ほんとの付加価値は、プロセッサ、アーキテクチャ、プログラミング 言語、コンパイラ、OSといった、もう終わったと思われている部分の革新によ っても得られるんですよね。
ttp://iiyu.asablo.jp/blog/2007/08/31/1760835
で書いたように、いま、モノ作りはもうだめだから、もっと付加価値の高い金融サービスに日本の産業構造をシフトしないとダメという議論がやかましくなっているが、ほんとなのか。
素晴らしいコンパイラ技術をもっていた富士通や日立は、その技術を若い世 代の技術者に伝承することなく捨てちゃったし、プロセッサもせいぜい日立がSHでがんばってるくらいかな。
ところが、IBMもIntelもAppleもMicrosoftも、もっといえばGoogleもこれらの基盤技術は捨ててないんだよね。
野口悠紀夫氏は比較優位説をすぐ持ち出すけど、Appleなんて経済学の比較 優位でいえば、Windowsに対して比較劣位にあるOSなんてとっくに捨てないと いけないのに、経営が苦しいときにも捨てなかったし、いまでも捨てない。それどころか地道に改良を続けてるし、Macintosh本体のみならず、iPhoneに使って、再び花開こうとしている。
IBMも、いまやサービスとコンサルの会社になってるけど、それでもプロセッサもOSもコンパイラも捨てないどころか、ずっと研究開発資金を投入してい る。
MicrosoftだってDOSとプログラミング言語の会社だったから、比較優位説でいえば、比較劣位にあったワープロやスプレッドシートやデータベースソフトを作る理由はなかったはずなのに、作って世界を支配するような大企業になった。
