  |
はてなキーワード: C/C++とは
プログラマやってるけど、昔話を聞くに、本当に隔世の感があると思わされる。
だって昔のプログラマの仕事って、入念に机上デバッグされたフローチャートを、ただひたすらCOBOLかFortranかアセンブラに翻訳して、コーディングシートに書くだけの仕事だったんでしょ？
フローチャートで書ける程度のロジックなんて全然難しくないので、シートを書き終わった時点で事実上プログラムは完成したに等しいと。
あとはパンチしてもらって、テストは大抵一回動かすだけで全部問題なく通って一丁上がりと。
そりゃ月残業300とか働くのも決して不可能じゃないし、それだってハイになった勢いでガシガシ書けるだろう。
そうやってカネがっぽり稼いで、日々のモヤモヤは酒タバコ麻雀パチンコ風俗でスッキリさせて、そんでまた思いっきり働く。それが男だろ！ってノリだよな。
仕事で懇意になってるパンチャーのお姉ちゃんと裏で仲良くなって、そのまま付き合って…なんてのも普通にアリだろう。
今はもう、あらゆることが複雑になりすぎて、設計だってUMLとER図で対処できるかすら怪しくなっている。
言語だってJavaだけじゃなく、SQLやら、HTMLにCSSにJavaScriptと心得てないと仕事にならない。
そして何より、動かして試して、都度直していかないと分からないことだらけになっている。
プログラマの脳にかかる負荷は昔と比べ物にならない。当然あまりに長時間の労働は事実上不可能。
俺は残業100まで行った所で帯状疱疹が出て、シャワーで腰をさすりながらココらへんが限界と思い知らされた。それが10年前。
勿論今はもっと無理が利かない状況。
でも、残業300可能な時代を、色んな会社で現役として駆け抜け出世した幹部オヤジ達に、今のプログラマが抱えているアレやコレやらは、多分理解できない。
それくらい、時代が変わりすぎたのだろう。見えている世界が違いすぎる。
だから今の若い奴らを根性無しとして完全に見下しているし、本音では「なんだよ急に辞めやがって使えねーなー」とか「アイツ死にやがった、ざまあwww」と思ってる、人でなしの老害ばっかり。
勿論Fortran→C/C++→Javaみたくスキルを身につけてきた人は例外だけど、本当に例外中の例外でめったにいない。
それで「昔のままのノリじゃ、今の開発は絶対に稼げない」ということに思い至らない。
こういうところで、自分の中にある、苦しみや悩みを吐き出す日が
来るとは思っていなかった。
中年を過ぎたオヤジの読みづらい戯れ言だと思われても仕方ない。
仕事はIT系システムエンジニアであり、プログラマーでもある。
経験した言語はC/C++、SQL・PL/SQL、PHP、JS。あとCOBOLは少しはできる。
PHPとJSはフレームワークはよく知らない。仕事で使う機会が皆無だったからだ。
最近は本業のタスクが無くなってしまうと、PL/SQLと言語が類似する
DELPHIを独学している。そのためにスターター版をインストールした。
もちろん、発注元には承認を得た上で残業させてもらっており、その点は感謝している。
ここからが本題。
発注元とは派遣契約。単金がいくらかも知っているから、どのくらいの
その会社で4割以上、ぼったくられている。。
両親自身の年金だけでは暮らせるわけも、毎月15万の仕送りをしている。
私自身はその会社が一方的に決めた法人契約のアパートで暮らしている。
お願いしたが、40時間残業すれば手取り40万を超えるから大丈夫だと
すべて笑って誤魔化され一蹴された。
この年齢で転職は無理だろうと感じている。
できるだけ支出を減らすために、1日1.5食まで減らして暖房も使わずに
可能な限り無駄を減らしているが、それでも生保や定期積金も難しくなっている。
預金は減る一方で増える見込みはない。そろそろ底が見え始めてきた
これを書いていて思ったのが、ひとつ救いだと思えたのは独身で良かったと。
カミさんが協力的な人だったとしても心苦しいし、顔を合わせづらい。
さらに支出を減らす努力や生保、定期積金の解約が必要になっている。
残酷だが「職業訓練でプログラミング」という人たちはこの業界はあきらめた方があなたのためにとって良い。
そのような人の上司になったことが何度もあるが成功した人を見たことがない。
とはいうものの、私も35歳から異業種転職にてアプリ屋になったが、転職直前の段階でC/C++/Pascal(Delphi)/html/js/SQL が書けた。
10代前半から8bitCPU(特に名を伏せる)のマシン語(ハンドアセンブル、つまり16進数直書き)でプログラムした経験がある。(もちろんBASICもある)
8bit時代ならメモリー増設の設計・実装(ハードウエア)ができた。
一応そのような状況ではあってもプロに知り合いもなく心配だったので、
(当時)第二種情報処理技術者試験に3週間の勉強(1.0/日程度)で
一発合格しなければ転職しないというような目標もたててクリアした。
技術的には 0 スタートではかったからこそ転職にも成功できたと思っている。
おっさんで技術的知識・経験ほぼ 0 スタートはきついでしょ。
参考：http://www.oreilly.com/animals.csp
大企業や銀行で、昔から動いている基幹システムは、大抵メインフレームにCOBOLの組み合わせである。
それをここ十年くらい、リプレースでx86系サーバにJavaという構成に変更することが多い。
しかし、ハードが汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。
ぶっちゃけCOBOLはCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは？と思うのだ。
その理由はこうだ。
COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。
勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOLの文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである。
そういうモノが既にある企業や銀行の文化において、当然発注側は担当者からお偉いさんまでCOBOLer系フローチャート脳だし、新しいシステムの設計でもそれを踏襲しようとする。
というか踏襲すること前提じゃないと設計書をレビューできない。
UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。
というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法の設計書で処理を組み上げざるを得なくなる。
そうなると、実装もフローチャートの設計を基にコードを書くわけだが、こういう設計はハッカー文化で発展してきた言語(Fortran→C/C++→Javaという流れと、PerlからPython・PHPというインタプリタ系の諸言語)との相性が最悪である。
設計とは実装を楽にするために書くのに、これらの言語において、フローチャートの設計は役に立たないどころか、邪魔でしかない。
だからFortranしかなかった頃から、本物のプログラマ達はフローチャートをdisってきたわけである。
ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である。
しかし、「普通の人達の普通の思考」からはかけ離れ過ぎているという意味で、「普通の人達の普通の仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。
…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLかアセンブラを選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。
というわけで、自分はCOBOLからのリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
今やプログラミングといえば、Webなどで使われるような高水準スクリプト系言語中心のアプリケーションプログラミングが主流だ。
そんなこともあり、もはや以前の低レベル言語によるシステムプログラミングの苦労など、タダの昔話である。
そこに来て、実際は齧った程度の分際で、性懲りもなくそんな昔話を書いてみる。
少なくとも10年位前に自分が手がけた(押し付けられた)仕事はそうだった。
大学で初めて触ったC言語しかもポインタ分からないで止まっているような奴に、電文の再配信プログラムを任せたのだから。
客は「遅延が絶対許されないシステムなのでJavaとかPerlとかはやめてねー」とにこやかな笑顔かつ笑ってない目で注文してきた。
このうちC++は、Java経験がある自分からしても仕様が膨大かつ複雑すぎて、とても手に負えないと感じ、必然的にCで書くことに。
勿論Cの言語仕様がKR本一冊で収まるほどコンパクトであっても、それが簡単であることを全く意味していないというのを開発早々に思い知らされたのだが。
あ、Cと言えば電文提供側の機関が受信用のスケルトンプログラムを一応は用意してくれていたが、どう見ても電文受信中に接続が切れた時のことを考慮していない内容で、全く参考にならなかった。
コード書きにおいては、例え一人屋台の俺ルールであろうが、コーディング規約のようなものは絶対に必要である。
その時のルールは「gccのオプションに"-Wall"を入れた状態で、Warningゼロになること」にしてみたが、その途端、日付変更線をまたがない限り退社できない生活が始まった。
というかオブジェクトを使えないだけでも地味に辛いのに、更にCの言語仕様はコンパクトである以上に原始的と言っていい代物で(だからWarningは基本無視できないのだ)、しかも言語仕様以外の環境依存要素が山積していると来たもんだ。
そんな言語でシステムコールだらけのコードかつ複数のファイルディスクリプタの同時監視(即ち非同期でノンブロッキング)しかもマルチプロセスでシグナルもあるよ！とか、お客さんは俺を殺す気か、そもそも完成させる気無いだろとか、今だったら思う(当時はそう思う余裕もなかった)。
仕方なく最初のKRに加えて「UNIXネットワークプログラミング」をわざわざ東京に出かけてまで買って読み漁った。
後にも先にも、古今東西の名著と呼ばれるような本を、泣きながら読んだのはこの時だけだったりする。
そこまで凄い良書なのになんで絶版になったんだか。
いかし、それでも「子供を殺しても死なない」、かなり前の処理での領域破壊のせいで突然プログラムが止まっちゃうなどなど、やればやるほど問題が出る。
シグナルを受信し、仕様のとおりに処理するのがこんなに難しいのか！と途方に暮れたこともあった。
そして途方に暮れても解決の手段になるような便利なツールもなければライブラリもない。
結局、「ある程度正しく動いたら、あとは出来た所まで」で勘弁してもらってようやく開放されたが、今でも当時の自分の仕事ぶりには全く満足していない。
無駄に頑張ったというか、頑張っただけの仕事であり、折角低レベル実装というCの本領発揮分野の案件でありながら、スレッド、malloc()、可変長引数は遂に習得できなかった。
こういうプログラムって、どうやったら正しく動かせるんだろ。
このような経験を経て、後年、Cやシステムプログラミングを指してギークな人々が
Cはとても高効率ですし、マシンのリソースもドカ食いしません。残念ながら、Cがそれだけの効率性を実現するには、あなた自身が低レベルのリソース管理（たとえばメモリ管理）を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります。今日のマシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシンの時間を少し非効率に使っても、あなたの時間をずっと効率的に使う言語を使うほうが賢明でしょう。
本物のプログラマはアプリケーションプログラムなど書かず、まっさらな金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。
あと、あれほど苦手だったポインタについても、「ポインタが理解できないと永久にC初心者」というのを嫌でも理解した。
あれはギターのFコードやSEALsのヘルウィークみたいなもので「習得できなかった者にとってはキャリアの終わりを意味するが、習得できた者にとっては始まりですらない」ものなのだ。
・・・で、これだけで終わってしまうと本当にタダの黒歴史だが、これには少しだけ嬉しい後日談がある。
それから数年後、やはり電文転送系のシステムで、かつて自分がCのソロプレイでこなしていた規模の数万倍はあると思しき超大型案件に助っ人の「兵卒」として参加したのだが、そこはインプラとアプリでチームが分かれており、アプリ側だった自分は
「配列とポインタと構造体しか使わないで済むなんて、なんて楽な仕事なんだ！」と左うちわでのんびり過ごし、しかも高評価をいただいて帰ってこれた。
「MacはUnix互換」とかMacユーザはいうが、Linuxユーザからするとディストリビューションが違うので正直使いにくい。別に調べりゃ使えるしLinuxユーザというのは黙って調べる人たちなので文句を言わないだけで、好んでMacをUnixのように使おうとは思わない。GUIがクソだが便利なLinuxユーザからすればMacはGUIがすげぇ糞なディストリビューションだ。情報少ないし。
なお、これは他のLinuxについても言えることで、Ubuntu使いからするとRedhat系は使いにくいし、Redhat系からするとUbuntuはコマンドがわからんことが多々あるので若干めんどくさい。もちろん他のディストリビューションも同じ。BSDとかあんまり使いたくない。まぁやりゃできるのだが、めんどくさいを極めた結果としてコマンドライン使ってるのに、調べるのはもっとめんどくさい。あと変なエラーが出ると大変なのでPCライトユーザにはまったくおすすめしない。
最近はWindowは一発ポンで入ることが増えてきたので便利だと思う。Cygwin使うよりはVM使ったほうが楽でねーかと個人的には思うが。PHPなどはXamppがあるのでむしろWindowsのほうが楽。文字コードが面倒だが。
なおLinuxは常に糞めんどくさい。すでに入ってるパッケージのバージョンが古いが、ディストリビューションによっては上げるのに四苦八苦とかふつうにある。サーバー関連のプログラム以外はいまどきWindowsとかMacとかのほうが断然楽だ。
Windowsのコマンドはよくわからんが、最近は情報が多いので特に…あと下手にコマンドいじるよりはフリーウェアを探してくれば良いと思う。
Linuxは慣れてるディストリビューションならCUIだけで十分。慣れてない奴はめんどくさい。
Windowsも良いとは言わないが、不便はない。細めのフォントが好みなのでむしろWindowsのほうが見やすい。
そりゃiOSアプリを作るならXCodeしかないし、XCodeは悪く無いと思うが、C/C++とか書く時は使いにくい。
WindowsアプリつくるならVisualStudioしかないし、最近のVSは使いやすいので特に文句はない。C#も良い言語だと思いますよ。すごくよく考えられてると思うし。
Webアプリケーション系もnetbeansなんかはWindowsのほうが軽い印象があるなぁ。ただC++はnetbeansだと補完機能が弱めになる気がする。まぁそもそもWindows上でMSのライブラリ使わないC++とか書きたくないですね。色々違うし。
LinuxのIDEはEclipse一択みたいな感じになっているが、正直Javaはいいが、それ以外は微妙。と言うか糞重い。netbeansが個人的には好きだが、前述のとおり補完機能がEclipseより弱いかんじがするのであんまり。Rubyはすっげぇ使いやすかった。C++で一番軽いIDEはQtかな。Vim?いうほどいいかね…まぁEmacs派なんですけどね
そりゃiOS開発するならMacしかないだろう。Windowsアプリケーション開発するならWindows機使うしかないのと同じでな！！！
LinuxでGUIのあるアプリケーション作るとか、考えたくないな！つうかGUIつかいたくないからLinux使ってんだよ！
Macは選択肢が少なすぎる。金だせばなんでもできるが、カネがないとストレスが溜まる。あとかねかければかけるほど周辺機器もグレードアップしなきゃいけなくなる感じがするのだが…正直Unix系のマインドに反しすぎていると思う。
あといまおれのMacbookProはバッテリが膨らんできてパッドが使えなくなったんだが、Mac対応のマウスがないのでコピペすらできない。キーボードも純正のやつ使いにくくね？プログラマとしてはHome,Endあたりはキー一個で対応して欲しいですし、Backspaceキーがないのは意味がわかりません。deleteキーって書いてるけどそれBackspaceやん、ほんとのdeleteどこいった！！！とにかくキーボードがひどいのでMac使ってプログラミングしようという意欲がおこらない。むしろ俺がMac嫌いな理由の一番がそれですね！
しらねぇがLinuxで音楽制作しようとする奴はアホだと思う。
が、若干コントラストが強目にでるか？という気がする。
Mac以外のディスプレイを自分で細かくカスタマイズしたほうが実際にあってる場合もあり、なんとも言えない。
ちょちょっといじる素人用フリーウェアが貧弱すぎて辛い。いやらしい成金に札束で顔はたかれているような気持ちになる。
いいわすれたがLinuxでデザインやデジタル現像しようっつうやつはアホだね。Ubuntuならあるのかなぁ…でもさいきんUbuntu重すぎて…
しらん。
MSOfficeは使いやすい。Officeを貶してる奴はだいたいOfficeを使いこなしていない。
LibreOfficeとか一昔前のMSOfficeじゃないですかーLinuxだとそれしか選択しないけど使いたくねぇ…それならGoogleDriveのをつかうわ…一太郎とか悪い冗談はやめていただきたい。
ただ、Latexを使う場合はLinuxは使い良いとおもう。もちろんWindowsならLatex用のエディタあるんですけども！
WindowsとMacで特に違いはないが、あえていうならMacはフリーウェアが少ない。
Linuxをホームユースで使いたがる人がいたら止めたいが、最近はWebだけでも色々できちゃうので、別段問題ない気がしてきた。
9. Macは性能に対してコストパフォーマンスが高い(……かも)
スペック対価格を比較すると、CPUやメモリやらのコストパフォーマンスが悪くない、と思います。
10年前は「Macは高くつく」という印象だったものが、ここ5年で「Macって割安」という印象に変換したと記憶しています。
むしろ使ったらMacって割高…って思うと思うけどなぁ。最近のWindows機は安いしデスクトップなんて価格破壊完全に起こしてるし、使い始めてからもほとんどお金がかからない。情報も多いし。なんか情報が全体的に五年くらい古い感じがしますね。もしかして2009年ごろからいらした方が書いたのでしょうか。
何をもって"無駄"と判断するか、非常に難しい論点ではありますが。
へんてこなアザラシのマスコットがデスクトップを泳ぎ出したり、なんとも言えないモッサリ感の明るさ調整ソフトが突如画面に出現したり。なんて事はありません。
常駐ソフトウェアはWindowsは決して多くないし、あるならメーカプリインストールアプリじゃねぇのっていう。
明るさ調整ソフトってそれはディスプレイのやつだろ？Windowsのせいじゃねぇよ。むしろMacはそういうの調整するときに探すのが大変。いや、あかるさ調整くらいならキーボードでできるけどさ…
常駐ソフト気にするならLinuxが一番管理できると思いますし、LinuxにくらべればMacもWindowsも似たようなもんです。
サーバサイドの通信プログラムなど、OSのシステムコール使いまくり系の、所謂システムプログラミングのうち、電話の交換器とか緊急地震速報のように、処理速度と信頼性が求められる仕様のソフトウェアは、未だにUNIX系(というか実質Linux)にC/C++になってしまうのだろうか。
速さの問題でJavaやPerlがダメとなると、未だにシステムプログラミングはアプリケーションプログラミングよりも高難易度というイメージがある。
かくいう自分の場合、C言語は学生時代の授業でポインタに挫折して以来、仕事で画像処理のプログラム実装でちょっと使ったけど結局よく分からない状態で、急病でリタイヤした人の仕事(C言語で少しだけ作った通信プログラムの引き継ぎ・納品)をムチャ振りされ、泣く泣く取り組んだ経験が半ばトラウマ化している。
だってC言語やっててポインタが分からないとか本当にド素人レベルの初心者が、socket()のノンブロッキングにpipe()にsignal()にselect()無限ループで複数のファイル記述子の監視を非同期通信でfork()もあるよという世界に放り込まれたのだ(当時のLinuxカーネルはpselect()がシステムコール実装されてなかったというオマケ付き)。
K＆Rと「UNIXネットワークプログラミング」片手に涙も枯れた状態で帯状疱疹作りながら挑み、最後はどうにかこうにか元請けが引き取ってくれたけど、共有メモリやマルチスレッドはハイレベル過ぎて手が出なかったのが悔やまれる。
これがC++(当時未経験)なら、Javaで体得したオブジェクト指向で複雑な仕様もかなり楽に出来るかと思ったけど、いざ始まってみたらC言語とLinuxのシステムコールを使いこなすだけで精一杯で、C++は今でも未経験と。
あとmalloc()やfree()とかも全く活用できなかった。懸案だったポインタと構造体は嫌でも覚えたけど。
というか休日遊んでいて、突然それまで分からなかった部分が理解できたのはいいが、次の瞬間「やべ！あのまま本番動かしたら洒落にならん！」という展開になり、休日こっそり会社に忍び込んで必死にソース直したこともあったっけ。
・・・という経験をしているので、いつかまたシステムプログラミングの仕事が振られた時のことを考えて、一応PGで飯食ってる仕事人として、何か準備しておきたいと思っているのだが、できればもう少し楽になる技術やフレームワークが生み出されていると嬉しいんだけどなーという感じ。
ストライクswitch文 これはゾンビプロセスですか？ キル-9キル
シューウデンタイム 最終納期彼女 テイルズ・オブ・エンジニア
VeriSignのばら ガンプラC++ビルダーズ IT土方まさか☆デスマ
ブラックラー刃牙 ロード・ストア戦記 れじ☆すた 謎の変数X
シスターprintf 新製品エヴァンジェリスト 鉄腕atof 評価
コード規約～反逆のリリース コードゼロ 大ピンチ・コード コード：ブレイカー
OCamlと香辛料 あらいぐまHaskell ヒカルのGo ななかC/C++ コボラ
あした納める製品の仕様を僕達はまだ知らない。 LOTUS;NOTES
継承ダイモス 鋼の連勤術師 コンパイラ 機動戦士ガンダム0080 パケットの中の戦争
廻るpingDRAM とんでboolean ゼロ除算の使い魔 THEビッグオー記法
あ、まず前提として、
はたして貴女を幸福にするかどうか、それはまた別問題だけれど。
ＩＴ系の超かしこい男なども多く、
多くっつーかIT系でないのにプログラミング大好き男っていうのは超かしこい学生（まぁこれは有望株）か研究者系なんか、
あとはまったくかしこくもないクセに頭いいつもりして「Lispやってます（ｷﾘｯ ハローワールドくらいですが」とか言っちゃうアホしかいないわけで、
したがって、釣り師たる女たちにとっては、
なかなかあなどれない釣り場です。
では、プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
まず最初に、その男がCOBOLのようなタイプのレガシーコードと
あとはC/C++、そして（TechEdに参加するほどではないけれど）VisualBasicが大好きな、
貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、
「わたしが、仕様書を作ってあげる♪」
これこそまさに必殺の答えです。
そこでプログラミング大好き男が、えへへ、とやにさがったならば、
貴女は、ひそかに、「コピペ量産しやすい技術的ポイントを抑えた仕様書」あたりを
ひそかに練習しておきましょう。これで成功まちがいなしです。
しかし、ここでは、もう少しハイブロウな（？）いわゆるプログラミング好きの男の
落とし方をお伝えしましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
もしも貴女がそう答えたならば、
かれの貴女への恋心は、
２０％増量になるでしょう。
なぜって、Scalaは、
コンパイルは遅いながらも、そこがまた
ちょっぴりメモリを多く積めばいい富豪プログラミングみたいなふんいきをかもしだしていて。
質高くふるまっていて、なおかつ、
JVM上で動くくせにJavaが「やるやる」と言ったまま実装してなかったラムダ式と仮想拡張メソッド、型推論を実装した功績もあって。
したがってScalaこそは、
本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、
インタプリタ言語大好きな綺麗系ＯＬと、玉もあれば石も混じっている、そんなプログラミング大好き男たちが、
この世界で唯一（いいえ、JVM系列のJRuby、Clojure と並んで唯三）遭遇しうる場所です。
●
では、参考までに、危険な回答を挙げておきましょう。
プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
「MicrosoftのVisual Basic for Applicationが好き♪ 週３回は Excelでコーディングするの。」
特にOfficeは平凡ながら、ま、無難にまとめてあるものの、
しかし、「新UIのリボンUI！」「メトロUI対応！」とかなんとか無意味な自慢を吹聴し、
VBAはさらにプログラミングについての謬見を撒き散らした罪がありますから、プログラミング大好き男にとっては天敵なんです。
ティーガー戦車乗りのオットー・カリウスは「ティーガー乗りなら誰でも片側の履帯がはずれ僚車に牽引されて帰ってきた経験を持つはずだ」 って言ったけど
社内SEかSIerなら誰でもクソみたいな前任者が書いたクソみたいなExcel-VBAコードを直した経験があるはずなんです。
また、もしも貴女が「PHPが大好き♪ あたしが書いたPHPのWebサイトが、さくらサーバに７件あるよ♪」
と答えたとしても、同様の効果をもたらすでしょう、
なぜって、PHPは、１９９０年代にはWeb系を目指す人にとっては簡単で要件を満たすWebサイトが簡単に作れる輝きの道だったものの、
しかし２０００年代そうそうから、セキュリティ関係の問題で転落し、
いまや、あの貧弱な言語能力では、Rubyの魅力に遥かに及びません。
（注１）
「わたし、.NET FrameworkのC#が好き、フォームアプリでも書くけど、
最高に好きなのはASP.net♪ SQLServer連携も、ajax control toolkitもすっごくおいしいの。」
と、答えたとしたらどうでしょう？
なるほど、貴女の趣味は高く、
たしかに.NET Frameworkは、C# が cool であるのみならず、
.NET Framework上で動く F# や IronPythonやIronRuby、マネージJScriptも最高においしいんですけれど、
しかし、貴女の答えを聞いて、プログラミング大好き男はきっとおもうでしょう、
（なんだよ、MS信者な女だな、カネかかりそう）って。
（注２）
貴女が、プログラミングが大好きで、言語の名を挙げるにしても、
たとえば、JavaScript(node.js)ならば安心でしょう、
なぜならば、JavaScriptは、かけだしのプログラミング初心者にもマニアにもともに愛されるめずらしい言語で、
貴女がその名前を挙げても必ずしも、(jQueryがやっとの初心者と思われることはあっても)あなたがプログラミング言語おた宣言をしているとは受け取られないでしょう。
むしろ「へぇ。ちゃんとprototypeは使ってる？」と聞かれたら「当たり前じゃない。むしろnode.jsでいいMVCフレームワークが分からないんだけど…」と話を振ってみましょう。
男は嬉々として、３０個くらいのnode.jsのフレームワークを教えてくれることでしょう。（まぁどれもどれで帯に短し襷に長しなんですが）
あるいはRighno上で動かしたコードをnodeへ移植する話とか、CoffeeScript、甚だしきはClojureScriptを振ってみてもいいかもしれません。
しかし、たとえば、世界が（つーか竹内先生とポール・グレアムが）誇る超絶関数型言語の名作、Common Lispにせよ、
selfと書きまくることと海外で使われてることに定評のあるPythonにせよ、
バージョンアップごとに言語仕様が変わり、かなり素敵なものではあるもののobsolatedな罠にはまりやすいRubyにせよ、
まったく読めない$_だらけで頭悪い仕様をリセットしてPerl6にする（そしてまた全く読めない）Perlにせよ、
気さくなクジラ飛行机さんがふるまう素敵においしい日本語プログラミング言語のひまわり・なでしこにせよ、
基地外トリッキー言語の代表BrainFxck・Glass・Missa・WhiteSpaceにせよ、
ましてや貴女が、「Haskellが大好き♪ わたし、プロジェクト・オイラーの問題もうほとんどHaskellで、解いちゃった♪」
と答えたならば、どうでしょう？
これはかなり博打な答え方で、
なるほど、Haskellは、純粋関数型でありつつも副作用のある操作が行える超絶名言語ゆえ、
あなたがそう答えた瞬間、プログラミング大好き男がいきなり超笑顔になって、
「へぇ、やっぱりHaskellなら大抵の問題は４行以内くらいで解いちゃった？」とか言いながら
鼻の下がだら～んと伸びちゃう可能性もあるにはありますが、
しかし、逆に、（なんだよ、この女、プログラミングおたくかよ）とおもわれて、どん引きされる可能性もまた大です、
なぜって、必ずしもプログラミング大好き男がプログラミング大好き女を好きになるとは、限らないですから。
男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、
もしも貴女が、「Haskellが大好き♪」なんて言ってしまうと、
そこにはもはや、男が貴女に圏論のモナドを教育する余地がまったく残されていません、
したがって貴女のその答えは、
プログラミング大好き男の貴女への夢を潰してしまうことに他なりません。
ま、ざっとそんな感じです、貴女の目にはプログラマーたちはバカでスケベで鈍感に見えるでしょうが、
しかし、ああ見せて、プログラマーはプログラマーで繊細で、おざなりに扱われると傷つきやすく、ローカル変数の名前一つにも気を使い、女と自分の将来に夢を持っています、
貴女の答え方ひとつで、プログラマーの貴女への夢は大きくふくらみもすれば、
一瞬で、しぼんでしまいもするでしょう。
●
では、スキットを繰り返しましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
そして、その瞬間、プログラミング大好き男の目がらんらんと輝いたなら、
貴女はこう重ねましょう、
「それからね、いま、わたしが使ってみたいWebアーキテクチャは、
Play Framework、素敵なリアルタイム嗜好のアーキテクチャって噂を聞いたから。
あなたのお暇なときがあったら、わたしをPlayへ連れてって♪」
これでもう完璧です。
PlayFrameworkと、Play（遊ぶ・じゃれる）のダブルミーニングでかれの股間も刺激しちゃえます。
そうなったらこっちのもの、
デートの日には、ペアプロ用に Happy Hacking Keyboard をばっちり決めて、かわいい下着をつけて（注３）、
github.comの通販で売ってるoctcatのTシャツか、facebookの「いいね！」ボタンがムネのところにあるTシャツ、 あるいは初音ミク（ないし彼のお気に入りのアニメキャラ。北米ならMyLittlePonyで鉄板なんだけど）のコスプレを着てゆきましょう。
その日から、プログラミング大好き男は貴女の虜になるでしょう。
注１：
（と、書いたもののPHPの現状をよく知りません。グローバル変数だらけになるのとか旧ASPみたいなもんなのかなぁ。count($array); とか書くのアホと思うがpythonも同じだった）
（あと、マジで単機能とかTwitter連携とか診断メーカー的なのでもPHPで７つも作ってる女子居たら付き合いたい）
注２：
もっとも。objective-Cなんていう言語をやることに比べれば個人で行う程度なら金のかからない手法もなくはないのですが。
注３：
プログラマーにとっての「かわいい下着」と、女性にとっての「かわいい下着」の定義にずれがあるので注意。
半数くらいのプログラマーはしましまぱんつが可愛いと思ってる気がするので、妙齢の女性が着用するには抵抗あると思うが、ボーダー柄のコットンショーツ（ただしキャラ絵のは除く）とか、
過度でないていどにフリルがついたものがオススメ。また、色は、レッドだとプログラミング大好き男は引いてしまう（だってそれはコンパイルエラーのときの色だ）ので、薄ピンクかホワイト、薄ブルー、せめて黒（に差し色でピンクとか）あたりに留めたい。
補記：
元ネタ： http://tabelog.com/tokyo/A1301/A130101/13002457/dtlrvwlst/3464106/
補記２：
「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。
補記３：
言うまでも無いけど、ネタです。
そもそも、よくよくLinkedListクラスのインターフェースを眺めてみると、これは連結リストのノードを表現するクラスではなく、連結リストそのものを表現するクラスのようですね。こんなものをいくらネストしたところで多次元配列の構造しか作ることができないのは自明でした。現段階では、元記事の文章は不適切であると言わざるを得ません。
ところで、Lispの真似事をC/C++でさせたいのであれば、タプルを定義するのが先だと思いますが、いずれにしても教育カリキュラムや人材の選別過程でこのようなコードを組ませる方針は私はあまり感心しません。あれは一種のハックであって、木構造のアルゴリズムをコードで表現する際に必須の、本質的な概念ではないからです。仮に知らなくとも、それは「その人が育ってきた文化が違う」だけの話です。例えばB木を実装するにもRadix Treeの実装にしても知らないままで全く困らないでしょう。
ほかにも、計算量の評価に触れていないなど、気がかりな点はありますが、元増田氏からのコメントもないようですので、ひとまずこのへんで。
型論争の一部。
動的型陣営と静的型陣営がそれぞれ大規模開発に向いてるとか向いてないとか言うけど、「大規模開発」って何よ？って話。
自分としていくらかのパターンがおもいつくし、それぞれ質的に異なるからごっちゃにしても話が混乱するだけだ。
お前らの言う大規模開発ってどれだよ？あともちろんこれ以外にもあれば募集。
ITゼネコンみたいな連中が行う、何万人月というコストをかけて行う開発。失敗した特許庁の開発みたいなやつだ。典型的にはワンオフ品なので、かけたコストのわりに品質は低い。fizzbuzzも書けない人すら1人月と数えられるし、そういう人が生息するのはここである。2013年現在では多分Java（かたまにScalaなど）で開発される。末端の人には自分たちの担当領域外の仕様をどうこうする権利が基本的にはない。
OS（カーネルのみの狭義のOSではなくパッケージとしての広義のOS全体）とか、あるいはモダンなブラウザみたいな、膨大な機能セットをもち、様々な環境でロバストに動く必要がある開発。膨大な機能セットの中には、膨大な後方互換のための機能（例えばブラウザであればクソみたいなレガシーHTMLでもなんとなく見せてやるような機能）や、ありとあらゆるハードウェアや言語などの細かな実行環境の組み合わせで動作するための抽象化および各環境のための固有の機能を含む。オープンソース形態で開発されることもよくあり、2013年においては多分C/C++で開発される。自分たちで仕様をコントロールする権利があったりなかったりする。
1日のPVが億オーダー以上になるようなWebサービスなど。昨今だと1日にGバイト〜Tバイトにもなるデータを解析できるシステムもセットになってることが多い。サーバの1台や2台がハードウェア的な故障してもロバストに動き続けるための機能や、そのときのリカバリが容易であること、壊れた分や単なる新規追加ののサーバの補充が容易であること、みたいや機能および設計上の工夫が求められる。人的な大規模開発や量的な大規模開発と比べると比較的少人数（数人〜数百人。数千人になるのは数えるほど）で開発される。2013年においても様々な言語で開発されていて決定打はない。自分たちで仕様をある程度コントロールする権利がある。
例えばこの方が、Haskellは大規模開発に向いていると主張されているが、おそらく人的な大規模開発には向かない。これは2013年においてHaskellを使うユーザがそれほど多くないから、というのも大きな理由だがそれだけではない。Haskellは学習コストが低いことを目指して作られた言語ではないことも極めて本質的かつ決定的な理由の一つである。（自分の思う学習コストが低いことを目指して作られた言語とは例えばJavaとPHPだ。）fizzbuzzを書けない人をHaskellを書けるまでに教育するのは、どうしたらいいのだろう？
Haskellが量的な大規模開発に向いているかどうかは（自分の無知により）よく分からない。典型的には量的な大規模開発を実現するためには、そのソフトウェアがWindowsとか各種ブラウザ並に多くの計算機上で稼働することが必須だ。そうでないと膨大な開発コストがペイできない。オープンソース的に貢献を募るとしても、量的に巨大なソフトウェアに貢献する人を一定以上集めるには、それなりのユーザベース（単に使うだけの人も含めて）が必要である。Haskellの実行環境というのは全然枯れていないが、10年前のハードウェア＋OSを未だに使っている人の計算機上でもちゃんと動くのだろうか？HaskellってVMで動くんだっけ？ネイティブコードを吐くんだっけ？
英語圏ではかなり前からPerlで開発し続けることのリスクについて語られていたが、いよいよ具体的な弊害が出て来ているようなので、かいつまんでメモ。日本でもそう遠くない未来だと思う。
Objective-Cのように需要が逼迫しているのに人材の供給が増えず需給ミスマッチが起っているわけでは無く、需要も供給も減るという状況下でわずかだが需要が上回っているとう性質の悪い状況がPerlに起きている。特に深刻なのは安価な若手エンジニアの採用が絶望的に難しいという現実だ。Rubyが台頭して数年経ちPythonがメインストリームの先頭を突っ走る2013年において新しくPerlを勉強しようとする若者はよほどの物好きしかいない。30~40歳のPerlエンジニアを雇うのはそれほど難しく無いだろうがコストがかかる。安価な20代前半の若手エンジニアを雇いたいという企業の思いとは裏腹にPerlを新たに学ぶ若者は絶滅寸前だ。
とても優秀な若者を雇用できるチャンスが巡って来た。採用担当者はこう尋ねる。「Perlは習得していますか？」「もちろんC/C++/Pythonはお手の物です。Javaもある程度可能です」「もう一度伺いますがPerlは習得していますか？」「申し訳ございません 未習得です」
悲劇だ。
もう何年もPerl界隈で新しいモノが生まれたと言う話を聞かない。こんな事を言えばPerlハッカーは激怒するかもしれないが、しかし現実にRubyやPythonやJavaに比べればこの10年の間にPerlから生まれたものは微々たるものだ。何かしらのライブラリにしてもwebフレームワークにしても、ハッカーが新しいモノを試す土俵にはいつもPythonやRubyやJavaが選ばれて来た(もちろんC/C++もね)。
最低の理由ではないだろうか。
10年前にPerlで開発していた企業は最先端を走っていた。迅速に自らのアイディアを具現化するツールとしてPerlは最適だった。それが今やどうだろう。自分たちの書いたコードを保守し続けなければいけないという理由「のみ」でPerlを使い続けている。他に理由など無い。Perlで開発する理由は自分たちの過去の仕事を保守しなければならないという理由のみだ。
控えめに言っても、そういう企業に未来は無いと思う。過去とは決別し、10年後の自分たちにとって最適な選択をすべきだ。今すぐにだ。本当に手遅れになる前に。
