アカウント名:
パスワード:
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
他人のコードを読むスキルには、かなり高度なものが必要だと思います。
＃ビール片手に一ヶ月前に書いた自分のコードは(ry
もう、この手のはFUD扱いしても良いんじゃないかな。
・TMTOWTDI (There's More Than One Way To Do It.) で書き方が多彩・暗号のような正規表現が頻出・$,@,%等の変数接頭辞
あたりが挙げられるけれど、別にそれは欠点ではないし(変数接頭辞はむしろ読みやすい)・純粋なオブジェクト指向ではないとか、殆ど言いがかり
・そもそもPerlの基礎知識が足りない・そのソースの書き方が汚い
という本質的な理由を、Perlのせいにしてるのが殆どじゃないの？
なんて指摘するとヒステリー起こす人がいるんだけど別にPerlに慣れてないのは恥ずかしい事じゃないわけで、使い込んでみたら意外と良い物だよ。
Perlはゴミ言語、そう思っていた時期が私にもありました。今ではガラクタ出力機だと思って愛用してます。
今ではガラクタ出力機だと思って愛用してます。
"ガラクタ出力機"ってのは本当にぴったりだなぁ。もちろん良い意味で。
あとはtkとかGDとかイメージマジック使わずに簡単なGUIが作れてグラフ作図や図形描画ができれば最高のがらくたメーカーなんだがなぁ。マルチプラットホームだし。
それなりに一通りの言語触ってきてそれぞれ向き不向きがあるのは分かるけど、とりあえずちょっとしたアイディアとかを試す時の楽さでいえばPerlが一番楽ちんだなぁ。言語のポリシーにもブレがなくていい。
アバウトにアバウトなプログラムが書けてアバウトに動かしても"きちんと"アバウトに動く、そんな感じ。もちろんキッチリとキッチリとしたコードを書いてキッチリと動かすこともできる。ラリーウォールの言語仕様に対するバランス感覚が天才的なんだと思う。ラクダ本を読むと特に。
# と、M1中だがあえてコメント
＞あとはtkとかGDとかイメージマジック使わずに簡単なGUIが作れてグラフ作図や図形描画ができれば最高のがらくたメーカーなんだがなぁ。マルチプラットホームだし。
この時代、GUI が必要ならウェブシステムにしちゃえばいいんですよ。
最近は、グダグダなPerlもありかなと思うようになりました。
Perlって元々行儀の良い言語じゃなくて、生まれも育ちも悪い。それでも熱い魂は持っている、Punkな言語なんですよね。
おバカなプログラマであっても、只のノイズにしか見えないコードしか書けなくても、快く受け入れてくれる。教科書に書かれたようなコードより、勢いのある熱いコードが似合う。そんな言語だと思うようになりました。
# 変態技巧を凝らしたコードも好きですけど！
>ほぼ並の人が解析できる量を、遙かに超えた自由度をもつ構文で、>必要とあらば使ってはいけないと言われる機能を自由に使う事ができ、
近年のPerlのVersion間の差が大きく、違う言語と思えるぐらい差があるにもかかわらず、完全な後方互換を有しているためでないでしょうか。
例:Perl4とPerl5は、CとC++とぐらいの違いがあるのに、Perl4の構文でPerl5を使うことができる例:Perl6では、文法がだいぶかわったのに、use v6;としないかぎり、従来と同じ構文で使うことができる
つまり、言語仕様が過去からの遺産を引きずってごっちゃなので、ソースコードもごっちゃになってしまいがちだと思います。
誰もそうなってる理由なんか聞いてないんだが。わかったところで何ら問題の解決にならない。
正規表現については言い掛かりだと思うけど、（正規表現で処理したいからするのであって、嫌なら別の方法で処理すればいい）「書き方が多彩」がある意味で欠点とされるのは仕方無いと思いますよ。特に、ビジネスでは、
個人でちょこちょこやるにはこんな気軽な環境は無いけど、仕事なら相応のフレームワークを加えた方がいいんじゃないかと、
「そのソースの書き方が汚い」についても、フレームワーク導入で解決すべき事だと思うな。自分のスタイルでないソースは読み難くて汚く感じるもんだよ。で、それが「書き方が多彩」と言う「欠点」と言われるわけだから、
> 別にPerlに慣れてな
正規表現が無ければ、オートマトンで書けばいいじゃない。
> なんというか、perl擁護派は昔の非構造化BASIC擁護派と同じタイプの主張をしているんだよね。> 欠点は「君が慣れてないから」で片付ける。そんなLispでもEmacsでも、なんにでも当てはまりそうなことで印象操作されてもなあ。
> > 別にPerlに慣れてないのは恥ずかしい事じゃないわけで、> うわっ、凄い上から目線！
そりゃ、ある言語が使える人は、使えない人よりも上でしょ？# どういう基準で上かはよく分からんが
「知らなくても別に良いじゃん」ってのがそんな反応するほど上から目線ですかねぇ
「Rubyワカンネ」「知らなきゃ読めないよ」「Pythonイミフ」「覚えりゃ読めるよ」ってのと同じ話なんだけど、これらも上から目線ですかね
> 「知らなくても別に良いじゃん」ってのがそんな反応するほど上から目線ですかねぇ
「知らなくても別に良いじゃん」って、何処が？
#1546737 [srad.jp]の以下の部分が「上から目線」だと言ってる事は読み取れるよね？
> ・そもそもPerlの基礎知識が足りない> ・そのソースの書き方が汚い>> という本質的な理由を、Perlのせいにしてるのが殆どじゃないの？>> なんて指摘するとヒステリー起こす人がいるんだけど> 別にPerlに慣れてないのは恥ずかしい事じゃないわけで、
Perlに難を示された場合に、『基礎知識が足りない』『書き方が汚い』と返すのが駄目駄目なの。
その前に挙げられていたのは枝葉の話だけど、それらは確かにPerlの特徴として存在するものであって、それぞれに、それが問題にならないようにする解も用意されてるよね？
それらを示して解決に導くのではなく、「そんなの問題ではない」と客観視の出来ない高慢な態度で、（相手が問題視してる部分に「俺は問題だと思わない」と返すのは論外でしょ）「お前の知識や書き方が至らないだけ」と切り捨ててしまって、挙句、『慣れてないのは恥ずかしい事じゃない』等と言う。
違う違う、Perlにはちゃんと解法が用意されてるから。なのに、それを教えられなかっただけでしょ？慣れてなくて上手く教えられないのは恥ずかしい事じゃないけどさ。
そりゃ「Perlは使えねぇな」と言う評価になりますよねぇ。本当は、その場その場で妥当な解決策を提示出来ない、その人に対する評価（このPerler使えねぇな）であるべきなんですけど、その人は「Perlはそーゆーもんだ」と言う態度なので、その周囲ではPerlの評価が下がってしまう。
>・純粋なオブジェクト指向ではない>とか、殆ど言いがかり
いや言いがかりではないでしょう。これもまた事実だけど「別にそれは欠点ではないし」というだけのこと。
ただし「純粋なOOPではないからダメダ」という意見は言いがかりね。ほんとにOOPダケになることが幸せに繋がると思うんだったら、RubyやSmalltalkからBlock(関数リテラル)のような関数型言語由来の機能を削除したらどれくらいラクになる※のか考えてみるといいよ＞OOP原理主義者
※もちろん実際にはマイナスのラクさが得られます。
>そのソースの書き方が汚い
Windowzへの「批判」とパターンが似ていますね。ユーザビリティにせよドライバの問題にせよ「OSが悪いんじゃなく使い方が悪いんだ」という指摘が有りますが、じゃあ「悪い使い方を許しすぎるユルユルな枠組み」は悪くないのか？という話が。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
Perlはもっと評価されていい (スコア:0)
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
Re: (スコア:1, 興味深い)
最近のPerlはそうでもない気がします。
Re: (スコア:2, すばらしい洞察)
他人のコードを読むスキルには、かなり高度なものが必要だと思います。
＃ビール片手に一ヶ月前に書いた自分のコードは(ry
Re:Perlはもっと評価されていい (スコア:0)
もう、この手のはFUD扱いしても良いんじゃないかな。
・TMTOWTDI (There's More Than One Way To Do It.) で書き方が多彩
・暗号のような正規表現が頻出
・$,@,%等の変数接頭辞
あたりが挙げられるけれど、別にそれは欠点ではないし(変数接頭辞はむしろ読みやすい)
・純粋なオブジェクト指向ではない
とか、殆ど言いがかり
・そもそもPerlの基礎知識が足りない
・そのソースの書き方が汚い
という本質的な理由を、Perlのせいにしてるのが殆どじゃないの？
なんて指摘するとヒステリー起こす人がいるんだけど
別にPerlに慣れてないのは恥ずかしい事じゃないわけで、使い込んでみたら意外と良い物だよ。
Perlはゴミ言語、そう思っていた時期が私にもありました。
今ではガラクタ出力機だと思って愛用してます。
Re:Perlはもっと評価されていい (スコア:3, 興味深い)
"ガラクタ出力機"ってのは本当にぴったりだなぁ。もちろん良い意味で。
あとはtkとかGDとかイメージマジック使わずに簡単なGUIが作れてグラフ作図や図形描画ができれば最高のがらくたメーカーなんだがなぁ。マルチプラットホームだし。
それなりに一通りの言語触ってきてそれぞれ向き不向きがあるのは分かるけど、とりあえずちょっとしたアイディアとかを試す時の楽さでいえばPerlが一番楽ちんだなぁ。言語のポリシーにもブレがなくていい。
アバウトにアバウトなプログラムが書けてアバウトに動かしても"きちんと"アバウトに動く、そんな感じ。もちろんキッチリとキッチリとしたコードを書いてキッチリと動かすこともできる。ラリーウォールの言語仕様に対するバランス感覚が天才的なんだと思う。ラクダ本を読むと特に。
# と、M1中だがあえてコメント
Re:Perlはもっと評価されていい (スコア:1)
＞あとはtkとかGDとかイメージマジック使わずに簡単なGUIが作れてグラフ作図や図形描画ができれば最高のがらくたメーカーなんだがなぁ。マルチプラットホームだし。
この時代、GUI が必要ならウェブシステムにしちゃえばいいんですよ。
Re:Perlはもっと評価されていい (スコア:3, 興味深い)
最近は、グダグダなPerlもありかなと思うようになりました。
Perlって元々行儀の良い言語じゃなくて、生まれも育ちも悪い。
それでも熱い魂は持っている、Punkな言語なんですよね。
おバカなプログラマであっても、只のノイズにしか見えない
コードしか書けなくても、快く受け入れてくれる。
教科書に書かれたようなコードより、勢いのある熱いコードが似合う。
そんな言語だと思うようになりました。
# 変態技巧を凝らしたコードも好きですけど！
Re:Perlはもっと評価されていい (スコア:3, すばらしい洞察)
perl が批難されてるのは、
「使えない」からじゃなくって、
「難解」だからだ。
本当に perl を批難してる人は、perl が使えない等と言わない。
わからないのは、恥ずかしい事じゃないだと？
的外れも甚だしい。
たとえば、perl ベストプラクティスって本を読んでみればわかるが、
やってはいけない事、使ってはいけない方法が大量に書いてある。
そしてそれらは過去の互換性のために、未だに使用できる状態だとわかる。
再利用を意図されていない他人のコードを再利用する場合には、
最低でも、こんな本に書かれている事のすべてに精通している必要がある。
# もしくは、自力でそれら問題を看破する必要がある。
ほぼ並の人が解析できる量を、遙かに超えた自由度をもつ構文で、
必要とあらば使ってはいけないと言われる機能を自由に使う事ができ、
# 使ってはいけないと言われているんだから、当然、使い方など憶えてない。
同じ目的に複数の記法があり、書き手の好みによって自由に選択する事ができる言語を、
難しいと言わずしてなんて言えばいいんだ？
Re: (スコア:0)
>ほぼ並の人が解析できる量を、遙かに超えた自由度をもつ構文で、
>必要とあらば使ってはいけないと言われる機能を自由に使う事ができ、
近年のPerlのVersion間の差が大きく、違う言語と思えるぐらい差があるにもかかわらず、完全な後方互換を有しているためでないでしょうか。
例:Perl4とPerl5は、CとC++とぐらいの違いがあるのに、Perl4の構文でPerl5を使うことができる
例:Perl6では、文法がだいぶかわったのに、use v6;としないかぎり、従来と同じ構文で使うことができる
つまり、言語仕様が過去からの遺産を引きずってごっちゃなので、ソースコードもごっちゃになってしまいがちだと思います。
Re: (スコア:0)
誰もそうなってる理由なんか聞いてないんだが。わかったところで何ら問題の解決にならない。
Re: (スコア:0)
>同じ目的に複数の記法があり、書き手の好みによって自由に選択する事ができる言語を、
>難しいと言わずしてなんて言えばいいんだ？
他の言語でも、一緒だとおもうけど。
汚く書くやつはどんな言語でも読みづらいし、
ルールを無視してコード書くやつは、どんな言語でも無視するでしょ。
それに長い年月たてば、コンパイラだって変わってくるし、
進化してゆけば言語だって変わるのは同じことだと思うがね。
それを、デメリットととるかメリットととるかは使い手しだいじゃないのかな。
Perlが評価されない理由が理解出来た (スコア:0)
正規表現については言い掛かりだと思うけど、
（正規表現で処理したいからするのであって、嫌なら別の方法で処理すればいい）
「書き方が多彩」がある意味で欠点とされるのは仕方無いと思いますよ。
特に、ビジネスでは、
個人でちょこちょこやるにはこんな気軽な環境は無いけど、
仕事なら相応のフレームワークを加えた方がいいんじゃないかと、
「そのソースの書き方が汚い」についても、
フレームワーク導入で解決すべき事だと思うな。
自分のスタイルでないソースは読み難くて汚く感じるもんだよ。
で、それが「書き方が多彩」と言う「欠点」と言われるわけだから、
> 別にPerlに慣れてな
Re:Perlが評価されない理由が理解出来た (スコア:1, 興味深い)
>（正規表現で処理したいからするのであって、嫌なら別の方法で処理すればいい）
これはそうとも言えないんだけども。
>「書き方が多彩」がある意味で欠点とされるのは仕方無いと思いますよ。
なんというか、perl擁護派は昔の非構造化BASIC擁護派と同じタイプの主張をしているんだよね。
手軽さ、機能の豊富さを誇り、欠点は「君が慣れてないから」で片付ける。
perlはあれもこれも出来る、(perlはXXが難しい、面倒くさいという意見に対して)それはperlに慣れていないだけ、俺には簡単
Re: (スコア:0)
正規表現が無ければ、オートマトンで書けばいいじゃない。
Re: (スコア:0)
> なんというか、perl擁護派は昔の非構造化BASIC擁護派と同じタイプの主張をしているんだよね。
> 欠点は「君が慣れてないから」で片付ける。
そんなLispでもEmacsでも、なんにでも当てはまりそうなことで印象操作されてもなあ。
Re: (スコア:0)
> > 別にPerlに慣れてないのは恥ずかしい事じゃないわけで、
> うわっ、凄い上から目線！
そりゃ、ある言語が使える人は、使えない人よりも上でしょ？
# どういう基準で上かはよく分からんが
「知らなくても別に良いじゃん」ってのがそんな反応するほど上から目線ですかねぇ
「Rubyワカンネ」「知らなきゃ読めないよ」
「Pythonイミフ」「覚えりゃ読めるよ」
ってのと同じ話なんだけど、これらも上から目線ですかね
Re:Perlが評価されない理由が理解出来た (スコア:2, すばらしい洞察)
> 「知らなくても別に良いじゃん」ってのがそんな反応するほど上から目線ですかねぇ
「知らなくても別に良いじゃん」って、何処が？
#1546737 [srad.jp]の以下の部分が「上から目線」だと言ってる事は読み取れるよね？
> ・そもそもPerlの基礎知識が足りない
> ・そのソースの書き方が汚い
>
> という本質的な理由を、Perlのせいにしてるのが殆どじゃないの？
>
> なんて指摘するとヒステリー起こす人がいるんだけど
> 別にPerlに慣れてないのは恥ずかしい事じゃないわけで、
Perlに難を示された場合に、
『基礎知識が足りない』『書き方が汚い』と返すのが駄目駄目なの。
その前に挙げられていたのは枝葉の話だけど、
それらは確かにPerlの特徴として存在するものであって、
それぞれに、それが問題にならないようにする解も用意されてるよね？
それらを示して解決に導くのではなく、
「そんなの問題ではない」と客観視の出来ない高慢な態度で、
（相手が問題視してる部分に「俺は問題だと思わない」と返すのは論外でしょ）
「お前の知識や書き方が至らないだけ」と切り捨ててしまって、
挙句、『慣れてないのは恥ずかしい事じゃない』等と言う。
違う違う、Perlにはちゃんと解法が用意されてるから。
なのに、それを教えられなかっただけでしょ？
慣れてなくて上手く教えられないのは恥ずかしい事じゃないけどさ。
そりゃ「Perlは使えねぇな」と言う評価になりますよねぇ。
本当は、その場その場で妥当な解決策を提示出来ない、
その人に対する評価（このPerler使えねぇな）であるべきなんですけど、
その人は「Perlはそーゆーもんだ」と言う態度なので、
その周囲ではPerlの評価が下がってしまう。
Re: (スコア:0)
> # どういう基準で上かはよく分からんが
分らないまま言い切る言語センスが凄い。
Re: (スコア:0)
>・純粋なオブジェクト指向ではない
>とか、殆ど言いがかり
いや言いがかりではないでしょう。
これもまた事実だけど「別にそれは欠点ではないし」というだけのこと。
ただし「純粋なOOPではないからダメダ」という意見は言いがかりね。
ほんとにOOPダケになることが幸せに繋がると思うんだったら、
RubyやSmalltalkからBlock(関数リテラル)のような関数型言語由来の機能を削除したら
どれくらいラクになる※のか考えてみるといいよ＞OOP原理主義者
※もちろん実際にはマイナスのラクさが得られます。
>そのソースの書き方が汚い
Windowzへの「批判」とパターンが似ていますね。
ユーザビリティにせよドライバの問題にせよ
「OSが悪いんじゃなく使い方が悪いんだ」という指摘が有りますが、
じゃあ「悪い使い方を許しすぎるユルユルな枠組み」は悪くないのか？という話が。