gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

竹の花が咲いたようなので

「竹の花」の元ネタは http://d.hatena.ne.jp/gallu/20110331/p1 の一番最後のほうをご参照あれw


というわけで、久々のお題なので、ある程度丁寧に。

PHP・⌒ ヾ(*´ー`) ポイ Rubyist is better than PHPer
http://blog.sumyapp.com/2014/04/php%EF%BD%A5%E2%8C%92-%E3%83%BE%EF%BD%B0%EF%BD%80-%EF%BE%8E%EF%BE%9F%EF%BD%B2-rubyist-is-better-than-phper/


さほど深い意味はないのですが、念のために、魚拓も取っておきました。
http://megalodon.jp/2014-0429-2220-35/blog.sumyapp.com/2014/04/php%EF%BD%A5%E2%8C%92-%E3%83%BE%EF%BD%B0%EF%BD%80-%EF%BE%8E%EF%BE%9F%EF%BD%B2-rubyist-is-better-than-phper/


で…先に。
この人のBlogって、右下に「Powered by One Designs」ってあるんだけど。
で、「One Designs」を調べると、 http://www.onedesigns.com/ のPageにぶち当たって、ここって、何となく、WordPressを使っているように見えて、っていうことはこの人のBlogってそもそもPHPで出来てるんじゃないかしらん? という疑問があるのだけど。


まぁ「RubyPHPより優れてる」じゃなくて「RubyistはPHPerより優れている」って発言なので、面倒だし、ここの突っ込みは軽めに。


で、本題。
ん…まぁ一言で片付けると「Rubyerの定義とPHPerの定義が明確になっていない上で優劣に対する基準軸の説明も感想に対するエビデンスも何もない」ので、とりあえず「論理構成力の弱い子なんだろうなぁ」で終わってしまうのですが。
終わっちゃうとBlogネタにもならないですし、久しぶりに観測できた「竹の花」なので、ここはもう少し、丁寧かつ丁重に、観察をしていくのが基本なのではなかろうか、と。

Rubyist is better than PHPer、ルビー使いがペチパーより優れている理由を3つ上げます。
PHPおよびPHPerはコードを書くのが嫌い
PHPerは実はHTMLに毛が生えた程度しか使えない人が多い
PHPは低級プログラマと過去の負債に引きずられる
Rubyとだけ比較してますが、Pythonと比較しても、Node.jsと比較しても別に良いでしょう。結果は一緒です。さぁPHPを投げ捨てよう!

ん…まず、文章の前半では「Rubyist と PHPer との比較」という文章を書いているのですが、後半は「RubyPython、Node.js、PHP」と比較をしていて、この時点で論理構成力が破綻していることがすでに明らかです。
細かく突っ込みますと、後半のうち、Node.jsは「JavaScript(という言語)を用いたNon-blocking I/O環境 *1」であり、他の「RubyPythonPHP」が言語であるのとはちょっと色々なものが違います。


なんだろう、何かを投げ捨てることを煽動する前に、自分が書いた文章をもうちょっと見直すとよい感じだと思われるんですがね。


まぁ、その辺の突っ込みは一端、イナバ物置よりも丈夫な棚に置いておくとしまして、次に進みましょう。

PHPおよびPHPerはコードを書くのが嫌い

………少なくとも「PHPは」主体的にはコードを書かないと思う。
なので、ここは好意的に「PHPerはコードを書くのが嫌いで、またそれ故にPHPは、コードを書く為に便利な諸々をサポートしていない」とか何とか、妄想力を最大限に働かせて解釈してみましょう。

この根拠は、PHPがほかの言語に比べてPaaSで動きにくい、というのを根拠にしています。PaaSで動くためには、少なくても下記の条件を満たしている必要があります。
DB Schemeをコードで管理している必要性(言語・フォーマット問わず)
必要なライブラリをコードで管理している必要性
PHP言語やサーバのバージョンなど実行環境をコードで管理している必要性

………まず、PaaSについて、念のために再確認。
あぁうん、wikiがやっぱり、なんだかんだ、そつの無い説明してるんでそこを引用*2


http://ja.wikipedia.org/wiki/Platform_as_a_Service

PaaS(Platform as a Service の略、パースまたはパーズ)とは、インターネットを利用したコンピュータの新しい利用形態の1つである。
PaaSでは、ソフトウェアを構築および稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供する。開発者は、プラットフォーム上で構築したサービスを自分の顧客に提供することができる。 具体的には、インフラ、DBMSユーザインタフェースなどのシステム開発手段となるツールや、開発したシステムを運用するための環境をインターネットを通じて「サービス」として提供し、月額使用料などの形で収入を得る事業モデルである。


多分これだと思うんだよなぁ、を前提に。


で。

この根拠は、PHPがほかの言語に比べてPaaSで動きにくい、というのを根拠にしています。PaaSで動くためには、少なくても下記の条件を満たしている必要があります。

文章の前半が「動きにくい」に対して、文章の後半では「PaaSで動くための必要条件の列挙をする」と述べているあたりで、相変わらず破綻が物凄い感じです。
一端、ここは「動かしやすくするためには、以下の条件を満たしている必要が」と書きたいんだろうなぁ、と、ここもまた妄想力を全力で働かせてみましょう。


で、次。

DB Schemeをコードで管理している必要性(言語・フォーマット問わず)
必要なライブラリをコードで管理している必要性
PHP言語やサーバのバージョンなど実行環境をコードで管理している必要性

………どうしようすでに突っ込む角度が多すぎてどこから手を出したモノやら orz
迷ったときは、正面から順序よく。


まず「上述の3つがあるとPaaSで動かしやすい」については、とりあえず「何を基準にして、易い難いを考えるか」があまりにも不明瞭に過ぎるので、一端、オミットします。
ここの議論展開は面白いところではあるんですが、ここで字数を増やすと多分、文字数が爆裂するって、そう魂が囁いてるもんで orz


次。

DB Schemeはデータベースのテーブルやカラムをソースコードの変更に追従できるようソースコードで定義しておくものです。多くのPHPフレームワークではDBのスキーマ管理は標準ではありません。たとえば、Rubyではもう4年も前から標準です。いまだに本番環境のDBやエクセルwを見ないとわからなかったりすることもあたりまえです。

「DB Schemeはデータベースのテーブルやカラムをソースコードの変更に追従できるようソースコードで定義しておくものです」………何を言いたいのかが今ひとつ。
恐らく「DRYの考え方に従って、変更の発生を1箇所に絞るってんで、ンならソースコードに書いときゃいいんぢゃね?」的発想なのであろう、と、ここでは妄想します。それならまぁわかるんで。
最も「ソースコードなの?」って所には疑問が残りますが、ンな細かいところを気にしていると文字数が以下略。

多くのPHPフレームワークではDBのスキーマ管理は標準ではありません。たとえば、Rubyではもう4年も前から標準です。

…まずは妄想力を使って、文章を以下のように書き換えます。

多くのPHPフレームワークではDBのスキーマ管理は標準ではありません。たとえば、Rubyフレームワークではもう4年も前から標準です。

一応念のため。上述は「スキーマ管理の機能って、大抵フレームワークが持ってるよねぇRubyでも検索すると出てくるのはRoRであってRubyではないし」ってあたりで妄想していますが、もし「Rubyっていう言語の言語機能として持っている」って話であれば、コメントで突っ込んで下さいませ。


んで、さらに。フレームワークとは「Webアプリケーションフレームワークである」と、ここもまた脳内補完をしておきましょう。「フレームワーク」だけだと、ちょいと、広すぎるんでね。
………もうちょっと、っつうかもういっぱい「自分の書いた文章、最低限の推敲くらいはしようよ」とか思うんですがね。
おいといて。


以上を前提に。
「多くのPHPフレームワークではDBのスキーマ管理は標準ではありません」そなの?
どっちかってぇと、ORMとかと絡んで、うざいくらい標準になってると思うけど? っつか、その辺言及するんなら、最低限「このように調べてこのような結果が出たので、標準ではないと考えられます」程度のエビデンスは出さなきゃ。
おいちゃんは別にどっちでもいいと思ってるし面倒だから大して調べないけど。
少なくとも、symfonycakePHP、Yii、CodeIgniter、FuelPHPあたりでは、普通に存在しているように見受けられるんだけど、どうなんだろ?
symfonycakePHP、Yii、CodeIgniter、FuelPHPあたりでは、普通に存在していて」なおかつ「標準ではない」場合、標準の基準、ってのを知りたいなおいちゃんは。


ちなみにMagicWeaponではあんまりサポートしていない感じ。その辺は「開発の仕方」とも絡む部分があるので…まぁどこかで、その辺は語れるといいなぁ、っと。
ごっつおおざっぱに吐くと「通常、dbinfo、と呼ばれるところで、DDL及び最低限のDMLを、生のSQLで管理している」ので。バージョンについては色々あるんだけど、個人的には「そこあんまりリッチに柔軟にしすぎても、かえって複雑化するしねぇ」ってなスタンスなので、現状、あんまり複雑で便利な機能は入れる想定してないです。


閑話休題


なので

多くのPHPフレームワークではDBのスキーマ管理は標準ではありません。たとえば、Rubyではもう4年も前から標準です。

については、妄想力を最大限使って補完して好意的に解釈してなお「標準的ではない」という発言に、山盛りで疑問が残ります。


次。

いまだに本番環境のDBやエクセルwを見ないとわからなかったりすることもあたりまえです。

場所に拠るよねぇ、としか。
かつ「何を以て当たり前とするのか、またそのエビデンス」など、恒例行事のごとき「エビデンスのなさ」は、ここでもしっかりと生きています。


ちなみに「エクセル」ではなく「エクセルw」と、wがついてるのは、なんなんですかね?
いや個人的には「DBスキーマの管理、もうちょっとバージョン管理ソフトで扱いやすいようにテキストフォーマットで」とか思うほうではありますが、とはいえお客様への提出物の一貫としての「表形式での可視性の良いもの」自体はそれなりに意味のあるものなのですが、その辺ってどうしてらっしゃるんですかねぇ?


次。

PHPはライブラリをComposerといったツールを使えばライブラリ管理出来ますが、これが標準になっているフレームワークはまだメジャーではありません。CakePHPもまだ標準搭載とまでは言えません。RubyでいうGemfileやRubyGemsみたいなものはまだ文化としてはないのです。いまだにみんなドキュメントに使うライブラリを書いたり、そもそもライブラリを使わなかったりするのです。

………これって「必要なライブラリをコードで管理している必要性」にかかるかと思うのですが………何を言いたいのかが、さすがに不明。
「コード」は、恐らく「プログラムコード」であろうかと思われるのですが。ここから想起される可能性は、以下の2つ。
・バイナリコードではなくて、プログラムコード、という意味合い
・「どんなライブラリを用いたいのか」の指示がプログラムコード内に書いてある、という意味合い
後者はさらに2つに分かれて
・いわゆる「ライブラリ名」の類いが書かれていること
・ライブラリの「要求したい、必要バージョン」が書かれていること
に分かれる。


で…検証資料がないので、一端先に進めてみて。
相変わらず「出来るか出来ないか」が論点なのか「やりやすいのかやりにくいのか」が論点なのか「出来る環境がメジャーなのかマイナーなのか」が論点なのか、論旨がぐちゃんぐちゃんではあるのですが、そこも一端放置して。

PHPはライブラリをComposerといったツールを使えばライブラリ管理出来ますが、これが標準になっているフレームワークはまだメジャーではありません。

メジャーの定義が不明なので何とも。

CakePHPもまだ標準搭載とまでは言えません。

「何が欠落していて」「どのような状態になったら標準掲載と言えて」ってあたりが一通り不明なので、何とも。
「あるかないか」だと、あるよね?
ついでに「フレームワークでメジャーになっていないとダメなの?」っていう突っ込みもまたあって、その辺から「フレームワークに使われ、振り回されてるんじゃない?」っていう、低レベル技術者に特有な現象への懸念が心配もされたりするところではあります。

RubyでいうGemfileやRubyGemsみたいなものはまだ文化としてはないのです。

これは明確に誤り。
文化は存在していて(ない、ってんなら、Composerはなんなの?って話になる)。
ここは好意的に妄想補完するとしても

RubyでいうGemfileやRubyGemsみたいなものはまだ文化としてはメジャーではないのです。

が限界で、それにしてもなお「本当にメジャーではないの?」っていう突っ込みがある。


で…

いまだにみんなドキュメントに使うライブラリを書いたり、そもそもライブラリを使わなかったりするのです。

「ライブラリ」の語彙にもよるけど、「全く使わない」は、昨今ではかなりレアケースかと。
また「使うライブラリ」であれば、ドキュメントに書かなくてもプログラム見りゃわかるわけだしっつかなんのためのinclude文よrequire文よ。
次に「バージョン依存」の場合、状況にもよるんだけどどちらかというと「ンなにバージョン依存したコード書いて楽しい?」っていう疑問符が先に出てくる感じだ。


次。

多くの言語では言語のバージョン指定などをどこかにコードとして記述します。RubyならGemfileだったり、.ruby-versionだったり。PHPはそんなことはないのです。

「多くの言語」って具体的にはどれ?

まぁ色々な見解があるけど、一つの見方として「そんな細かいバージョン依存するとか、どんだけイケてない、計画性のない、未完成な言語なの?」って突っ込みもまたあることを念頭に置いておかなきゃいけないと、おいちゃんは思う。
勿論色々あるから「完全な互換性」とか言う気もやる気もないけど、とはいえ「メンテナンスバージョンに依存する」ってのはさすがにイケてないので、その辺のバランス感覚とかもあろうかと思うし。
ついでに「言語のバージョン指定などをどこかにコードとして記述」は、別にPHPでも可能。
単純に「さほど必要とされていない」から書かない人が多いだけじゃない?


まぁ確かに最近「モダンPHP」とかって流れで「古いバージョンのPHP、または"新しく出来た言語仕様"の存在の有無に起因する問題」は色々と抱えてたりもするけど、その辺はそれこそ「どこの言語に行ったって」出てくるお話で、それは大抵、各言語ごとに折り合いを付けていってるんじゃないかなぁ? と思う。

この3点から導き出される結論は、「ソフトウェアを動かすのに必要な情報をコードに書く文化がない」ということです。つまり、PHPおよびPHPerはコードを書くのが嫌いということです。

「ソフトウェアを動かすのに必要な情報をコードに書く文化がない」と「コードを書くのが嫌い」との間には、ちょっと戸惑うくらいの隔たりがあることに、こーゆー書き方をしているってことは多分気づいてないんだろうなぁ、っと。
ちなみにおいちゃん的には。
・「設定ファイル」はコードに含まれますか?
・そんなに「厳密かつ限定環境下でしか動かない」狭いコード書いてて楽しいですか?
の2点くらいかな。疑問点は。

(コピペコードを書くのは好きかもしれませんね\(^o^)/

ん…「コピペコードを書く人が多い」って意味合いでは今ひとつ否定はしにくいんだけど、一つ質問。
「じゃぁ他の言語の人は皆ちゃんとコピペをせずに書いてる?」
この辺でも、見識の甘さというか論理組み立ての出来てなさというか文章力の欠落というか、が、見て取れてみたり。

PHPerは実はHTMLに毛が生えた程度しか使えない人が多い

まず「PHPerの定義」ってのもあるしなぁ、っていうのはあるけど。
それ以外にも定義が曖昧過ぎて、是とも非とも。

PHP入門」って書いてある本、本屋さんでよく見かけますよね?Amazonでも。でもあれ、ほとんど「PHP言語」について書いてありませんよね。PHPでウェブサイトを作ることを目的としていて、1/3ぐらいしかPHP言語の仕様に触れてませんよね。

単純に「目的」が違うだけだと思うなぁ。
PHP言語、について書かれている書籍」が欲しいんなら、オライリー本辺りを買えばいいわけだし。
んと…「選択肢が広いのと狭いのと、どっちがいいですか?」って突っ込み。
或いは「へぇ。Rubyって選択肢が狭いんですねぇ」ってほうがいいのかしらん?
もう一つ「1/3ぐらいしかPHP言語の仕様に触れてませんよね」ん、そんなに触れてないと思う。っつか、それなりの厚みの書籍の「1/3以上を、言語仕様の説明そのもの」に費やすって、どんだけ面倒な仕様よ?

なのに、PHPWindowsPHPをインストールするGUIインストーラスクリーンショットから始まり、HTMLとCSSPHPを使って現在時刻を表示とかメールを送信、あたりで終わったりしますよね。

これ、興味深いなぁ。
WindowsPHPをインストールして(ってことは多分XAMPPだよねぇ)」「メールを送信」( ゚A゚)〃∩ ヘェーヘェーヘェー
知ってる限りの入門書で、メールなんて鬼門扱ってるの見たことないなぁ。おいちゃんも今、PHPの入門書は手を出しておりますが、そこでも避けました。
なんでかってぇと簡単で「デフォルトでは、WindowsOSの、特にクライアント系は、SMTPdを持っていない」「ネットのお外に出る必要がある場合が多く、その辺の設定とかが色々と面倒にすぎる」「特に気軽に試してみたい"フリーアドレス系"や"携帯アドレス系"は、現在とてもお堅い状態なので、SMTPそのもののお作法をある程度把握していないといけないために、入門からはかけ離れた内容になるために、入門書で手が出せるレベルじゃない」等の理由から。
文章を拝見している限り「それなりの数の入門書をチェックしてみたけど」って感じですが、どの入門書に「メールの送信の仕方」が載ってるのか、聞いてみたい感じ〜。

あれでみんなPHPを勉強していると思うと。。。そして、そういう人でもまぁWordPressで仕事したり、普通にサイト作るお仕事ぐらいできたりすると考えると、「PHPerは実はHTMLに毛が生えた程度しか使えない人が多い」んじゃないかと思っちゃいますよね。

「可能であること」と「●●な人が多い」との間にある、見事な繋がらない感を無理矢理つなげている文章に、ある種の可能性をすら感じます B-p
あとついでに。
PHPが書ける」では「普通にサイト作る」は出来ません念のため。
…まぁ「普通にサイト作る」が何を意味しているのか、にも拠るんでしょうがね。

もう4年も前の本ですか、パーフェクトPHP。。。新版が出てないのがつらい。みんなPHP言語自体には興味ないのでは。。。?

日本語訳に限った状態にしてから…


発売日: 2013/8/21

初めてのPHP、MySQL、JavaScript&CSS 第2版

初めてのPHP、MySQL、JavaScript&CSS 第2版


発売日: 2012/9/24

初めてのPHP5 増補改訂版

初めてのPHP5 増補改訂版


発売日: 2014/3/25

プログラミングPHP 第3版

プログラミングPHP 第3版


とかありますし。PHP関連書籍とかだと、最近出たのも山ほどあって面倒だから書きませんが、ってくらいある、っていうエビデンスを前提に。

もう4年も前の本ですか、パーフェクトPHP。。。新版が出てないのがつらい。みんなPHP言語自体には興味ないのでは。。。?

何を以て、この文章の正当性が僅かでもある、とか思うんでしょうかねぇ?

PHPは低級プログラマと過去の負債に引きずられる

あぁ…否定はしない。
おいちゃんも、害意と殺意と滅意に満ちあふれる瞬間とか、山盛りあるから。
じゃぁ質問「PHP以外のプログラミング言語は、低級プログラマと過去の負債に引きずられてないの?」ん…およその現場とか、ちゃんと、見たことある?

結局、人間は人と人のつながりで生きてます。「えー、言語仕様変わるのー、やだー」「え、急に私のプログラム、新しいサーバで動かなくなったんだけど、どうすればいいわけ!?」「PHPの書き方はずっとこうだったんだよ!もう何年も前からこうやって書いてるんだ。間違いなはずないだろ!」みたいな、人たちがいるプログラミング言語は、そういう人たちにどうしても引っ張られます。そういう人たちが多ければ多いほど、そういう人たち向けにフレームワークなども作られます。
もしそういう人たちを置いて行ったら、それはもう、PHPではなくなってしまうわけです。100人を犠牲にして10人が便利になる、ぐらいなら10人に留まってもらうのがPHPの世界だと思うのです。

んと…「もしそういう人たちを置いて行ったら、それはもう、PHPではなくなってしまうわけです」なんで?
どのような条件を満たされたら「PHPではなくなる」で、それはどのような状態を指し示しますか?


もうちょっと細かく突っ込みを。

「えー、言語仕様変わるのー、やだー」

どのレベルか、にも拠るけど「言語仕様が変わる」のは、どの言語でも一緒で。悲鳴を上げてる層ってのも一定数居て、それにあらがっている層もまた一定数居て。
「やだ」の後にどうするか、ってのにも拠るし、そんな人達を「擁護する」のか「切り捨てるのか」も、言語とは関係ないところにあると、基本的には思う。
で、おいちゃんは現在「最もよく使ってる言語」がPHPだけど(じゃぁおいちゃんは果たしてPHPerなのか? については、議論が分かれるので一端放置)、上述のような発言を、おいちゃんが仕切る現場でやると、馘首されること請け合いです B-p

「え、急に私のプログラム、新しいサーバで動かなくなったんだけど、どうすればいいわけ!?」

言語の問題じゃなくて管理手法の問題でしょ?
まぁ「その管理手法を言語が取り込んでる」ってのをメリットとして発言したいんだと思うんだけど、でもそれって「他の場所でも可能」だから、「唯一無二のメリット」ではないよね?
あと、もし「daemon依存」とか、その辺の「現在提供されている管理手法の想定外での問題」の場合、どうなるんだろうねぇ? とか思う。

PHPの書き方はずっとこうだったんだよ!もう何年も前からこうやって書いてるんだ。間違いなはずないだろ!」

居るけど、それって他の言語でも居るよね?

みたいな、人たちがいるプログラミング言語は、そういう人たちにどうしても引っ張られます。そういう人たちが多ければ多いほど、そういう人たち向けにフレームワークなども作られます。

あちこちで見るねぇ…それはどの言語にしても。


なので。
勿論、問題定義のいくつかは、文章がまともで論理構成力がもうちょっと上がってきちんとしたエビデンスやら何やらがある状態であれば、という前提付きではあるにしても「興味深い」とは思うのですが。
ただ、コンだけ抜けまくって呆けまくった文章で

さぁ、「cakephpを窓から投げ捨ててrailsを採用」しましょう!

とか言われても…えと…まず「じゃぁPHPの他のフレームワークは?」とか出てくる訳ですし、そも「Rubyで、他のフレームワークを使ってるけど駄目なんですか?」とかって突っ込みもあり得るし勿論「やはりJavaが」「時代はC++なのです!」「やはりC#」「最先端はScalaです!」「Pythonを忘れてはなりませぬ!」「LISPが基本に決まっておる!」「Brainfuck最狂*3」「Goで決まりだろ!」なんていう各方面の発言も当然あり得るわけで。


勿論諸々を考えた上で*4「どの言語がよりよいか?」を分析するのは、それはそれで楽しいのですが。
ここまで「一通りと言っていいくらいに駄目なものを積み重ねまくった」上で「PHP駄目! ゼッタイ! Ruby最強!」とか言われると「…あぁ駄目な人がよいと言っているRubyって言語は、よっぽど駄目な人達の巣窟なんじゃなかろうか?*5」とか、むしろ色々と逆効果なような気もするんですが、どんなもんなんですかねぇ?


論調が全体的に「まずPHPerをdisりたい」という結論に対して前提を貼り付けているだけのような内容で、考察に検証も反証もなにもないので。
論理構成としては、最低、のレベルに質が悪いなぁ、と思われます。


んで。
記事って「書かれた文脈」を見るので、見てみるのですが。

株式会社アクトキャットのCEOのブログです

はぁそうでっか。
どんな会社なんでっしゃろ?


http://www.actcat.co.jp/


………
プロダクトの1つに「StudyTech」ってあるのですが…「PHP, Ruby, iOSでアプリ・ウェブサービスを作れる学習サイトです。」だそうな。
PHP(或いはPHPer)をdisってるSEOが作る」「PHPでアプリ・ウェブサービスを作れる学習サイト」…なんの冗談でしょうかね?


個人的には「スマートフォン向けアドエクスチェンジ事業「SmAdd」などもリリース。」この辺に興味がありますねぇ。
Ad系は、色々と「駄目でだめでダメ」な状況をよく見かけるので。


まぁ…うん、何となく突っ込んでみようかと気軽に考えて突っ込んでみたら思ったより基本的なところがダメ過ぎて、ちょっとびっくりだw


きっと「エンジニアCEO」ってくらいだから、えんぢにありんぐ、には色々とお詳しくていらっしゃろうかと思うので。
是非、おいちゃんと線が交わらないところで、健やかに伸びやかに、ご健勝にしてますますのご繁栄のほどお祈り申し上げます。


以上現場からのレポートでした。


追記
…こんなので「Rubyistって、技術力低くて論理構成力がなくてプライドだけ肥大したヤツが多いんだ」とか思われるとそれはそれで大変そうだなぁ、っと。
何名か、くらいはRubyistさんを存じ上げてますが、おいちゃんの観測範囲内では「普通に技術に対して真摯だし、だからこそ相手に対しても真摯な人(ただし問題に対しては苛烈な人)が多い」です、と、別段フォローする言われもありませんが、一応、書いておきます。

*1: http://d.hatena.ne.jp/badatmath/20101020/1287587240

*2:陰陽ってまて俺のFEPどーゆー学習してやがるw

*3:マテコラどさくさに紛れてなに突っ込んでやがる

*4:ここで一つアドバイス。「お仕事で」扱う場合、案件数の多さなども、考慮用の1変数としては考察対象にしておきましょう

*5:念のために書いて置くと、ンなこたぁないです。真っ当な人達もたくさんいます。言語としても、とても面白いですし。扱いに注意すべき言語、でもありますが