【Perl,PHP】LLバトルロワイヤル10【Ruby,Python】
1 :
デフォルトの名無しさん:
最強のLL=軽量プログラム言語は、どれよ?
エントリーは、Perl、PHP、Python、Ruby、JavaScript・・・
さあ、死ぬまで語りやがれ!!!
■LLとは?
軽量プログラミング言語(Lightweight Language,LL)とは、取り回しに優れ、
コードの作成や修正が容易と見なされるプログラミング言語のことを指す。
ここでいう「軽さ」はプログラマの負担の軽重を指し、
実行速度に優れているという意味ではない。
現在の水準では
・インタプリタ
・動的型
・正規表現
・関数オブジェクト
などを利用できるものがLLと呼ばれることが多い。(Wikipediaより)
過去スレは容量オーバーのため
>>2に分離
2 :
デフォルトの名無しさん:2010/04/11(日) 23:31:23
※前スレ
http://pc12.2ch.net/test/read.cgi/tech/1267553581/ ■過去スレ
【Perl,PHP】LLバトルロワイヤル8【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1259287439/ 【Perl,PHP】LLバトルロワイヤル7【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1248487404/ 【Perl,PHP】LLバトルロワイヤル6【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1244166510/ 【Perl,PHP】LLバトルロワイヤル5【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1238720336/ 【Perl,PHP】LLバトルロワイヤル4【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1234635513/ 【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1215319832/ 【Perl,PHP】LLバトルロワイヤル2【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1209289408/ 【Perl,PHP】LLバトルロワイヤル【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1188997302/
3 :
デフォルトの名無しさん:2010/04/12(月) 00:27:22
今旬のLL言語教えてください!
Pythonが最強ってのは決まってるからあとは次点をどうするかだな。
,―ヽ_(((((_、―
,/ ノ ヽ ~\
/ ノ IPA ヽ ~\
/ ノ ヽ、 `ヽ
| ノ / ̄\ / ̄~ヽ ヽ i
| ノ | ノ
\ | <●> <●> ( )
\ | | | i /
| / ヽ レ
i (●_●) /
i、 ,-――-、 ・ /
i、 <(EEEEE)> ∵/ IPA Ruby最強、他は糞
i、 \ ./ /
\ ーー ,ノ
,,.....イ.ヽヽ、ー-―一ノ゙-、.
: | '; \_____ ノ.| ヽ i
| \/゙(__)\,| i |
6 :
デフォルトの名無しさん:2010/04/12(月) 00:52:22
このスレッドは天才チンパンジーのアイちゃんがうんたらかんたら乙
LL言語は総じてだめ
Javaが最強
Scalaがこれに続く
LLなんだから徹底的に楽さを追求したPerlとPHPが最強だろ
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
抽出単語数(前スレ1〜994)
Select-String 'Perl|PHP|Python|Ruby|JavaScript' -AllMatches -Path R:\1267553581.dat -Encoding Default | % { $_.Matches } | group
Count Name
----- ----
91 Perl
146 PHP
213 Python
119 Ruby
21 JavaScript
前スレ
>>994 > オレの使っているエディタはなぜかブロックの終わりを自動判定できない。
> そういうインテリジェントなエディタを是非紹介して欲しい。
分かっている人には当たり前な話だが、
returnとかpassとかの明らかにブロックの終わりを表すフレーズが出た場合は別として
ブロックの終わりは、プログラムの内容を把握している人にしか分からない。
別の言い方をすると、それを知る方法があれば、ブロックを表すのにインデントも括弧もendも何も要らない
いやだからそれを明確にするために他の言語は括弧を必須にしてんだろ
Pythonはそうじゃないから逆に判りづらい
なんとなく見た目が綺麗と言うだけ
passのあとにブロック続くことはある
} の代わりに デリートキー を押せばおk
>>13 そりゃ、あるにはあるだろうけど、まともな使い方ってどんなの?
コメントの代わりとかはやめてくれよ。
>>12 コピペしづらい言語だなぁ、とかnotepad.exeで書きにくい言語だなぁ、といいたいのなら同意するが、
タブとスペースを混在させないオートインデントと、1回のキー操作でインデント下げができる程度には
まともなエディタで自分で書く分には何ら問題ない。
Pythonでは構文を明確にするために括弧やendの代わりにインデントを必須にしている。ただそれだけのこと。
機械での構文解析ならともかく、人が目で見るには分かりにくくはならないはず。
他言語でも、エディタは自動では閉じ括弧やendを挿入してくれないか、してくれたとしてもブロック終わり時に
ユーザがカーソル移動させてブロックから抜けないといけない。
エディタや処理系が自動で判断できない言語では、どうせユーザの操作が入ることになる。
引数の数が固定な関数型言語だと、括弧もendもインデントも何もいらない言語ができるのかなぁ。
だから解りにくいんだっての
括弧の方がシンプルだよな
まともなエディタで書くならCだってオートインデントで綺麗に書けるぜ
馬鹿には使えない言語
それが Python
>>11 いや何というか
終わりのカッコが無いのを皮肉ったつもりだったので他意はない。
終わりのカッコがあればオレだってオートインデントくらい作れる。
あ〜眠い
つか
お前ら新スレになってもま〜だやってんのか
この手の論争は長引くな
なんかBRスレっぽくねぇけど、こうゆうのも活気があって悪くねぇか
もう思う存分やれ〜
今日は真面目に仕事だ
python使いの言い分
・一行野郎じゃなければ、どうせインデントはするものなのだからインデント強制は苦にならない
・よほどの括弧好きでなければ、括弧を数えるよりもインデント位置で制御構造を見る方が楽だから、括弧がなくても視認性は悪くならない
ワンライナー、テンプレートなどへの埋め込み、DSLみたいなのをやりにくくしてる
ってのは一応LLとしては重要な欠点だと思うけど
ブロック構造を空白文字で表現するのは
慣れてないとパンツ穿いてないみたいな不安があるんでないの
空白なんて、そもそも見えないし
典型的にはトリムされたりタブと置き換えたり同一視されたり
特別に虐げられる(ことが多い)地位にある文字だから
個人的にはLisp系のがエディタ選ぶかな……
LispのコードはEmacs以外で書く気がしない
>>24 つかlispはschemeで設定かemacs lisp以外で必要になったことないw
ワンライナーに限るとperl最強だな
>>24 少なくとも、対括弧の強調機能の無いエディタでは書きたくないなw
pythonってwhitespaceの命令がスペースじゃない版だろ?
29 :
デフォルトの名無しさん:2010/04/12(月) 20:22:45
このスレ見てpython始めてみます。
まずは初めてのpythonで勉強してみます
恥めてのpythonは偽者があるから気をつけて!
31 :
デフォルトの名無しさん:2010/04/12(月) 21:23:20
ポール・グレアムはvi使い
俺はifブロックの終わりで、ifと同じインデント位置で"# end if"みたいに書いてるけど。
if 条件:
pass
# end if 条件
どうしてもインデントだけではブロックの終わりがわかりにくいという人は、これ試してみるといいよ。
それに、{}やbegin-endでブロックを構成している言語でも、
if文に続くブロックの終わりにどんな条件だったかをコメントで書いておけば、
ぱっと見ただけでどこからどこまでがブロックを構成しているのかがわかりやすいから、
こういうコメントの付け方をオススメしてみる。
>>32 それはまずいだろ
# end if
の行がブロックの終わりじゃなくて次に逝っちゃってるから
インデントに対応したエディタによってはかえってめちゃくちゃなことになる
あえて採用するなら
if 条件:
pass
else:
pass
# end if 条件
こうしないと
if [ 〜〜 ]
then
〜〜〜〜
fi
って書きたいわ
fi = pass
passって意味不明じゃん
ぜんぜん直感的じゃない
せめてendif
endaaaaaaaaaaaaaaaaaaaaiyaaaaaaaaaaaaaaaaaaa;
38 :
デフォルトの名無しさん:2010/04/12(月) 23:20:51
>>29 それPython2.5だからやめたほうがいいよ。
少なくとも初心者は買うべきじゃない
Python人気凋落ヤバス
http://journal.mycom.co.jp/news/2010/04/13/024/index.html プログラミング言語 インデックス 年間推移 備考
1 C 18.058 2.59↑ 5年ぶりの1位
2 Java 18.051 1.29↓ 長期に渡り下落傾向
3 C++ 9.707 1.03↓
4 PHP 9.662 0.23↓
5 (Visual)Basic 6.392 2.70↓
6 C# 4.435 0.38↑
7 Python 4.205 1.88↓
8 Perl 3.553 0.09↑
9 Delphi 2.715 0.44↑
10 JavaScript 2.469 1.21↓
11 Objective-C 2.288 2.15↑
12 Ruby 2.221 0.35↓
13 SAS 0.717 07↓
グラフ見た感じ、2004〜2005年あたりの動きが極端だな
Java急降下&LL系注目
RoRの影響か
それ以後はそんなに目立った動きがないね
Pythonは伸びそうな要素が全くないもんな
まさかPerlが伸びるとは
Google App Engine が出て話題が多かった時期に比べると、
検索の比率が落ちてるだけだろ。
検索数じゃないんだがこれ
Pythonが形勢不利になると何故か伸びないスレ
Python万歳
やっぱ受け入れられてないんだな
インデントでのブロック指定は
新興言語でもPython規約をインスパイアってまずないしな
HaskellもISWIMもオフサイドルールという一般名も知らないんだろうな
パイソン今から2.x始めても大丈夫なのか不安
だいじょうぶ
>>48 python 2.4 以下は糞
最低でも python 2.5 以上で
Haskellのオフサイドルールっていつからあったのかね
98の時点?それよりもっと前?
perl、伸びてんのか!
なんかうれしいな
いやだからpythonにインスパイアされた言語はないって話だろ
Pythonの見た目をCやJavaっぽくしたような言語が出てくる方が早いだろうな
plaggerはアイディア次第で小遣い稼ぎになるw
HaskellもOCamlも全然流行ってないからな
後から出てきた括弧大好きScalaあたりにあっさり抜き去られた
Perl5の「クラスなんてイラねーよ。ハッシュと等価じゃねーか。」
を地で行った設計にはしびれる。
せっかくハッシュマンセーな作りなのに
クラスベースっぽくさせたがる人達は何がやりたいんだろう。
最初からそういう言語使えばいいのに。
Moose使うならPHPかRubyかなんかに移行するわ
>>55 >いやだからpythonにインスパイアされた言語はないって話だろ
pythonが良く出来てるから
pythonに満足しちゃうんだよ
>>56 言語じゃないけど Qt がいい線逝ってると思う
Rubyは、Matzが、Pythonは良い言語だけど気にくわない部分もあるということで開発された言語。
変数とオブジェクトの関係とかはほとんど同じ。
64 :
デフォルトの名無しさん:2010/04/14(水) 12:35:34
Pythonの影響も受けてるよ
「オブジェクト指向スクリプト言語Ruby」pp. 475-476 を見よ
I hate C++. とか
perl は美しくないとか昔は色々言ってたけど
最近は言わなくなったね
Rails が美しくないからかな
影響ってか反面教師だよな
嫌な部分を真似しないようにしたみたいな
あーだこうだ言われるのがウザくなったんで「Rubyと他言語の比較」のページを消した
のが約5年前、ってだけだろ
まず教祖がこれだもんな
前にpython信者がどうとか騒いでたruby厨もこれで満足か?
先に因縁つけてきたのはrubyの方なんだよ
嘘と言うか我田引水と言うか自画自賛と言うか
黒歴史にしてしまうのは惜しすぎる
教祖も創成期には色んなところに喧嘩売ってたんだな
PHPのことは最近でもdisってるけどな
子供が社会進出するようになってやっと親も分別が付くようになって
恥ずかしくなって来たので引っ込めて蓋閉めたっていう感じか
>>70 これ読むとPythonよりRubyを使いたくなるな。
でも、Rubyには俺の欲しいライブラリが無いんだよね。だから無理。
>>70のリンク先ははキモさが足りねえ。
まったくpython信者はキモいな。python信者がどうとか言ったらruby厨かよ。
でもpython信者はいつもキモくあって欲しい。
教祖の教えは絶対なのです
もし教えを知らない異教徒が居れば
出来る限り速やかに折伏しなければなりません
ヘ⌒ヽフ
( ・ω・) dd
/ ~つと)
昔それっぽいの作ったことあるから後で見てみよう
御託はいいから、おまいらの得意な言語でこれ書いてみ。
ttp://headlines.yahoo.co.jp/hl?a=20100404-00000003-zdn_ep-sci ●問題
麻雀の手牌が入力として与えられたとき、「待ち」を出力するプログラムを書いてください。
・字牌なし・萬子のみの想定、つまり、いわゆる「チンイツ」限定で結構です(プログラミングの本質的にはこの限定でまったく問題ないため)
・1〜9の数字13個からなる文字列を受け取り、できている順子・刻子・アタマを()、待ちの部分を[]でくくって出力してください
・面前かつ槓子は存在しない前提でOKです
・()[]の出力順は自由ですが、順序だけが違うものは同一視してください(例:111222を刻子2つで構成するとき、(111)(222)が(222)(111)に入れ替わるだけのものは同一解答とします)
・多面待ちのときも含めすべての待ちを出力してください
・待ちがないときは何も出力しないでください
制限時間は3時間、プログラム言語・OSは自由です。もしあなたがプログラマーやSEであれば、この問題にぜひ挑戦いただければと思います。回答に要する時間の計測は、読者の方のモラルで行っていただきたいと思います。
・麻雀を知らない人は、順子・刻子・アタマ・待ちといった用語の意味だけ調べてから解答に取りかかってください。これを調べる時間は計算外とします。
コメント
無駄な探索をできるだけしないための工夫、デバッグを効率化するための工夫などがあればソースコードにコメントとして記入してください。
出力例
1112224588899 :
単純なケースです。45を軸にする両面の待ちなので、(111)(222)(888)(99)[45]になります。
1122335556799 :
“99”をアタマの両面か“55”“99”のシャボであるので、(123)(123)(555)(99)[67]、(123)(123)(55)(567)[99]、(123)(123)(99)(567)[55]が正解です。
1112345678999 :
「九蓮宝燈」という役です。1〜9すべてが待ちになっています。これに正しく答えが出るのであれば、プログラムはほぼ正しいでしょう。
>>84 >マルチか
俺はここにしか貼ってない。アルファルファで見たので2chのどっかでは既出ってことは知ってたが。
次のかたどうぞ
Pythonってオブジェクト指向言語だと一般には言われてるけど、
関数型言語の要素も存分に持ってる感じがするね。
マルチパラダイムっていう意味じゃJavaScriptもそうだな。
つかPyhtonって「文」を高階関数に渡せるようになったの?
>Rubyと他言語の比較
この程度の贔屓目なら他の言語・フレームワークも当たり前のようにやってるし、
Matzの書き方は茶目っ気あって気分を害す程でもなかった。
なぜ消したのかが分からん。余裕無さすぎだろ。
Matz語録なら多重継承とMix-inに関するコメントの変遷を拾ってみると面白いよ。
初期は多重継承をdisってたのに最近はあまり悪く言ってない。
仕様継承(interface)よりも実装継承(Mix-in)を選んだせいで
同じ実装継承の多重継承を悪くいえなくなったとしか思えん。
PHPとPerlの使い分けが一番いいよ
RubyやPythonやっても仕事にあぶれるぞ
多重継承はダイヤモンド継承避ければ
なんてことない
楽しけりゃいいんだよ
結局CかJavaなんだな世の中
>>Rubyと他言語の比較
>この程度の贔屓目なら他の言語・フレームワークも当たり前のようにやってるし、
>Matzの書き方は茶目っ気あって気分を害す程でもなかった。
>なぜ消したのかが分からん。余裕無さすぎだろ。
技術者同士でニヤニヤやってるうちは良かったんだが
アホ文系マスゴミがチヤホヤし出したあたりから
危険が危ないと気付いて隠したんだろう
> なぜ消したのかが分からん。余裕無さすぎだろ。
世の中には
>>71 みたいな気狂いが多いんだよ
>>76 釣りかどうかは知らないがruby厨の喰いつきがなかったな。
これが逆だったらpython信者が入れ食いだったろう。
このあたりがruby厨がpython信者にキモさで負けている。
ライブラリ有無で言語を選ぶ理由というのがわからん。
無ければ作ればすむのだがその言語を使っている間はその
言語風の書き方を強制されるわけでそちらの方がおれには
苦痛だ。
>>98 は自分のキモさに気づいていないRuby厨
100 :
デフォルトの名無しさん:2010/04/15(木) 08:50:06
Ruby使ってて満足してるけど、関係者がうざくて仕方がない。
特にtdiaryは作者も使ってる人もキモイのばかり。
spamの温床だしあれに関わってるやつ全員首吊りにしてくれ。
,―ヽ____、―
,/ ノ ヽ ~\
/ ノ IPA ヽ ~\
/ ノ ヽ、 `ヽ
| ノ / ̄\ / ̄~ヽ ヽ i
| ノ | ノ
\ | <●> <●> ( )
\ | | | i /
| / ヽ レ
i (●_●) /
i、 ,-――-、 ・ /
i、 <(EEEEE)> ∵/ 他人をキモイと言う前に鏡で自分を見ろよ?
i、 \ ./ /
\ ーー ,ノ
,,.....イ.ヽヽ、ー-―一ノ゙-、.
: | '; \_____ ノ.| ヽ i
| \/゙(__)\,| i |
> ヽ. ハ | ||
spamの温床ってどのへんがどういう風に?
>>99 はいはい、どうしてこうもpython信者はパターンどうりなんだ?
Ruby厨と呼ばれるのは嫌だからC厨とでも呼んでくれ。
python脳には難しすぎるか。
もっともCにもたいした思い入れはないけど。
python,rubyはにたようなもんだろ。共同してPHP.Perlをsageてりゃ
いいのに。
うわー、お約束の「俺はC使ってるからお前らよりエラいけど、」系のキモイのが来たよ。
みんなCとPythonやRubyを使い分けているのに、妄想の中の「Cを使えないPython脳のPython信者」
をdisって自尊心を満たしているんだろうなぁ。
あーキモイ
python,ruby関係無くCぐらい普通使えると思うけどな
どの言語が使えるとかそう言う問題ではないよ
おっさんはC必須の時代が当たり前かもしれんが
今の大学はJavaとアセンブラとかOcamlやHaskellやるけど
Cはやらないって所も結構あるし
逆に言えば必須はアセンブラかもしれん
>>106 Cが重要なのは現存する大半のOSのOS記述言語だから
それは今でもなんもかわらんよ
RubyでもPythonでもPerlでも中心となる実装はCで書かれているから、
拡張を書く為にもC言語は必須だろ。
どの言語でも、既存のライブラリしか使えない初心者はともかく、中級者以上は
C言語も使える。
>>104 コンプレックス凄すぎ。
Python脳に難しいのはpython sageるのをruby厨以外に想像できないか
単に"C厨"という文字が難しすぎて書けないと言っている。"Cを使えない"
なんて書いてない。最後の行はそのまま返すよ。
>>108 経験上多くのJava土方はCをロクにしらないし、使う必要も感じていないようだった
けどな
使い勝手のいいffiを最初から導入せず、Pure Javaの方向にユーザを
持っていこうとしたSunの戦略の勝利なのか
>>110 Ruby厨認定されているのは、単純にPythonをsageているからではなく、
>>76 に対して
>>98 みたいな反応をしてるからなんだけど、自分で気づかない?
1.
>>76 は別に普通の書き込みに見えるのに、
>>98 は釣りっぽい書き込みだとか、
ruby厨の食いつきがなかったとか、逆だったらPython信者が入れ食いだとか、
「コンプレックス凄すぎ」と言いたくなるような反応をしている。
2.
>>76 に対して
>>98 は
> ライブラリ有無で言語を選ぶ理由というのがわからん。
> 無ければ作ればすむのだがその言語を使っている間はその
> 言語風の書き方を強制されるわけでそちらの方がおれには
> 苦痛だ。
という反応をしておきながら、その後
>>103 で
> python,rubyはにたようなもんだろ。
という反応。似たようなもんなら、
>>76みたいにライブラリの有無で言語選んだって良いだろ?
お前の論理は、「Python厨キモイ」という結論が前提にあるために色々破綻しているんだよ。
「べ、別にわたしはRuby厨なんかじゃないんだからねっ!」と言いながら、
必死でRubyやRuby厨を擁護してPython厨をdisっている
>>98を想像して和んだ。
>>107-108 Cをいじる必要がある人が必要な時に覚えればいいだけ
覚えてなければ初心者と言うのは違う
自分でOS作るのが目的じゃないから金を払ってOSを買うわけで
スポーツ選手だって道具は自分では作らない
作り方を知らなくてもうまく使える
>>114 OS記述言語は事実上そのOS上の母国語になる
C、ないしC++がどれだけ利用されているか、自分が日常使っている
プログラムがどの程度Cで書かれているか、知らんわけではあるまい
OSを書かないならCは要らない、ということではないよ
アセンブラがいらんなあ。
互換性がない。
基本はcである場所だけアセンブラにするとかはあり得る。
速度が出て、ビット操作やバイト単位の操作ができるのがcかアセンブラ。
スクリプト言語ではバイナリの取り扱いが困難で出来たとしても遅すぎる。
PHPをC言語に変換するやつがあるが速度は解消できても、
ビット・バイト単位の操作ができない。
>>117 > スクリプト言語ではバイナリの取り扱いが困難で
別に困難ではないよ
遅いのはその通りだが
開発効率、成果だけを追求するならRoadsend PHPというコンパイラはいい。
PHPでC言語並みの速度が出る。
いったんCソースにしてそれをコンパイルする。
windowsではPHP5にいまは対応していない。
>>111 Javaが流行ったことでSunは結局のところ得をしたの?
>>112 >>76は言語の好みよりライブラリの有無を優先しているから
わからんと書いている。ruby,pythonに限った話でもない。
世の中にはRuby厨以外の人間がいるのを理解させるのは
無理みたいだからオレも諦めた。
>>121 言うまでも無いと思ったが、俺が「勝利」と書いたのはただの皮肉だよ
今からPHP始めるとしたら、pixivぐらいのサイト作れるようになるまでどれぐらいかかる?
>>122 Ruby厨乙
元々
>>98みたいな書き方してる時点で
何を言おうが説得力なさすぎ。
ヘ⌒ヽフ
( ・ω・) dd
/ ~つと)
>>124 webシステムってのは作るのよりも維持が大変
作るだけなら半年もやれば、PHPでやる部分はだいたいできる
もちろんデザインとかセキュリティ対策とか負荷対策とかは
半年じゃまかないきれんぞ
3年やっても半人前くらいだな
できるできるというわりに、誰もコードを書かないスレ。
何のコード?
>>90 名前付きの関数でなら昔からできるんだがな
とりあえず名前を付けちゃったほうが話が早い
132 :
デフォルトの名無しさん:2010/04/16(金) 00:40:01
IronRubyでRuby大勝利なのに?
Gemを使ってMaven経由でライブラリが引っ張ってこれるJRuby大勝利なのに?
IronPython がいいよ
IronPython は名前が悪い
アイアンパイソンはなんかンが多くて長くてキモい
Pyron とか Pion とか Iython とかにすべき
Pythron
パイパン
>>106 大学はC、アセンブラ、Fortranだよ
>>141 Cをやらない大学のURL貼ってくれない?
>>142 俺は
>>106じゃないし、そんなこと言われても知らんがなw
C、アセンブラ、Fortranという品揃えに突っ込んだだけだし
Cとアセンブラなしで計算機科学やるところなんてあるの?
fortranを挙げたのは、それで書かれた教科書も多いから
Javaを最初にやるのは別に良いけど、それって文系でも取れる講義だろ
>>144 「大学」って話から、いつの間に「計算機科学」縛りになったんだ?
「文系でも取れる講義」は「大学」じゃないのか?
関数型言語は無視していいの?
言ってることが意味不明すぎ
>>145 だから〜そういう大学も理系はCをやってるだろって話
文系が大学じゃないなんて言ってねえよ
>>146 だったら
>大学はC、アセンブラ、Fortranだよ
こんな紛らわしい書き方すんじゃねえよ
「大学」以外に何も限定せず、言語3つに限定してるようにしか見えんぞ
代表はそれだよ
計算機科学をやるところは関数型も論理型もやるけど、文系はやらないだろうな
>>148 文系は逆にCやアセンブラなんて触らんだろ
相変わらず何言ってんのお前
文系向けのプログラミングの授業も受けたけどCだったよ
>>150 ま、そういうところもあるかもな
それについては言い過ぎた
LLスレ…ですよね…?
文型はFORTRANだった
情報学系統でも演習でCやらん学校はたくさんあるぞ
理系らしいゴミスレ
は?誰も情報学系統だなんて言ってないですけど?
計算機科学では必須って言ってるじゃん
低レベルの情報学なんてゴミ以下の不要学問だから
〃〃∩ _, ,_
⊂⌒( `Д´) < 0120-107-929♪ 城本クリニック♪
`ヽ_つ ⊂ノ
ゴロゴロ
_, ,_
(`Д´ ∩ < 0120-107-929♪ 城本クリニック♪
⊂ (
ヽ∩ つ ゴロゴロ
〃〃
( ・∀・) < 城本クリニック
情報学ってレベルが高いとか低いとかあるんだ。
へえ
あるよ。情報学が指す範囲が広すぎるから
どうみても
>>140の文脈のほうが
低レベルな件について
自分が理系であるとか計算機科学やってるってことを
自慢げには話すんなら
ちゃんとものごとを順序だてて論理的に伝えろよ
こんなの日常会話もつらいレベルだぞ
そんな豆腐さしだされても
164 :
160:2010/04/18(日) 13:23:37
これ食って元気出せよ ( ´∀`)つ□
OSがC/C++で書かれてるのに、それをやらずにアセンブラだけ必須にするのはどうかと思うね
豆腐といえば〓だったのにな
隔世の感があるな
別に情報系の大学は技術者養成専門学校というわけじゃない
よく頂く質問に「なぜ豆腐と納豆の文字が逆になっているの?」というものがあります。
これは、豆腐の「腐」が「くさる」と理解されていることと、納豆が「くさった食べ物」
ということから生じた説と思われます。話をわかりやすくするために、まず豆腐の歴史のお話をします。
豆腐は、中国が発祥の地で、中国でも同じ漢字をあてます。
豆腐を最初に発明したのは、漢代の学者で劉安(紀元前122年没)といわれますが、
劉安の著でもある前二世紀の『淮南子』はもとより、六世紀の『斉民要術』にも、「豆腐」は見当たらず、
やっと宋(960〜)時代の『清異録』にでてきます(元大阪学芸大教授・篠田統氏調査)。
劉安説は16世紀の中国の書物に「豆腐は劉安が始まり」と記されているから広まっただけで、
それを証明するような記録は一切ありません。
日本に豆腐が伝わったのは、奈良時代に中国の僧侶から教わったといわれていますが、これもよく分ってません。
日本で初めて豆腐が文章にでてくるのは、平安末期である寿永二年(1183年)の奈良・春日大社の
神主さんの日記で、「唐符」と記述されていますから、中国から伝わってきたのは確かと思われます。
本当に「豆腐」という漢字が記述されたのは、鎌倉時代の日蓮上人の書状(1280年)からだそうです。
さて、ここから文字のお話です。
実は、古くから中国では「腐」には、くさるという意味はなく、「ブヨブヨしたもの」(コロイド状)という意味があります。
例えばヨーグルトのことを「乳腐」(ルウフウ)と書いたりしますが、これは乳が腐ったもの、
という意味ではなく、乳がブヨブヨになったものという意味からきているそうです。
ですから、豆腐は豆が腐ったから「豆腐」と名付けられたのではなく、豆を加工してブヨブヨしたものだから豆腐です。
「納豆」はお寺の台所、すなわち納所で作られた豆だから「納豆」と元禄時代の『本朝食鑑』に書かれています。
学際的な意味で情報学とか情報系とか言ってるのなら、もうこの話はやめた方が良いね
大卒で技術が養成されてないって文系SEかよ。話にならない
>>171 なんでそう自分の世界用に誤訳してからレスするんだ
> 大卒で技術が養成されてない
ではなく、
大卒で技術者として養成されてない、だろ?
それはおかしなことではないってのが
>>168じゃないか
せっかくここ数十レスで一番有用な
>>170を読んで不覚にも和んでたのに
それは素晴らしいことだね
>>172 > 不覚にも
ツンデレさんだなあ
べっ、べつにあんたのために和んでたわけじゃないんだからね!
やっぱりこのスレ、ID必要だな
誰が誰だかw
レスの立ち位置が分かれば誰が誰とかどうでもいいよ
同じスタンスのやつは同一人物と見なしても問題ないだろ
豆腐野郎は一人じゃないと思うがな
それは
立ち位置:豆腐
ってことでいいんじゃないの
主な関心の対象が豆腐
この流れだとそれも仕方ない
ググってみたら大学でもCやらないところは結構あるらしいぞ
アセンブラは絶対やるみたいだけど高級言語はJavaやLisp系メインが多いようだ
もちろん半数くらいはCもやるけど
ソース
アセンブラやるのにCやらないってw効率悪っ
俺はCやったほうがいいと思う派だから
>>106には賛同しないが
>>140にも賛同しない派
っていうか大学で何やってるかとかどうでもいいっす
こんなおれは豆腐派ってことでいいのカナ?
>>184 大学で何やるかとか興味無くても、
>>106はCやるのはおっさんとかアホなこと言ってるじゃん
お前はCやる派だろ
俺の大学はC言語1年からするけどな。
>>185 うんだから
>>106には賛成しない
といっても、俺のCやるべきってのは
計算機科学を本気で習得するつもりなら、あるいは
職業プログラマになるとして、人月で使い捨てられる
土方で埋もれるつもりがないのなら
Cぐらい(もし教えられなくとも)自分でやっとけ
という程度の意味なので、つっこみどころは「おっさん〜」ってとこね
>>140に賛成しないのは、単に言い方の問題かな…
自分でやっとけって、なんの話だよ
というかCやらない大学というのを紹介して欲しいんだけど
>>188 ?何が分からないのか分からない
俺そんなに変なこと言った?
プログラミングを行う、または学ぼうとしている人の視点の話だよ
191 :
デフォルトの名無しさん:2010/04/18(日) 16:51:18
Cやらないって高専とか工業高校とかの間違いじゃないの蟹
>>188 どうもゆとり教育受けた人たちは
「教えられてないことは出来なくても良い」
見たいな精神が染み付いているように見受けられるから
それに対して
「(教えられなくても)自分でやっとけ」
っていうのは大事な教えだと思う
まあ独習なら教材の多いCは良いだろう
そもそも教材が多い理由が、学習する価値や大学で取り上げる理由を表しているんだろうけど
頼んでもないのにCを無理矢理すすめてくる奴って、
スレタイも読めないほど馬鹿なくせして
なんでこんなに偉そうなのww
誰が無理矢理勧めたの?
C自体はどうでもいいんだけど、makeとかコンパイルが複雑過ぎて覚える気にならないなあ。
>>197 最初からm4マクロとかautotoolsとかやろうとしてたら面倒に思うだろうけど
別にそんな必要ないよ
IDEならMakefileなんて書く必要ないし
OMakeとかRakeとかSConsみたいな代替ツールもある
早稲田だったけどCは授業ではやらんかたたわ
OCamlとかやってた
ゼミではC使ってるところももちろんたくさんあるけど
LLの文法なり雑多なことなり覚える手間で、
makeなりリンカなりのツール一式は絶対に頭に入る
地底だとCすらまともに使えないアホ教授がいる
そして、OCamlやHaskellに憧れても触る機会は永遠にない
perlは触ってないとすぐ忘れるとか言ってるのをよく見かけるが
触ってないものはなんでも忘れてしまうような気がする。
設定ついでに扱える、elispがオヌヌメ。
教授なんて関係ない
学びたくなったら独学ででも学べ
つーかLLスレにいるやつの9割以上は、少なくともLLを独学で学んだんじゃないの?
違うのか?
そらそうよ
>>200 「レガシーで不要な知識だから覚える手間をかけたくない」という意味なら
少し悲しい
俺もCOBOLやJCLやれって言われたら、同じ気持ちになるかもしれん
俺も授業はJavaとアセンブラだけだった
ゼミではLispだった
MARCH以下だから学校名いいたくないけど
Javaなんてこの世になかった
確かに教育向けとしてはC言語は適さないもんなぁ
最近はやっぱりJavaが流行ってるのかね
えっ
つれますか
で、LLは?
>>208 FランだからJAVAなんだろwww
MARCH以上はJAVAなんてやらんよ
そりゃ Java「も」やってるところはあるだろwww
>MARCH以上はJAVAなんてやらんよ
負けを認めようよ
私大だと教科内容公開してるとこ多いから調べれば解るよ
がっこで習わんとプログラム言語すら使えねえのか?
ハッカーは小学生の頃からプログラムを組んでるってことだよ言わせんな恥ずかしい
さすがイケメンハカーは言うことが違うぜ
>>210 アドレスやメモリ管理ならダンプ見ながらアセのほうが覚えられるだろうし
アルゴリズムだったら高級言語のが余計なことで躓かなくて良いだろうしなあ
そんなとこで躓く奴はそこまで
>>224 大半のアルゴリズムはLLの方が楽だが、リストの結合とかじゃなくてちゃんと要素の入れ替えでクイックソート書こうと思ったら
Cの方が書きやすかったりするんだよなぁ。
変数の定義とメモリとが密接に関わってくる分、Cはメモリのコストがすごく見やすい。
……まぁ、LLはそんな余計なこと考えないためにあるんだから、当然っちゃ当然なんだが。
LLならソート組込か外部のCライブラリでいんじゃね
>>225 いやさ、Cなかなか覚えられなかったLL脳の俺でも
アセやった後ならスッキリと頭に入ったんだよ実際
たしかにCのポインタ表記とかはちと面倒なんだよな
アセンブラやDelphiの方が学びやすいとは思う
>>227 それだとアルゴリズム書く練習にはならんでしょ。
>>226 いやだから学校はLLじゃなくてJavaなんだろ
そもそもCでのメモリ管理なんて実務での実装の話であって
情報処理や計算機の基本を学ぶのとは関係ないでしょ
そっちの基礎やるのにFランでもみんなアセンブラやるんだろうし
Cだって高級言語だぜ
単にメモリ管理が手動なだけ
ゼミで研究やるときにC使うなら
Cでのやりかたを覚えればいい
C→C++、C→Java の方がその逆より容易だからだよ
現実問題いまやプログラミングの基礎演習てC使う学校少ないんだから諦めな
じゃあ基礎演習でC使ってる大学教えて
>>233 現場ではC(not++)プログラマはコボラーくらい潰しが利かないのは常識だぜ
本気でプログラムの世界に浸かるならCとLispは押さえとけ
そうでないならJavaでもなんでもいいけどさ
と言うかたとえ小学生とかの子供でもコンピューターに興味を持ったらCぐらい自力で覚えるだろ
学校で教えてもらわないと駄目とか言ってる奴は向いていないから止めちまいな
実は、この5つすべて(Python, Java, C/C++, Perl, LISP)を勉強しておくのがいちばんいいのです。
これらはもっとも重要なハッキング用言語だというだけでなく、
それぞれプログラミングに対してまったく違ったアプローチをしているので、どれも非常に有益な勉強となるでしょう。
Java創世記は、ポインタがないからJavaは使えないと公言するCプログラマが死ぬほど沢山いたな。
オブジェクト指向は意味がなく重くなるだけだから++は使いたくない派とか。
今でもいるけど。
>>236 「c言語 プログラミング 演習 大学 シラバス」とかでググれば?
++を使いたくないのはオブジェクト指向が問題なんじゃなくて++自体の問題だろ
C/C++っていう文脈じゃないのにそこで一緒にしてしまうのは何でなんだぜ
どっちかにできないの?
そんなこったからPythonとPerlを両方上げるのにも、Rubyを排除するのにも
説得力が出ないんじゃね?
how to become a hackerを読んでhackerになった人なんているのかしら
みんながみんなコンピュータアーキテクトを必要としている訳じゃないんだぜ
昔はその必要ない人もCしか選択肢がなかったねってだけの話だろ
そもそも国語力ないから曲解して荒れるんだろ。
>>224 今でもCしか選択肢はない
否定できない事実だから
LLスクリプターがいくらわめこうが
世の中はCプログラマが動かしてる
AmazonだってPerlが動かしてるんじゃない
Perlを書いてるCが動かしてるんだぜ
これに気がつかない奴は今すぐ技術者やめろ
いい加減同じネタ同じ展開で回りすぎ
自分用に何かちょっと組むのも結局Cが一番多いんじゃないかな
LLが普及してるから微妙な面もあるけど、まあJavaはないだろ
このスレなに?
答えがC言語最強っていうクイズ問題作るスレ?
>>249 いやだからC言語は高級言語でその下にアセンブラだの機械語だのあってだな
その下にはハードウェアがありエレクトロニクスがある。
人間が生きるためには、農業が一番偉いとかそういう結論になるな、最終的には。
なんだそりゃ
>>237 Cがまともにできるヤツなら
言語なんて普通に5-6種類位は使えるし
むしろjava専、ms専、web専のが潰しきかんよ
>>251 ちょっとならスクリプトじゃねw
俺は複数を自然に使い分けてるな
>>245 うちの大学はCの演習やってるぞ
情報系じゃなくて機械系だが
そりゃ機械系はOcamlとかやらんだろうよ
結局LLよりCだな→だから学校は間取ってJavaなんだろ
って反論では
>>258 理工系でJavaの使い道あんま無さそうだね
科学技術計算にFortranやMatlabやCは使ってもJavaなんて使わないだろうし
制御でJavaはありえないし
道具の使い方を教えたいんならCやFortranになるだろうし
抽象度の高い次元で「計算」の概念を教えたいんなら関数型のがいいだろう
なんでJava教えてるんだろう?
263 :
デフォルトの名無しさん:2010/04/20(火) 10:40:50
PHPで
Notice: session_start() [function.session-start]: ps_files_cleanup_dir: opendir(※セッションファイルパス※) failed: No error (0)
ってエラーが出て、maxlifetimeになってもセッションファイルが削除されません・・・
そもそもps_files_cleanup_dirってなんなんでしょう?誰か助けて・・・
Javaが使い道無いって社会に出たこと無いのか
>>264 「理工系で」と言ってるんだけど、読めないの?
ああ、職業訓練学校として、将来のIT土方を育成するためにJavaを教えるわけか
納得納得
制御でJavaはありえるんだが
>>266 JavaでI/Oとか叩けるっけ
ああライブラリを使うのか
そりゃ、決め付けてすまんかった
なんか一人だけアンチJavaのキチガイがいるな
Javaは実務でも学術でも広範囲に使われてるだろ。
職業訓練やるならLLだろ。
刑務所じゃRuby教えてるぞ。
> 刑務所じゃRuby教えてるぞ。
これはすごいw
271 :
デフォルトの名無しさん:2010/04/20(火) 10:51:55
あれ、PHPってすれ違いだったの
Javaを学術に使うのは幼稚園とFランだけ
>>271 特定の言語に関する話題は専門の言語スレでやるとよいよ
PHPだとWebプログラミング板のほうになるのかな
274 :
デフォルトの名無しさん:2010/04/20(火) 10:59:47
Oh..
>>226 関数型ならともかく、LL一般の話なら
別にインプレースソートがCより書きにくいってことは無い気がするけど…
def quicksort(xs, low, high):
if low >= high: return
j, pivot = low, xs[low]
for i in range(low + 1, high + 1):
if xs[i] < pivot:
j += 1
xs[i], xs[j] = xs[j], xs[i]
xs[low], xs[j] = xs[j], xs[low]
quicksort(xs, low, j - 1)
quicksort(xs, j + 1, high)
世の中algol系言語で回ってるからな
ポインタで躓くヤツさける意味でjavaなんだろ
関数型とかも教養としてはいいが
LLはたいてい型甘いから教育に向かないよ
だからポインタの有無とかじゃねーよ
アセンブラはやんだから
C以外の言語の間接参照で躓くやつっているの?
ポインタが躓きやすいってのはCの構文が原因だろ
未だにJavaにはポインタがないとか言う奴が居るとは目眩がする
Cにしかないってのはメモリアドレスのポインタ限定の話だろ
参照だろ?
動き回れないからわかりやすいんだよ
>>278 Cのポインタが難しいと思う人ならPerlのリファレンスも難しいと思うんじゃないの
分からんけど
俺の考えでは、Cのポインタが分からない人は
ポインタが分からないのではなく、変数とは、右辺値や左辺値、代入とは何か、
関数の値渡し、といった基本的な事柄を理解していない
多分教え方が悪いのだろう
ポインタを理解する上でアセンブラを理解したほうが速かったという人も
多いけど、その必要は無い
よくあるボックスモデルのような抽象図で考えれば十分なはず
あれはアセンブラやCPU/メモリからプログラム言語への抽象化ギャップが超えれないんだよ
でもアセンブラのメモリモデルを理解できたらCのポインタの理解が早まるのは確か
ボックスモデルでは結局具体的なイメージが定着しないんよね
つか、わかる奴はほっといたらスグ理解できる、、っていってしまえば話終わるかw
> つか、わかる奴はほっといたらスグ理解できる、、っていってしまえば話終わるかw
まあそうなんだろうね
数学と同じで、抽象とそれを理解できる能力ってのは個人差があるんだろう
>>239 >それぞれプログラミングに対してまったく違ったアプローチをしている
PythonかPerlかの、それならではの
特異的なアプローチを教えてください。
答えられないのかよ
答えても理解できるレベルに達してないくせに欲するなよ。勉強しろ勉強
>>256 > Cがまともにできるヤツなら
> 言語なんて普通に5-6種類位は使えるし
それは、どうだろう?
逆に、組込み系で、C言語しかやっていない奴は、Cしかやらない奴が多いよ。
C言語が最高の言語と信じて疑わない。
彼らは、C++でさえ、継承はオーバーヘッドが大きい、という理由で、
継承を全く使わずにC++を書く。(元からあるライブラリ使う時だけ継承を使う)
Javaやっている人は、たいてい、他の言語もやっていると思うよ。
良くも悪くも、Javaをやる仕事の人は、他の言語も使う必要に迫られるからな。
つまり、必要に迫られなければ、C言語だけでも十分!
ただ、最近は組込み系の分野にも、Androidというものがやって来て、、、、ゲホゲホ。
俺も組み込みならCが最高だと思う
androidとかUI(web含む)を使うようなのは別だが
例えばモニタ用にPCのソフトとかも作ったりもするし
スクリプトでデータを前処理したり、いろんなとこで他の言語つかうしょ
逆に組み込み系でC以外の言語使えない奴は
だいたい仕事の幅が狭いか視野が狭いな。私感だが
Javaの創世記はCから転向した奴が何人も挫折していった
Cのようなポインタがないからロジックを組めない
そもそもオブジェクト指向が受け入れられない、多重継承ができない
GCに任せるなんてアホだ、など理由は色々だったが
お前何回それ言ってるんだよw
どこからの受け売り?それが書いてある本を紹介してくれない?
個人で使う分にはboostは最高じゃないだろうか
個人でCを何に使えばいいんだろう
数値計算
>>294 4,5年かけてじっくり書く分には、一番に安定していると思われ
>>292 いや実際1999年からJavaやってるんで
>>291 俺の周りにおおかったのは
文法とかなんやらは屁のようだが
クラスライブラリの山が
面倒になったやつらかなw
大学でJavaなんて土方言語やらないってw
今でもCが授業の基本
各大学の情報系学科プログラミング基礎演習で使用する言語をざっと調べてみた
C/Java
早稲田大学理工学部情報理工学科
慶応大学理工学部情報工学科
芝浦工業大学システム理工学部電子情報システム学科
C/Java/Scheme
東京工業大学工学部情報工学科
C/C++/Java/Fortran
法政大学理工学部応用情報工学科
C
慶応大学理工学部物理情報工学科
日本大学理工学部電子情報工学科
東海大学開発工学部情報通信工学科
東海大学情報理工学部各学科
東海大学情報通信学部各学科
C++
慶応大学理工学部システムデザイン工学科
Haskellがなんで斜め上なんだよw
だってHaskellしかやらないんだぜw
つか東海大学悲惨すぎ
複数挙がってる大学も一つのプログラミング演習という講義で同時に習うわけじゃないだろ
教員によって変わるのか、あるいは計算理論とかコンパイラとかいう別の講義で別の言語をやるのか
コンパイラの授業は言語じゃないだろ
東海大学って大学だったのか
付属高校のグループ企業かと思ってた
私立大学は企業みたいなもんだ
確かに全国展開チェーンだな
310 :
デフォルトの名無しさん:2010/04/21(水) 08:46:38
>>303 Haskel以外は教えるまでもない学生しか来ない。
まだ正しくHaskellを綴れないようだ
>>303 授業でぐらいしか使う用途がないから、率先して使ってあげてるだろう
大学の情報科でVBってのも凄いな
専門学校でもやらんぞ
さすがにVB6ではなくVB.NETなんだろうか
せめてC#にすればいいのに
VB使ってるのは情報系の学科ではないのでは?
>VisualBasic
> 東海大学産業工学部各学科
>>315 東海大学産業工学部電子知能システム工学科
次世代を切り開くIT技術者を育成する
東海大学産業工学部機械システム工学科
自動車やロボットなど、高度に知能化された機械システムを実現する設計手法を学ぶ
そういえばMITはSchemeからPythonに変えたんだっけか
>>239 今だったら
Python, Java/C#, C/C++, Javascript, Haskell
あたりになるんだろうか
Haskellはちょっと趣味的な感じがする
>>318 Lispのcode-as-dataとかマクロは独特のものなので、
Lispを単に関数型と見做してHaskellで置き換えちゃうのはどうなんだろうな
元々のESRの挙げてる言語にしても、Lisp以外Algol系ってかC系ばっかりで
「まったく違ったアプローチ」と言うには偏りすぎに見えるけどな
違いの分かる漢になりましょう
あとから出てきて一気に抜き去ったScalaかな関数型言語最強は
ロボットやるのにVBって嫌がらせだな
一部組み込みでもBASICはあるけど、Cか最近でもせいぜいJavaだろ
>>303 東大は、Rubyで情報科学教えているぞ。
なんでも、教えたいことをは言語の細かいことじゃなくて、考え方とかなので、
そういうのをやるには、思考のじゃまにならないRubyが最適とかって。
なかなか良く出来た教科書だと思う。
Ruby が思考の邪魔にならないってのは幻想だよ
>>324 教えてないよ
それ工学部とか理学部じゃない
俺が出た大学の情報科学科は、
Pascal、C、Standard ML、Java、Perlにアセンブラだったな。
おまえら的にはレベルはどう?
おれが出た大学の電気工学科の情報処理の授業はFortranだった。
これからの言語としてPascalを紹介された。大学では端末から
JOBをお願いして翌日受け取りだった。30年前のことだ。
当時自分で持っていたのは自作のZ80マイコンで機械語しか使えな
かった。やっぱり機械語が最高なんじゃないか? んなわけないか。
俺も大学ではFortranとPascal、それとTK-85でZ-80だったな
まぁそんなのとは関係なく小学生ぐらいから独学でMZのBASIC、Z-80
本を読んでPascalやLisp,Prologを勉強してたっけ
TK-85でZ-80は無い、8085のミスだw
Z80の機械語<<<<6809の機械語
Cで構造化以前のbasicみたいなコード書く教授を、どうしたものか
小学生だったけどZ80アセンブラとか覚えざるを得なかった
色々やるけどCASLやらない学校はないよな
色々やるけどPrologやらない学校はないよな
CASLなんてやんねぇよオッサンwwwwwwwwwww
CASLIIだろ
昔はCOMP-Xなわけだが
ここは平均年齢の高いインターネッツですね
>>327 ML系言語をやる大学は、基本的にレベルが高いとは聞く
ただし教科書が少ないw
みんな金持ちだな
俺は小学校ではfxのアセンブラだったわw
ロングライフバトルロワイヤルスレか
実際のところおまいらって、何がきっかけでLL使い始めたの?
かっこつけるため
C以外の選択肢がVBとawkとPerlとLisp系くらいしかなかった
PHPはギリ世の中に出てたけどRubyとかPythonとかは
今で言うD言語みたいな微妙なポジションだった
そんな状態でWeb系の仕事初めてPerlを
元々BASICとHSPしか経験無かったんだが
Vectorでフリーソフト漁ってたら「オブジェクト指向プログラミング言語Ruby」ってカテゴリがあって
なんぞこれと思って使い始めたらいつの間にかPerlやPython、関数型言語にも手をつけてた
Vectorルートでなんかやり始めるって、あるよね
テープ回覧とかjusのCDとか個人的にはcompuserveかftp mail使ってた俺には別世界だな
吉崎さんがPC-VANにあげたLHAを(ry
HyperRoadの奴は金持ち
uucpにも世話になったな
草の根uucpにもつないでた
つか、おっさんたち乙
ニュースから細切れのバイナリ落としてきて結合して
さらにFLマスク
それちょと違うw
altだなw
俺十分におっさんの自覚あったがこのスレはそれ以上に年齢層高いな
FLマスクの中のひとって死んじゃったんだっけ?
結局RubyやればいいのかPythonやればいいのか分からないのよね
356 :
デフォルトの名無しさん:2010/04/23(金) 21:46:15
ただただしのような痛い人がいるRubyはやめとけ。
両方やらなければよい。そしてPerl,PHPに宗旨変え。
悩むぐらいなら全部やれ
個人的にはRubyとPHPは勧めないがなー
どの言語もそれなりに大きいコミュニティなんだから、
下を見ればきりがない
むしろ痛い人がいない言語を聞いたことがないw
痛い人の割合が多い言語ならある
痛い人がいない言語は、かなりマイナー言語な悪寒
362 :
デフォルトの名無しさん:2010/04/23(金) 22:32:48
どれか1つやれば万事解決、なんてわけがないのに
なんで1つしか習得しようとしないのかね。
全部やりゃいいやんな
この言語は任せとけ!みたいな持ち言語がほしいのれす。。
365 :
デフォルトの名無しさん:2010/04/23(金) 22:45:10
いろいろ齧れば自分に合う言語がどんなものか分かってくるんじゃない?
>>364 万年筆や原稿用紙にばかり拘っても仕方ないよ
Cやりゃいい
LLは適当でいける
用途が似たような言語ばっかりやっても仕方ないし
最初にどれをやるかは考えるだろ。数ある言語の中から、サイクロを振って決めるわけ?w
言語が思考の基盤であるとする「サピア=ウォーフの仮説」に影響された
ような言説をプログラミング言語の界隈でもたまに見るけど
サピア=ウォーフの仮説は誤りらしいですね
教養課程ね
>>369 awkやObjective-Cってマイナー言語か?
IronPythonの方がよっぽどマイナーだろ
375 :
デフォルトの名無しさん:2010/04/24(土) 01:29:19
awkはマイナーでしょ。
Objective-CはもうDelphiよりはメジャーと言っていいかも。
awkがマイナーとか言う奴はもれなく若者
377 :
デフォルトの名無しさん:2010/04/24(土) 02:00:08
awkがマイナーとかねーよwwアホ
AHO
Perl4のころはawkと拮抗してたな
>>355 Google関連やりたければ、
クライアントサイドAPIも、GAE APIもあるPythonで当然。
えっ
Javaのおまけなのに?
>>381 にわか乙
最新のAPIにはまだPythonのみのものも多いよ。
はい?
パフォーマンスもPythonの方が上の場合もあるしね。
>>341 どーりでCとFortranが人気なわけだ。
COBOLも十分ロングライフだと思うが、そのわりに人気ないね。
>>374 IronPythonは言語じゃなくて処理系だろ。
Objective-CってiPhoneの開発してる奴だけど。
>>373 >
>>371 > 要するに工学部や理学部じゃないだろ
え?理系の一年を対象にって書いてあるのは?
工学部や理学部といっても、一年生のうちは、教養課程の授業が大半じゃないのか?最近は?
教養科目って浅く広くで微妙だよな。第二外国語とかプログラミングなんて浅く狭くだし
She never eats NONI.
理系の一年=看護学科の奴も農学科の奴もさらっとやれるレベル
大学一年の授業内容ってめちゃめちゃ基礎レベルだぜ
文系でも出来る
他のIT系の授業の内容を考えるとOfficeの使い方とかと同レベルの内容だろうな
プログラマーでOfficeまともに使えない(使いたがらない)香具師は多い
使う必要があるならすぐ使えるだろあんなもん
単に自分に仕事が降り掛からないように使えないフリしてるだけだろ
陰でエクセルは使ってそう
tsvにしてLLで処理してる
大学1年前期でやらされる情報基礎って授業は実はオフィスの使い方やったりする
latexとtgifじゃないのか?
いつの時代の数学科だよ
latexは実学系の学科はやらないところも多いかな最近は
もちろん数学科とかは必須だろうけど
地底の情報システム科だけど、shもlatexも使うぞ。
latexは理系なら今もとりあえずやると思う
一番速いのはどれですか?
ちなみに今はRubyメインで使ってます。
スピードが欲しい時は、C使ったけどやっぱり面倒クサイ。
Ruby以外ならどれでも十分速いと思うけど?
Perlは平均的にそこそこ速い
Pythonはモノによっては快速、基本的にはまあまあ
Rubyはやっぱり遅い
Perlは自身が速いんじゃなくて、手間がかかる処理だとbinaryのモジュールが
たくさんあるのが強みだな。
同等の機能をPure Perlで動かすと速度が1/100、1/1000なんてのがごろごろしてる。
Lispも速いほう
SBCLなんかめっちゃ速い
あとOCamlもイイ!
えっ
LuaJITの速さが尋常じゃないな
ベンチマークでの差なんて誤差のレベルだよ
だいたいPがつく3つは同じくらいでRがつく奴が遅い
Rがつく奴は1.9になってJRubyの実装取り込むまではもっと遅かった
415 :
デフォルトの名無しさん:2010/04/25(日) 02:15:16
JRubyの実装を取り込むって何のこと?
いろんな実装があったんだけどダントツで最高速なのがJRubyだった
なのでそのロジックをCのRubyにも取り込んだら早くなった
まぁどのプログラムでも良くある話だよ
YARVの勘違いじゃね
ruby は捨てていい
php は論外
perl は斜陽
PHPは別に論外じゃないと思うぜ
言語としてクソとか言うけど、実際問題PHPで構築されて長年維持されているサイトはたくさんあるわけだし
カーマニアが
「軽自動車はクソ。ハンドリングも甘いし、ボディの作りも悪い。
高速道路での加速が悪いから渋滞の原因にもなり得る。
それに田舎のDQN車と言えば最近は改造した軽ワゴンじゃん。
燃費がいいからAT限定免許の主婦みたいな素人はそれでも好むだろうけど。」
とか言うレベルの話と同じ
PHPは軽自動車っていうより原動機付自転車だと思う
意味のないたとえ話をしてわかったつもりになってる香具師って馬鹿じゃねーのとは思う
Javascriptよりは良い
なにが良いんだ?
424 :
デフォルトの名無しさん:2010/04/25(日) 02:51:43
なんだ、YARVとJVMの区別がついていないアホか。
>>422 javascriptつーか、ecmascriptつーか、あれは言語としてはこのスレで出てきてもおかしくないくらいによくできたLLだぜ。
言語そのものとしては規格になってるけど、Web用途以外でのまともな実装としての標準(デファクトスタンダードも含めて)がないから
perl系みたいな使い方がしにくいわけだけど。
macrubyはllvmだが結構速い
>>422 お前にJavaScriptの何が分かる
JavaScriptって糞過ぎる。標準状態じゃ使い物にならない。ライブラリはたくさんありすぎて、しかも互換性がない。
クライアントサイドでPerlでもPythonでもJavaでもいいけど、これらが動くなら、誰もJavaScriptなんて使わない。
rubyからpythonに乗り換えようかと思って試してみた。
floatするとずれる。
"93.42" => 93.4200000002
になる。
ググるとしょうがないって書かれてた。
気付いてないだけでrubyもいっしょ?
一般的な浮動小数点数を使ってる限りは、2進で正確に表現できない少数は
そうなるよ、少なくとも内部的には
それをどう「印字」するかは言語によって色々だろうな
Pythonにしても
>>> 0.1
0.10000000000000001
>>> print 0.1
0.1
こうだし
0.1 == 1/10
どっちもfalse
だった。
ちなみに実行時間は
Ruby 31秒
Python 5秒
思ってた以上に差が有った。
ちょっとショック。
>>430 どうしても誤差を無くしたいならdecimalを使うしかない。
>>> 0.1 + 0.2 == 0.3
False
>>> from decimal import Decimal
>>> Decimal('0.1')+Decimal('0.2')
Decimal('0.3')
>>> _ == Decimal('0.3')
True
お金の計算に浮動小数点数使っちゃいけないってのは
金融に限らず業務系のお仕事でプログラミングしてる奴なら常識だろうな
JavascriptはWebベースなのにブラウザがサポートしてくれないと意味ないとか期待出来ないところがあるから
小数の精度はLLだからじゃなくてJavaでもCでも同じだろ
そういうのこそ、「情報系」の大学で教えてるんじゃないの?
どの言語を採用するかとか二の次三の次にしてさ
つーかそれ基本情報技術者試験レベルだから
小学生で受ける奴もいるらしいね
気象予報士とどっちが難しいんだろうね
気象予報士は史上最年少が中学生みたいだね
442 :
デフォルトの名無しさん:2010/04/25(日) 13:58:54
ruby-talk(えいごのほう)見てると、浮動小数点がらみで
誤差だエラーだと騒ぐ投稿が後を絶たない。
きっと他の言語も似たようなものなんだろうと思う。
>>438 普通に入門書の数値型の説明でも出てくるレベルの話
>>444 なんだこの釣り記事と思ったら
思ったのと同じことをshiro氏が突っ込んでいた
まぁ所詮ちんこだしな
>>435 ところがExcelの世界だと常識じゃなかったりする
>>444 自称電気系出身者と言いながら日本語おかしい香具師は全く信用出来ない
お金の計算にExcel使っちゃいけないってのは
金融に限らず業務系のお仕事でプログラミングしてる奴なら常識だろうな
ニートが言っても説得力無いだろ
まぁ所詮Excelだしな
LLスレだけに再帰的なレスが多いな
それを言うならloopyだろ常考
LLから再帰という相関はあまりないような気がするんだが。手続き型な言語のほうが多いし
末尾で再帰るからキリがないな
再帰は R だしな
458 :
デフォルトの名無しさん:2010/04/28(水) 09:19:19
,―ヽ_(((((_、―
,/ ノ ヽ ~\
/ ノ IPA ヽ ~\
/ ノ ヽ、 `ヽ
| ノ / ̄\ / ̄~ヽ ヽ i
| ノ | ノ
\ | <●> <●> ( )
\ | | | i /
| / ヽ レ
i (●_●) /
i、 ,-――-、 ・ /
i、 <(EEEEE)> ∵/ どういたしまして
i、 \ ./ /
\ ーー ,ノ
,,.....イ.ヽヽ、ー-―一ノ゙-、.
: | '; \_____ ノ.| ヽ i
| \/゙(__)\,| i |
しかし下世話な大衆向けサービスとかやってる開発者は大変そうだよな。
ほぼゴミの情報を大量に扱って削除してまわったり、どうでもいい機能つけたりはずしたり、
心が折れるプログラマーの気持ちもまあわかるわ。
ここは
>>459が高尚なソフトウェア開発について語るスレになりました。
Excelを舐めてはいかん
あれはある意味、世界で一番多用されている関数型言語だぞ
…VBAは別だが
>>462 何しろ「ワークシート関数」というぐらいで式と関数しかない
代入も実行順序の制御も存在しない
どう見ても関数型だろう
プログラミング言語ではないよ
チューリング完全でないだけだもん!
>>459 ユーザ参加のクラウドによる集合知がWeb2.0でロングテールになってんだぜ
ってバイラルマーケティングしてる人がトゥイッターで言ってたぞw
つぶやいてたぞw、くらいにしようや
トゥイートしてた、だな
>>463 セルに関数そのものを入れられて、高階関数が使えるようにならない限りは認めない。
えっと、定義次第な気はするんだけど、できるんじゃね?
>>470 そしたら例えば、
A1に = (lambda x: x + 1)入れて、
A2に =(lambda f: (lambda x: f(f(x))))入れて、
A3に =A2(A1)(0)入れるのはどうすればいいの?
何がしたいの?
ま、そもそも高階関数どころか、ユーザ定義関数書きたきゃVBAだからな
関数定義を
>>471のようにセルにバインドする必要は無いだろうから、
外だしにすること自体は妥当だが
マクロ言語としてVBAじゃなくて関数型言語が使えると良かったな
それは誰得なんだよw
セル一個一個がファーストオブジェクトかつ関数でもあるエクセルをJavaScriptで作ればいいじゃんwww
477 :
デフォルトの名無しさん:2010/04/29(木) 09:16:49
時代遅れのはてなーとtDiaryユーザという地点で見る機内
twitterでつぶやけばいいんですねわかります
なんだ握手風俗のアキバ48ヲタかよ
伝説のPHP作者「Rasmus Lerdorf」名言集を聞くと嫌PHP厨がファビョる
・今のPHPを作ったのは、何十人もの開発者ですよ。私は1人目の開発者だったに過ぎません。
・問題を解くのが好きなだけで、プログラミングは大嫌いです。
・いかにプログラミングを避けるかを考えていたら、コードを再利用するためのツールとしてPHPができました。
・PHPは、歯ブラシみたいなものですね。毎日使うものですけど、だから何でしょう?誰が歯ブラシの本なんて読みたがります?
・パーザを書くのは苦手です。本当にダメなんです。今でもね。
・PHPには「protected属性」も「仮想メソッド」もありますよ。情報学科の教官が「重要だ」っていうやつは何でもね。僕自身は、こんなものどうでもいいと思ってますけど。
・プログラミングを好む人がいるのは知ってますが、全く理解できないですね。
・僕はホンモノのプログラマではありませんから、やっつけ仕事ですよ。ホンモノのプログラマは、「動いてるように見えるけど、メモリリークだらけじゃないか。直す必要があるかもね」なんて言うでしょう?僕なら、10リクエストごとにApacheを再起動しますね。
・いえ、メモリリークはちゃんと気をつけてますよ。でも、プログラミングってほんとクソだなと思いますね。
・プログラミング言語を作るつもりはありませんでした。どうやって作るのかも知りませんし。論理的に必要だと思われるものを足していっただけなんです。
・僕の発言に怒ってる人がいるようですね。僕がプログラマとしてひどいのは認めますけど、でも、多分あなたたちよりマシだと思いますよ(笑)。
これ、PerlでPHPを書いた人?
それなら、わからんでもないし功績は認めるので、これくらいの事は言ってもいい
・PHPは、トイレットペーパーみたいなものですね。
毎日うんこを拭うものですけど、だから何でしょう?
誰がうんこの本なんて読みたがります?
・PHPを好む人がいるのは知ってますが、全く理解できないですね。
スレタイ言語は全部こんなもんだろ
偉そうにしてかっこいいのはLisperのみ
486 :
デフォルトの名無しさん:2010/04/29(木) 20:59:23
(e)
>>485 確かにあの言語はクールだが、それにしてもカッコつけすぎだろ。
それ、あんまりPHP褒めてないよな。
PHPってRasmusが関わってた初期の頃は良かったと思うんだけど、PHP5くらいから妙にエンタープライジーになってセンス最悪になったと思う。
Rasmusってウェブフレームワークとかも否定的なんだよな。そんなもの使う必要ないって。
Pythonistこそ偉そうにして良い
何でみんなPHPを馬鹿にするの(´;ω;`)
素人がすぐに手を出せるのがPHPの弊害というのなら
PHPなんかよりRailsで作られたRubyのプログラムの方が酷い場合が多いぜ
別にどれでも素人がすぐ手を出せるだろ
print "hello, world"
とかで済むんだから
エラーでも勝手にcontent-type: text/htmlを出してくれるってアイディアが最高
495 :
デフォルトの名無しさん:2010/04/30(金) 00:57:08
>>489 × Pythonist
○ Pythonista
>>490 バカも使うから。
それが嫌ならバカは近寄れない言語にする必要があるが、
バカを遠ざけるとLLからも遠ざかる。
重症のバカでも使えるPHPやVBは、ある意味LLとしては優秀
バカも使うから駄目というのならCやじJavaだって駄目だろ
引きこもりのバカと出たがりのバカぐらいの差
ちょっといみわかんない
>>497 実際そういう理由でよく馬鹿にされてるよね、ネット上では
日本人なら馬鹿でも話せる日本語は使うと恥ずかしい
Dimの印象しかない俺になぜVBがどこ行ってもバカにされてるのか教えて下さい
変数名の大文字と小文字を間違えまくる馬鹿とかに優しい設計だからだろ
一般的にはJavaの方が速いんだよね?
昔メールのサブジェクトを表示させるプログラム作ってみたけど、Rubyの方が速かった。
小規模だから?用途次第?
VMの起動にかかる時間じゃない?
>>502 おもちゃだからじゃね?まあスクリプトはどれもそうだけど
あと、バカにされるかどうかは本人がそれしか使えないとかの場合じゃないかな?
>>497 Cだって、分かってる人だけしか使ってなければポインタがどうこう文句言われることも減る。
>>504 両方のソース晒してから言え。
同じように同じ処理を書いたら、Javaの方がやや速く
Javaでは書けない高度なLL特有の処理を書いても、Javaの方がすごく速くなる
、、、と一般的には信じられている。
>>504 LL自身で大した計算をしていなければ、そういうことは普通に有り得る
ボトルネックがIOであったり、Cで実装されているライブラリ(正規表現など)
である場合はね
その例は、grepに毛の生えたようなプログラムだろうから、
普通に予測される結果だな
JavaどころかC++でも、その手のプログラムは、
パフォーマンスを意識せずに書けばLLより遅くなることも多いと思うよ
512 :
504:2010/04/30(金) 11:27:14
プログラミングを覚えようと思って言語選びをしていた時の話。10年以上前のこと。
一番簡単に書けて、速度も速かったからそれ以来ずっとRubyなんだけど、この前Pythonと比較したら速度差が大きかったんで、他の選択肢も考えようかと思って。
JavaはRobocodeをちょっと触ったくらいかな
eclipseもpythonにしか使わないし
重要なのがCで実装されてるのは当然の前提条件として、
Cの関数を呼び出すまでにどれだけ無駄な動きをして、
それが全体にどれくらい悪影響を及ぼすか、という話じゃなかったのか。
LL同士の速度差なんて、信者同士の煽り合いくらいでしか役に立たないと思うのだが、
「RubyをやめてPythonにすれば今まで重かったプログラムが信じられないくらいに軽くなりました。
Ruby使ってた日々がバカみたいです。Pythonは素晴らしいです。
Rubyなんて今すぐやめて、あなたもPythonを使うべきです。」
みたいな体験談ある人なんているの?
お金貰えたらそんな体験談でも語るんだけど
10年前のRubyって速かった?
2003年に検討したときは遅くてなしにしたわ
PerlとJavaしか残らなくてJavaにした
Rubyから移行することで、劇的に速度が改善され、かつプロジェクトの開発しやすさも向上した
っていう、TwitterのScala導入話についてはどうよ?
Rubyの速度の話をするなら、1.9系を使ってるかどうかを明示すべき。
1.9でもこのスレ的には最下層の速度だけど、
まあ速度だけで決めるわけでもないので。
大昔perlは1linerで作れる検索がgrepより速ええって自慢してたな
PHP簡単で便利なのに(´;ω;`)
PHPが何か悪いことした(´;ω;`)?
>>518 あれで劇的に速度が改善って、皮肉としか思えない。
524 :
デフォルトの名無しさん:2010/05/01(土) 00:18:39
twitterがrubyオンリーの頃ってかなりひどかったけどなあ
日本での会員数が倍になってもあの程度で済んでるんだぜ
PHPでへぼいソースを書くやつはRuby与えても同じ。
頑張って馬鹿にされないPHP使いになるお(´;ω;`)
PHPがあほ呼ばわりされないようにがんばるお(´;ω;`)
>>527 ちゃんと本を買って学べばいい。インストールだけの入門書や、クックブックじゃない奴ね。
ガンバレ。
PHPerは最初に使うフレームワーク間違えると変な癖がついて死ぬ
CakeやCodeingiterは絶対駄目
ZendかKohanaV3がいいと思う
530 :
504:2010/05/01(土) 17:00:12
Ruby1.9試してみた。
同じコードが1.8の半分程度で完了した。
Pythonとほぼ同等になったよ。
タブキーでインデントする癖があってイマイチPythonに馴染めなかったからもうRubyいいや。
タブキーでインデントしたらなんでPythonに馴染めないのか良くわからんが
>>529 >PHPerは最初に使うフレームワーク間違えると変な癖がついて死ぬ
>CakeやCodeingiterは絶対駄目
>ZendかKohanaV3がいいと思う
なんで?
非オブジェクト指向のべた書きだからあれ参考にするとえらいことになる
534 :
504:2010/05/01(土) 18:21:54
emacsだとタブキー押すと自働インデントになる。
何回押しても適切な位置で動かない。
pythonは押す度にズレる。
俺の悪癖なんだけどね。
スクリプト言語ってこんなにたくさんあっても意味ないよね。どうせウェブかコマンドラインツールぐらいしか使い道ないんだから。
車輪の再発明。
emacsなんだから設定ちゃんとしろよ
設定できないなら調子こいてemacsなんて使うなよ逆に生産効率落ちるから
537 :
504:2010/05/01(土) 20:04:10
>>536 使いこなせていないのは確かなんだけど、この場合は違うよね?
>>535 Webかコマンドラインツールにしか使えてない人にとってはね。
他に使い道ないでしょう。
540 :
デフォルトの名無しさん:2010/05/01(土) 20:35:19
>>528 オライリーのプログラミングPHPはある程度使えるようにならないと役に立たないから要注意。
>>540 私に言われても困るけれど、初めてのPHP5はどうなの?
あまり噂を聞かないんだけどさ。
542 :
デフォルトの名無しさん:2010/05/02(日) 15:35:54
> 意思決定までコンピューターが出来るようになると、
> 人間自体が必要なくなる。
今でもほとんど「意思決定」に人間なんか要らないだろ。
1. 提案者「こんなアイディアがあります」
2. 決定者「費用対効果を数字で示せ」
2. 提案者「費用が○○円、利益が△△円を見込んでいます」
3. ○○ < △△か?
true → 4.へ
false → 5.へ
4. 決定者「そのアイディアを採用する」
→ 6.へ
5. 決定者「そのアイディアを却下する」
→ 6.へ
6. 決定者「次のアイディアはなんだ?」
結局のところ、「意思決定」(笑)とやらをやる人間はこんなロジックで動いているんだから、
人間なんかおく必要ない。Excelどころか、20年前のPCでBASICで組んでもいいレベル。
「費用対効果を出せ」「数字で示せ」「説明責任を果たせ」、って言うと非常に説得力が
あるように見えるけど、実は判断基準のなすりつけなんだよね。
>>542 会議に出す長い資料を作成する能力には長けているようだな。
>>534 C-h bでバインドも調べられないなら、emacsなんて使うな
KohanaV3はPHPなのにかなりいい出来だな
547 :
504:2010/05/02(日) 22:24:55
>>544 ブロックの区別をインデントで行ってる部分に馴染めないって言いたかったんだ。
emacsは余り関係ないね。
>>538 535ではないけど、おまいはそれ以外の何にLLを使うの?
俺はそういうのとかテキスト処理以外なら、C系のどれかで済ます。
GUIフロントエンドまで作れば良いじゃない
>>539 アプリケーションのバインディング用言語になってたり、GUIフロントエンドで手軽にGUI組めたり。
まぁ、知らなかった上に知る気もなかった人にとっては、その使い方は必要ないんだから、
コマンドラインツールとWebにだけ使ってればいいんだと思うけど。
>>548 俺か?
簡単なGUI組むときはPyQt4で書いてるし、自分で書いたの以外にもPyQtとかPyGtkで書かれたソフトも結構使ってるはず。
全部調べたわけじゃないから数はしらないが少なくともJavaよりは使用頻度高い。
重たいもの組むときはC系の方がいいとは思うが、そんなに重くないものだったらCよりもLLで組んでしまうことが多い。
そのへんは好みの問題だろうが、例えばCで画像扱おうと思ったらいくらOpenCVやらがあってもやっぱ面倒な気がする。
みんなGUI好きなんだな
老若男女、みんな大好きGUI
554 :
548:2010/05/03(月) 12:32:41
>>549 >>550 手軽に組むGUIフロントエンドって、それCUIのフロントエンドでよくね?って思うんだけど。
CUIフロントエンドじゃ間に合わない時に、IDEで複雑なGUIをぱぱっと作っちゃう。
>>551 Javaより使用頻度多いって、GUI関連でなのか?もしそうならLL+GUI勉強するわ。
最後の文はなんだ、知らずに喋ってたのか
556 :
548:2010/05/03(月) 12:39:34
>>555 んー、知ってるとは言えない。
Tk系とかWxRuby(Python)は触ったことあるぐらい。
557 :
551:2010/05/03(月) 12:40:43
>>554 少なくとも俺の使ってるソフトや、俺が適当に書くのでは、Javaより多い。
そうなってるのはLinuxデスクトップ使ってるからだと思うし(管理ツールのGUIが結構Pythonで書かれてる)
万人に薦めるつもりはないが。
CUIで入力が変わるごとに画像の表示やりなおしたりは難しそうだったのでGUIで書いた。
最近はGUIだって簡単に作れるんだから、そう大げさにとらえる必要はないよ。
>>556 RubyのGUIは最悪だからなぁ
>>554 の最後の行みたいな感覚になるのも止むを得ない
JRubyでSwingのラッパー書けば解決じゃね
Webでいいじゃん
561 :
デフォルトの名無しさん:2010/05/03(月) 13:42:33
>>554 > Javaより使用頻度多いって、GUI関連でなのか?もしそうならLL+GUI勉強するわ。
そこで、Scala(=LL言語) から、JavaのGUI(Swing)ライブラリを呼び出すのが最強。
うまくやれば、LL言語で、V2C並のアプリケーションが作れるだろう。
まずは、V2C試してみるのがお勧め。Java(Swing)でもここまで出来るのかと感動するぞ。
>>561 PyQtでいいじゃん。あれだと機能的にはQtと変わらない。
速度面では当然C++に劣るが、重いことしなければ実用上は問題ないレベル。
> Java(Swing)でもここまで出来るのかと感動するぞ。
って時点で、既に残念ライブラリ。
今は、Qtは、商用に使ってもタダだっけ?
ずっと昔に、仕事(組込み系)に使おうとしたらライセンス面倒だから辞めて、それ以来スルーしています。
JavaとかSwingは、昔から毛嫌いされてきたけど、
今の時代になって使ってみると、アレ?意外良いじゃん、って感じ。
ScalaとかJavaだったら Androidにも応用が利くし。
PyQtからC++のQt呼んだり
その逆って出来る?どうやんの?
PythonからQuickTime呼ぶとか正気か
釣れますか?(AAry
567 :
デフォルトの名無しさん:2010/05/03(月) 15:28:15
(´・ω・`) nullpo
しかしQtで検索したことのある人間なら誰でも身に染みているネタではある。
深いな
>>563 LGPL版はタダ。
Qtライブラリに手を加えないなら自分のソースはクローズドでもいいけど、
リバースエンジニアリングの禁止条項は入れられない。
ライセンスがゆるくなったPySideってのがあったと思うがそれはどうなんだ?
>>572 PySideがLGPLで、従来のPyQtはGPLのまんま。
574 :
548:2010/05/04(火) 14:45:29
うーん。いろいろいじってみたんだけど、IDE使い始めると
やっぱり静的言語がいいと思ってしまう。
俺がクソなのかな。まあいろいろ有難うでした。
時代はScalaへ…
576 :
デフォルトの名無しさん:2010/05/04(火) 19:44:27
クソ
型は静的な方が良い。動的が便利というのは1ヶ月で卒業する。
負け惜しみみたいでダサい
動的も静的も出来るのがいい。
ごもっとも
一画面たらずのスクリプトでいちいち変数宣言なんてやってられるかっての。
そう考えると、型推論というのは非常に良い妥協点である。
この話の流れだったら、Scalaお勧め。
今のところマイナーなのが悩み。
またおまえか
なら俺はOCamlと言ってみるぜ
>>579 オプショナルな型付けを導入した言語は今のところ珍しいが、
今後は流行るのかなあ。硬さを選べるとでも言うべきか
わざわざ型をつけるからには、
コンパイル時に多くのエラーを検出できる方がいいし、高速ならなおよい
かつ、動的な部分を十分残すからには、柔軟性をあまり犠牲にしたくもないw
部分的な型指定から型推論をがんばって、わからない部分は実行時に決定、
推論過程で矛盾が発生したらコンパイル時エラー、
ぐらいがいいとこ取りで理想的? とはいえ、なかなか簡単ではなさそう
LispとかVBあたりもそうじゃね
ここでCとPythonの間を狙ったgolangの登場
登場するなり消えた言語きたー?
>>590 Javaが登場したときもそんな反応は多かったが
15年ほど経った今はどうだ?
goは5年くらいで今のJavaの位置に来るだろう
goってマルチプラットフォームの位置づけなの?
CPUはx86_64がメインでx86, arm
OSはLinux, MacとNacl。
winへのportもやってるからぼちぼち動いてるかもしれんよ
俺も591に近い印象。うまく育てばC++の領域をかなり食うかもしれん
どの言語も上手く育てばいいのにね^^;
C#最高という結論か。
Windowアプリではそうなるかも
動的型というと、なんかアレだが、変数が全部object型と言ってしまうとそうでもなく思えてくるよ。
実際、インスタンス自体は型に縛られてて、ただ変数が型に縛られてないだけってのも結構あるし。
Win固有つかMS由来のモノはなあ
有料ソフトが嫌いでFreeBSD使ってるポール・グレアムはMSが衰退するとか言ってたけど、早くしてほしいよ
C#か。
コンパイラいらなくなって、マルチプラットフォームになって、
重い専用IDEに頼らなくても快適に書けるようになったら、
使うかどうか検討してもいいと思ってる。
少なくともLLとしては、それくらいの条件を満たしてないと議論の対象にもならんだろう。
何故かCやFortranでも議論の対象になるスレだから、このスレ的にはOKなのかもしれんが。
いやC#はLLじゃねーよ
>>601 ダックテスト風に言うなら、だ。
LLのような機能を持っていて、LLのように使えるなら、それはLLだ。
C#信者が言うように、複雑な処理もC#なら数行で出来るってのが本当なら、十分LLになりうる。
C#信者いわく、生産性はpythonの4倍らしいよ
プログラミングが出来ないキチガイ荒らしだったから信憑性はないけど
生産性4倍なら余った3/4の暇な時間は2chに割けるな
MS脳になったらかなりヤバいよね
あれに関わるならバランス取りが必要だよな
MS脳ってなに
>>603 生産性はxxのn倍って台詞をいろんなとこから集めてくると、どっかで循環参照してる気がする。
アンダース・ヘルスバーグがいるだけでC#を使う理由になる
生産性なんてフルスクラッチで車輪の再発明するんでもなけりゃせいぜい倍も変わらんだろ
ビジネスロジックなんてCで書いてもPHPで書いても同じようなもんだ
VBなら確実に遅くなる
なら倍速いマシンを使えばいいじゃない
C#がLLだとか言ってる人がいるあたり、PowerShellってまだ普及してないんかね。
Windows限定だけど、めちゃめちゃ強力なスクリプト環境なのに。
PowerShellってGUIok?
ok
この前、はてなブックマークでRubyからScalaに移行したってエントリーがあったんだけど、コメントじゃC#勧めてる人が多かった。
はてなユーザだとMS系よりオープンソース系の人が多いと思うんだけど、C#って人気あるんだなと思った。
>>615 C#は最強に現場主義的で工学的。
そんなところがJavaやRubyの対極にあると思う。PerlやPHPに近い。
個人的に「こうであるべき」が前面にでてる言語は使ってて楽しくない。
C#ってサーバーサイド書けるの?
クライアントアプリ用だと思ってた
もしそうなら比較するの自体おかしくないる
.netってむしろ
>>603 C#+VSなら実際そんなもん。たぶん全言語で最強の生産性になる。
VSとの組み合わせで使うことを前提としてるから、VSの支援をフルパワーで受けられる。
そもそもコードほとんど書かないしな。
Pythonとかの動的言語はIDEの支援の受けにくさで、どうしても不利。
ただ、俺はLinuxが好きだし、MSに依存してるって点で100%使わないけど。
>>618 普通に書ける。ただしWindowsServerで。
>>618 .NETは最初からASP.NET、ADO.NETでサーバーサイドを前面に出してる
まじか
C#すげーじゃん、最強じゃん
で、そこらへんのレン鯖で使えるの?それ
Windows Server用って書いてるでしょ(まあMonoもあるけど)
業務システムのサーバ用途が大半だと思う
そういうところではサーバサイドでも結構使われてる
.NETはRailsより出た時期早いから、当初はサーバサイドJavaより高生産性って
奴を売りにしてたぐらいだよ
JavaがPythonだとすると、C#はRubyだと言ってみる。
うちではASPは使ってないなあ。Web系は全部FreeBSDでPHP。
C#のサーバサイド用途はWindowsサービスだけやね。
C#はWindowsプラットフォームでのJavaやDelphi、VBの置換にはなり得るけど
LLのライバルかつったら違うんだよな
スクリプティングには全然向かないし
仕事のために学ぶんならLLよりずっとお勧めではある
・静的型故の型安全性+IDEの強力サポートがあります
・Javaと違ってデリゲートやプロパティがもともと使えたけど
今や型推論、ラムダ、クロージャ、ジェネレータ、匿名型、LINQとかあるよ
・ダックタイピングもできるようになりますた
・GUIはIDEでポトペタ可能です(Web系もそう)
・StringはUnicodeです
・CLR上の他言語との連携が、非常に容易です(ネイティブのffiも当然あります)
・まともに機能するスレッドや非同期I/O、抽象化されたevent構文がつかえます
いやC#の宣伝は他所でやれよ
参考資料だろ
いつからだっけ。この板でC#信者がC#スレ以外でも自信満々でC#の凄さを勝手に語り始めたりするようになったのは
メリットしか見えてないから怖いわ。マジで宗教じみてる
C#もScalaも手軽に使えるレン鯖が無いのが欠点だな
「宗教じみた」理由(MSが嫌いだからMS言語はWindows上でも使いたくないとか)
以外の具体的な理由があるのなら、反論するなり主張の誤りを指摘するなり
すればいいだけだろ
ハッカーは囲い込まれるのが嫌いだから
JavaがRubyだとすると、C#はPythonだと言ってみる。
JavaはCOBOL、C#はVBだと思っていたが
C#だけ全く別物に進化してしまったな
C#が悪いとか言ってないだろ。信者は悪いが
>>635 MSとしてはVBとC#で競合させる意味がないからな
JRubyがCPythonだとすると、J#がC++だと言ってみる。
俺は
>>626だが、別に「C#信者」ではないよ
>>603の言う「4倍」は疑わしいが、生産性が高いのは事実なように思えるので
その理由を列挙した
Monoはあるにしても、基本的にWindows用であって
クロスプラットフォームでないのがC#の最大の問題だが、そんなのは皆知ってるよな?
列挙したのも知ってるよ。散々宣伝してる奴がいるからな
胡散臭いCMみたいなレスには虫唾が走る。それだけ
C#の特徴を見ると、F#がScalaほどのインパクトを持ち得ない理由が分かる
F#とScalaの違いはさておき、
C#は同じ位置にあるJavaよりずっと「高級」な言語になってしまっているので、
C#で既に満足している人、あるいはC#すら使いこなしていない人が
Javaよりずっと多いのだろうと考えられる
本当に文系的な反応しかできない奴ばかりだな
呼び方なんてどうでもいいよ。有難がってる方がおかしいんだから
確かに元々敬称じゃねえしな
デファクトスタンダードになれば仕方なく使わなければいけなくなる
OSやOfficeと同じくMSの一人勝ち。それだけ
そりゃ秒給150ドルになるわな
けど汎用プログラミング言語はデファクトスタンダードとりにくいぜ。
特定分野のJavaScriptとかCOBOLみたいなもんか
>>631 MSがなぜ嫌われているか理由を挙げてごらんよ
お互いを尊重する宗教なら戦争にならない
MS原理主義を正義として他の宗教を狩ってるから戦争になる
MSは分かるがAppleがなんであんなに強気なのか分からねえ
新規を獲得するつもりがないのかな
信者だけでやるってのは悪くないと思うけどAppleの場合は信者すら蹴り倒してるからなぁ
C#はコンパイル型言語(非LL)じゃ一番しっくり来るな。変な癖がないのがいい。
monoは使った事ないけど、MSがUNIX系OSに移植すれば(できればVSも)、UNIX系OSでもあっという間に普及すると思う。
VBSscritみたいにIEに載せればいいのに。
糞スレチはどうでもいいよ死ね
Java, C#の話題のこのスレの守備範囲ってことでいいんじゃね?
>>654 因習にこだわる古い信者は害にしかならないことを良く知ってるからじゃね?
VBScriptがUNIXに載った日にはこの業界から足を洗いたい
>>653 Objective-Cも使えない新規ならいらないって事では。
ジョブズの言い分も分からないではない。Adobeは怠慢こきすぎ。
蹴り倒した相手ってAdobeだぜ
>>660 使えても使いたくない言語じゃない?ObjCって
気持ち悪い
引っ込み付かなくなってAppleが独自のFlashやSilverlite的なもの出したらウケる
Flashいらねぇって割にはSilverlightもJavaFXも対応しないんだろ
全部Objective-Cでそれなりのアプリケーション作ってねって事なんだよな
アホだろ
AppleとAdobeだけならただの企業エゴのぶつかりあいだが
Appleは結果的にデベロッパーにケンカ売ってるのと同じだよな
あれはいかにも拙い
2012とか2014とか言われるとJobsおまえそのときまで生きてんのかと
Flashが流行ってるのって、IDEの出来がいいって言うのが大きいでしょう。
Airとかはともかく、アニメーション作成ソフトって点から見れば、Flashを代替するのは非常に困難だと思う。
PhotoShop、イラレ、Fireworks、Dreamweaverと連携出来るのも有利だし。
悪チョンスクリプトのIDEとしてはあんまり評価良くないが
レコードチャイナ今落ちてるのにどっから引っ張って来たんだ
>>648 C#ってデファクトって程に普及してるのか?
サーバーサイドならむしろUNIXがデファクトだから、
C#使いたくても使えない状況だろ。
Winのアプリ作るにも別にC++があるし、Javaもアリだし。
なった後はその言語の良し悪しに関わらず、嫌でも使わなければいけなくなるって話だろ
675 :
673:2010/05/08(土) 12:52:25
>>674 ん?嫌でもC#を使わなければいけなくなってるのか?
> OSや...MSの一人勝ち
C#に関してはこれ違うでしょって言いたかった。
なればって言ってるのに、普及してるのか?なってるのか?っておかしくね
WindowsサーバでもC#って圧倒的に多いって訳じゃないよぜんぜん
ましてやGUIアプリになればC++やVBの方がぜんぜん多い
デファクトって言えるくらいまで普及する見込み無いから騙るだけ無駄
技術者集まらないからJavaでいいかみたいになっちゃうし
679 :
673:2010/05/08(土) 13:06:46
>>676 > 一人勝ち
> そりゃ秒給150ドルになるわな。
これらから
>>648はC#がデファクトになっている、もしくはなる可能性が
かなり高い、と見ていると思ったんだけど。(つまり
>>648の「なれば」は仮定ではない
こんな日本語の問題でつっかかってる自分がキモいし、別にどっちでもいいのでROMるわ。
何言ってんだコイツ
MSの製品でUNIX系に移植されて成功したものがかつてあるだろうか
Lua触ってみたけど言語仕様がスッキリしてて使いやすかった
ここじゃ全然話題にならないのはライブラリが少なすぎるから?
VM経由になるからじゃね
PHPは別格としても、rubyやpythonよりかはASP.NET(C#)の方が数は多いと思う。Perlに将来性があるとは思えないし。
MSに囲い込まれるのはいやだがAppleにならいい俺
ObjCはダルいが
MSに囲い込まれるのはいやだがAppleにならいい俺
ObjCはダルいが
pythonは何げにかなり多いぜ。
大事じゃないがエラー出たから二回書いちまったw
>>682 別に話題にしていいと思うけど、組み込み用途がメインだからじゃないの
GenieはLL?
これはひどいwwwwwwww
これFlashやSilverlightの代替?
MSとAppleで市場をかき回そうとするのも別にいいんだし仕方ないんだろうけど
あんまり幸せになる人はいないんじゃないかなあと
Adobeがプラットフォームに縛られないだけまだ良質に見えてくる
せっかくいろいろ統一の方向で自由がきくようになってきたと思ったら
また頑張って囲い込もうとするのな
それでもiPadは売れる。いつまでかはしらんが。
MSは長期で凋落しかないレガシー企業。ピークは過ぎた
ポカミスの多い俺はJavaScriptではやりたくない…
動的言語=ポカミス多い?
実行時にエラー出るか
コンパイル時にエラー出るか
の違いであって
ポカミスの量は変わらない
コンパイルエラーは必ず発見できるけど実行時エラーは常に発見できるとは限らない
バグの量は変わらなくても発見できるバグの量は違う
上でちょっとLuaの話出てたけど、テーブルをリストとして使ったときの
インデクスが1ベースなのと、変数のデフォルトスコープがグローバルなのが
好みじゃないなーと思った
HTML5がJavaScriptじゃなくってActionScriptで書けたらね。何でJS2.0ってぽしゃったんだろう。JSで長いコード書けって拷問だよな。
JSはもとの意図をはるかに超えて利用されるようになってしまったからなー
かつてのawkやPerl、Tclにもそういう面は多分にあっただろうけど
>>700 コンパイルエラーが無くなればバグは無くなると思ってるひとですねわかります
>>703 元の意図をはるかに超えて使われている最たるものは C
ぬるぽの意味を考えればすぐわかるな
あるフラグを立てるときに
一方では flag = 1
一方では flug = 1
みたいなことやってしまった場合に
コンパイラなら気付く可能性が高いが
インタプリタだとスルーしてしまうな
インタプリタでも初期化されてませんWarning出るけども
エディタに一度しか出現していない識別子をハイライトする機能でも付けときゃいい
>>708 マルチスレッドとかだとそれで見逃す場合がある
>>706 言いたいことは分かるが
それ「コンパイラ」とか「インタプリタ」とか関係ねーから
JavaScriptに関しては、
常にvarを要求するようにすればいいものを、varは不要で、varなしだと
グローバルになってしまう仕様がよくないんだよな
varが必須なら、
>>706はエラーにできるよ
perl だと use strict; 使えば解決だけど
php とか ruby とか python とかだとどうすんだろ
>>713 実行時エラーにすらならないから、単体テストしかない
PHPなんて初心者限定簡易スクリプトなんて使ったことないから知らん
JSってPHP以下じゃん
PHPも一応未定義の変数を参照すれば警告が出るな。けど、ブロックスコープレベルで変数の監視が出来るのはLLじゃPerlだけだな。マイナーなLLは知らん。
PythonやRubyはやっぱだめだな
>>719 PHPのマルチパラダイムは悪いマルチパラダイム
この例では代入がででることが重要
勝者PHP
確かにPythonやRubyはででらないもんな
Groovy は型指定できて,動的型は def キーワードで宣言できなかったっけ。
次期JavaScriptにはstrictモードが
指定できるようになるんだろ?
はやく使いたいなー。
はやくででるようになるといいぬ
変数の安全性については
Groovy > Perl > PHP > JavaScript > Ruby = Python
守るべき仕様が存在するってのはJSのいいところ
IEさん標準違反っぷりはひどいが、IE9では準拠に積極的
要するにあと3年は我慢が必要と言うことだ
現実的にはJS(とCSS)の実装はブラウザメーカー毎に様々。今どきこんなバッドノウハウの固まりの言語はない。
日本はガラパゴスがーとか言う奴いるけどガラパゴスなんて世界共通だよな
俺の頭ん中もガラパゴスだし
>>731 DOMはともかく、ESの範囲では言語仕様や標準ライブラリの非互換性はそんなにないぞ
getterやらsetterやら__proto__やらの独自拡張はあるにはあるけど
>>729 遅すぎ、だが全く期待してなかったので、本当ならうれしい。
IE8の時も標準にしますとか言ってた気が
(やろうとおもえば)出来るけどしない
これが囲い込みの鉄則
だから絶対無理
全角とか
DBは自分で選べるからな。DBライブラリ自体を作成しない限りは、そのDBの事だけ考えればいい。
JSはクライアント側がバラバラだからな…
そのうちJavaScriptが世界を征服
Yes, we can!
745 :
デフォルトの名無しさん:2010/05/17(月) 00:38:41
>>728 クズが火病ったwwwwwwwwwwwww
>>745はRuby厨かPython厨だろw
ざまぁwwwwww
どう見ても火病ってるのは自分だという
煽ってないでネタを投下しろよ
なでしこのスレがあると聞いてやってきました
ゆっくりしていってね。
perlでFA
他は不要
python3.0スレ見てて知ったんだが、メソッドやプロパティの命名規則が汚いんだな
こんなのPHPだけかと思ってたが…
その点、RubyやScalaは統一されてて美しいな
えっ
なんでRubyがでてくんのw
レスはやw
Rubyの有名なライブラリでこんな適当な命名してるメソッドとかあるの?
少なくともmatzはネーミングにはかなりうるさいよね
PHPは言うまでもなくグダクダだよね
Perlは使ったことないから名前あげなかった
140 名前:デフォルトの名無しさん [sage] :2010/02/28(日) 18:37:24
Python3.xで俺が期待したこと
ライブラリの命名規則を統一してほしかった...orz
classmethod, assertEqual, set_autholizer
orzorzorz
厳格なJavaでもいくつかミスはあるけどなぁ
Javaにミスがあるからといって、PythonやPHPの命名が汚いことの免罪符にはならないなぁ
後方互換をぶったぎったPython3ですらそういうところが直らなかったということは、ネーミングの統一に気を使うという意識がパイソンコミュでは薄いんだろうなぁと思った
コードの読みやすさをアピってるのに、そんなところが汚いなんて思わなかったからビックリしてさw
人によるだろうけど、書いてるときもそういうの気になるからこんな初歩的な規則はビシッと統一されてて欲しいね、個人的には
作ってる人はそれぞれ自分が綺麗だと思う規則で倒立してると思うよ
それが禿なら全部自分一人で練り直せば良いじゃん
758 :
デフォルトの名無しさん:2010/05/23(日) 15:30:14
作ってる人はそれぞれ自分が綺麗だと思う規則で統一してると思うよ
それが嫌なら全部自分一人で作り直せば良いじゃん
統一されてないじゃん
>>754 統一しないように統一している、ってことなら君のいうとおりだけどw
引用してきたpython3スレにあったが、欧米人はこういうところズボラなのかねぇ
Scalaはきれいに統一されてるからそうとも言い切れない気がするんだが
Python3で後方互換性を切っているのは、言語仕様や言語組み込みの機能。
ライブラリのAPIに関しては、後方互換性を残して、Python3への移行をしやすくする。
APIの変更は、古いAPIをdeprecatedにしながらしばらくの間新しいAPIと並行サポートして、
充分時間が経ってからdeprecatedのAPIを捨てる。
例えばPythonのthreadingモジュールでは、 mixedCase から lower_case_with_underscore
への移行期間中で、両方がサポートされている。将来的に mixedCase が deprecated -> 廃止
の道をたどる。
ただし、assertEqual は、unittest がJUnitをリファレンスとして設計されているから、
それに従った命名にしている。
パッケージ名やモジュール名は大文字小文字を区別しないファイルシステムがあるから
Python3で小文字に統一されたけど、メソッド名や属性名は、他の言語のライブラリから
移植されたライブラリでは元の命名を維持している。
なるほど
Python3でもまだ緩やかな移行(並行)が続いていたり、「ライブラリでは移植元の命名規則を採用する」というPythonの統一基準がある
というのを知らないPython素人の自分がパッと見で汚く見えただけで、ちゃんと理屈はあるのね
それは失礼しました
Pythonユーザーでも引用したようなレスを書くってことは、あまり一般に浸透してない基準なのかもね
ちんこさんキター!
PHPのメソッド名の問題はラクダ式かハイフンでつなぐかとかって所じゃなくって、
組込み関数が大量にありすぎて、収拾がつかないって点だと思う。
さらに名前空間がつい最近までなかったから、クラス名を_で長くつなげざるを得ないっていう。
移植元の命名規則を採用する意味あんの?
>>764 まったくないね
不統一に見えるだけだと思う
もし移植元がC#だったらメソッド名は大文字のキャメルケースになるのか?
んなアホなw
>>767 C#からの移植はないけど、例えば wxPython なら、binding 作成するときに勝手に CamelCase から
lower_case への変換はしないよ。
>>764,766
複数の言語でプログラムを書く人が、同じライブラリなら同じ名前を使える。
CamelCaseなメソッド名でクラスと混同しないの?selfが絶対つくんだっけ
命名を変換ったってcamelやpascalをlowerに変えるとかでそ
元のライブラリわかってる人はメソッド探すのもそんな苦でもなさそうだが。
てかインテリセンスがないからなのかな?
>>770 その質問で、「混同しないの?」の主語は、プログラマ?それともインタプリタ?
プログラマであれば、C#なんかがクラスとメソッドが両方CamelCaseになっているけど、
大きな問題にはなっていない。
インタプリタであれば、クラスは基本的にモジュールのメンバで、メソッドはクラスのメンバだから、
クラスとメソッドで同じ名前がぶつかる事はほとんど無い。
関数とクラスならぶつかる可能性があるけれども、ちゃんとモジュール毎に名前空間が分かれているし、
他の言語で実用されているんだから名前がぶつかることはないだろうな。
>>760 >Python3で後方互換性を切っているのは、言語仕様や言語組み込みの機能。
>ライブラリのAPIに関しては、後方互換性を残して、Python3への移行をしやすくする。
これ意味ねえよな
言語仕様レベルで互換性がないのに、改修すべきことをせずにライブラリの後方互換性を残すとかバカだろ
けっきょくこういう学習の末に学んだことは、言語は問題じゃないってことだ。
大事なのは言語でなにをするか。実ははじめからこんなのは知ってたんだが、
いろんな言語に気が散らされて定期的に忘れてしまう。もちろん今はもう忘れ
ることはないし、お前もそうあるべきだ。
お前が学んで使うプログラミング言語は大事じゃない。ぜったいにプログラミ
ング言語界隈の宗教論争に巻き込まれちゃダメだ。プログラミング言語はそれ
を使っておもしろいことをするためのツールだという本来の目的が見えなくな
ってしまうから。
>>774 言語仕様や組み込み機能は、後方互換性を維持しながら移行するのが難しいから、
どっかの段階で後方互換性を持たない切り替えが必要。
それに対して、APIは、後方互換性を残しながらの移行が可能。
後方互換性を残せるのに残さない理由があるの?
うるせぇ 駄目なものは駄目なんだよ
はい
俺は言語なんて、ちょっとややこしい設定ファイルくらいにしか思ってない
でも設定ファイルって,通常ステートフルじゃなくね?
>>774 まったくだ。
命名ガイドラインを示し直して、少なくとも標準で入ってるものについては、
ガイドラインに反するものは改名して、旧名は将来的に廃止にしてほしかった。
784 :
101:2010/05/24(月) 10:29:25
ひとつのソースコード内に異なる命名規則が混在することはかなり読みづらい(その理由を知らない初見ならなおさら)と思うんだけど、Pythonではこれが当たり前なの?
信じられんな
しかもそのコードが世間的に読みやすい言語とか言われてるなんて
>>784 >ひとつのソースコード内に異なる命名規則が混在することはかなり読みづらい
統一されていたらきれいだなーとは思うけど、統一されてなくても読みづらいということはない。
Pythonは構文がシンプルで規則正しいから、名前のスタイルから「それが何なのか」を推測する必要性が薄い。
>>783 Python3は、Python3000やRuby2やPerl6とは違って、Python2と別言語でも無ければ遠い理想郷でもない
現実の言語だからな。
タダでさえ難しいPython2からの移行をさらに難しくしてまでこのタイミングで命名規則の統一をするのは、
「愚かな一貫性」だろう。
あと、改名と旧名の廃止予定は、同時にはできない。
廃止予定(deprecated)にしてしまうと、(抑止可能だけど鬱陶しい)DeprecatedWarningメッセージが出るから、
最低でも1バージョンは間に挟む必要がある。
例えば hashlib モジュールがPython2.5で入って、md5モジュールがdeprecatedになったのはPython2.6。
統一されててきれい、統一されてなくてもそんなことはないって人より
統一されてて普通、統一されてないときたないって感覚の人のほうが多そう
>>785 Python3とPython3000って同じじゃないの?
Ruby2やPerl6が理想郷っていう認識についても良かったら教えてください。
うるせぇ
>>787 Python3000 は、3000年リリース予定の架空の言語として考えられていたけれど、
実際にリリースしてPython2から移行を進めていくという方向性で動き出してから、
Python3 という現実主義の言語になった。
Ruby 2.0 は、まだ現実のスケジュールがでてないから、空想上の理想の言語。
Perl 6 は、Perl 5 からの移行を積極的に進める気のない、別言語。
>>760 Python3スレでorzってかいたの俺だけど(どうでもいいか
その規則自体が嫌だわ。Rubyみたいにいちいちアンダースコア記法に直してほしいな。
>>761 threadingモジュールの件は恥ながら知らなかった。
けど、__builtins__.classmethodなんかがアンダースコアになることは
一生ないだろうし、httplibのAPI群なんかもないだろうなあ。
好きな言語だけに非常に残念。
ってかPythonって全体的に名前が格好良くない気がする。とりあえずRubyと比較してみると
Python <= Ruby
Django < Ruby on Rails
easy_install, pip < RubyGems
pydoc < ri
Jython < JRuby
WSGI < Rack
等々。
ただし、endないのがイケメンすぎて全部カバーしちゃうかも。
>>775 このスレはその宗教戦争を楽しむところだと思ってる。
バージョン違いで互換性ないとかもうでぐだぐだだよな、、どれも
俺はなるべくコード資産はJava/C#に移していってるよ
ジェイソンはかっこいいだろ
>>790 classmethod はPEP8に違反してないからな。
Function names should be lowercase, with words separated by underscores
as necessary to improve readability.
アンダースコアは、単語の区切りというより、句の区切り。
set_maxclients は set_max_clients よりも良い。
中高生の頃、英語の文章を理解するために、句ごとに / で切らなかった?
あの / が _ になってる。
単語の区切りなんてアンダースコア無くてもすぐにわかるから、句の区切りが一目で判る方が良い。
Java/C#ってバージョン間で互換性あったっけ?
>>790 >ってかPythonって全体的に名前が格好良くない気がする。とりあえずRubyと比較してみると
これわかるわー
名前ダサいだけで使う気失せるw
ダサいのはどうでもいいけど、strが組み込み型名なのでstrって名前の変数作るのがあんまり推奨されないってのはなんとかしてほしい。
今更変えられないからねえ
互換性と言っても程度によるけど、Perlの場合、言語仕様自体はほとんど変わってないけど、CPANモジュールに強烈な流行廃りや仕様の変更がある。
トータルで判断すればJavaやC#は互換性が高いと言えると思う。
俺は全部大文字にすると定数扱いとか、そういうのがしっくり来ない。
結局、javaやC#は、LLでくくっちゃうのか?
くくっちゃおうぜ。カオスの中からきっといいアイデアが見つかるのだ。
機械語とアセンブラ以外はLL
>>785 >タダでさえ難しいPython2からの移行をさらに難しくしてまでこのタイミングで命名規則の統一をするのは、
>「愚かな一貫性」だろう。
こういうのが信者だよなあ。まずい点があっても絶対にそれを認めようとしない。
Python3 では dict.has_key() をなくしたり StringIO を io モジュールに移動したりと整理しているんだから
命名規則も変更するチャンスだったろうに。
assertTrue() とかバカかと思った。assertEqual() も三単元のsがないし。
もういいじゃん。golangで。
なんか懐かしい名前を聞いた
>>804 組み込み型のメソッドやパッケージの移動とメソッドの名前の変更を同レベルで語ってるあたり、
アンチPythonは現実が見えてないなぁ。
組み込み型の方がメソッド名の段階的な移行が難しいし、逆にパッケージの移動は import 文を高精度で
自動的に変換できるので大胆なリファクタリングが可能。
それに対して、ライブラリのメソッド名なんかは、静的に型を判別できない言語では自動で変換するのが難しい。
Python3への移行が終わってからPython4までの間にゆっくり変えていけば良い。
命名規則が混ざっているのは汚くても、実際に致命的な問題にはならないことは、Python2がここまで
普及したことで証明されている。
研究者間でlushとか流行らんかな
>>807 表面上の叩きやすいところを叩いているだけだから真面目に反論するだけムダだよ。
事業仕分けみたいなもんだな
使いやすい使いにくい以上の差って、それほど無いんだよね結局
設計や実装は実際どれもすげーなーとしか思わんわけで
俺のレベルでは、って話ですまん
命名規則をその言語用に変えても致命的な問題ないことはpython以外の普及してる言語で証明できないかな?
>>812 Javaなんか徹底してるんじゃね?
「問題ない」証明は無理でも、あの強制力は一つの真理を表してるような気はする
>>804 初めの方は同意なんだけど…
三単現のsって、主語ないのにどこに出てくる要素あるんだwww
>>813 でも、それがいいとは思わないんだよね。
まったく。
別ライブラリから持ってきたものは、そっちの命名規則使うってのは方針としていいと思うんだが。
ラッパー作る人に面倒なこと考えさせないって意味で。
それ以外の部分は統一すりゃいいのに。
で、やる機会があるとすればPython3への移行のときしかなかった。
4のときにとか言ってる人はなんだかなぁ。それこそ、西暦3000年まで直す気ないだろ。
>>815 それはもう好き嫌いのレベルになっちゃうかと思った
迷わず行けよってことでいいじゃないか面倒くせえ
俺はJavaの命名規則だけは好きだ
MSの命名規則は好きじゃない好きじゃないからつい違うことをしてしまってカオス
個人レベルでも規約レベルでも単純にそれだけのこと
じゃないのかなあ(←迷ってる)
てか、普通は統一するもんじゃないの?
パイソンみたいに統一せずに元ネタの命名規則に依存を方針としてる言語ってほかにあるの?
この方針って、あくまで「元ネタ依存できる範囲で」という前提条件がつくんじゃないの?
できなかったときはパイソン風に書き換えるなら、最初から全部パイソン風にしろよって話にならんの?
ラクダ式とかハイフン繋ぎとかが混在したコードとか気持ち悪すぎるわw
郷に入っては郷に従え
だれかこれをくどいくらいの、説話混じりで三回忌の坊さんくらい
くどい説教込みの解説付きで英訳してくれ
それできっと全て丸く収まる
気持ち悪いね、インデントが揃ってないコードの次ぐらいに気持ち悪い
>>821 ほんとだよ
頭隠して尻隠さずって言葉がピッタリだね
インデントしかそろってないPython
perl読むよかはるかにマシ
>>804 assertTrue()はクソすぎる。いくらPythonでもスクリプト言語としての自覚
が足りなすぎ。
>>807 互換性を気にするPythonが2->3で思い切ってそれを破ったのに、
それで名前変わらないならもう変える気がないとしか言えないだろ。
致命的な問題がないなんてみんな知ってるよ。フィーリングの問題。
でもフィーリングは特にLLでは重要な要素。
しかもリファクタリングできないって、エイリアスつけとけばいい話だろ。
まさか、名前がふたつあるなんてPythonicじゃないみたいな?
>>812 LLではRuby。他言語から持ってきたライブラリもアンダースコア記法に変えてる。
たぶん問題は起きてない。
>>820 自分の国(Python)がより良くなって欲しいとは思わないのか?
あの命名規則をみて、これがPythonのやり方なんて思ってるのなら、
相当なアホか洗脳されきってるかのどっちかだろ。
>>825 なんども既出だが、APIの変更は互換性を維持したまま緩やかな廃止プロセスが利用できるし、
メソッド名を変えたらソースコードの変換が不確実になるから、移行作業が難しくなる。
Python3への移行が完了してからAPIのリファクタリングしたので充分。
今は名前の統一よりも先にするべきことがある。
LLだって、フィーリングよりも、現実性、互換性、信頼性が大事だ。
wxRubyはメソッド名をRuby風にしているけど、メソッド名がwx風なwxPythonの方が広く使われている。
Rubyは名前を頑張って統一する前に他にすることがある気がする。
あと、名前が他言語と共通になっていると、名前で検索したら多言語の情報も引っかかるから、
wxPythonの使い方で判らない部分がwxWidgetsのコードサンプルを見て理解できたりする。
検索容易性は、同じライブラリの他言語バージョンと名前をできるだけ統一するメリットだな。
他には、wxPythonだとCamelCaseのメソッド名が出てきたらwxPythonのAPIで、
それ以外の名前はユーザーが作ったメソッドだと一瞬で判別できるというメリットもある。
間違ってオーバーライドするつもりがないメソッドをオーバーライドしてしまうというミスも避けられる。
>>826 前半と後半で食い違ってるように見えるが、
前半の「修正するけどまだ先」なのが開発陣の考えで
後半の「直さなくてよい」的なのが個人の主張?
ちなみにこういう変わった命名規則をもつ言語はPython以外に存在する?
>>826 >Rubyは名前を頑張って統一する前に他にすることがある気がする。
あと、これは逆だと思うよ
あなた自身がいってるように一度付けた名前は簡単には変えられない
他にやることがどんなことかわからんが、それが後からでも容易に変更改善できることなら、後回しで良いと思う
PHPがいい例だとおもう
命名の統一より機能実装を優先してきたから、いま名前がかなり破綻してきてる
そのおかげでここまで普及したとも言えるかもしれないが、純粋に言語として見た場合はそれが正しいとは言えない
だから、よそからもってきたのはよその名付け方に合わせた方がいいんだって。
ラッパー作ってくれる人に名前がどうこうなんて面倒な問題を負わせないためにも。
面倒が少なかったら作る人が増えてラッパーが充実する。
統一感ないと気持ち悪くて使えないなんてごちゃごちゃ言ってる人はどうせろくにプログラム経験のない奴だ。
例えばCで標準ライブラリとWin32API同時に使うだけで名前の統一性なんて破綻するんだから。
それよりも問題は、よそから持ってきたわけでもないのに名前が統一されてないことだろう。
830 :
829:2010/05/26(水) 10:20:42
一応、つっこまれそうなので補足しとく。
名前は統一した方が望ましいけれど、そうしなければならないってほど重要ではないと思ってる。
新たにラッパー作る人に圧力をかけないために、既存のラッパーの名前変更は望まないけど、
新たにラッパーじゃないパッケージ作る人や、普通のPythonプログラマーに守るべき指針を示すために、
そうでないパッケージはPythonらしい名前の付け方にしてしまえばいい。
C/C++があんなに名付けルールごちゃごちゃなのにそれなりにはうまくやってるのだからLLだってそうできない理由はないだろうが、
C/C++はもう今更だが歴史の浅いLLなら、指針をきっちり示して、例を示せば綺麗になるのだから、綺麗にすればいいと思ってる。
>>829 > 統一感ないと気持ち悪くて使えないなんてごちゃごちゃ言ってる人は
> どうせろくにプログラム経験のない奴だ。
そりゃまぁ経験者たちは shit とか悪態つきつつも納得してくれるかも知れんけどさ。
でも初心者には,言語に標準添付なライブラリとよそから持ってきたライブラリの
区別なんてつかないっしょ?
全部「その言語に用意されている機能」としか思わないはず。
で,それらに違和感を感じるのは十分あり得ると思うんだが。
初心者への訴求も大事なんじゃないの。
初心者は、そもそも大文字と小文字が混ざっててもそういうものだとしか思わないよ。
#include がおまじないと思うのと同じでね。
初心者への訴求よりも、Python2からPython3への移行をなるべく楽にするのが優先。
ライブラリは作る人より使う人のが圧倒的に多いんだから
命名規則変換ぐらい頑張ってくれよとも思うが
てかナニも考えずに機械的にできるっしょ?命名変換、そんな圧力になる?
Pythonはいつから教育に使える言語を目指さなくなったんだ
>>829 >面倒が少なかったら作る人が増えてラッパーが充実する。
言語の普及率の前では微々たるさだと思うが、具体的にPython以外にこの命名規則を採用してる言語を教えてくれ
>>832 > 初心者は、そもそも大文字と小文字が混ざっててもそういうものだとしか思わないよ。
いやいや,それはそうかも知れないけどさ,
> #include がおまじないと思うのと同じでね。
例えば,そのおまじないが,
#include <stdio.h>
と
%include |stdio.h|
と
!include =stdio.h=
などが混在していたら,嫌にならない? ということだと思うのだが。
言語自体の初心者は unittest は使わんから無問題
つーか命名規則なんてライブラリの中で一貫性があれば十分じゃね?
ライブラリをまたがって統一する必要はないように思うんだが。
>>826 > あと、名前が他言語と共通になっていると、名前で検索したら多言語の情報も引っかかるから、
> ...
> 検索容易性は、同じライブラリの他言語バージョンと名前をできるだけ統一するメリットだな。
これはそうかもね。
変に名前を変えられて混乱させられる恐れもないしね。
こま(ry
>>833 そうすること自体は簡単だが、ちょっとした間違いに対して君のように、
使う人のこと考えろ、それくらいできるだろ、やれ。と言う人が出てくるのが
作者のモチベーションを下げる原因。
>>837 そうなんだ、でも話しあうのっておかしくね?他言語ライブラリの移植はpythonではもうそう決まってるんでしょ?
pythonのライブラリの命名規則の方針自体を変えようって話し合ったてんならわかるけど
>>845 unittest は元々はJUnitから移植されたけど、今は互換性が無い別物。
あと、バインディングみたいにC言語で実装されているもののPythonインタフェースならともかく、
ピュアPythonによる再実装の場合は、Pythonの命名に従ったほうがいいだろうな。
自作クラスの命名が統一されてなくて生きるのが辛い
よくある
>>846 >unittest は元々はJUnitから移植されたけど、今は互換性が無い別物。
だよねー、だから
>>829 >よそからもってきたのはよその名付け方に合わせた方がいいんだって。
こんなこと言うやつが存在することにびっくり。
>>826 >あと、名前が他言語と共通になっていると、名前で検索したら多言語の情報も引っかかるから、
>wxPythonの使い方で判らない部分がwxWidgetsのコードサンプルを見て理解できたりする。
>検索容易性は、同じライブラリの他言語バージョンと名前をできるだけ統一するメリットだな。
wxPythonがどういうのか知らんけど、Python の unittest はドキュメントがしっかり書かれてあるから
JUnitのドキュメントを参考にする必要はまるでない。
assertEqual は assert_equals にすべきだった。
そしてその最大のチャンスがPython3.0だったのに、頭の固い連中のせいで残念な結果に。
>>851 >そしてその最大のチャンスがPython3.0だった
ダウト
なんども既出だが、Python3.0 への移行に伴なう痛みを最低限にするために、
unittest の命名規則変更なんて後回しでOK。
下位互換性を損なうというのは、何をやってもOKという意味ではない。
後回しにした痛みがそのうちやってくるんでしょ?
そんな段階的にきてそのたびにソースコード変更が必要なら
むしろ一気にって感じじゃね?
>>853 並列してサポートされる期間が何年もあれば、利用者はその期間のうちの好きなタイミングで切り替えられる。
Python3へ切り替えるにはテストを全部修正しないといけないなんてなったら、Python3への移行が
全然進まない。
Python3 で下位互換性を失う修正が入っているのは、下位互換性を維持したまま改良することが
不可能 or 現実的でないほど難しい修正だから。
そうじゃないタダのAPI修正を同時に決行して移行コストを上げるのはただのバカ。
PythonにおけるAPI修正の一般的なプロセスを理解していれば、Python3と同時にAPIの切り替えを
しようなんてバカは言えないはずだよ。
Python3への移行ガイドでも、ライブラリはAPIの互換性を可能な限り維持して並列サポートする
ようにっていう指針が示されている。
CPU設計におけるTick Tack戦略みたいなものだね。
リスクの高いプロセス進化と、リスクの高いコア設計進化は、同時には実行しない。
GoってScalaのコンパイルが早くなったらいらない子じゃね
Goはネーミングが失敗だろ
Golangを正式名称にすべきだったと思う
Goって一般文章の中に出まくるから情報を検索できない
go naming considered harmful
JavaVMはメモリ食い過ぎだし、標準APIがOS非依存を目指しているために
OS依存のシステムコールを使いにくかったりするから、Goも必要だろ。
Goは、Java、C、C++、Python、それぞれから少しずつシェアを奪って、
充分メジャーな言語になると思う。
日本では流行らないよ
もっとマイナーな言語を語るスレはないのか
GoならD言語の方がまだいい
それならCなんてもっと終わってるし
GoはGo言語って呼べば良いんじゃないのか。
GoもScalaもスクリプト言語ではないからスレ違いな
>>864 普通はANSI CとかObjectivCとかUNIX Cとかで検索するから
そのうちANSI GOとかObjectiv GoとかUNIX GOとか出てくるだろ
Cは終わってるんじゃなくて枯れてるんだろ
終わってるってのは検索性の話だろう
Java/C/C#/goはスレ違い
>>852 >unittest の命名規則変更なんて後回しでOK。
信者乙。なんか前提がおかしいよね。
unittestは将来も命名規則を変更するつもりがないんでしょ?
そもそも変更するつもりがものを「命名規則変更なんて後回しでOK」とか言い出すのは意味わかんない。
ここで説明すべきは「将来にわたっても変更しない理由」であって、「3.0で変更しない理由」じゃないよ。
>>854 >Python3 で下位互換性を失う修正が入っているのは、下位互換性を維持したまま改良することが
>不可能 or 現実的でないほど難しい修正だから。
>そうじゃないタダのAPI修正を同時に決行して移行コストを上げるのはただのバカ。
unittestの関数名の変更なんて、それこそ互換性を維持したまま簡単に変更できるものじゃないか。
assert_equal = assertEqual
とするだけ。これが難しいか?そんなわけないよね。
だから、unittestの関数名が変更されないのは、単に開発陣がそう決めたというだけのことであって、互換性は関係ない。
>>873 >ここで説明すべきは「将来にわたっても変更しない理由」であって、「3.0で変更しない理由」じゃないよ。
なんで?
俺は「Python3でバッサリ変更するべきだった」という主張に反論しているだけで、
将来にわたっても変更しないなんて一言も言ってないが?
並列サポートとやらを3.0を出したと同時に出すべきだったね、いつ出んのかしんねーけど
結構命名規則とか統一感を重視してる人が多いように見える(自分もそう)けど、そういう人達からみて命名規則とか統一感がしっかりしてる言語ってどんなのが挙がる?
自分はRubyかなぁやっぱ
オブジェクト指向言語全部
>>876 Javaかな。自分としては、あのキャメルキャメルな命名は嫌いだけど
Objective COBOL始まったな
>>876 Rubyはendと}の両方が構文に出てくるのが受け入れられなかった。
>>876 Pythonで命名規則が統一されていないのは unittest とかごく一部だけ。
Rubyは命名規則以前に、Perlと同じ「やり方は幾つでもある」方針を取っているために
API設計方針が統一されていないので、ライブラリの使い方とか把握するのが面倒。
そりゃJavaとかC#とかでしょう。
最近話題のscalaはその点ではどう?
javaとだいたい同じなんじゃね?
DSLを意識して標準の命名規則と違うのにするってことはありそうだけど
>>856 KMCのひとか
こんな卑下もじゃだったっけ?
やることは何言語使っても同じなんだから他の言語で読み刈ればいいのでは
PythonのバイナリをハックするんじゃなくてPython使ってハックする本でしょ?
go 用のツールがまだないって話ですがなにか
え?
これから趣味で覚えるならPythonだろうなあ。
あとJavaScriptとか
>>882 そんなことはどうでもいい。命名規則の話だ。ごく一部だけでも統一されてないのがあったら、それは統一されてない。
俺だってRuby?はぁ?って思ってるPython使いだが、お前みたいな信者には迷惑してる。
>>893 >>876 へのレスなのに、「俺だってRuby?はぁ?って思ってるPython使い」が必死に反論するの?
PEP8の最初に、
A Foolish Consistency is the Hobgoblin of Little Minds
ってあるんだよな。
このルールは、その下の全てのPEPに優先されている。
つまり、名前の修正のコストパフォーマンスが悪いなら古い名前を維持することすらも、
Pythonの命名規則のうちで、unittestはPEP8にしっかりと準拠している。
Pythonは理想より現実を優先する言語だから、潔癖症には向かない。
潔癖症はHaskellでも使えば良い。
Pythonって普段は潔癖に見えるんだけどなあ
Pythonのきれいさは見かけだけだからな
なんていうか、簡潔さより
正規化にこだわる言語のような印象がある
名実ともにきれいなのはJavaくらいじゃねマジで
MFCだろ常考
>>874 >なんで?
>俺は「Python3でバッサリ変更するべきだった」という主張に反論しているだけで、
>将来にわたっても変更しないなんて一言も言ってないが?
873と825をみれ。
>>825 >互換性を気にするPythonが2->3で思い切ってそれを破ったのに、
>それで名前変わらないならもう変える気がないとしか言えないだろ。
ふつうはこう思うよね。
あと
>unittestの関数名の変更なんて、それこそ互換性を維持したまま簡単に変更できるものじゃないか。
>assert_equal = assertEqual
>とするだけ。これが難しいか?そんなわけないよね。
この部分には反論してないってことは、
>>854 >Python3 で下位互換性を失う修正が入っているのは、下位互換性を維持したまま改良することが
>不可能 or 現実的でないほど難しい修正だから。
この主張は間違いってことになっちゃうよ。
別にそんなにこだわる内容じゃないと思うけどな。Rubyの場合、メソッドの命名規則とかより、覚えなきゃ行けない規約が多すぎるのが嫌だ。
>>901 >>俺は「Python3でバッサリ変更するべきだった」という主張に反論しているだけで、
>>将来にわたっても変更しないなんて一言も言ってないが?
>873と825をみれ。
どのスレを見ても、将来永劫変えるべきじゃないなんて主張は無いが?
>>互換性を気にするPythonが2->3で思い切ってそれを破ったのに、
>>それで名前変わらないならもう変える気がないとしか言えないだろ。
>ふつうはこう思うよね。
お前の普通を押し付けるな。
お前はライブラリを何個メンテナンスしている?
>>854 が正解
>>unittestの関数名の変更なんて、それこそ互換性を維持したまま簡単に変更できるものじゃないか。
>>assert_equal = assertEqual
>>とするだけ。これが難しいか?そんなわけないよね。
>この部分には反論してないってことは、
>>Python3 で下位互換性を失う修正が入っているのは、下位互換性を維持したまま改良することが
>>不可能 or 現実的でないほど難しい修正だから。
>この主張は間違いってことになっちゃうよ。
お前日本語理解できる?
互換性を維持したまま改良できるなら、Python3.0 でやる必要はないと言っているんだが?
Python 3.0 は、あくまでも組み込み型の変更、old style class削除などの下位互換性を維持したままの
移行が難しい物の修正であって、unittestの命名規則変更なんて労多くて功少ないものは後回し。
俺は2.6使ってます(キリッ
>>895 ごく一部だけ、なんて痛々しいこと書いてるから。
> PEP8の最初に、
> A Foolish Consistency is the Hobgoblin of Little Minds
> ってあるんだよな。
> このルールは、その下の全てのPEPに優先されている。
だったら初めからそれを出せばよかった。
統一する気が初めからない、というのと、統一されてないのはごく一部だけ、という主張は全く異なるのだから。
> 潔癖症はHaskellでも使えば良い。
その認識はあまりに残念。
>>903 > unittestの命名規則変更なんて労多くて功少ないものは後回し。
標準で入ってるのに限って
>>assert_equal = assertEqual
のようにすることが、そこまで労が多いとは思えない。
> 互換性を維持したまま改良できるなら、Python3.0 でやる必要はないと言っているんだが?
やる必要がないことは、やらない理由にはならない。
どうせ他が大きく変わるんだったら、今後変えるつもりがあるならやってしまってもデメリットはなかった。
3.xで移行になったら結局二度手間だろ。
>>905 は?その最優先原則は、ムリに統一を頑張らないと言っているだけで、
統一する気がはじめから無いという意味じゃないぞ?
>>906 >>>assert_equal = assertEqual
>のようにすることが、そこまで労が多いとは思えない。
そもそも、新APIが旧APIのリネームになるという事自体が決まってない。
新APIはメソッドではなく関数にしようとか、その関数は unittest.asserts モジュールに
入れようとか、色々なアイデアがある。
unittestの議論より、Python3を早く提供することが優先された。
>やる必要がないことは、やらない理由にはならない。
やらない理由が無い事を全部やってたら、Python3が出るのがほんとに3000年に成りかねないな。
3がメインになってもあと1000年は2は使われるだろう
>>907 する気があるなら、するだろ。
できるのに無理にやらないって言ってる時点で、する気がないんだよ。
>>908 > やらない理由が無い事を全部やってたら、Python3が出るのがほんとに3000年に成りかねないな。
プログラマでも論理学に鈍い人って一定数いるんだよなー
やらない理由が無い事を全部やれ、とは誰も言ってない。
いろいろ理屈こねて結局やらない子
ここはLittle Mindな人の巣窟ですね。
>>911 >>>やる必要がないことは、やらない理由にはならない。
>>やらない理由が無い事を全部やってたら、Python3が出るのがほんとに3000年に成りかねないな。
>やらない理由が無い事を全部やれ、とは誰も言ってない。
屁理屈にしか聞こえん。
なら、Python3.0でやらなくてもいいんだよな?どう言う意図で「やらない理由にはならない」なんて言ったの?
>>906 >どうせ他が大きく変わるんだったら、今後変えるつもりがあるならやってしまってもデメリットはなかった。
大あり。
Python3はPython2に似た別言語じゃなくて、Python2から一部の組み込み機能を変更したり
古い機能を切り捨てたPython2の延長の言語。
一度に大きく変えすぎると誰もついて来れなくなる。Python3.0ではPython3.0のタイミングでないと
できない事に集中したことは正しい。
>3.xで移行になったら結局二度手間だろ。
完全に独立した変更なんだから、2つの変更を一度にやるか、各個撃破するかの違いでしか無い。
今回は大きな敵を倒す必要があったんだから、各個撃破の方が正しい。
なんつーか、あまりにも信者フィルターのかかった
物言いで、逆に釣りかと思っちゃう。
くだらない内紛やってる間にScalaにあっさり抜かれていく
>>914 > なら、Python3.0でやらなくてもいいんだよな?どう言う意図で「やらない理由にはならない」なんて言ったの?
「やる必要がなかったからやらなかった」というのが理由として成り立ってないと言ってるだけなのに
なんでそれ以上の意味を無理やり見出そうとするかなぁ。
> 一度に大きく変えすぎると誰もついて来れなくなる。
どうせついてこれてないし、それも変更したところで一気に難易度が増すとも思えない。
> 完全に独立した変更なんだから、2つの変更を一度にやるか、各個撃破するかの違いでしか無い。
そして、後者のことを二度手間という。
苦労して3.xに対応させたらとりあえずしばらくは安泰なら移行する気になっても、させたところでまた別のモジュールの名前だか使い方だかが変更になると思ったら移行する気にならないんじゃないか。
個人で適当に書いてるだけならともかく、自分一人の判断じゃ変更できず、変更したら些細な変更でも毎回きっちりした動作確認が必要とか、そういうケースでは特に。
それも、例えば3.2で変えますとか言ってるなら待てばいいけど
「変えないとは言ってないが、今は変えない。かといって、変えるとも言ってない」
なんて状態だと。
>>917 >> なら、Python3.0でやらなくてもいいんだよな?どう言う意図で「やらない理由にはならない」なんて言ったの?
>「やる必要がなかったからやらなかった」というのが理由として成り立ってないと言ってるだけなのに
>なんでそれ以上の意味を無理やり見出そうとするかなぁ。
文脈的に、「やらない必要が無いことは全部このタイミングでやるべきだ」という主張に聞こえただけだよ。
まさか何の主張も含まれていないとは思わなかった。
「やる必要がない」ことが「やらない理由にならない」なんて自明すぎて情報量ゼロなんだけど、何のために言ったの?
>> 一度に大きく変えすぎると誰もついて来れなくなる。
>どうせついてこれてないし、
いきなりは移行が進まないのは予想済み。それでもPythonの開発者はきちんとコミュニティに移行してもらえる
ように開発している。
>それも変更したところで一気に難易度が増すとも思えない。
>>908 で書かれている通りの議論が必要で、その議論が終わって新unittestが完成するまで
3.0のリリースが遅れたら、移行も同じだけ遅れる。
>> 完全に独立した変更なんだから、2つの変更を一度にやるか、各個撃破するかの違いでしか無い。
>そして、後者のことを二度手間という。
言わねーよ。二度手間ってのは、1回分の努力がムダになることを言うんだ。
>苦労して3.xに対応させたらとりあえずしばらくは安泰なら移行する気になっても、させたところでまた別のモジュールの名前だか使い方だかが変更になると思ったら移行する気にならないんじゃないか。
苦労して3.xに対応させたらしばらくは安泰だよ。
unittestなんて重要で移行が大変なモジュール、3.xの途中で捨てるとかPythonに限って有り得ない。
4.0 で捨てられることが決定してから、3.xでdeprecated扱いになるだけ。
まあどうでもいいが、RDBまわりとかの重要コンポーネントだけでも、さっさとすっきり3対応させてくれ
MySQLとか、もう安定してるの?
Pythonの内紛はPythonスレでやれよ
>>918 > 「やる必要がない」ことが「やらない理由にならない」なんて自明すぎて情報量ゼロなんだけど、何のために言ったの?
>>903がそれ以外の理由を挙げなかったから。
> いきなりは移行が進まないのは予想済み。それでもPythonの開発者はきちんとコミュニティに移行してもらえるように開発している。
それは当たり前。ここで話に出てるのは、unittestも変えると移行が進まなくなるかどうか。
> 言わねーよ。二度手間ってのは、1回分の努力がムダになることを言うんだ。
それは間違い。
> unittestなんて重要で移行が大変なモジュール、3.xの途中で捨てるとかPythonに限って有り得ない。
それなら、ますます3.0でやっておいたほうがよかったんじゃないのか?
あるいはどうせ4.0まで持つんだったら、名前変更くらいしておけばよかったんじゃないのか?
とりあえず擁護派の主張が揺らいでる気がする。
・ (3.xの間に)変える必要性を感じているか?あるいは、変わると思っているか。
・ 変える必要があるとすれば、それは名前の変更程度のものか、使い方自体が大きく変わるほどの変更か?
・ 変える必要がないならば、名前を統一してしまうことにそれほど大きなデメリットはあったのか?しないメリットはあったのか?
俺の主張はすごく単純。
・ 今のを名前変更するだけでいいと思うが、よりよいものを作るアイディアがあるならそれも作ればいいと思う。
ゆえに変える必要性はさほど感じていないが、新しいものが途中で出る可能性はあると思う。けれど現行のが当面は使えるだろう。
・ 名前変更は、してしまってよかった。してもさほどデメリットはなかった。
内情はしらんが、
>>908,
>>918の書いていることを合わせると、現行のが続くか、あるいは
現行とは異なるものが4.0 で捨てられることが決定してから、3.xでdeprecated扱いになるかどっちか。
それなら、どうせ3.xではずっとサポートが続く現行のは3.0の段階で名前変更すればよかった。
>>921 > 「やる必要がない」ことが「やらない理由にならない」なんて自明すぎて情報量ゼロなんだけど、何のために言ったの?
>
>>903がそれ以外の理由を挙げなかったから。
>やらない理由が無い事を全部やれ、とは誰も言ってない。
んだから、やらない理由を挙げる必要無いんじゃねーの?
いい加減矛盾していることに気づけ。
>> unittestなんて重要で移行が大変なモジュール、3.xの途中で捨てるとかPythonに限って有り得ない。
>それなら、ますます3.0でやっておいたほうがよかったんじゃないのか?
>あるいはどうせ4.0まで持つんだったら、名前変更くらいしておけばよかったんじゃないのか?
だから、やったほうが良い事を全部やってたら何時までも3000年リリース予定のままだろうが。
Python3.0ではやらないことがたくさんあったんだから、Python3.0じゃないと出来ない事に集中するのは当然。
つーかな、Python-devとPython-ideaをしっかり読んでから、そっちで批判しろよ。
こんなところで、全然Pythonの事わかってないやつが批判してどうする。
続きはPython系スレでやってくれ
Pythonだけの話を延々とされても困る
pythonは話題に事欠かないからな
>>922 俺は、Python3.0でやらないという決定を擁護しているが、それ以外の主張は一切していないぞ?
> ・ (3.xの間に)変える必要性を感じているか?あるいは、変わると思っているか。
するかどうかは将来議論して決まる。
> ・ 変える必要があるとすれば、それは名前の変更程度のものか、使い方自体が大きく変わるほどの変更か?
それもPython-ideaかtestingのMLで議論して決まる。
> ・ 変える必要がないならば、名前を統一してしまうことにそれほど大きなデメリットはあったのか?しないメリットはあったのか?
現時点で変えるか変えないかが決定していない。
決定していない状況で単にエイリアスを定義すると、コミュニティにコレが新APIで将来コレに移行するのだという
誤解を生みかねないので、名前変更は将来が決定されるまで待つべき。
>・ 今のを名前変更するだけでいいと思うが、よりよいものを作るアイディアがあるならそれも作ればいいと思う。
> ゆえに変える必要性はさほど感じていないが、新しいものが途中で出る可能性はあると思う。けれど現行のが当面は使えるだろう。
おおむね同意。
ただし、 unittest は標準ライブラリの中でも特に影響が大きいライブラリなので、将来の方向性を決めずに
「とりあえず」でエイリアスだけ定義するのは反対。理由は前述の通り、コミュニティを混乱させるから。
>・ 名前変更は、してしまってよかった。してもさほどデメリットはなかった。
デメリットはなんども言うように、結局新しいものを作ることになった時のコミュニティの混乱と、
一時的に3種類のAPIをメンテナンスしないといけなくなるコスト。
それに対して、後回しにするデメリットはほぼ皆無といって良い。
日本語読めない奴でも書けるんだなPythonって
批判派は、Python3はたくさん変更があるんだから3.0のタイミングで何でもやっちゃえば良いていう考えで、
擁護派は、Python3.0はPython3のコアな変更に集中して、それ以外の部分は後回しにしたほうが良いという考えってだけだよな。
こんな平行線の議論で長文レスを大量に書き込むなよ。
とりあえず、俺は一緒に仕事したいのは擁護派の方だな。
仕様決定するときに、「今はやらない」という決定ができ無いとスケジュールがgdgdになる。
>>924 Pythonだけの話にしても、もちょっと面白い話もあるんだろうけどね
同一宗教の中の宗派間の争いのさらに細論にしか見えないような
長文の応酬をやられても困る
いちいち各行に1行以上で答えなくて、言いたい事をまとめて行って欲しい
相手のレスを各行全部引用して、それぞれ改行されたら堪らんわ
擁護派もウソだらけだろ。
http://archives.free.net.ph/message/20080716.195747.4a5c18e4.ja.html を要約すると、
1. unittest のメソッド名を変更すると、大量のテストコードの移行が大変だからしない。
2. 既存の標準ライブラリの名前の大幅な変更はしない。でも、より良い新しいライブラリが充分な実績を積めば、それが追加で標準ライブラリになる可能性は充分にある。
3. 同じことをするメソッドが無駄に複数あるのは気に入らない。でも、互換性のために消すことはできない。
なので、推奨するメソッドだけをドキュメントに載せる。
だから、小文字のメソッド名への変更はしないと決定されている。
変更しないんだから、もちろんエイリアスの定義もしない。
unittest が未来永劫残るとは限らないが、消えるとしても10年やそこらの話じゃないだろうな。
いい加減空気嫁よ
>>923 > んだから、やらない理由を挙げる必要無いんじゃねーの?
うん。ないよ。
ただ、やる理由として挙げられている「名前の統一」に「やる必要はない」という理由にならないことを持ち出した人がいただけ。
俺はやらない理由なんてないかあっても大したことないと思ってるし、挙げてほしいなんて思ってない。
> だから、やった(ry
なんだ?お前はorの前が条件に合ってなくても後を読まないのか?
> つーかな、Python-devとPython-ideaをしっかり読んでから、そっちで批判しろよ。
> こんなところで、全然Pythonの事わかってないやつが批判してどうする。
実際に、名前の統一が重要だと思ってる別言語使いもいるスレで、「分かってない、勉強しろ」じゃ、根拠を示せないから言っているようにしか見えない。
Pythonそのものの開発者でもなけりゃ、そんなとこ読むのは相当な勉強家か暇人だけだ。
>>926 > 俺は、Python3.0でやらないという決定を擁護しているが、それ以外の主張は一切していないぞ?
その後どうなるかの予想も希望もなく、3.0でどうすべきだったかを言っているのか。それはあまりにお粗末だろ。
例えば3.2で新しいのが出て3.3で現行のが廃止になるのなら、俺だって名前変えろなんて言わない。
> するかどうかは将来議論して決まる。
んなことは分かってる。その上で、あなたがどうなると感じる/思うかを聞いたのだが。
> 決定していない状況で単にエイリアスを定義すると、コミュニティにコレが新APIで将来コレに移行するのだという
> 誤解を生みかねないので、名前変更は将来が決定されるまで待つべき。
そんな誤解するバカがそんなに多いのか。
当面はまとまりそうにないからとりあえず名前変えといた、で理解できるだろ。
> 将来の方向性を決めずに「とりあえず」でエイリアスだけ定義するのは反対。
ようやく、ここまでの長文の煽り合いの核心が見えてきた。ここの意見の不一致が、今までのやりとりの一番大きい要因。
俺の意見は、3.0で大幅な変更が入って、以後4.0までは大幅には変えられないだろうに、
将来変わるかもしれないのだからと今の統一されてない状況をダラダラと続けるのに反対、ということ。
どちらが「正しい」かは宗教の領域。でもどっちが「Pythonらしい」かは場合によっては答えが出うるので、決定的な資料を持っているのなら示してほしい。
それで納得できてもできなくても、それ以上続けるつもりはないが。
> 一時的に3種類のAPIをメンテナンスしないといけなくなるコスト。
どうせ2.xでのAPIと3.xでのAPIをいっしょに扱うことはできないんだから実質変わらないと思うよ。
>>931 それってpython3への移行に関する話? そうなら、結論が出た。そうでないなら、3への移行では多少の超法規的処置があってもよかった(ていうか、あった)と思っている。
これって荒らしだよな。死ねばいいのに
まとめるとPythonはうんこってことだな
実用的な言語はみんなうんこする。
うんこしないのは実用にならないアイドル言語だけ。
Pythonもgdgdだしその信者も日本語を理解できない
日本語なんていらねーよ。なでしこでも使ってろ
なんで日本語でレスしてきたの
>>936-941 うぜぇ、ヨソでやれ。unittestの話の方がまだ身があるだけマシだ。
Python 3000 と Ruby 2.0 が理想郷で、
Python 3.x と Ruby 1.9 が最新メジャーバージョン。
Pythonの方が過去の資産が多いし互換性を重視する文化を持っている分
Rubyより移行が大変そうだけど、Ruby 1.9への移行は順調なのかな?
目くそ鼻くそだろ
こりゃあと5年はPerlとPHPが安泰そうだな
>>945 よりにもよって文字列周りを変更しちゃったからね
処理系としても1.9が安定してきたのはごく最近だと言われているから、
ゆっくりライブラリが移行してきて、それに伴ってユーザーも移っていくには
時間がかかるだろう
1.9がうまくいけば、たぶん次はSelector Namespaceとか、
アクターとかが入るような言語拡張が視野に入ってくるんじゃないかね
D言語が踏んだ轍をなんでみんなこぞって踏んでるんだ
低所得スクリプターって大抵おしゃべりだよな
命名規則は表記もそうだけどこういうメソッドはこういう動詞、みたいなもの重要だよね
JavaやScalaの連中は規約とは何かってのを痛いほど解ってるけど
LL志向の連中って自由度重視だからこうなるのは目に見えてた
一方のPython3は、Javaや.NETで実績のある、内部コードをUnicode化する方式に統一。
IronPythonやJythonでは完全に.NETやJavaの文字列と互換性があるし、
GTKやQtみたいに内部コードにUTF-8を採用しているライブラリとも相性バツグン。
UCSが良いかかCSIが良いか、まあ神学論争
Ruby1.8の文字列はバイト列そのままなので、
仮に1.9でUCSを採用したとしても、何らかの移行措置は必要だった
最近言語に目新しいとこなんて何あるんだよ。クラス、テンプレートはいまさらで、関数型がちょっと話題で
Lambdaできればまーいいよねくらいだろ。
あとは文字コードがどうしたとかforeachやりやすいとかどうでもいいことくらいだろうに。
つ生産性
パフォーマンスやら互換性やらがほぼクリアされた今、
やっとどうでもいいと切り捨てられなくなった最後の分野
>>953 そして2ちゃんねるのようなShift-JISのシステムや、過去のUNIXのEUCなシステムとの互換性が最悪
>>957 想像だけで書くのはもう止めにしないか?
Pythonの場合、入出力でバイト列からUnicodeに変換すれば、もしデータにエラー(Shift-JISのはず
なのにShift-JISに含まれない文字が入っているとか)があった場合は変換部分でエラーになるけど、
Rubyの場合はどこでエラーが起こるかは予測不能で、エラーが発生したときにそのエラーの原因と
なったデータがどこから来たのか特定するのも面倒そう。
Rubyなら内部処理を全てEUCにする、という回避策が可能。
想像だけで書くのはもう止めにしないか?
何々ならとか関係なく全言語そうだから
>>960 CSIのRubyでは内部コードの統一が不完全だった場合も型エラーを出してくれないので、
「内部処理を全て○○にする」という作業自体が面倒。
UCSとCSIの言語を比べているのに、「CSIの言語でも(プログラマが手作業で)UCS方式を取れば
問題ない」というのはおかしいだろ。
せめて、Python2のUnicode型みたいに、CSIとUCSとを選択できれば良かったのにね。
へー Ruby では実行時エラーになるけど Python では「型」エラーになるんだ。
すごいね。で、その型エラーになる Python ってどこにあるの?
>>963 Python3だよ。
b"abc" + "def" で TypeError になる。
型エラーをコンパイル時エラーと勘違いしただけだろ。
型エラーでも実行時に発生するのであれば、どこからそのバイト列オブジェクトが混入したのか
さがすのが面倒なのはPython3も一緒。
問題は型エラーだけじゃなくて、例えば open() 関数が 'r' モードで開くと自動でデコードして
Unicodeを返すようになるとか、標準ライブラリや組み込み関数が全力でUCSをサポートしていること。
Rubyだって、内部コードをUTF-8に統一するのが簡単になるように標準ライブラリや
組み込み関数を設計していればUCSが使いやすくなる。
>>966 でも、UCSを「Pythonic」といって推奨しているPythonに比べると、
RubyだといろんなライブラリがCSI用のAPIと並列して必ずUTF-8を返すAPIを
サポートしてくれるかどうかは微妙。
やっぱり、ライブラリが返してきた何かのエンコーディングの文字列を、
アプリケーション側のコードがチマチマとUTF-8にエンコードしなおす処理が
必要になるんじゃないかな。
Ruby信者とPython信者ってバカだろ
これはRuby特有とかこれはPython特有とか、いやいやお前言語1つしかしら無いだろwって発言ばっかり
>>968 Perlはみんながuse utf8したら内部コードをUTF-8で統一できる。
PHP6はUnicode化しようとして破綻。
これで良いか?
いやだから取り扱いさえ間違えなければ外部の文字コードがなんであれ
処理に困るような言語はないだろって話でさ
内部が○○だからこの言語は駄目だとかそういう話じゃないでしょうに
NTTデータに破防法を適用しろ
NTTデータに破防法を適用しろ
NTTデータに破防法を適用しろ
>>970 >取り扱いさえ間違えなければ
そんなことは大前提で、最初から、「取り扱いを間違えない」ことがどれくらい容易なのかを議論しているんだけど?
973 :
デフォルトの名無しさん:2010/06/07(月) 20:54:21
ウホッ
>>970 内部がsjisの処理系でンコ文字扱いたいんだけど、どうすればいい?
߀
まあ下に挙げられた言語はそう簡単に落ちないだろ
PythonRubyはむしろ流行ったことのほうが奇跡かと
Rubyはこの調子でいくともうダメだな
Railsの頃が異常だっただけ
Railsというか自動的に枠を作ってくれるという仕組みがもてはやされただけで
Ruby自体やMVCフレームワークとしてのRailsが注目されてた訳じゃないだろうな
PHPやJavaで同じ事が出来ればみんなそっち使うよ
出来ればw
>>984 まさかRailsでしか出来ないとか思ってないよな
scaffold的な物なんて今時だいたいのWebフレームワークに備わってるぞ
scaffoldがあるからRailsが流行ったって言いたいの?
えっ
まさか違うと思ってるの
scaffoldとActiveRecordのおかげでRuby自体の魅力ではないだろうな
LLだと、ウェブの仕事はほとんどがPHPだな。多少Perlもあるって感じ。
いやそれはないだろ
PHPとJavaとPerlとMS系で四分くらいな感じだぞ実際は
>>LLだと
992 :
デフォルトの名無しさん:2010/06/09(水) 22:51:41
scaffoldなんか業務アプリじゃ使わないぞ。
PHPには、デファクトスタンダードになっているフレームワークってある?
いまだにオレオレフレームワークを頑張って作ってる人が多い気がするんだけど。
SymfonyかZendだろJK
terra-intl.comってApacheとかのドキュメント検索すると出てくるドメインだな
PHP自体がウェブフレームワークみたいなものだからな。
PerlだとCatalystとか極力CPANモジュール使うけど、PHPだとPHP4でPEAR::DB使うぐらいで、後は全部自前で書く。そっちの方が見通しが良い。
PEAR::DBて今時
PHP4だとDB関数でプレースホルダー使えないのがどうしようもない。
mysqli ってPHP5から?
1001 :
1001:
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。