【えっ】Perlに未来はあるのか？【終わり？】

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/06/02(土) 00:54:11
青春をともに過ごしたPerlの何がだめって言うんだよ〜
教えてくれ！
2008/07/14(月) 20:50:29
Ruby作者も変な信者が集まっちゃって災難だな。
341デフォルトの名無しさん
垢版 |
2008/07/14(月) 21:12:01
私はこれで Perl から乗り換えました。
http://web.archive.org/web/20010427071311/www.ruby-lang.org/ja/column/v0004.html

バベル案内
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
Perlもまた、間もなくなくなる。

Perl, Python, Ruby の比較
http://www.shido.info/py/python1.html

perl/Ruby、これから覚えるべきなのは？
http://q.hatena.ne.jp/1145610898
2008/07/14(月) 23:17:38
Rubyは、2000年頃は狂信者が本当にひどかった。Rubyに手を出したことを
隠さなければならないほどだった。

でも今は人が増えたので良くなったね。
343デフォルトの名無しさん
垢版 |
2008/07/16(水) 00:53:25
だんこがい...
2008/07/18(金) 00:56:41
>>334
同意。
PerlのEncodeは終わってる。

言っておくが、自分には使える。
Perl好きだし、Encodeモジュールもわかっているつもり。
ただ、そこまでPerlにはまっていない周りには使えないし、わかってもらえない。
これが致命的。
（よくはまるのは、UTF-8フラグのついた文字列と
バイト列としての UTF-8文字列の違いとかのあたり）

それに、ソースコードを UTF-8 で書くと、システムがローカルエンコーディングの場合
ファイルを開いたりするのさえ面倒。

Unicode がらみのスクリプトを書くたびに、

sub e { Encode::encode('cp932', $_[0]) }
sub d { Encode::decode('cp932', $_[0]) }
sub E { map { Encode::encode('cp932', $_) } @_ }
sub D { map { Encode::decode('cp932', $_) } @_ }
↑こんなのを上に貼って、
open IN, e"日本語.txt";
とか書いたり、デバッグする時に
b 30 ($str eq d"日本語")
とかやったりしてるけど、正直言って超バッドノウハウ。
人が見てもやっぱりわからないし。
2008/07/18(金) 10:31:33
（・∀・）ｶｴﾚ
2008/07/18(金) 19:49:02
全部EUCでやるなら
問題ないのですか？
2008/07/18(金) 23:00:17
>>346
日本に引きこもって、外に一歩も出なければｏｋ
2008/07/18(金) 23:02:04
趣味でプログラミングやってるならソレで良いだろうけど
仕事となると「日本語だけしか扱いません」てワケにはいかんだろ。
2008/07/18(金) 23:24:45
>>346
[ぁ-んァ-ヶ] 等ができない。
JPerl なんて言わないでね
2008/07/19(土) 01:36:00
>>346
>>344なみの回避技/裏技を駆使する必要がある。
2008/07/19(土) 01:44:58
>>346
どうせ引き籠もるなら今はUTF-8だろうけど、
Windowsだとファイル名がShift_JIS(cp932)のAPIあるじゃん。
2008/07/19(土) 10:13:42
>>351
PerlはA系APIを使ってて、せっかくUTFフラグなんてモノを内部に持っていながら
ユーザが手動でWindowsコードページと相互変換する必要があって、
そこまでやっても所詮A系決めうちだから、コードページ範囲外の文字が使われてる
ファイル名とか手も足も出ないんだっけ？

あまりにクソ過ぎてワロタ
2008/07/19(土) 17:34:47
そもそもＵＮＩＸ系ＯＳ自体がユニコード対応してないんだから
ＰｅｒｌなどのＵＮＩＸ系生まれの言語がユニコード扱えないのは仕方ないだろ。
2008/07/19(土) 17:40:58
>>353
一行目も二行目も言ってることがありえなさ過ぎてワロタ

たぶんあんたはLANGをja_JP.UTF-8にできることもしらないし
CIFSでWindowsのUTF-16なファイル名を完璧にSambaで扱えることもしらないし
JavaやPythonやTcl/Tkなどの言語が、Perlよりよほど優れたUnicodeサポートを
Windowsにおいても提供していることも知らないわけだな

Perlってテキスト処理が得意で簡潔に書けるのがウリのシステム管理者向けの
言語なんじゃなかったっけ？
2008/07/19(土) 22:13:53
　↑
またか・・
もういい加減に、UTF-8 とユニコードの違いを理解しろよ。
2008/07/19(土) 23:05:14
>>353ってなんでこんな馬鹿なの?
2008/07/19(土) 23:32:22
議論に負けると人格攻撃はじめる
2008/07/19(土) 23:36:04
ぶっちゃけ>>353もすげえが>>355はもっと面白いな

ネタか何かのつもりかしら
2008/07/19(土) 23:36:25
議論に勝っても人格攻撃を始めるのが2ch。
要するに、勝負がついたということ。
2008/07/19(土) 23:45:51
で？UTF-8 とユニコードの違いは理解できたのかい？
2008/07/20(日) 00:21:29
？

そらエンコと文字コードまとめて語ったら誤解産むケースがあるのは
確かだが、そういう話じゃねえしな
2008/07/20(日) 02:02:38
そういう話だということにしないと、>>355があまりにもかっこ悪いから
必死なんですよ。
2008/07/20(日) 02:23:41
>>355
ユニコード ≒ 思想・アルゴリズム
UTF-7、UTF-8、UTF-16、UTF-32 ≒ 実装
じゃねえの？

「UTF-32エンコードされたユニコード文字列」とかいう表現が一般的だと思うが、
単純に「ユニコード文字列」と言った場合、
「エンコード不明なユニコード文字列」と取るか
「(最近一般的によく使われる)UTF-8でエンコードされたユニコード文字列」と取るか
「(一部儲が一般的と考える)UTF-16でエンコードされたユニコード文字列」と取るかは
人それぞれだと思う。

ってか、前にも>>355みたいな変な書き込みをPerl関連のスレで見た記憶が・・・。
2008/07/20(日) 02:50:25
>UTF-8 とユニコードの違い
なんかそのものずばりのスレがあるじゃん

UnicodeとUTF-8の違いは？
http://pc11.2ch.net/test/read.cgi/tech/1177930957/
2008/07/20(日) 08:07:10
>>363
「ユニコード」は、規格全体あるいは団体の名前ですよ。
「UTF-8」は文字エンコーディング名。ユニコード規格の一部。元はRFC。
2008/07/21(月) 09:14:52
>>363-365
誰がコピペしろと言った？
自分が理解してるかどうか、それを問うてる。
ユニコードと UTF-8 の違いをだ。
もしちゃんと理解してるなら、>>354 のような恥ずかしいカキコミはできないはずだ。
2008/07/21(月) 10:00:24
してないし、できないわなw
2008/07/21(月) 10:02:18
やっぱユニコードと UTF-8 の違いを理解するのは、このスレの住人には無理か・・・
2008/07/21(月) 10:09:22
例えがアレだが、、、生まれつき目の見えない人がいる。
目が見えないから「色」というのが理解できない。
手で触れるものなら形で区別つくのだが
「空は青い」とか「雲は白い」とか言われても
何のことやらわからない。

生まれつき１バイト＝1文字の世界の人がいる。
彼らにはマルチバイトがなぜ必要なのか、ユニコードがなぜ必要なのか
理解できない。
３次元の世界で暮すわらわれに時間の壁が越えられないのと同じように
perl には漢字・マルチバイト文字・ユニコードの壁は越えられない。
「世間の風潮で、とりあえず utf8 を導入してみました〜〜〜〜」
「でもぜ〜んぜん実用的ではないでぇ〜〜す」
それが perl
2008/07/21(月) 10:31:27
perlのユニコードサポートは凄いもんがあるぞ。
言語レベルであそこまでサポートしているのは少ない。
ライブラリならIBMのがあるけど。
2008/07/21(月) 10:55:12
Perlの問題は、システムコールにencodingで指定した文字コードを使わず、
Perl内部エンコーディングの文字列を直接使うこと。
だから、プログラム側で変換しないといけない。
Perl側で変換するにはPerlIOのコードを書き換えるか、変換レイヤーをかます必要がある。
2008/07/21(月) 19:42:52
>>368
そうか、君には無理なのか。
2008/07/21(月) 20:04:05
UTF-8を槍玉に挙げてるけど、UTF-16なら良いのか？
2008/07/21(月) 21:36:02
>>373
そう。Windows 系ＯＳはな。正確には UTF-16LE だ。
（Win95,98 は切り捨ててもいいだろ）
だが今度は UNIX 系ＯＳのヤツらがブーブー文句たれる事になる。
2008/07/21(月) 21:49:06
別にブーブー文句たれてないぞ。
普通に使えるし。
2008/07/21(月) 22:14:55
サロゲートペアなんか知らないふりしとけばおｋ
2008/07/21(月) 22:25:42
>>375
そりゃそうだ。まだユニコードには対応してないんだから。
2008/07/21(月) 22:29:50
>>374
ん？UTF-16のリトルエンディアンではなく、UTF-16LEなの？
2008/07/21(月) 22:57:46
「UTF-16LE」のLE＝りとる・えんでぃあん
2008/07/21(月) 23:00:20
ユニコード化すると、どうしてもリトルエンディアン・ビッグエンディアンを気にしなければならなくなる。
ここらへんがＵＮＩＸ系ＯＳにユニコードが導入されにくい理由の一つでもある。
Windows系ＯＳならＣＰＵはインテルしか無いからな。
2008/07/21(月) 23:05:29
perlの質問をしているつもりが
CPUレベルまで降りてきたぜ
2008/07/21(月) 23:36:36
ビッグエンディアンなんていらんかったんや
2008/07/21(月) 23:39:19
つまりネットワークもいらないと
2008/07/22(火) 00:00:17
>>379
それは違うんじゃね？
UTF-16LEとUTF-16BEはBOMなし。UTF-16はBOMあり。
WindowsのコードはBOMありのUTF-16でリトルエンディアンで直列化してるはず。

ってかそんなことも知らないでユニコードの話してるの？ｸｿﾜﾗﾀ
2008/07/22(火) 00:10:47
もうPerlと関係なくなってね？
2008/07/22(火) 00:19:11
お前よく気づいたな
2008/07/22(火) 00:22:43
>>384
ライブラリやAPIレベルではBOM要らないぞ。
2008/07/22(火) 00:27:12
これから >>384 をたたえる祭りが始まります。
2008/07/22(火) 00:29:11
ＢＯＭなしって、どゆこと？代わりにスーパー写真塾がついてるのか？
2008/07/22(火) 00:34:38
>WindowsのコードはBOMありのUTF-16でリトルエンディアンで直列化してるはず。
>ってかそんなことも知らないでユニコードの話してるの？ｸｿﾜﾗﾀ
これは良い釣り
2008/07/22(火) 00:40:13
おれは熱烈投稿のお世話になったよ。
2008/07/22(火) 00:49:58
>>389
内部ではワイドキャラクタ(16bit)で扱うので、バイト直列化してないということ。
2008/07/22(火) 01:30:20
まさかのマジレス？
2008/07/22(火) 01:46:29
ボケが判りにくいからじゃね？
2008/07/22(火) 15:41:17
一つだけ言えるのは、海胆コードによって、コード系世界は地獄と化したと言うこと。
396あああ ◆RrX6W08b02
垢版 |
2008/07/22(火) 23:50:01


397デフォルトの名無しさん
垢版 |
2008/07/23(水) 00:44:17
つまりはJPerlの方が使いやすかったと。

しかし、どこをどう間違えてしまったのだ？

やはりこれは *バベルの塔* なのか？
2008/07/23(水) 00:50:04
JPerlはスクリプトやブロックの定義がイマイチ。
Perl5.8の方がいい。
399デフォルトの名無しさん
垢版 |
2008/07/23(水) 00:55:10
JPLと勘違いしてないか？
2008/07/23(水) 01:37:59
PerlのUnicode化は、内部表現である"UTF-8"が見えてしまうのが一つの問題。
たとえ内部的にUTF-8を使っていても、抽象化して「Unicode文字列」としてしか
扱わない、扱えないようにするべきだった。
内部形式なんて、見えるようにしても何のメリットもない。

さらに、「わかっている人向け」のインターフェイスしかないのも致命的。
LWP::SimpleとLWP::UserAgent（等）のように、簡単・手軽な普段使いのものと、
複雑・強力な本格的なものを用意するべきだったのに。

Pythonで、コマンドプロンプトから"print u'あ'"を実行すると、"あ"と表示される。
もちろん裏では"use encoding(cp932);"と同様の処理がされているのだろうが、
ユーザには見えない。見える必要もない。
Perlでは、Unicode 専用の文法を何も作らずにUnicode対応したのも敗因。
u"" のような文法がないから、例えば"use utf8;"や"use encoding(cp932);"のような
「モードの切り替え」が必要になる。
しかし、これは一般ユーザには敷居が高すぎて、単純に理解してもらえない。

残念なことだ。
2008/07/23(水) 02:06:01
１文字１バイトの国で生まれ育った人には、何を言っても無駄。
湯煮コードだ、CP932だ、何だかんだ言っても、その概念が飲み込めない人なんだから。
（このスレにも、ユニコードと UTF-8 の違いが飲み込めないヤツがおるくらいだから、
アメリカ人に漢字が理解できるワケが無い）
生まれつき目の見えない人に、「青い」とか「赤い」とか言っても理解してもらえないのと同じ。
色の概念が無いわけですから。（目の見えない人、変な例えに使ってゴメンなさい）
もうこれ以上、perl に何かを期待しても無駄だよ。
2008/07/23(水) 20:35:44
>>401
ユニコード ∋ UCS2, UCS4, UTF-7, UTF-8, UTF-16, UTF-32

確かに　ユニコード≡UTF-8　は成り立たないが　ユニコード≡UTF-16も成り立たない。

ゆえに「ユニコードはUTF-8ではない」が真ならば「ユニコードはUTF-16ではない」もまた真になる。

ユニコード∋UTF-16　をもって　「ユニコードとはUTF-16の事である」というのであれば、
ユニコード∋UTF-8　なので　「ユニコードとはUTF-8の事である」もまた真になる。

一般用語としてのユニコードがUTF-16を指すとしても、
UTF-8との比較対照としてUTF-16を扱う場合、ユニコードをUTF-16として語る事は
釣り餌以外のなにものにもならない。

UTF-8を使う事がどうしていけないのか、UTF-16がUTF-8と比較してどんな利点があるのか
具体的に例示しないのは、本人がユニコードとUTF-16とUTF-8について理解してないからだと思われ。

注1)　∋　は集合論の記号。右に列挙したものが左の集合の要素であるという意味。
注2)　≡　は集合論の記号。左右がまったく同じものという意味。
2008/07/23(水) 20:49:22
UTF-8は1バイト圏の人が嫌々国際化に対応した結果です
2008/07/23(水) 21:16:23
>>402
一般的にはUTF-32(CEF)じゃないのか？
2008/07/23(水) 21:29:42
シフトJIS が生まれる前のパソコンって、どんな漢字コード使ってたか知ってるよね？
そう、ＪＩＳ漢字コード（JIS6226）だね。ちょっと常識すぎたかな。
UNIX も、マイクロソフトのBASICを乗っけたパソコンも、漢字はJIS漢字コードを使ってたんだよ。
ところが、これが非常に使いにくい。ASCII の１バイト文字とJIS漢字を共存させるのが、えらい苦労する。
そこで、ゲイツ一味が考え出したのが、シフトＪＩＳってワケ。
これは、JIS漢字コードに無理やり数値を足したり引いたり掛け算したり・・・
で、ASCIIコードと重ならないように工夫したコードなんだね。

UTF-8 ってのは、このシフトJIS のユニコード版と言えるかな。
笑われるのを覚悟で言って見れば、「UTF-8 とは、シフト・ユニコードである」 ってところだろうか。
（・・・あ、こんな言葉は無いから外では使うなよ。たった今オレが思いついた言葉だからね）
ユニコードと１バイトASCIIコードは共存できない。そこを、無理やり、数値を足したり引いたり掛け算したり・・・
で、ASCIIコードと重ならないように工夫したわけさ。ほら、シフトＪＩＳと状況が似てるだろ？

ということで、UTF-8 はシフトJISと同じ問題をはらんでいる。
つまり、コンピュータの文字の内部表現には向かない、って事。
たとえば、頭から１０万文字めを取り出す、という処理を考えると、先頭の1バイトめから順々に数えなければ
１０万文字目が特定できない。次の１０万１文字めを取り出すには、またまた先頭の1バイトめから順々に数えなければ
文字が特定できないって事なのよ。大量の文字列を扱うのにはスピード的に不利なわけ。
ユニコードで内部処理していれば、こんな事にはならない。単なる文字の配列だから１０万文字めだろうが１０万１文字め
だろうが、素早くランダムアクセスできるからね。

いつまでも内部表現にUTF-8を使い続けるのは、問題を先延ばしにしているだけで、未来は破綻が待っている。
2008/07/23(水) 21:44:47
にもかかわらず、UNIX系OSがUTF-8に固執するのは、OSがC言語で記述されているから。
UNIXのシステムコールもC言語から呼ぶことになっている。
UNIXはすべてC言語が基本なんだね。

ところで、ユニコードの"ABC"という文字を、C言語のライブラリに渡すことを考えてみよう。
int fd = open("ABC", O_RDONLY);
ユニコードの"ABC" を受け取った open　関数はどういう挙動をするか？
ユニコードの"ABC" は char の配列 { 0x41, 0x00, 0x42, 0x00, 0x43, 0x00 } と解釈されてしまう。
（インテルCPUの場合）
ここで注意しなければならないのは、 0x00 は文字列の終端記号に間違われてしまうという事。
文字列に \0 が含まれていると、それが文字列の終わりという腐った約束ごとがあるから
結局、open 関数には "A" というファイルをオープンしようとするだろうね。

つ・ま・り、UNIX系OSは、どうあがいても、泣けど叫べど、絶対にユニコード化は不可能。
だから UTF-8 に固執してるんだよ。
くやしかったら 文字列の終端が \0 って言うクソ仕様を廃止してみろｗｗｗ
407デフォルトの名無しさん
垢版 |
2008/07/23(水) 21:53:12
>>405
先頭から何文字目の文字とかを扱うのってそんなに重要か？

まあ、それが重要だとしても、UTF-16だって先頭から数えなきゃならない。
なぜならサロゲートペアってものがあるから。

そんなにユニコード完全準拠が必要だと思うなら、UTF-32(UCS4)を内部表現に使うように主張するべきじゃね？
2008/07/23(水) 22:02:14
>>405
> で、ASCIIコードと重ならないように工夫したコードなんだね。

重なってる。
2008/07/23(水) 22:03:56
>>406
うーん、C言語について、誤解してるようだが・・・。
\0というのは、別に、(0000 0000)bを意味して無いぞ。

オリジナルのC言語は6bit=1キャラクタのマシン(PDP-7)で動作していた。
それが今の8bit=1キャラクタのマシンに移植できたんだから、
16bit=1キャラクタだろうが、32bit=1キャラクタだろうが

C言語の言語仕様としては全く問題は無く扱える。

まあ、問題があるとすれば、
1キャラクタ(1Byte)=8bitを前提としたビットアクセス、 union、ポインタ操作などだけど、
その辺はフィルタ作ればソースから抽出するのはさほど難しくは無い。

2000年問題に対応した時の規模の修正で対応可能だろう。
2008/07/23(水) 22:05:23
>>407
UTF-32 って、後から出来た規格じゃん。
後出しジャンケンに勝ってたくらいでいい気になるなよ。
ぜんぜん普及してないんだし。
2008/07/23(水) 22:09:30
>>410
サロゲートペアに反論は？
2008/07/23(水) 22:12:12
>>409
ほうほうほう。それは勉強になった。
で？UNIXは、なぜ１キャラクタ１６ビットや３２ビットのCコンパイラを使わないの？
そうすれば数々のユニコード問題が一気に解決するじゃん。
そんな石器時代の石斧を持ち出して自衛隊に持たせても、北の侵略から日本は守れないぞ〜
2008/07/23(水) 22:13:41
gccのwchar_tは4バイトなわけだが・・
2008/07/23(水) 22:22:56
>>412
それこそ後出しジャンケンだろ。
UNIXにしても、Linuxにしてもユニコードが普及する前からやってるわけで、
最近は64bit対応とかワイドキャラ対応とかで順次対応が進んでる状況なわけだ。

少なくとも2036年問題対応の頃までには、longは64bitか128bitになってるだろうし、
必要性があれば、内部文字コードがUTF-32になってるかもしれない。

もっとも、charを16bit(32bit)にするアプローチがいいのか、wchar_tを標準にした方が良いのかは
十分議論を尽くしてないだろうから、wchar_tを文字列の標準にする方向になるのかもしれないが。
2008/07/23(水) 22:28:00
で？UNIXは、なぜ１キャラクタ１６ビットや３２ビットのCコンパイラを使わないの？
2008/07/23(水) 22:29:56
perl もC言語で記述されてるんでしょ？
だったら1文字１６ビットや３２ビットのCコンパイラでコンパイルした perl を使えばいいじゃん。
ユニコードとか utf8 とか、メンドクサイ事を考える必要無いじゃん。
なぜそれが出来ない？
2008/07/23(水) 22:35:44
何か痛いのが居るな
2008/07/23(水) 22:40:43
だから、サロゲートペアの反論は？

UTF-32が後出しジャンケンだっていうけど、藻前が主張したいのはWindowsの実装こそ正義って話？
UTF-32なら藻前が言った先頭から何文字目とかの話に対応できるから、
藻前がその話を引き合いに出すならUTF-32を内部コードにするべきって主張するのが本当だろうって話なんだが？
2008/07/23(水) 22:41:45
Win厨必死だな。
2008/07/23(水) 23:08:22
合成や正規化の問題があるから、UTF-32にすればハッピーというのも何か
微妙な気がするんだが、
せいぜいサロゲートペアが消えるだけでしょう
2008/07/23(水) 23:16:38
1文字1Byteの国の連中(マイクロソフトを含む)が、1文字1Byteじゃ表現できない範囲をカバーするために提案したのがユニコード。
当初は何が何でも2Byteに収めようとかなり強引な事(見た目が同じ文字は1つのコードにまとめる等)を色々やってUCS-2を作り上げた。
それを表現する方法として作ったのがUTF-16。

でも1文字1Byteじゃ表現できない文字を扱ってる国からの反発がものすごくて、Unicode2.0では21bitに拡張され、結局32bitのUCS-4が作られた。
1文字1Byte圏批判をするなら、当初の頃Unicodeを2Byteに押し込めようとした連中を批判すべき。

UTF-8に対するUTF-16の優位性なんて、Unicode2.0誕生でサロゲートペアが出来て以後ほとんど無いのに、
妄想でUTF-16賛美UTF-8批判するヤツはオカシイと思う。


「Microsoftが採用してWindowsの内部表現になったからすごいんだ」と言いたいならはっきりそう書けばイイジャン。
2008/07/23(水) 23:19:54
UTF-16でサロゲートを見なかった事にするのが一番現実的
2008/07/23(水) 23:21:11
「UTF-32にすればハッピー」ってどこに書いてあるの？
2008/07/23(水) 23:24:59
>>423
> UTF-32なら藻前が言った先頭から何文字目とかの話に対応できるから
UTF-32にしようが、この問題はちっとも解決しないでしょ、ってこと
2008/07/23(水) 23:27:15
ASCII混在ファイルが現役で大量に残ってる間は、英字部分だけでもASCIIと互換性があるUTF-8を使うのが一番現実的。
HTMLだって、metaタグのcharset見て処理できるような仕様になってるのは、ASCII混在が前提になってるから。
2008/07/23(水) 23:29:07
>>424
ん？サロゲートが消えて1文字32bit固定になれば、
「単なる文字の配列だから１０万文字めだろうが１０万１文字めだろうが、素早くランダムアクセスできるからね」
が出来るようになるんじゃねえの？
2008/07/23(水) 23:39:10
>>426
UTF-32ならUCS-4の「コードポイント」を確かに32bitの整数一個で表現できるけど
Unicodeの仕様では、今や一つの「文字」が一つのコードポイントに
必ずしも対応しないわけですから、
> 先頭から何文字目
のような「文字」ベースの話では、どのみち問題はおきますよ、と言ってるんですよ
2008/07/23(水) 23:42:55
>>427
そうか。
つまり、>>405も>>418もユニコードに関しては素人だって事ね。
2008/07/24(木) 00:21:06
encode,decode使ってればいまのとこそんなに困る事もないし
行き詰ったらラリーがどうにかしてくれるから
いい加減unicodeスレに帰ってください
2008/07/25(金) 09:32:05
え？今後は Perl 6 だから、 Perl 5.x での問題はなくなるんじゃないの？
まぁ、 Perl 5.x とそれで動くプログラムは切り捨てられるんだろうけど。
2008/07/25(金) 09:36:19
10000対1で、切り捨てられるのはPerl6
2008/07/25(金) 10:39:19
え？今後は BTX だから、 ATX での問題はなくなるんじゃないの？
まぁ、ATX とそれで動くボードは切り捨てられるんだろうけど。
2008/07/25(金) 12:54:25
え？今後は Vista だから、 XP での問題はなくなるんじゃないの？
まぁ、XP とそれで動くプログラムは切り捨てられるんだろうけど。
2008/07/25(金) 13:00:21
え？今後は 「ねんきん機構」 だから、 「社会保険庁」 での問題はなくなるんじゃないの？
まぁ、 消えた年金５０００万件 とそを納めた被保険者は切り捨てられるんだろうけど。
2008/07/25(金) 13:19:32
つまんね
2008/07/25(金) 13:59:34
え？今後は Mach だから、 UNIX での問題はなくなるんじゃないの？
まぁ、 UNIX とそれで動くプログラムは切り捨てられるんだろうけど。
437デフォルトの名無しさん
垢版 |
2008/08/02(土) 01:11:14
「美しいコードを書けるからRubyを選んだ」---Ruby on Rails作者 David Heinemeier Hansson氏：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20060620/241346/


DHH：いろんなPerlソースを見ていると，頭が爆発しそうでした。
なぜかというと，どのコードを見てもスタイルがそれぞれ違って，
正しいのはどれかがわからない。
それぞれおもしろいんだけど，自己主張が激しすぎると感じました。
一方で，Rubyで書いたものはどれも，
同じことをする場合はだいたい似たように見える。
この「統一感」がすごく重要でした。
2008/08/02(土) 03:49:14
そりゃPerlにくらべりゃな・・
2008/08/02(土) 07:32:10
>>437
そのURLのページに、そんな文章ないんだが・・
2008/08/02(土) 09:14:40
そこで Perl6 ですよ。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況