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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/06/02(土) 00:54:11
青春をともに過ごしたPerlの何がだめって言うんだよ〜
教えてくれ！
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 ですよ。
2008/08/02(土) 09:37:55
Lakeの書式見てRubyイイと言い出す人間は多いな。R&Rもそのクチじゃないかな。
442デフォルトの名無しさん
垢版 |
2008/08/02(土) 11:03:56
一つの動作を色々な書き方ができるほうがいいのか
一つの動作なら同じ書き方で統一するほうがいいのか
これは価値観の問題じゃない？
2008/08/02(土) 11:10:00
まぁそうだが、同じ動作なら読むほうにとっては後者が歓迎されるんじゃね
2008/08/04(月) 00:18:55
統一感を求めるならPythonのほうがよくね？
2008/08/04(月) 03:27:14
Pythonも使ってるけど、コンソールコピペで叩けるような長文ワンライナができないと面倒な感じ
その意味ではまだRubyかな
SpiderMonkeyあたりがコンソールライブラリ充実したらRubyとか糞とか言える日が来るかもしらんけど
2008/08/04(月) 07:08:53
>>440
ますます迷走してるし
2008/08/04(月) 09:47:30
今から初めてプログラミングをする人が選ぶならば、PerlとRubyどちらがいいと思う？
ただし、職業としてでなく、あくまで自分で使うため。
書籍も多数発売されて、Rubyを学ぶ環境は問題なくなりつつあるよね
Perlとは違った意味でRubyにも将来性の不安というのはあるけれど…


実はどちらも勉強するが正しいのかな
2008/08/04(月) 10:11:43
どっちもやれよ。
2008/08/04(月) 10:51:22
でもそれじゃ話が進まない。
どちらか一方をと言われたら？
2008/08/04(月) 11:05:44
どっちもやれ
2008/08/04(月) 11:22:29
では、どちらを先にやりましょうか
2008/08/04(月) 14:11:01
php
2008/08/04(月) 16:26:25
perlとphp長いことやってきたけどやっぱいろいろできるperlのがいいな
2008/08/04(月) 17:53:41
>>451
perlとruby
2008/08/04(月) 18:34:44
>>447
Perl
2008/08/04(月) 23:34:29
perlの将来性は確かに不安だ
だが、rubyやpythonに将来性があるかといわれると、それも大いに疑問だな
phpは立ち位置が違うから比較にならない。上の3つのどれかを知っていても別に覚える意味はあると思う。
457デフォルトの名無しさん
垢版 |
2008/08/05(火) 00:27:50
迷ってる暇があったらとっとと習得すればいいだろ。
今週はPerlをマスターして、来週前半でRuby、後半でPythonを
マスターすれば良い。
458デフォルトの名無しさん
垢版 |
2008/08/05(火) 01:05:52
Perlに未来があるとすればUnicodeを捨てて、もとのPerlに
戻るのみ。
幸いにも癌は取り除きやすいようにパッケージされている。
2008/08/05(火) 05:49:44
>>457
どんだけ記憶力良いんだよ
2008/08/05(火) 05:53:55
Rubyだけやった方がいい
Perlやって変なクセつくより、オブジェクト指向のRubyだけを勉強した方がいい。
多けりゃいいってもんじゃないんだよ。
2008/08/05(火) 21:02:07
PerlをいやになるぐらいやってからRubyのほうが感動するらしいぞ。
2008/08/05(火) 22:34:56
その頃にはRubyがあるかどうか…

あっても大幅に仕様変更しているだろう
2008/08/06(水) 07:47:51
>>461
今、Perlを嫌になるほどやれるシチュエーションってないな。
もうPerlでCGIって時代でもないし。Perlのwebフレームワーク使った案件もないし。
せいぜいワンライナーとかチョンプロぐらい。
2008/08/06(水) 09:59:50
この板別に職業プログラマだけとは限らんのよ？
2008/08/08(金) 22:15:05
Rubyもまたいずれ暴走するんだろうな
2008/08/08(金) 22:20:55
「仕事でやむをえず」以外に、いまさらPerlなんぞを使う理由って何かあんの？
趣味ならもっとマシな言語を好きに選べるのだし、選んだほうが幸せになれるだろ

まあPerlは非常に広い範囲で使われてるから、知っておくと便利は便利だが
それを言うならもっと先に学ぶべき言語はいくらでもある
2008/08/09(土) 08:33:28
>>466
webならPHPってこと？でもPHPから入らないほうがいいって意見もあるんだよねえ
さすがにCじゃ荷が重いだろうし…となると、やっぱりRubyってならない？
2008/08/09(土) 12:56:50
Perl6ついに今年のクリスマスにα版が？
http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=001357
2008/08/10(日) 11:54:05
>>468
な〜んだ。それって、Perl6が発表された時がクリスマスって言ういつもの話じゃないか。

それよりも、Perl6の日本語の情報がほしいお……
2008/08/10(日) 16:22:17
ウェブなら、PHPかPerlでいいんじゃない。モダンなスクリプト言語ならPythonってなるだろうし、Rubyにはメリットというか、存在意味を感じない。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況