Perl厨マジきめぇｗｗｗｗ

時代はＰＨＰだろ
いつまでPerlなんて使ってるんだよ化石乙ｗｗｗｗｗｗ

HTML厨>Java厨>Python厨>Ruby厨>PHP厨>Perl厨>C++厨>C厨>Java厨
厨たちの自己評価

Web技術ごときで　時代は　とか　言ってる奴
激しくだっせー！！！ｗｗｗｗｗ

web如きなら、PHP+MySQLで決まりじゃないか。
中規模案件なら無敵だよ。

PHP+SQLiteでじゅうぶんすぎ

>>1
ひつじ？

まぁ、最強はアセンブラでいいです

きめぇとかいう何語だか分からん物使ってる時点で>>1は馬鹿

>>33

ヽ( ・∀・)ﾉ●ｳﾝｺｰ

JAVA+JavaServletPages+JDBC+MySQL+Tomcat+Eclipse Pleiades+Feedraが最強。

Perl書いてて思うけど自分の書いたソースは見るのは良いけど人の書いたPerlは見たくない。

RubyやJavaだとそう思わないから不思議。

CPANのライブラリ使おうと思ったら、ソース読まざるを得ない。

>>37
ひどいソースしか見た事ないんじゃない？
モダンな Perl はきれいなソース多いと思うけど。
（一部モジュールはのぞく）

モダンなPerlソースは、
中途半端なオブジェクト指向で
さらに醜い。

愛され憎まれてんだなぁPerlは♪

CPANのメジャーなモジュールは、そもそも開発者のスキルが高いからな。

ラクダ本を読んでる人と読んでない人のソースは対照的になる傾向にある。
読んでる人のソースは綺麗なソース
読んでない人のソースは酷いソース

結論はぺヤング最強

少し前に本なんて読まなくてもネットで調べれる時代って言いながら
書いたらしい動作しないスクリプトをだ

原因調べて直してくれって言われて見てみた事はあるが、、、酷すぎだったorz

全部コピペでソースはぐちゃぐちゃ、動かない原因？全てだろ。
いらいたくもない、みたくもない、かかわりたくもない。

本読んで勉強しろよと言いたかったけど
相手がお客様でして。。。そんな事言える訳も無く

一から書いて渡したら｢どこのページにソースあったの？｣って言われて
一から書いた旨を伝え去ろうとしたら｢どこのページみたらわかる？｣って聞いてきたので

次の日に相手のデスクに無言で家から持ってきたラクダ本二冊置いた、経験はある。

Perl厨は性格が悪い、根暗、藁人形とかしてそう

PHP厨は頭が悪い、イカ臭い、肛門オナニーとかしてそう

てかperlわからないからPHPでええやん。perlに比べてPHPってすげー簡単だし。
perlわかる奴はPHPテキトーに利用しつつperl使ってりゃええやん。

まぁ難易度は
perl＞＞＞＞PHPだろうな。
てゆーかPHPってHTMLやjavascryptとたいして変わらん

化石の意味を勘違いしてるな

Perl厨はキモイが、なぜPHPが出てくるのかがわからん

まあ俺はc一筋だけどな。パールとかあたらしいのは好かんよ

PHP厨のほうがきめえよwwwwwwwwwwwwwwwwwwww
クソスレたてんじゃねえよかす？な？PHPのゴミがほざいてんじゃねえよwwwwww
頭が悪いのはてめえだろごみwwwwクソススレしめろよはやくwwwwwwwwww

PHPとかやってるやつてクソガキしかいないし　Windowsばっかりつかってるやつらでむかつくんだよね
頭崩壊してんじゃね？ばかだしwwwwwwwwwww
PHPとかやってるwebデザイナーとかもほんとごみwwwwwwwwwwwwwwwwwwwwww
PHP＝HTMLと同等でいいよごみだからwwwwwwww

俺はプログラミングやってないからわからないけど　perlとかごみだしなwwwww
perlのオブジェクト指向とかクソすぎwwwwwwwwww　本とゴミwwwwwww　オブジェクト指向にしなくてもいいのに
真似ばっかりしちゃってwwwwwwwwごみすぎるよ

俺は仕事ではJava、趣味でPerlとPHPをやってる。
暇になったらRubyとHaskellやりたいんだが。

中２病「やれば？」

御前自己紹介うざいよ？？？？消えろ！！

haskellやってどうすんの？名前がハッキングみたいでかっこいからやんだろバカじゃねえのこいちwwwww
頭湧いてんの？wwwwwhaskellがunkoって名前だったらやらねえんだろばかがしんどけwwwwww

バカ発見晒しage

未だに、perlでシコシコがんばっているエンジニアの
殆どは４０代以上の人間ばっかり。

適材適所で選べば、Web開発に適した言語は、少なくともPerlではないという
結論に達するのが普通で、未だにPerlでWeb開発してる人間は、ハッキリって
世の中の新陳代謝の邪魔をしている不要な人間であることがほとんど。

「自分が好きな言語はなにか」ということと、「Web開発に最適な言語はなんなのか」ということを
分けて考えることが出来ないエンジニアは即効で、この業界から引退すべき。

Perl厨＝お年寄り　が、この業界に居座ることで、この業界の新陳代謝が阻害されている
事実は、本当に深刻な事態だ。

なぜ、日本ではgoogleのような企業が生まれないのか。
その解決方法の一つとして、まず、Perl厨のようなお年寄りは、さっさと
この業界から去るべきだと思う。

大切なことなので、もう一度言います。

「自分が好きな言語」と「Web開発において、最適な言語」は分けて考えるべきです。
分けて考えることが出来ないPerl厨は老害以外のなにものでもない。

日本のPerl厨のみなさん、ちゃんと理解できましたか？
これが、常に上を目指すWebエンジニア達の本当の意見なのです。
目をそらさないでください。

#もちろん、perlがなければ、UNIX系のOS自体、成り立たないだろうという
#話とは全くの別次元です。あくまでもWeb開発における話ですので、がっかりしないでください。

Perlのどこらへんが適していないのか具体例を挙げてください

>>56
標準ライブラリと言えるものがcpanモジュールなのだが、
その作者がばらばらでモジュールの品質が安定しない。

人によっては互換性をなくすような修正をするから
環境、つまりOSを変えたりバージョンを上げたりで
アプリが動かなくなったりする。

この点Javaなんかは最強。
Windowsで動くものがそのまま
Linuxで動いたりする。

サードパーティ製モジュールに品質や後方互換を求めること自体ナンセンス。
アーキテクチャ依存の言語をインラインすればOS間の互換問題は当然発生するわけで
自分で自制出来ないんならお母さんにオムツつけてもうしかないな。

> サードパーティ製モジュールに品質や後方互換を求めること自体ナンセンス。

サードパーティ製モジュール を使うことが
事実上の標準になっているPerl涙目だなｗ

開発元が提供するのはコンパイラ、VMでモジュールなんかは必要最低限ってのが標準だろ。
コアであれこれ介護してくれるのはPHPぐらい。

>>60
Javaの話をすればいい？
C++標準ライブラリの話？
.NETフレームワーク？

いずれにしても企業、もしくはそれなり大きさの
コミュニティでみんなで話しあって決めるのが普通

個人開発者が気まぐれで仕様変更されようなものを
今度のバージョンから標準バンドルしました。
なんて世界じゃないんだよ。

> いずれにしても企業、もしくはそれなり大きさの
> コミュニティでみんなで話しあって決めるのが普通
Perlがそうではないと？

>>62
はい、そのとおりです。

Perlでライブラリを使おうと思ったとき
cpanで探すのが常識ですが、そのcpanには
一般の人が簡単にアップロードができます。

そして恐ろしいことにPerlの標準モジュールとは
このcpanから任意のバージョンをチョイスしてきて
いるだけなのです。

コミュニティで議論されず個人開発者が気まぐれで仕様変更されようなものを
無作為に任意のバーションをチョイスしてPerlに標準バンドルされるってことか。
Perl終わってるな

例えばこんなのがPerlの世界
http://gihyo.jp/dev/serial/01/modern-perl/0015
ただし，Cから継承してきたlocaltime()やgmtime()の返り値は，お世辞にもわかりやすいとはいえません。

1996年11月には，Class::Struct（当時はClass::Templateと呼ばれていました）をベースにしたTime::tmと，
それを利用したTime::localtime，Time::gmtimeがそれぞれPerlのコアに導入されました（Perl 5.003_11以降）。

このメールに反応して生まれたのが（2000年3月のリリース当初はTime::Objectと呼ばれていた）
現在のTime::Pieceでした。このTime::Pieceは，ラリーの仕様を実装したという事情もあり，
2001年4月に一度はPerl 5.8系列（正確にはその開発版である5.7系列）のコアに入ります

ところが，それと相前後するように第二の日時モジュールブームが起こり，2001年の4月から7月にかけて，
Date::Handler, Date::ICal, Class::Date, Date::Simpleといったモジュールが立て続けにリリースされたため，

このような議論はDate::Calc，Date::Manip，Date::Parseといったモジュールが
次々にリリースされた1995／1996年の時点ですでにあったのですが，

血統的には最も標準に近い位置にあったTime::Pieceでさえ
「論争中の名前空間における一実装に過ぎない」という理由でコアから削除されてしまいます

そのような混乱にいちおうの終止符を打ったのが，デイヴ・ロルスキー（Dave Rolsky）氏が
2003年初頭に始めたDateTimeプロジェクトでした。

長らく待ち望まれてきた共通APIへの反応はおおむね好意的なものでした。2003年だけで19人の
作者が50個の関連モジュールをリリースしていますし，

ただし，DateTimeモジュール群にも泣き所がないわけではありません
モジュール群の大きさやタイムゾーン・データベースの更新頻度などの都合もあって
Perlのコアモジュールにはしづらいというのも悩みの種でした。

その隙間を埋める試みとしては，まずアダム・ケネディ（Adam Kennedy）氏が2006年の
8月末から9月頭にかけてリリースしたDate::TinyとTime::Tinyという2つの::Tinyモジュールがあげられます。

これはログファイルの処理など，複雑な計算は必要ない用途向けにコアを軽量化し，
必要があれば本家のDateTimeに処理を委譲しようというものだったのですが，
氏が提唱した::Tinyというカテゴリーそのものに対する疑問や，それぞれ日付のみ，
時刻のみしか扱えないという大きな制約などから，多くの関心を集めるには至りませんでした。

同時期に起こったより重要な出来事としては，一度はコアから外れたTime::Pieceが，
2006年11月にふたたびPerl 5.9／5.10系列のコアに入ったことがあげられます。

また，ごく最近の例としては牧大輔氏によるDateTimeX::Liteの例をあげることもできます。

ほらな、個人がばらばらで作って、どや、どや、どや、ばかりやってる。
気が向いたら標準モジュールにピックアップして嫌なら消す。

方向性がバラバラで無秩序でなんだよ
標準モジュールとして採用されても、モジュールの開発は
Perl本体とは別に進んでいる。だからPerlそのものが信用できない状態。

Time::Pieceは一時開発版でコアに入れたけど直近の正式版5.8では見送られ5.10〜最新版までは
標準モジュールとなっている。

> Cから継承してきたlocaltime()やgmtime()の返り値は，お世辞にもわかりやすいとはいえません。

モジュールにしたからといって分かりやすくなるわけではない

use constant One => 1;
use constant Two => 2;
use constant Three => 3;
↑分かりやすくならないYo!!
無駄なドキュメントが増えてしまうだけ

良識のあるマは軽くスルーしている

>>68
お前なんの話してるの？
バカじゃないの？

C言語由来なんだから、資料も豊富だし
使い方のノウハウも蓄積されている

そこをあえて新しいインタフェースにする
必要がない

と、読み下してあげましたよっと

だとしたら大きな勘違いだなｗ

C言語由来だからといって、使いやすいわけじゃないし、
（むしろC言語は使いにくいからPerlを使うんだろ）

資料が豊富だからといって、使いにくいものが使いやすくなるわけじゃないし、
使い方のノウハウが溜まったからと言って、使いにくいことに変わりはない。

新しいインターフェースを作ってから、理由を考えるわけじゃない。
理由があったから、新しいインターフェースができた。

理由がないことをわかっていて、新しいインターフェースを作るなどという
馬鹿げた例（>>68）は出発地点（作る理由がある、かたや理由がない）が
正反対なので全く当てはまらない。

お前が分かりやすいものを書いて自己満足することに
だれも反対しないけどな

使いやすいかどうかを他人に押し付けんなってことだ

Perl忍者呼んじゃうぞ

localtimeもろくに使えずにCPANモジュール使うなんざ
15才が魔女なんです。

せやろか

...という議論の末、結局localtimeに落ち着きました。

誰でも簡単にネットで稼げる方法など
参考までに、
⇒　『半藤のブブイウイウレレ』 というサイトで見ることができます。

グーグル検索⇒『半藤のブブイウイウレレ』

3KXHM290JF

(ﾟДﾟ)ﾊｧ?

この中に、お医者様はいらっしゃいませんか？