アカウント名:
パスワード:
Pythonはライブラリというかモジュールがたくさんあるし、コンパイルしなくていいので手軽だし、最近はCPUも十分早くなってるし、メモリもたくさんあるので、処理速度も巨大データを扱わない限りは問題になりにくい。言語仕様もわかりやすいし、なんといっても辞書型が強力なので、データ処理もやりやすい。「(習得と)開発にかかる時間と処理にかかる時間」の合計では一番短時間で課題解決できると思うのである意味納得。
かつてはCPUは遅く、メモリも今ほど潤沢でなかったので、Cで書かないと処理時間が・・・なんてこともあったけど、今はCで書く気は起きない。組み込みでない限り・・・。
#Javaはそのうち手を出すかなぁ、と思ってるうちに、ださないまま終わりそう。
Python 3を使うべきでない場合(なんてない) [postd.cc]
私の経験では、プログラマの90%はUnicodeについて考える必要はありません。とても多くのプログラマが仕事でASCIIを使うからです。
この問題の影響を受ける人口は、Unicodeを扱う、10%の人々だけなのです。
はい解散
その記事自体がThe Case Against Python 3 (For Now) [learnpytho...ardway.org]という、Python 3をディスった少々的外れな記事に対する、これまた頓珍漢な反論記事なので……。(特に文字列の部分)
元々Pythonにはstrという文字列型(いわゆるマルチバイト文字列)と、後から追加されたunicode(こっちはUNICODE文字列)がありまして、両者は混在可能でした。C言語で言うと、char文字列とwchar_t文字列が混在できる(別の型同士でstrcatしたりできる)というものです。ところが、こいつは英語圏以外では実用にならないのです。なぜかというと、
strとunicodeが混在したときには、自動的にunicodeをASCIIとしてエンコードしstrに変換する
からです。(当然、日本語などの非ASCII文字は実行時エラーになります)元記事は「混在するとエラーになるから駄目」みたいなことを書いていますが、そうじゃない。「混在はエラーにしてくれた方がありがたい」のです。下手に通ると、バグ発見が遅れるので。反論記事の「私の経験上、もしそんなことを言っている人がいるのなら、初心者ではなく、こういった問題の対処法を知っている人でしょう」も的外れ。そもそも、「UNICODE文字列とマルチバイト文字列は混在させない」のが正しいのですから。(C/C++からすれば当然ですよね)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
短時間で結果がだせるからありがたい (スコア:0)
Pythonはライブラリというかモジュールがたくさんあるし、コンパイルしなくていいので手軽だし、
最近はCPUも十分早くなってるし、メモリもたくさんあるので、処理速度も巨大データを扱わない限りは問題になりにくい。
言語仕様もわかりやすいし、なんといっても辞書型が強力なので、データ処理もやりやすい。
「(習得と)開発にかかる時間と処理にかかる時間」の合計では一番短時間で課題解決できると思うのである意味納得。
かつてはCPUは遅く、メモリも今ほど潤沢でなかったので、Cで書かないと処理時間が・・・なんてこともあったけど、
今はCで書く気は起きない。組み込みでない限り・・・。
#Javaはそのうち手を出すかなぁ、と思ってるうちに、ださないまま終わりそう。
Re: (スコア:1)
Python 3を使うべきでない場合(なんてない) [postd.cc]
私の経験では、プログラマの90%はUnicodeについて考える必要はありません。とても多くのプログラマが仕事でASCIIを使うからです。
この問題の影響を受ける人口は、Unicodeを扱う、10%の人々だけなのです。
はい解散
Re:短時間で結果がだせるからありがたい (スコア:0)
その記事自体がThe Case Against Python 3 (For Now) [learnpytho...ardway.org]という、Python 3をディスった少々的外れな記事に対する、これまた頓珍漢な反論記事なので……。(特に文字列の部分)
元々Pythonにはstrという文字列型(いわゆるマルチバイト文字列)と、後から追加されたunicode(こっちはUNICODE文字列)がありまして、両者は混在可能でした。
C言語で言うと、char文字列とwchar_t文字列が混在できる(別の型同士でstrcatしたりできる)というものです。
ところが、こいつは英語圏以外では実用にならないのです。なぜかというと、
strとunicodeが混在したときには、自動的にunicodeをASCIIとしてエンコードしstrに変換する
からです。(当然、日本語などの非ASCII文字は実行時エラーになります)
元記事は「混在するとエラーになるから駄目」みたいなことを書いていますが、そうじゃない。
「混在はエラーにしてくれた方がありがたい」のです。下手に通ると、バグ発見が遅れるので。
反論記事の「私の経験上、もしそんなことを言っている人がいるのなら、初心者ではなく、こういった問題の対処法を知っている人でしょう」も的外れ。
そもそも、「UNICODE文字列とマルチバイト文字列は混在させない」のが正しいのですから。
(C/C++からすれば当然ですよね)