  |
はてなキーワード: javaとは
界隈ではかなり前から Python界の perlcodesample こと @makotokuwata のリスクについて語られていたが、いよいよ具体的な弊害が出て来ているようなので、かいつまんでメモ。
https://twitter.com/makotokuwata/status/315510592171556864
この人、「HaskellDBはORMより素敵！」「ORMと全然違う！」と言ってるけど、ActiveRecordすら知らない可能性でてきた。まあ、なんだ、Javaしか知らずに「静的言語はクソ」と言う人もいる世の中だし、最近のORM知らずにORMより凄いと言う人がいてもおかしくない。
まあその通りだ。しかし、次のツイートを見れば完全に自己矛盾しているのがわかる。
HaskellDBのことを知らずにORMの方がすごいと主張している訳だ。口が悪いだけで、ほんと話にならない。
この人はkwatchでググればわかる通り大昔から perlcodesample 的な振る舞いを続けていた人だ。他人の意見を聞けない視野の狭さとか、独善的な振る舞いなど、共通点は多い。インタネットの黎明期にはこういう知識が中途半端にあって調子に乗ってしまう人は他にも多かったので別段珍しい訳でもないのだが、この人のプロフがほんとの意味でのリスクだ。
https://twitter.com/makotokuwata
Pyを広げるのに熱心なだけの人間
いや、この人別にPythonのメインストリームにいないし、迷惑。本当にPythonを広めたいなら、プロフィールを「Perlを広げるのに熱心なだけの人間」に変えて欲しい。
http://d.hatena.ne.jp/iad_otomamay/20130318/1363596244
この記事。本当に腹が立ちました。
まず質問自体が酷いのが多い。
省略したのは知らないと障害の危険があるので知っとくべきってことで同意なんですが、
これは使うときにググれば良い話。暗記しておくメリットがわからない。
結合テスト中のシステムで、OutOfMemoryErrorが発生しました。UT後ソースコードの変更はしていません。ヒープメモリは足りているようです。原因として何が考えられますか？（筆記解答）
「UT後ソースコードの変更はしていません」という一文が意図不明。単体テスト終わった後にソースコード変更したら、再度単体テスト必要だと思うのですが？この一文は何のヒントにも制限にもなっていないです。
なぜNGなのかというのは「文字列連結演算子(+)では速度が遅いから」であり、StringBufferかStringBuilderのような結合用クラスのappend()を使うことでパフォーマンスは向上する、というところまでが質問の狙いなのかと思いました。もう一歩踏み込むならば、+をしたときにコンパイラでどのようになるかを知っているかどうか、みたいな。しかし結合用クラスにはデメリットもありまして、append()は冗長過ぎて可読性が酷く低下するデメリットがあります。文字列の連結時にクラスをnewするタイミングを調節したほうが速くなることもあります。近年ではマシンのスペックもあがってますので、そんなに気にする部分ではないと思います。そもそも、このStringBufferの仕組みは絶望的に救いがないJava言語の汚点と言ってもよい部分です。なんで文字列の連結方法に複数のやり方を速度だけの理由で取捨選択させるというバッドノウハウなので、早くコンパイラが最適化して一元化くれることを望む部分です。
StringBufferかStringBuilderと書いていて、そういやスレッドに関しての質問がないのはどういうことなのかと感じました。JavaのWeb系ってスレッド重要だと思うのですが。
JavaScriptでHTML要素をid属性の指定により取得するメソッドは何ですか？（筆記解答）
もうjQueryやDojoも使われるようになってきたからこれも知らなくてもいいんじゃないかと。id指定で取れるということとを知っておけば答えにはたどり着けるはず。バッドノウハウです。どうしてJavascriptが最近になって流行ってきたかを思い出して欲しいです。
プログラマーはバッドノウハウの塊でなくてはならない、というのが見えてくる質問内容ですが、最近は覚えなければならないことが多く、技術の更新スピードも早いので、あの質問のような重箱の隅まで暗記するようなことをしていては、重要な部分が抜け落ちているし、暗記の苦手な人は辛いと思います。書籍もネットのような情報の蓄積と抽出する部分は充実してきたので、概念は知っておいて、実装手段はその都度調べるほうが効率的であるかと思います。質問は、応用の効く根本的な部分を問う方がよかったです。
「現実は、もっと凄惨な世界を経て時代が進んでいくようだ。」などと締めくくっていますが、この人は凄惨な世界が嫌なのでしょうか？不安を煽るだけで対策も講じていません。まず、質問の回答を書くだけでも、読んだ人の知識の底上げに貢献できると思うのが普通です。「これは基礎教育をやってれば当たり前」とか言ってドヤ顔して、できない人間を馬鹿にしているだけに見えます。本心では凄惨な世界を望んでいるのでは？としか思えてなりません。
この記事を読んだことで、またSI業界から優秀な人が遠のくことでしょう。こんな人間が居る業界には居たくないと。
どうして悲しみを減らす方向に動いてくれないのかと…
※追記
頭沸騰しててスルーしてしまったのですが「淘汰」って書いてあったので、業界の底上げは望んでないんだなあと、見当はずれなこと書いてしまったなあ、と、後悔した。
http://anond.hatelabo.jp/20130310152356
元増田に便乗したお陰か、思ったより多くの方に読んで頂けたようでとても嬉しいです。
こんな付け足しを書くのは興ざめかもしれないけれど、
似たような境遇の人も多いようだし、
もうちょっと具体的な事を「あとがき」として補足しても良いかな、
という気になりました。
（申し訳ないことに、この付け足しも長いです）
私の文章は、元増田
「上流エンジニアなんて死んじまえ」
http://anond.hatelabo.jp/20130309233920
「上流にも技術力はあるはず」
という、上流下流のどちらが優秀かという議論が問題からやや外れているように思えたため書いたものです。
優秀な人がいても活躍できず、当たり前のような施策もうまく働かない、
（下流にいたほうが技術力の見せ場が多いため、
下流に優秀な人が多いように見える傾向はありそうです）
そして、その他の19人～49人は基本的に普通の人です。
20～50人に1人の人をあてにして仕事を進めるのは（現状のSIer周辺では）不可能なため、
19人～49人の普通の人が持つ価値観・思考・ペースで仕事を進める事になります。
さて、システム開発でソフトウェアの基本構造を決める部分について、
どうしても一種の才能（パターン認識・適用能力）が必要なのですが、
才能のある人が適切に作業に割り当てられる可能性は低くなります。
その結果、普通の人が納得しやすい下記のような方法が取られがちです。
こういった構造は、当時は場当たり的なつもりでも結局は規約化してしまい、
「途中で何を思いついても設計書の通りに絶対作れよ」
といったSIerにありがちな規約と相まって、未来永劫負の遺産として残ることが多いです。
そして、一旦ダメな土台が出来上がると、その上には基本的にダメなものしか重ねられないため、
どんどんダメになっていき、最終的には手のつけられない沈没船になります。
プログラムの基本構造がダメだと、どんな優秀な人であっても出来ることが限られます。
当然リファクタリングすれば良いのですが、
といった、普通の人による突っ込みには、現場での反論がなかなかしにくいです。
そして、リファクタリングもやはり才能のある人が中心になる必要があり、
ここまで書いてきたようなことが、
現場の中に居たままそこを良くする方法は、結局思いつけませんでした。
これをこの先何年続けても無意味だな、と思い、転身することにしました。
正当な取るべきリスクを取った結果だと思うのです。
沈没船では最初から沈没寸前のため、リスクを負うことができないか、異常に増幅されます。
運用上リスクを負うことのできない（機能追加できない・構造を改善できない）システムなど、
黒船は、取れるリスクの幅が大きいからこそ難しい航路を選べるし、
そこで失敗したとしても、それ自体が業界や人類全体の資産になるのだと思います。
黒船は水平線のはるか向こうで、船長はそれらが見えないため気楽です。
ちゃんと沈没してくれれば、最終的にはまともな船しか残らないので助かるのですが、
まともさに関する競争が働きにくいところがあるらしく、
リスク満載のはずの沈没船を安泰とさせている事によるコストは、
最終的には企業全体・社会・国家・人類といったものが負っていると思われます。
普通の人というのは、
家に帰ってから基本的には勉強せず（資格や仕事で必要な場合は別）、
仕事で決められた範囲のツール・技術・問題領域で満足できる人の事です。
これは不真面目とか怠慢とかそんなわけではありません。
例えば、マクドナルド店員が、
自宅でもビーフパテを練ってハンバーガーの焼き色を研究したりレシピを何冊も書いたり、
毎日毎日ポテトやハンバーガーをキーワードにググったりブログを読んだり、
枕元には常に藤田田の著作を数冊積んでいて、本棚には完全なコレクションがあったり、
1日に5度は銀座1号店の方角へお祈りを捧げたりしたら、
やはり変だと思うのです。
「才能のある人」とは、そういう事をごく自然に、
それこそ食事や睡眠のように日々やっている人です。
さらに言えば、これはマクドナルド店員を例に出すと変に思えるのであって、
ギタリストやピアニストや作家や写真家やデザイナーといった専門家であれば
不自然でも何でもない最低限のたしなみです。
20人～50人に1人という割合も、それがプロのギタリストであれば納得できる数字です。
本来そのぐらい特殊な専門領域を広く一般に開放してしまっているという問題が、
元増田の「システムエンジニアなんて免許制にしちまえよ」という言葉に繋がるのだと思います。
「Javaは学習コストが低くHaskellは学習コストが高い」みたいな話をよく見るけど、本当なのかねぇ。
初期のJavaならともかく、AutoBoxingの落とし穴とかワイルドカードの正しい使い方とか、
強力なenumの使い方とか、色々入ってる今のJavaがそこまで簡単には思えない。
元記事はそんなに外してもいないと思いますけどね。
静的型付き言語として関数型言語を持ち出してくるのは、論点が違うような気がしました。
静的型、型推論の嬉しさって、関数が一級かどうかでも違ってくると思いますし。
(つまり、静的型の得失について、scheme vs ML での議論と Java vs Perl の議論は別物だと思います)
結局は適材適所という結論にしかならないと思いますが、たとえば Web 系なら静的型付き言語で書いても面倒臭さの方が多そうです。
Web 系で一番面倒なのは文字列の扱いなので。そこは型システムで何も解決しないですよね。
そういうことより、文字列を関数名として $funcName(arg1, arg2) みたいにコールできたりとか、
そういう柔軟さが便利なのですよね。
こういうの、静的型がある言語だと大変ですよね。Java ならリフレクションですよね。
他の言語ではどうするのでしょう。おそらく、自前で関数テーブルを作ることになるでしょうか。
静的型を持たない言語での開発が、大規模になると破綻するというようなことが言われます。
大規模開発といっても、大抵フレームワークの規約に沿って実装するだけですし、
規模を LOC だと考える限りにおいては、大規模になっても複雑さは LOC に比例しませんから。
単純にモジュール数が増えるだけで、一つ一つは単純な実装の繰り返しですよね。
おさしみにたんぽぽを乗せるお仕事と変わりません。たんぽぽの山が積まれていて途方に暮れるだけです。
もちろん、大規模になったときにスケールしなくなるので C/Java にするというのはありますけど。
型論争の一部。
動的型陣営と静的型陣営がそれぞれ大規模開発に向いてるとか向いてないとか言うけど、「大規模開発」って何よ？って話。
自分としていくらかのパターンがおもいつくし、それぞれ質的に異なるからごっちゃにしても話が混乱するだけだ。
お前らの言う大規模開発ってどれだよ？あともちろんこれ以外にもあれば募集。
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年後の自分たちにとって最適な選択をすべきだ。今すぐにだ。本当に手遅れになる前に。
変数に型がないということの利点について考える
http://d.hatena.ne.jp/perlcodesample/touch/20130227/1361928810
が大変お粗末な内容だったので、反論記事を書きます。
型推論はソースコードのコンパイルの時間を遅くしてしまいます。ソースコードが大きくなってきた場合に、すばやく書いて、すばやく実行結果をもらうことができなくなります。
大規模開発環境はコンパイル時間よりリンク時間の方が問題になりやすいが、それは別に型の話とは関係ない。
あと、インタープリタも最近は実行時にJITコンパイラが走る。
実行時間に影響がなく、開発者の待ち時間で済む方が実はよいのでは？
統合開発環境での、メソッドの自動補完の機能の実装が少し難しくなります。
みんなが統合開発環境をつくるとでも？
そもそも型が不定なら補完することすらできないので、
比較対象として相応しくない。
変数に型がないとソースコードの変更に強くなります。たとえば右辺の返す型に変更があったとしても、受け取る側のソースコードを変更する必要はありません。
これは逆に危ない。
実行するまで意図したインスタンスが返ってこなくなった事実に気づかないから。
変数の型を持つ言語は、型が異なるのだが、処理としては同一の処理を行いたい場合には、オーバーロードという機能を使う必要があります。変数の型がなければ、オーバーロードの機能は必要ではなく、ただ単にif文で分岐すればよいだけなのでとても楽です。
CならVTable。Javaならinstanceofなど同等の事はできます。
というか、これ。型を意識しまくったコードじゃないですか？？？
C++のテンプレートのような複雑でデバッグしにくい機能を使ったりしなければなりません。
実は全然ちがうものが混ざってた！なんて事故がコンパイラによって止められる分、デバッグする必要すら無いんですけどね。
変数に型がないとどのような型の値が代入されているかわからないという批判があるかと思います。可読性の問題で
あれから色々とあった。
（最近は仕事の納期が近いのに、インフル等で時間が取られてしまってイライラしているが・・・）
妻に対しても、なるべく話を聴くようにした。
早く家に帰れたら今日あったことを聴いたり、
朝食の時は今日は何をするのか聴いたり。
妻も僕に対して優しく接してくれるようになった気がする。
このおかげで、会社の人とランチに行ったり遊んだり出来るようになった。
他にも、何だかんだで僕の好物を作ってくれる機会が多くなった。
会話しても妻がイライラすることが少なくなっていると思う。
家族として良い方向に向かってきていると思う。
タイトルに「その２」と書いた。
理由は、今日祖母の見舞いに行くので、
気が向いたら書こうと考えているからだ。
作って持っていこうと思う。
祖母の昔話でも聴こうか。
そこの人から祖父のところに嫁いで欲しいと言われて
結婚したという。
なんというか、今では考えられないような結婚の理由だ。
まぁ、何となく祖母らしいとは思ったが。
祖父の顔を僕は知らない。
不思議と知りたいとは思わなかった。
たぶん、知りたいと言うと祖母や母が
一度だけ祖父のことを聴いたことがある
何にでも興味を持つ人だったらしい。
家にある鉄製のフライパンは祖父が作ったとか。
母が二十歳の時に亡くなったとか・・・・。
----------------------------------------
帰宅。
とりあえず、今日は色々と有り過ぎたので
夢は追っています。
独学でAndroidアプリを細々と作っています。
（JAVAで作って、JavaScriptに書き換えてということをやったりしてます）
そこにはあえて触れなかったんですがね・・・
そこに対して過剰反応する人が居るとは思っていなかったし、
僕自身が夢の進捗を語れるレベルではないと思っているので。
書けるようになって楽しいです。
仕事で新しいことを任されたので、良いプログラムを書く楽しさで
一日でサンプル作り上げたりとか。（コメント含めて６００行なので、量は多くなかったですが）
自分なりに成長はできているのかな？っとちょっと思い始めているところです。
ただ、目指しているところには全然届いていないので、
とりあえず、疲れたので今日はこの辺で。
IT土方の自分が初めてプログラムなるものを体感したのは、中学校の授業だった。
当時は5インチフロッピーが主流のパソコン上で、BASICを走らせたらそれが妙に面白くて、時間を忘れて夢中になってしまった。
原体験というのは恐ろしいもので、今振り返ってみればそのときの体験が、その後の人生に計り知れない影響をもたらしたわけだ。
例えるなら、あやとりと拳銃早撃ちに目覚めたのび太的感覚だろうか。
開発者の社会的地位は「コード書けるだけで何が偉いの？何が凄いの？」という微妙なポジション(国家資格でもコード書き方面の高度区分は組み込みだけというのが現状をよく表している)で待遇も微妙だが、それでもプロのコード書きは自分にとって天職だと思うし、そうなってしまったことにあまり後悔はしていない。
山下清じゃないけど「まあ仕事だしな」で過ごしたり過ごさなかったり。コード書き以外は何をやっても全然ダメだけど。
とまあ、これだけで終われば満更でもない思い出話なのだが、正直、初めて触れた言語がBASICだったことは、自分にとって黒歴史でもあったりする。
かつての自分と同じようにBASICでプログラムに興味を持った人に「あんなのはダメ」と頭ごなしに言うつもりはないけど、もしBASICのBの字も知らない人であれば、今ならPythonかRubyを、Linuxとセットで勧めると思う。
気がついたらCもJavaもPerlもこなし、いつの間にかアプリもシステム・プログラミングも経験していた自分からすると、それくらい、BASICは言語として拙いというのが実感なのだ。
色々問題はあるんだけど、一番はプログラムに対するスタンスを誤解してしまう所。
あれを最初にやると高確率で「プログラミングなんて、その場で出来る範囲で適当に書いときゃいいんだ。なんつってもノリが大事なんだから、うるさいこと言って神経取られちゃダメだ」という恐ろしい考えが身についてしまう気がする。
だってかなりいい加減に書いても、それなりに動いちゃうから。人は大抵易きに流れるので「これでいいのだ」になるのが自然というか。
更にこれがVBだったりすると、MSの用意した機能だけしか使えない人になるだろう。もっとヤバい気がする。
ともかく自分はそうやって身についた悪習慣が祟って、折角大学で習った知識はまともに身につかず、就職後にOJTを通して自らを叩き直すハメになった。
勿論これは自力じゃなく、当時のメンターの驚異的な忍耐力を以てなされたことであり、今でも頭が上がらない。
全く遠回りをしたもんだと思う。
今でも周囲のVBしか業務経験ない人のコードの品質は基本的に低い。某掲示板ではVB厨という言葉があるらしいけど、そういう蔑称も仕方ない気がする。
まあ自分の場合、当時はBASIC以外の教育用言語といったらPascalくらいしか無かっただろうし、振り返ってどうにかなるもんでもないし。
オープン系のデスクトップアプリ開発、Webプログラミング、システムプログラミングを仕事にする人向けとして考えてみた。
学習環境はUbuntu Linuxで、デスクトップ上のターミナルか、WindowsからTeraTermでsshログインして行うことを想定。
なので前提知識としてLinuxのabcくらいは教えておくとして、もし来年度やるならこんなもんかな。
結構分量多めだけど、これでも基礎の基礎に絞った感じ。
おまけ：Pythonで学ぶ関数型プログラミング
なお、上述のカリキュラムでやらない言語(VB、javascript、C++、Objective-C、C#、PHP、Rubyなど)やWebフレームワーク(Django、Ruby on Railsなど)は、全てこれらの応用で覚えられると思うので、基礎教育終了後に各現場にてOJTで習得してもらう。
IDEも使わないけど、はじめの一歩で軽量エディタ+コマンドラインをやり込んでいれば正直どうにでもなるので省略。
あと最後がおまけ扱いな上にLISPで学ばないのは、要するに「リストすげー！超すげー!!」という感動を胸に今後も頑張ってもらうのが狙いなので(だって現状使う機会殆ど無いし)、最初にやって一番手に馴染んでいるツールで、理解のコアになる部分にサクッと触れて欲しいということ。
言語なんてツールの一つに過ぎないし、ツールなんて適材適所という前提で書いてみる。
PerlはC言語やJavaとともに、自分にとっては原点とも言うべき言語で、今は全く使ってないけど、昔はとてもお世話になった。
今更書くまでもなく文字列処理やハッシュが強力で、あんな便利なものはないという感じ。
少なくともPerlのないLinux/UNIX環境なんて死ぬほど使いにくいだろう。というか実質不可欠だろう。
書きやすいけど読みにくいのが玉に瑕で、間違っても最初に覚える言語ではないけど(書き散らかすクセがつくので)。
でもPerlは、C/C++バリバリな古参のプログラマでは嫌っている人が結構多い。なんでかなあ。
最近ではPHPやPythonなど、Perl以外のLL勢からも微妙な感じで見られている。
確かにCでも文字列処理は可能だけど、Perlに比べたら機能的にとても貧弱だし面倒。だからちょっとした作業なら間違い無くPerlのが楽。
PHPはWeb方面ではPerlより手軽だし、Pythonはシンプルかつ見た目もスッキリで初心者には一押しなんだけど、それでもPerlの書きやすさにはまだまだ及ばないと感じる。
今時のパソコンをいきなり与えられた人(普通はそうだけど)は、そもそもポインタなんて機能が何故必要なのか理解できないと思う。
JavaとかPerlとかVBとかは、扱いたいデータを直接切り貼りするだけでプログラムとして成立するし、それで十分なわけで。
そのレベルでコンピュータの仕組みや、メモリの使い方を理解する必要性は、普通は全く感じられないからね。
それにポインタを意識しながらプログラミングするというのは、前述の演算に必要なデータ構造に加えて、メモリ管理上のデータ構造も扱うという、2重のデータ構造を考えないといけない。
これはプログラム初心者には全く想像できない領域だし、そうそう簡単な事じゃないと思うわ。
ましてやC言語の*pとp[]の交換性が、基本環境依存のデータ型のバイト長をいちいち把握しながらポインタ演算してアクセスなんて面倒でしょうがないから結構必須とか、そもそもポインタ演算を使いこなせればハードのリソースをビット単位で搾り取れて、それをアセンブラよりはシンプルかつ抽象的に実装できるC言語は非常に効率がいいとか、まず理解不能でしょ。
そんなことが必要な分野が世の中にはあるという現実すら知らないだろうし。
尤もマイコンキットから入って「メモリにデータをロードして、そのデータのメモリ上の格納場所がCPUから分かるように(ry」というアプローチなら、ポインタを使う以外に方法が無いので嫌でも覚えるだろうけど。
臓疾患持ち、身長170cmどまりの超低スペック高校１ 年生です。
プログラミングに興味を持ったのは今から３年前の 1２歳のときだった。
まだ、世の中がプログラミングは教育に必要だとか あまり叫ばれていないときの話だ。自分は勉強も運 動もできない。いや、何もかも人以下だ。
だから、プログラミングという物ができれば、他の 人と同等、それ以上になれると思いJAVAの教本をアマ ゾンで買った。 がんばってサンプルコードを打って 動かした
しかし、なかなか身に付かない。
構造体？とかよく理解できないのだ。
僕は教本が悪いと思い評判のいい教本をアマゾンで 買った。 しかし、理解できない。次第にサンプ ルコードを打ち込むことが嫌になってきた。
まだ、僕は懲りていない。
今度は言語が悪いと思い始めたのである C言語の 教本を買った。
結局、続かず２ヶ月で挫折した。
父親は僕の本棚にいろいろな言語の書籍が増えてい くのを見かねてPHPを僕に直接教え始めた。
PHPはなんとか理解する事はできた。
プログラミングで何か作りたいなんてなかった。
取り柄が欲しかった。
そしてプログラミングを学ぶのを一時的に辞めた。
その間にもなぜかプログラミング言語の教本を買い 物中毒のように購入して行った。 python、javascript、lisp入門。
去年の１月にiPhoneアプリを作ろうかなとふと思っ た。mac book airと書籍をお年玉で購入した。
結局、挫折した。
自分はプログラミングの本を購入する事しかできな い。金を使う事しかできない。プログラミングで何か したい訳でもなくただプログラミングが出来るという 取り柄が欲しかった。
想像をはるかに超える高速性と安定性を持つWindows ServerをメインにWindows＋Linuxのハイブリッド環境でインフラを構築
http://gihyo.jp/admin/serial/01/gloops/0001
IISとASP.NET，そしてC＃で書かれたアプリケーションが
想像をはるかに超える高速性を実現していることが挙げられます。
そのうえ，安定して動作しているのです。
ttp://itpro.nikkeibp.co.jp/article/NEWS/20090609/331590/?SS=imgview&FD=-654674548
HPCでもダントツのパフォーマンスをたたき出すWindows
ttp://cloud.watch.impress.co.jp/docs/interview/20101224_416025.html
ttp://wsmgr.jp.brothersoft.com/screenshot-50450.html
NASパフォーマンス比較テストでWindowsがLinuxを圧倒！！
ttp://www.flexense.com/documents/nas_performance_comparison.pdf
ttp://it.slashdot.jp/story/12/04/24/0052242/
【一方Linuxは…】
Linux Daily Topics：2011年9月2日 Kernel.orgがトロイの木馬の侵入被害に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/02
Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
ttp://japan.internet.com/webtech/20110902/2.html
Linux Daily Topics：2011年9月15日 狙われるLinux… 今度はLinux Foundationが標的に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/15
Linux Daily Topics：2011年9月2日 Kernel.orgがトロイの木馬の侵入被害に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/02
Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
ttp://japan.internet.com/webtech/20110902/2.html
Linux Daily Topics：2011年9月15日 狙われるLinux… 今度はLinux Foundationが標的に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/15
MySQL.comのWebサイトに不正なコード 闇市場でroot権限も販売か
ttp://www.itmedia.co.jp/news/articles/1109/27/news027.html
またもOSSプロジェクトが被害に! Wineプロジェクト、不正侵入を発表 | エンタープライズ | マイコミジャーナル
ttp://journal.mycom.co.jp/news/2011/10/13/115/index.html
・安定性・信頼性
フリーソフトであるLinuxの安定性・信頼性はハッキリ言って問題外。
1日連続で稼動させることすら困難。
いまやWindowsの安定性・信頼性はメインフレーム(汎用機)をも凌ぐ。
世界中のメインフレームが全てWindowsServerに置き換わったのがその証拠。
・脆弱性
Linux()
Linuxで稼動している世界中のサーバーがクラックされまくっている。
デフォルトスタンダードOSとしてあらゆる攻撃を受けてきたWindowsはいまや世界で一番強固なOSとなった。
豊富なウイルス対策ソフトもさりながら、カーネルの構造的に絶対に外部からクラックされることが無いOSとなった。
しかし上記内容により安定稼動させるのはほぼ不可能。
またサポートが存在しないため自前で何とかするしかなくかえってコスト高となる。
OSは無料ではないが従来のメインフレームのOSと比較すると安価。
もともと安定性に優れたOSであるため、誰にでも安定稼動させることが容易である。
サポート面もマイクロソフトを始め、各ベンダーが完璧なサポートを行える体制となっている。
自分の中でも良くまとめきれないことを書かせてくれ
ＩＴ系増田はなんであんなにイシキが高いんだ？
俺はＩＴ系ではない
でも一応、それがどのような仕事か判る程度には判ると思う
学生時代はZ80ダンプくらいは読めた（いまのコードやjava使いと一緒にするなと言われるならあやまる）
彼らはなんであんなに仕事場の生産性とかにこだわるのか、判らない
勉強会とかも、判らない
なんか、すごくえらい
俺から見ると光り輝いて見える
ものすごく前向きに見える
転職はしたことがある
でも転職したときもキャリアなんて気にかけなかったし口から出さなかった
いたたまれない感じだ
あんまりにもＩＴ系増田がいいヤツ過ぎて、世界観が違いすぎて、いたたまれない
どうなってるんだろう
追記：いまのこの流れで書くのも荒らしみたいでためらうんだが
ソーシャル屋にもちこんで、一件50～100万とかもらった
ライトノベルも何冊か出してたりする
ソシャゲのテキスト仕事なんて量は少ないのに買いきりでお小遣いには大きい
金がなくなったらどっか適当な会社に行って思いついたことを喋れば
わりと困らない程度のお金は毎回もらえる
試験業務中心だった。
その中でもシステムテストとかやったりしてるのでネットワークやサーバー、アプリは商用の状態に近い環境で試験をしている。
具体的にはサーバーはLB使って冗長化/スケールアウトされていたり、クラスタリングされていたり、データセンターにあるサーバーにリモートでログインして試験をしたりとか。
rebootコワイヨーとかHW障害うざいよーとか思いながら。
ソフトウェアの受託開発の会社で、Javaの業務アプリを設計・開発・試験していた様な人達が集まっているので、ネットワークやLinuxなどアプリよりは低レイヤなところに詳しい人が地味にいなかった。
システムテストの項目書をExcelで作るお仕事や、試験を実施するお仕事は凄くやる気しなかったが、試験の実施方法を検討するお仕事や、試験をするための環境を構築したり、仕様書を読んでミドルウェアやアプリにコンフィグを投入する仕事は楽しかった。コンフィグを投入する作業をスクリプトで怠惰に自動化したりするのは、けっこー楽しかった。
リグレッションテストや、バージョンアップでの改修テストなどで環境を再構築する際に、作成した自動化スクリプトは腐らさせずに誰かに展開することが出来たので、自動化した工数も無駄にはならなかった（ちゃんと効率化に！）大量にデータを投入するとき、さすがにだるい。ツールも使えば使うほどバグなくなるし良い感じ。PerlやBashを覚えるきっかけにもなるし。
今思うと出向も楽しかった！メーカーSIの会社は社員食堂とかあったので、うわすげぇドラマみたい！とか朝はエレベーターの前に人が並ぶのでうわすげぇ人多い！とか。（最初だけだけど）
後はサーバー室でサーバーとかLBとかを目の前で見れたのがテンション上がった。うわこれF5じゃね？うわこれJuniperやん…いくらすんだよ…HPのブレードサーバーだ！いくらするのかググった。
まぁ、普通に誰も興味示さないw あの時は商用ネットワーク機器という物に憧れている少年だったw
作業で疲れたときはぶらぶらして眺めてた。
何かの見学の時は「おいふらつくな」とか誰かに怒られそうだけど、仕事で来てると誰も何も言わないので見たい放題。転んでケーブル抜いた日には大問題になりそうなので、さすがにそこは気をつけた。
あの1UサーバーにRHELをインストールするとか、少年には楽しすぎた。でも手順はMacのVirtualBoxにCentOS入れるのと変わりはなかった…。ただ、仕事として1UサーバーにRHELをインストールした、という経験を持つことが嬉しかった（少年だから）
でもいいさ。
F5なんか使わずにLVSやUltraMonkey-L7で負荷分散すればいいし、商用のアプライアンス機器なんか使わずにオープンソースで解決してしまおう。AWS使うならELB使えばいいし。そういう環境行ってみようぜー。
