【Python】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ47【pl,rb,php,js】 [転載禁止]©2ch.net

なんで誰も建てないんだよ




前スレ
【Python】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ46【pl,rb,php,js】
http://peace.2ch.net/test/read.cgi/tech/1409066255/

>>1 乙

http://i.imgur.com/SduT7qR.jpg
http://i.imgur.com/2f8fP3F.jpg
http://i.imgur.com/u0ymg8c.jpg
http://i.imgur.com/LruEssT.png
http://i.imgur.com/AeSQqRT.jpg
http://cisburger.com/up/bnf/6016.jpg
http://up.pangya.tv/src/www_pangya_tv18594.jpg

>>1
なんで必要だと思ったの？

>>1
乙

こんなに過疎ってるということは、結論が出たということでいいのか？
結局どのスクリプトが一番になったんだ？

>>4
このスレは隔離スレ。
他のスレが荒れるから立てる。
そういうものだ。

ここで注意しなければいけない点が一つある。
現在メジャーな言語と 違ってRubyのブロックローカル変数はshadowingをしないのだ。
ブロックの内側でiに代入しても外側に同じ名前があればそれを使う。
だから内側でiに代入すれば外側のiの値が変わる。
この点に関しては何度も何度も「間違いやすいからshadowingしてくれ」
という文句が出てそのたびにフレーム寸前になるのだが、 いまだに結論は出ていない。

>>7
> いまだに結論は出ていない。

10年以上も前(2002年)に書かれた RHG(Ruby Hacking Guide)を引用して、
いったい何を主張したいのだろうか？？？（困惑）

・第8章 Ruby言語の詳細（節「ブロックローカル変数」を参照）
　http://i.loveruby.net/ja/rhg/book/spec.html
　
すでに結論は出て、Ruby 1.9 では仕様が追加されている
まったくいつものことながら、アンチ Ruby はレベルが低い

いやだからみんなを納得させるほどの「結論」じゃないってことでしょ
アタマ悪いなあw

>>9
何を言いたいのかよく分からんが、>>7 で指摘されてた Ruby 1.8 の
問題(バグ)は結論が出て対策を終えている
・Ruby 2.0 ブロックローカル変数 -- Matzにっき(2005-03-09)
　http://www.rubyist.net/~matz/20050309.html#p03
この記事では 2.0 となっているが、実際には 1.9 で対策を終えた
・ブロックパラメータ（仮引数）に関する変更 -- 第3回　Ruby1.9の新機能ひとめぐり（中編）
　http://gihyo.jp/dev/serial/01/ruby/0003

Ruby 1.9 以降でブロックローカル変数に関する話題は記憶にないんだけど、
　> みんなを納得させるほどの「結論」じゃない
と主張する根拠(ソース)は何よ？

Ruby1.9ってほぼ7年前だよな…
アンチはそんな前の話を引っ張りだすのか…

>>9
まだソースを探しているのかな？いつまで待てばいいのかな？

とりあえず「みんなを納得させるほどの「結論」じゃない」にふさわしい、
過去の状況をクロージャのスレで発掘してみたから、コピペしとくね
　http://peace.2ch.net/test/read.cgi/tech/1415419907/197
アタマ悪い自分でも、たいへん分かりやすかったです

--
調べてみると、Python のラムダ式で任意の文が書けないという問題(>>189)は、
過去に何度もネット上で話題になっていたようだね：
・Is it possible to have multiple statements in a python lambda expression? - Stack Overflow (May 14 '09)
　http://stackoverflow.com/questions/862412/is-it-possible-to-have-multiple-statements-in-a-python-lambda-expression
・syntax - No Multiline Lambda in Python: Why not? - Stack Overflow (Aug 5 '09)
　http://stackoverflow.com/questions/1233448/no-multiline-lambda-in-python-why-not
・Why doesn't Python allow multi-line lambdas? - Programmers Stack Exchange (Aug 7 '11)
　http://programmers.stackexchange.com/questions/99243/why-doesnt-python-allow-multi-line-lambdas

そして、この問題を解決すべく数多くの提案が出された：
・AlternateLambdaSyntax - Python Wiki
　https://wiki.python.org/moin/AlternateLambdaSyntax

それら提案の中には、Ruby のブロックを真似しよう(similar to Ruby's blocks)、というものまであった
・[Python-ideas] Proposal for function expressions - Grokbase
　http://grokbase.com/t/python/python-ideas/097ccjz2c3/proposal-for-function-expressions

しかし残念ながら、これ以上続けても収束しそうもないから議論は打ち切り、とGuido氏が宣言(強権発動？)して終わった
・[Python-Dev] Let's just *keep* lambda
　https://mail.python.org/pipermail/python-dev/2006-February/060415.html
この顛末をGuido氏は「複数行のラムダは解けないパズル(unsolvable puzzle)」と語っている
・Language Design Is Not Just Solving Puzzles
　http://www.artima.com/weblogs/viewpost.jsp?thread=147358

キモい

Rubyは良い言語だが、インデントが2半角スペースという慣習があるのは好きじゃないなぁ
大クラス主義もあいまって横に短く縦に長いコードが出来上がって読みにくい

Ruby使いが_アンダースコアを_使って_長いメソッド名に_したり、
ブロックまでワンライナーにするのは右の広大なスペースを埋めたい意識からくるものとみた

>>14
大クラス主義は標準クラスがそうなってるだけで、実際に組む人は好きにしてええんやで

PythonってAPIが基本的にプル型で綺麗に統一されてるから複数行ラムダの必要性は感じないな
Rubyみたいにコールバックまみれになるくらいなら複数行ラムダなんて要らない
思想の違いはともかく、Rubyは逆に単一式のラムダがクソだよなあ

Pythonに慣れた状態でRubyみたいにブロック的な書き方すると妙に楽しい感覚がある

けどあまり読みやすくないんだよね
デバッグもしにくいし...

Rubyは本人の書きやすさ、Pythonは読みやすさを重視してるようには感じるな

　　∧,,,∧　
　( 　・∀・)　ほー　それで
　 (　　：　)　
　　し─J

Rubyはコールバックの多用でどんどんネストが深くなるからインデント幅2だと画面に収まらなくなる
Pythonはネストが増えると非常に読みづらくなるのとブロック引数も無いのとで、
自然に呼び出し側主導のフラットなインターフェースになる
そのへんが、Pythonがバッチ処理などスタンドアロンな処理向きで
Rubyが受動的なDSLっぽい使い方に向いてると言われる違いに繋がるんだろうな

思想的にはRubyに賛成(多様性は善とか)
だけどPythonを使ってしまう

Intelのガリレオやエジソン上ではrubyが普通に動くからmrubyの役目は薄くなったな。
組み込み系とデータ分析ではpythonは意欲的だしこの世界は面白い分野なんだけどrubyはWeb系に迎合し過ぎた結果出遅れてマイナスモデレートな印象はある。
（Ruby+Web系）＝信者というマイナスダウなーパターンだな。本当はスクリプトは汎用的でないといけない。
rubyマニュアルも完成度は不十分だし昔のほうが理解しやすいのも痛いな。どうなってるんだろうか。

perlも含めてスクリプト言語はみな似たようなもんだから流行り廃れは差はないと思うけど
市民権を得ているが故にJavaScriptなどは廃れるときは一気に廃れるみたいな印象はあるな。かってのBASICのように。

PythonとRails Scriptが同格だと思ってるのは日本人だけだろ
すっかりWebの雑な文化に染まっちゃったし話題の中心も海外に移ってしまって
昔みたいにとっつきやすくて丁寧な言語というRubyのイメージは見る影もないね

>>22
それは外から見る人の話であって、Ruby自体は昔から基本的に変わってないんだけどね

Rails前提でRuby見る人間が増えただけだよなあ

Railsって落ち目なイメージあったんだけど、違うのか
俺はRuby派ではないが、Rubyは生き残るとは思う

Rubyは死んでStreemにうまれかわるよ

Railsが落ち目なら上がり目なフレームワークがそもそもあるのか…

↓明らかにRailsより落ち目

Node.js関連…トップフレームワークが開発終了どころか、遂にNode.js本体が内ゲバで崩壊ｗｗｗｗｗ
Django…今となっては「Rails並に優れていたフレームワークのひとつ」
PHP…毎年のようによく分からんフレームワークが出てきては消えていく。Wordpressは残りそうだけど。
Java関連…言語自体がRubyに劣らず落ち目だし、フレームワークも分散気味　そもそも幾らシェアが有ろうがJavaを書いてる時点で負け組


↓明るいといえるのはこれぐらいか

Play!…意識高い()Java使いと希少種のScala使いがどれだけ増えるかによる
ASP.NET…公式がやや乱立させているがLinux対応もはじまったし流行りそう

Railsはいまだに新バージョンを精力的にリリースし続けてるからね
Rail3が出た時の衝撃はもうなさそうだけど

>>27
ttps://www.google.co.jp/trends/explore#q=%2Fm%2F0505cl%2C%20%2Fm%2F06y_qx&cmpt=q

Railsで捌ける程度のショボいWeb開発が需要無くなって落ち目なんだよね
フレームワークの問題じゃないでこれ

GitHubや2008年前後のTwitterよりアクセスの多いサイトって世の中にどれだけあるのか

加えて最大の負荷対策はインスタンス復数作ってロードバランサーでセッション持ち越して切り分けたりSSDにすることなんだけど、
言語やフレームワークなんてそれに比べたらゴミみたいなものだよ

Rails止めてJavaかScalaにするだけで
サーバ台数が1/2以下になるって本当ですか？

オープンソース系の(小規模、お金ない)ほとんどの人が"ショボイWeb開発"の方で間に合うと思うけど、
ブームは終わって淘汰される時期が来てるんだろう

ttp://www.google.co.jp/trends/explore#q=%2Fm%2F0505cl%2C%20%2Fm%2F06y_qx%2C%20%2Fm%2F02vtpl%2C%20%2Fm%2F02_qnn%2C%20%2Fm%2F0dhx5b&cmpt=q

Wordpress以外はどうなるか予見できないけど、今更PHPはねー...

俺はsinatra、bottle.pyみたいな軽量お手軽ものにシフトしておく

時代はPHPかJavascript

>>32
嘘でーす

大規模数値計算なんかだとRuby1000台動かしてもJavaには勝てないだろうな

>>36
Rubyはそんな分野なんかハナから勝負しようなんて思ってないだろうし、別にいいんじゃね？
Javaも数値計算に向いてるとはいえないけど

単純な数値計算ならJava速いよ
オブジェクト作らないように書かなきゃいけないから記述性でC++に劣るけど

それでもC/C++より遅いし、C#と同じぐらいだし
Numpyより遅いベンチマークすらなかったけ

ところでCGI+PerlとPHPでは、どっちがつおいの？？

>>37
>Rubyはそんな分野なんかハナから勝負しようなんて思ってないだろうし、別にいいんじゃね？

ところがぎっちょん、HPC Ruby というプロジェクトがある：
　　http://toro.2ch.net/test/read.cgi/tech/1382307475/347
この URL にアクセスすると人大杉らしいので、ログを貼っておく

--
347 名前: デフォルトの名無しさん Mail: sage 投稿日: 2014/01/26(日) 21:42:45.23
>>336-341
バイナリを吐き出す訳ではなくて(Rubiniusと同様に)
Rubyソースを内部でネイティブコードへコンパイルする方式であれば、
HPC Ruby（High Performance Computing Ruby）というプロジェクトがある
・ベンチマークによればJavaを越えGCCに匹敵する性能を叩き出し、
　これまでのRuby1.9(YARV)やRubinius(LLVM)と比較すれば100倍以上の圧倒的な性能
・実現技術としてはソースを静的解析して型推論で確定できた部分だけをコンパイルするもので、
　既存の高速スクリプトエンジンであれば(PyPy(JIT)というよりも)asm.js が近いと思われる
・当然、(PyPyとは異なり)フルセットのRuby仕様をサポートする一方で、
　(asm.jsと同様に)あらゆるコードが高速化する訳ではない
・作者様は日本人なので、「HPC Ruby」でググると複数の日本語情報を発見できる。たとえば：
　　・HPC Ruby: 静的解析に基づく Ruby の高度最適化コンパイラ
　　　　http://ci.nii.ac.jp/naid/110008583419
・あまりの衝撃故か、Rubyコミュニティですら話題になることは殆どない
　この技術が本家Rubyツリーへマージされる日は、はたしてやってくるのだろうか....？

>>40
そこはPHPと言っておかないと暴れ出す馬鹿が居るし
Perl使ってる人間でも今CGIとして使ってる人間は少ないからもうPHPってことでいいよ

>>41
プロジェクトっつーか、論文な
実装もない現状でプロジェクトとは言わん

学生の妄想は置いといて、HPCだとノード間の同期の速さも重要だよな
Rubyだと1マシン内で複数のプロセスを走らせなきゃコアを使いきれないからその時点で極めて不利

シングルプロセス限る、というアングルをわざわざ設定してプロレスをやればそうだね

えっ、PerlってもうCGIでは使われてないの？

>>45
同期コストの話をしてるんだよ
プロセス跨ると同期コストが増える
HPCだと、ノードを跨った並列化はMPIでやるけどノード内ではOpenMP使ったりする

>>46
Web言語としては流石に下火な上に、毎回プロセス生成はないだろもう

>>46
今はPSGIを挟んで使う。
http://ja.wikipedia.org/wiki/PSGI

今時のHPCでそんなにノード内にこだわるのか

今時もクソもHPCなんか未だにFortranがバリバリ現役で動いてるような超保守的な世界だよ

と頑張ったところで、1ノードのスパコンなんていう化石をいまだに運用してるほど保守的な所は無いしな

Pythonって文字列に変数埋め込めないの？
ルビーとかPHPみたいに
"$a"みたいなやつ
C#のstring.Format的なのは見つかったけどさ。イライラしないの？？

PHPのはそもそも謎仕様過ぎるし、Ruby のは "foo#{expr}bar" の expr になんでも書けるので
パーサが大変なことになってる。Python は % 演算子でだいたいの用は足りると思うが。

'{a}'.format(**locals())

>>46
ギャグで言ってるのか？ｗ
perl大好きな初めてのperlみたいなラクダ本でも、
CGIのCの字も出てこないぞ。

phpはwordpress専用のDSL言語（キリッ）

DSL言語って、RAS症候群だな

>>56
ラクダ本は初めてのperl的な本ではなくね？ｗ

>>58
リャマ本だったｗ
ラクダ本はラリーが書いたプログラミングperlだったわ。

>>57
DSLだったわ。

２つも間違えるとは、これは恥ずかしいｗ

python3とruby2の速度比較記事ってどこかに無いですか？

そんなもん無意味だろ
スクリプトがボトルネックになる時点で負け、無能、ゴミ設計

速度が無意味だとは思わんが。。。

模範的な回答をすると、

ググる →　見つからないなら自分で計測する →　公開する

C/C++で書かれたライブラリの使用は禁止とか言い出して
良く分かんなくなる予感

基本的にスクリプトの速度は

v8 > pypy > PHP > Ruby

という認識でいいと思う


どちらにしろJavaC#に比べたら10倍は遅いし、C/C++に比べたら100倍は遅いんだけどね

>>62
スクリプトの実用性は
「アプリケーションコードの実行コストはIOに比べて無視できる」
という大前提に基づいており、それを覆したベンチマークは無意味
そして、インタプリタが少々速くなったところでその前提の適用範囲はほとんど広がらない

あと、スクリプト言語が実用的なもう一つのケースとして
「運用コストに比べてスクリプトを書く手間が無視できない」というのもあるね
ちょっとしたバッチ処理がこれに当てはまるけど、そういうのはPythonやPerlが圧倒的に多く使われてるからRubyと比べるまでもない

>>64
pypyじゃなかった場合、その例の中でPythonはどのあたりに位置するのですか？

Cythonが最強

Cythonが出すコードには無駄が多過ぎるけどね…
おかげでちいとも速くならん…

>>67
おおむね、jruby > ruby > python だと思うお。
http://www.mk-mode.com/octopress/2014/11/21/benchmark-c-cpp-m-java-scala-ruby-python/

こういう数値計算処理だと普通のPythonはnumpyやらscipyやら
超強力なライブラリが揃ってるから実際には圧勝だけどね
うまく行列演算に乗せられれば並のCより圧倒的に速い

>>69
低脳自慢されてもね…

なるほど、こっちはちゃんと無駄が多いと根拠を述べてるのに
相手を貶めれば自分が偉く見えると勘違いした厨房が一行
レスで口出しか…
冬休みとかほんと困ったもんだな…

型指定を1ヶ所忘れただけでビックリするぐらい遅くなるから、
-a 等で出力されるコードをチェックしないとダメだな
でも最強

それはもはやPythonじゃないだろ
C言語のPython風マクロ

MRIやCPythonもちょっと頑張れば今より速くするのは難しくないけど、
修正や機能追加が困難になるから余計な最適化はしない
現にIronPythonやらJRubyやらpypyやら速い処理系が現れても本家のバージョンアップに追いつけずに脱落していってる
JavaScriptが速いのは仕様が固まってるから

luaは？

>>73
無駄が多いコードしか吐かせられない低脳乙

ちょっとボキャブラリーが貧困過ぎるからマジモンの厨房かもしれんな…

luaって、なんであんな速いんだ

>>80
スタックマシンだからかな。
forthも早い。

Python,JSには、Local,Global変数の2つしかないけど、

Rubyにはブロック変数もあるので、大規模開発によい

luaのライブラリ数ってpythonとかに比べてどれくらいなんだろ

シンプルそうだしコルーチン使えるし、好みなんだけど。。。

>>80
実装がコンパクトになるように設計されているし、
PythonやRubyみたいに頻繁な仕様変更もないから最適化が容易
>>82
PythonもJSも関数をネストすれば同じだろ
>>93
LuaはホストアプリケーションがLuaに対してAPIを公開するもので、
いわゆるライブラリとは考え方が違うよ
ホストに組み込まれたC/C++のライブラリを使う

>>81
Luaはレジスタマシンだよ。 例えばローカル変数は256本のレジスタに割り当てて
スタック操作なしに直接参照できるけど、ブロックの変数は最大で256個。

>>70 のベンチを Lua にかけてみた。 すべて 64bit 版。
- C (vc2013) : 2.7560 secs.
- C++ (vc2013) : 2.7420 secs.
- Lua (5.3rc2) : 211.8460 secs.
- Ruby (2.1.5) : 311.0818 secs.

正直、関数呼び出しのウェイトが高すぎる気がする。あくまでも指標の一つだね。

---- Lua版
local os = require("os");

local function calc(s, n)
　local n1 = s.n0 + (1 - 2 * (n % 2));
　s.n0 = n;
　return n1;
end

local n = 1;
local objBench = { n0 = 0 };
local t1 = os.clock();
for i = 0,2147483647 do
　n = calc(objBench, n);
end
local t2 = os.clock();
print(("Lua\t-> %8.4f secs."):format(t2 - t1));

>>70 のベンチを Cython でやってみた（gcc 4.8.3, Python 3.4.2, Cython 0.21.1）
- C -> 6.1558 secs.
- Cython -> 12.8584 secs.


http://ideone.com/ltQvdF

上記リンクのコードをbenchp.pyxというファイル名でコンパイルした後、
以下のPythonスクリプトで実行

import benchp
benchp.main()

だからPythonさんに本気を出させるなとあれ程…

Cythonスゲェ
なんでRubyとか真似しないの？

ruby はC言語の呼び出しは超簡単じゃん。もともとCythonの状態じゃないの？
ただ、jruby もあるから、ruby系言語の間で互換性がなくなる。
jruby はjavaの呼び出しが出来る。jruby はJVM言語同士で
やりとりできる。clojureとの連携はカッコイイが、clojureが分からんwww
jruby はluaよりちょっとだけ遅い程度のスピード。
ruby はなんでもruby3系でソフトタイピングだかで、静的型とは違う
型システムを導入するそうだ。

ruby3系でのソフトタイピング

http://gihyo.jp/news/report/01/rubykaigi2014/0002?page=2
ソフトタイピングはコードを静的に解析していき，「この式はこういう処理が
行われているため，こういう型を要求しているに違いない」と分かる範囲内
で型推論を行う技術だそうです。

>>89
> ruby はC言語の呼び出しは超簡単じゃん。もともとCythonの状態じゃないの？

CLも型を書いて高速化できるけど、そういうのとC言語で書いて呼び出すのは
全然違うでしょ
それにlibffiが普及して以降、RubyだけがC言語の呼び出しが得意な言語ってわけじゃ無くなったし

>>85
Haxeを追加。 Cythonと同じくソース変換型のコンパイラ。
http://ideone.com/6IFXSG

- C (vc2013) : 2.7560 secs.
- C++ (vc2013) : 2.7420 secs.
* Haxe (cpp) : 5.8569 secs.
* Haxe (neko) : 181.2250 secs.
- Lua (5.3rc2) : 211.8460 secs.
- Ruby (2.1.5) : 311.0818 secs.

neko vm もかなり速い。 品質と周辺環境次第では良さげかも

>>91
基本、C言語かJava かどっちかはそこそこ出来るのは普通だからねぇ。
ただ、俺もJava はそこそこ分かるけどC よく分からんので
jruby 使うんだけど、もし部分的に Javaで書いちゃうと（それはそれは面倒だが）
ruby では使えないコードになっちゃうのでそこはやっぱり残念。
ruby とjruby 共通の高速化ツールがほしいとは思う。
今後取り入れられる予定のソフトタイピングで多少よくなってほしいが、
実はあんまり期待してない。
ruby jruby 共通で呼び出せる ruby ライクな型付スクリプト言語がほしい。
mirah を正式なrubyのツールに格上げすればいいのに。

RubyはWeb系がほとんどだから、一部JavaやC++で書いて高速化したいとなれば
サーバーごと分けてしまえという発想になるからそういうのあんまり重要視されないんだろうな

>>41

Rubyは最近、大学教育用言語としての利用を視野に入れ始めて、
数値計算関係のライブラリの開発が活発になっているね。
Rubyで行列扱えるようになるとうれしい。

言語は使う人少ないと結果として発展が遅くなるから、みんなとにかく使え。

Ruby は勘弁して

Ruby使うくらいならJulia使うわ

Juliaは初動が遅いんだなぁ

Julia は科学計算に強いんでしょ。
それぞれ得意とする分野は違うからなぁ。
Ruby に限らないけど、スクリプト言語は文字列処理が中心だから。
といっても、html はもちろん xml や dviや pdfや svgとかも文字列だけど。
なんでも RubyからR言語を使うという本を見たら csv でやりとりしてたとか。
それも文字列だなwww

Rubyが文字列に強いというより、文字列くらいにしか使うところがないってことだけどな
文字列操作は性質上IOがネックになる場合が多いし、
他の言語とやりとりしやすいから構文解析とか難しいところは外に投げればいい

juliaとpythonどっちが良い？

ruby かpythonの中でjulia の構文組み上げさせて、
外部コマンドで juliaに投げる方がいいかも・・・
科学技術計算しかほとんどしないってんなら juliaでいいかもだけど、
汎用機能があるっていっても、チラッと見た限り頭クラクラしそうだし、
ruby かpythonの関数の中に隠してしまいたいなぁ、俺なら。

>>100
最強の文字列はプログラムそのものだよね。
苦手な言語のプログラムそのものを ruby なりpythonで
組み上げさせればラクできるかもしれない。場合によっては。

例えばの話、Java ならヒアドキュメントさえない。
もうそれだけで死ねる。

Juliaの構文組み立てて外部コマンドで実行するくらいなら
Cの構文組み上げてコンパイルしてリンクした方がマシ

>>105
つまり……
Cython!!!!

RもJuliaもpythonがあればいらんな

python、文法がruby ほどエレガントじゃないじゃん。

Rubyがエレガント？ 具体的に差を示してよ

each からブロックとかさ。
python3系ではどうだか知らんが、俺がptython やってたころは
オブジェクト指向さえあと付け感ありありだった。

なんで解り難くなる事をわざわざエレガントとかいう言葉で濁さなきゃならないの？

要するにさ、ruby で全要素から各要素をぶん回すんだけど、
そことき、each やら ブロックならでやりたい放題できる。
python は なんだっけ elem in elements みたいな感じで（書き方忘れたよ）
取り出すんだけど、そっから先になんか制約あるんだよな。
ruby のように自然にやりたい放題というわけにいかない。
python3 は知らないので、そのあたり改善されたかは知らない。

Python の iterator, generator, list comprehension を知った上での発言なんだろうか？
コレクションに関数オブジェクト（ラムダ式、ブロック）を渡すのか、
外側のループからコレクションからの列挙子を使うのか、大きく分けて2種類のデザインがある。
Rubyは前者を、Pythonは後者を好むだけに思えるがね。

違う。違うんだ。
なんかねぇ、１行しか出来ないんだよ。
ruby のブロックとかと自由度が全然違う。
ラムダとかprocとかそういう話まで行く前の話。
そこまでいったら、遅延評価とかどうやるかとかの
話までいくし。ruby はここでもいろいろある。
ああ、あと python3 での話は知らない。念のため。

あと、ruby で各要素をぶん回しているとき、
外の変数にも中からアクセスできる。遮断することも
できる。僕がpython 触ってたのは 2.5か2.6くらいの
ときだったかな。ruby はすごい自由だなと思った。

Pythonはプログラマの自由を制限して画一的で可読性と保守性の高いコードを書かせるというコンセプトの言語だ
だからこそ大規模な開発でも使用される
また、Excel方眼紙に代表されるように、ジャップは論理性を無視してクソ細かいレイアウトに拘りがちだが
向こうの人は細かいことを気にせずに論理的に書いてレイアウトは機械に任せるようなやり方を好む(TeXとかWordのアウトライン)
その違いがRubyとPythonの違いにも表れてるわけだね

で、どっちが勝ったの？

Rubyはメソッドチェーンで補完バリバリというメリットはある
REPLやら書き捨てるようなものだと非常に重宝する

俺はRubyの自由度は好きだけど、Pythonの内包表記はRubyにも欲しいなーと思ったりするよ
あれ使えるようになってくると、Pythonも案外画一的じゃないなーと思うw

「Pythonのクロージャはキャプチャ変数を変更できないのが気に入らない」
というなら理解できる。 その代わりに
「Rubyは自由だ」
と言う表現を使われると、非情にキモチワルイ。

いま、RubySpec がRubinius の人がブチ切れて廃止されたと知った。
おいおい、えらいこっちゃ。
僕は Javaがそこそこ分かるから jruby 使ってるんだけど、
今後の ruby 処理系の互換性確保はどうなるんだろ。
まあ、みんなが勝手に Cruby に合わせた test作るって感じになるしかないか。
Rubinius の人、切れやすいんだよねwww

互換性もクソもMRI以外のRubyのユーザーなんて無視しても全く問題ない程度だろ
今も昔もMRIが唯一の実装であり仕様

c言語はよく分からんが、Java ならそこそこ分かるから jruby を
使う俺の立場はいったい・・・
とはいえ、ruby2.2 がRubySpec 通らんのに出すなよ、ゴラァ
という話じゃないん？　よく分かってない。

RubySpec の件、
Java の互換性テストが廃止されたようなもんだからな。
一番困るのは、Cruby の過去の動作との互換性のチェックが
なくなること。Cruby は過去の動作がどうであったかのチェックなしに
あっちふらふら、こっちふらふらの動作となる可能性高し。
まあ、いままでもそうだったが。
Java8 が Java7 と互換性ない場合、どうなるかという話。
自身の過去の動作との互換性検証が・・・、破綻。

なんか、RubySpec、百箇所ぐらい通ってなかったらしい。
要するに、過去の動作とそれだけ食い違ってたという話。
今後が怖い。

思いつきで、その場で仕様を変えてしまう。
その途端、新バージョンでは過去のコードは走らなくなるかもしれない。
困ったものだ。

Ruby開発者が使わないので「RubySpec」開発終了
http://www.softantenna.com/wp/unknown/ruby-spec-end/

>>126
どの言語でも同じだよ。
その為のバージョン表記なのでチェック入れてもらうしかない。

そうかなぁ。
同じ名前のメソッドは、同じ動作をするべきじゃないの？
変更しますと宣言したのでないかぎり。
たとえば、Java7 のコードは Java8の vm上で走らないなどとは
誰も思わないはず。明確に宣言された仕様変更に触れない限り。

Rubyは前からそうじゃん

>>130
そうなんだよね。哀しいことに。
いまは RubySpecがあったので、どれくらい『その場の思いつき』で
過去と動作を変えてしまったかが、テスト通らないという形で
ハッキリ分かっただけで。
結果、過去のコードが動かないということに。

「どの言語でも同じ」ってのは言いすぎだったので撤回するけど
pythonなんかも同じでしょ
ようやく周知されたブランドを捨てて
一からやり直すってのは酷だから
メジャーアップデートで後方互換を捨てるってのはざらにあるよ

× どの言語でも同じ
○ Rubyの品質は糞

周囲をDisって擁護するのは止めてくれ

Rubyはそんなもんだろ
たまたま今の実装ではそのように動くというだけのこと
仕様なんかどこにもMatzの頭の中にさえ存在しないんだから

>>132
おいおい
何も知らなすぎ 撤回しろ

Rubyだけの問題だろ

Pythonは保守的だよね
だからこそ、破壊的変更を入れようとすれは丸ごと別言語にしてしまうしかなかった
Rubyは今や立派な一大ドカタプラットフォームなのに、MRI開発陣は昔のノリから変わってない

ドカタプラットフォームはRubyというかRailsの話じゃね？

MRI以外のRubyを無視できるのであれば、Web以外のRubyの用途も十分無視していい程度だろう

Web以外を無視するならWebProgでどうぞ

ヒューストンて難しいのか

CRuby開発者達の本音

「RubySpecに協力してCRuby開発者に何のメリットがあるわけ？
受益者であるJRubyやRubiniusの開発者が勝手に頑張れば？
まあ俺等は思いつきで仕様変更するけど告知はしないから頑張ってテスト直せよwww」

RubySpec の暴きだしたことは、他の実装と互換性のことじゃないよ。
過去のCRuby 自身との互換性のなさ。
最新のCRuby では、過去のCRuby のコードは走らないかもしれない。
明確な仕様の変更が宣言されていない部分の互換性のなさで、ということ。

過去のCRubyとの互換性の無さを暴かれるのも
テキトーに仕様変更かますCRuby開発者にとっては都合が悪い
RubySpec消滅は彼らにとっては嬉しいだろう

言語が進歩していく過程で、仕様変更は避けられない部分は
あると思います。
Java だってある程度の仕様変更をしてきたわけで。
けれども、仕様変更を明確に宣言することなく、『その場の思いつき』で
やっちゃダメですよね。
それやったら、過去に書かれたコードが走らなくなるかもしれないんだから。

そういう意味で、RubySpec はやはり貴重な存在です。
CRuby がいかにテキトーに『その場の思いつき』で仕様変更しているかを
これ以上ない形で示してくれたんだから。
なんとかして RubySpecを今後も維持していってほしいものです。
Ruby のために。

RubySpecが「MRIの挙動を監視する」以上の意味を持たない以上、
RubySpecを維持する(=MRIに合わせてテストを修正し続ける)のは
MRI開発陣へ「我々は容易に仕様変更に追従できる」という誤ったメッセージを与え、
MRIの勝手な仕様変更を助長することにしかならないよ

>>145
だからって、カオスがいいって話にはならんでしょ。
少なくとも、仕様変更の明確化にはなる。

いまの問題は、仕様変更の明確な宣言なしに思いつきで仕様を変えてしまっているってことだから。
RubySpec の変更が仕様変更の条件としておけば、それの更新履歴によって、
なにをどう変えたのか他人にも分かることになる。

なにしろいま、どこをどう変えたのか、
思いつきで変えた本人以外、誰も知らないという状態だから。

>>146
ああ、そうか。
だから、git に移行せよ、という話になってるわけだ。いま分かった。

開発版がコケるテストが追加されたときに
互換性を破壊した側がテストを書いた側を責める
それがMRI開発陣クオリティ

>>146
だったらRubySpec開発者はバグ報告をMRIに上げればいいだけなんじゃ？
ここはこんな仕様変更が入ってるけどどういうことなんだ？と

その上で「ごめん、実装上の都合」と言われたんならいくらでもキレたらいいけど、
それもしてないのにただ「俺らがこんないいもん作ってんのに使わないとは何事だ」と
言ってるだけなら「んなもんそっちで勝手に作っておいていちゃもんつけんなよ」と
なるだけだろうに

>>149
過去のバーションとの動作の互換性の検証はどうすんのさ。
いま問題になってるのは、明確な変更の宣言もなしの動作の変更は
マズイでしょ、て話じゃないの？
過去に書いたコードが動かなくなるかも、という問題だからね。
RubySpec なしでは、そもそも動作の互換性の検証が出来ないでしょ？
思いつきの仕様変更は弁護出来ないと思う。

>>150
だから、バグ報告すりゃいいじゃん
MRIにはバグ報告の窓口があるんだからさ

RubySpecっちゅー超いいもん作ってバグ報告してあげるなんて、ボランティアベース満載で
オープンソースぽくていいじゃん

RubySpec の現在の位置づけがよく分からないんだよな。
（いま見たら、ホントにもう閉鎖されてたwww）
Java の互換性テストと同じ位置づけじゃなかったの？
だから、互換性テストは一つ。（であるべき。いくつもあっちゃダメ）
CRuby(MRI)、JRuby、Rubinius は（その他も）すべてこのテストを
互換性のチェックに使う。
仕様の変更は、RubySpec の変更をともなう。
というのが建前のはずだったと思うんだが・・・

現実はまったく違った。最新の公式Ruby2.2 はテストに不合格www

もともとどういう位置づけだったんだ？ 公式の互換性キットじゃなかったの？？？

バグ報告して冷たくあしらわれるより、今回の様に問題提起した方が
いい加減な開発体制に由来する互換性問題が分かって
良かったと思う

Ruby のこの状態を考えると、
やっぱ Javaて偉大だな。信頼感が月とスッポン・・・ www

もうホントに RubySpec 閉鎖されてるよ。
MRI で引き取ってやるしかないんじゃないの？？？
でないと、ホントにそのまま廃止だよ。
Java が互換性テストなくなったら、Java はたぶん破滅する。
同じことだと思うけどな。

>>152
https://gist.github.com/nateberkopec/11dbcf0ee7f2c08450ea

Brianが目指したものは良かったんだけど、その手法がところどころ間違っていたり、Brian自身が
エキセントリックだったりしてRuby界には受け入れ難かった、ということろかな

>>156
少し流し読みしたけど、最初の方に
「Rubyに仕様が無いというのは間違い。ISO規格がある」
とか書かれてて吹いたw
あれは所詮1.8のサブセットでしょ

これ読む価値あるの？

>>155
JavaはIBMのJVMがAIXでバリバリ動いてたりして、ヘタすりゃ一国の経済に大きく影響するようなシステムもザラにあるわけで
それとRubyを一緒にするなよw
MRIもたいがいオモチャみたいなもんなのにその互換実装なんてほんとどうでもいい

てーか、なんで CRuby (MRI)のテストに
RubySpec 使わんのよ？ それが分からん。
それぞれが互換性テストを勝手に作ったら、
それはもう互換性テストにならん。

互換性テストの種類が二つ ＝ 仕様が二つ
互換性テストの種類が三つ ＝ 仕様が三つ

互換性テストの意味がない。当たり前の話だと思うんだが。

いやそもそもMRIにとっては互換性テストじゃないから。
MRIの仕様を確認して、他の実装がそれを真似するためのテストだから。
MRIがそのテストに通らないってことはテストが間違ってるの。
仕様=テストであるならRubyの唯一の仕様はMRIのテスト。
互換実装を作ってる連中は文句垂れてないでMRIのテストを使用すればよい。

MRIはMRIのテストをパスしている
MRIがRubySpecをパスしないということは、
元々MRIのテストに含まれていない(=未定義)挙動を誤って仕様としていたか、
もしくはMRIのテストが変更されたということ
MRIのテストの変更は即ち仕様変更であり、テスト変更は実装変更とは違って誰の目にも明らかだ
どちらにせよ、「MRIが互換実装開発者の与り知らないところで勝手な仕様変更を行った」という批判には当たらない
MRIのテストが不十分であるというRubinius開発者の主張を信じるなら、責められるべきはRubuの仕様変更ポリシーではなく
テストの品質だ

>>160
では、その MRIのテストを改めて RubySpecと名付けなさいよ。

いずれにしても、互換性テストはJava と同じく絶対に一つじゃないといけないよ。
互換性テストが複数あったら、それは仕様が複数あるのと同じだから。

なんでもいい。
互換性テストは一つにしてくれ。互換性テストが複数あっちゃダメだ。
でないと、Ruby の仕様が一つにならん。

結論。 Java はなんて偉大なんだ！

>>161
Ruby2.2でRubySpec走らせるとSegmentation faultになるんでしょ？
MRIが仕様っていうのは良いけど、かつて動いてたコードが
落ちるような仕様変更して「仕様です」ってカッコ悪いねw

>>162
RubySpecはRuby公式の互換性テストを目指したけどなれなかった
それだけの話だよね

それをRubySpecを閉鎖においやったRuby開発陣はクソだというのは違うんじゃね？
RubySpecがRuby開発陣に受け入れられなかった理由について何も述べてないよね

>>165
当初、明らかに Rubyの公式互換性テストの扱いだったよね。
yugui氏とかが顔きかしてたころ。2009年ころかな？
なにがどうしてこうなったんだろう？？？

MRI のテストが新たな RubySpecでもいいけど、
セグメンテーションフォールトで落ちるの見抜けないとか、
しっかりしてほしい。

Rubiniusの人、切れやすいんだよね。
JRubyのナッターさんはCRubyともうまくいってんのに。
Rubiniusの人、CRuby のコアチームにねじこんだ方がいいじゃない？
でないと、あとで必ずもめると思うよ www

>>166
そういう「扱い」の時期もあったけど決して公式的にそうなってたわけじゃなかった

そして、時が経るにつれて軋轢が生じて仲違いしてしまった
別々のプロジェクトなのだからよくあること言ったら言い過ぎかもしれないが、珍しいことでもない

> セグメンテーションフォールトで落ちるの見抜けないとか、

この件もMRIのバグチケットとして登録することをBrianが拒否したとか？
で、結局別の人が登録して、MRIでは解決したとか？
てなことを俺の紹介したリンクには書いてたね

BrianはRubySpecが自動的にRuby全体のSpecとして認知されることを期待したのだが
MRI開発者としたらバグ窓口はあるんだからそっち経由でされないと管理しきれん、という
感じだったんだろうな

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/39138

> > I already committed tests in RubySpec, which I believe is where they
> > are the most useful.
>
> Adding tests to RubySpec is not enough.
> You should also add tests to CRuby's test-all.

MRIの日本人コア開発者という立場を利用して、こういうことを他の開発者に強制してたんだから
RubySpecが上手く行くはず無かったね
RubySpecの人もフラストレーション溜まったと思うよそりゃ

RubyやPythonからwin32apiやCOMを呼び出すとき、
みんなどうしているの？
変数や構造体のマーシャリングはどうしてるの？

WinでRubyはないわ
C#ならそんなもん一発よ

>>168
RubySpecが完璧じゃなかったのは事実じゃないか
RubySpecにテストを追加したからそれで十分じゃないか、なんて言われたら、そりゃMRI開発者は
カチンとするだろうよ

RubySpecが通ればMRIテストがなくても完璧だというなら話は別だが、実際はそうじゃなかったんだし

MRIのテストもRubySpecが見つけられたsegfaultを見つけられない程度の出来だけどなー

で、MRIのテストには追加を強制するけど、仕様変更してもRubySpecに追加するのは断固拒否w

>>172
RubySpecに追加するのは勝手にどうぞ？でしょ
だって別プロジェクトなんだから拒否する権限はMRI開発者にはないわけだから

>>173
ああごめん、もしかしてMRIのテストを責めてると思った？ いやいや全然責めてないよ
ただRubySpec哀れだなーってだけでw

だって最初から負け戦でしょ？
仕様変更できるのはMRIだけで、そのテストもMRIに書く事強制されるんだから
二重にテスト持つなんて面倒というか害悪なレベルなんだから、そりゃRubySpec死ぬでしょ

>>174
そういうの承知でRubySpec始めてるんだと思ってたよ

だってMRI独自の実装があるわけだから、MRI用のテストは必須なわけだし、MRIの修正にはMRI用のテストが
セットなのは当たり前でしょ

それを「RubySpecにテスト書いたから十分じゃーん」なんて言われたら「そんな独自テストの話なんかしらねーよ」
ってなるだけなのは、ちょっと考えたらわかる話じゃん

まあ、もしRubySpecを始めてたのが日本人だったら
上手く行った可能性も多少あったかもね、って感じだね

日本語も話せないIRCにも来れない外国人が
Rubyの仕様をどうこうなんて何様だよってのが
MRI開発者の本音だからね

>>175
そこまで言われたら、そりゃおかしいとなるよ。

仕様の変更は、そんな軽いもんじゃないでしょって。
Java を見ろ。明確に変更を宣言したもの以外は、動作は絶対に変えない。

仕様を変えた場合は、仕様のテストの変更を要する。
それが出来ないなら、仕様の変更はするな。

当たり前の話じゃん。

なんでCRuby はころころ仕様をお気軽に変えるわけ？
そんなに変えてるもの、ほかにある？ Rails はそれ以上に気まぐれに
変えるのは知ってるけど、ほかにないよね？

Java 見習ってよ。Java はそんなこと絶対にしない。

>>177
だったらRubySpecの方からこんなバグあるよって登録すりゃよかっただけじゃん
それすら拒否したんでしょ？Brianって奴は
（結局別の人が登録したおかげで当該バグは潰せたみたいだが）

そりゃ廃れるわ

Javaと比較するのはナンセンス
お前はRubyで書かれた銀行システムに金を預けられるか?
お前はRubyで書かれた病院システムに命を預けられるか?

>>179
それは言語の優劣に拠らない話
そのプロジェクトのテスト品質がどうかという話

>>178
だから、仕様のテストは実装のテストと違うだろって。
実装のテストなんぞ、好きにしろっての。

仕様は動作を定義する。
俺が言ってるのは、気まぐれに動作を変えるなっての。

はっきり言えば、みんなRuby が勝手きままに動作変えるので
怒ってる。

ruby1.8 から ruby1.9 のころなんぞ、ひどいもんだった。
明確な変更を宣言したものはいいんだ。それ以外。
もうメチャクチャに近かったぞ。

>>180
逆に、利用のされ方が言語の開発スタイルに影響を与えるのは当然だろ?
品質軽視、いい加減な自動テストさえ通ってりゃOKというWeb文化をそのまま言語に持ち込めばこうなる

>>180
違う。君はJava が分かってない。
Java7 で書いたコードがJava8 じゃ動かないかもしれないと、
誰が心配するのか！

Rubyとは桁違いの信頼性だ。本物とおもちゃの違い。

>>181
まぁ、1.8->1.9は正直しゃーないと思うぞ
あれはメジャーバージョンアップと言ってもいい内容だったし

で、きまぐれに内容変えるなというなら、そういうのを見つけ次第バグ報告すりゃいいんだよ
それがオープンソースってもんだろう

>>182>>183
それで心配しなくてよくてまともなテストしてないというのなら、それこそ銀行や医療で
使ってはいけないシステムだと思うぞ

>>185
君に Javaを語る資格はない。
Ruby は Javaに比べたらおもちゃにすぎん。

>>184
いやー、そんな穴の空いたバケツ（MRI開発者）に水注ぐ（バグ報告）なんて
時間が幾らあっても足りないでしょ
安定性が欲しいなら素直に別の言語を使うべき

>>186
どんな言語にだって穴はあるさ
それも含めて埋めるのがシステムってものだろう
特に銀行とか医療とかならな
（Web系は適当でいいんだろうけど）

>>187
MRI開発者にリソースが足りてないのはMRI開発者が一番分かってる話だよ
それでも使いたいって人なら、それなりの貢献をMRIにしてくださいよって話
オープンソースってそういう文化でしょ？

それすら嫌ならJava使ってればいいじゃん

そんなに難しい話なのかって。言ってることは、

互換性テストは一つにしろってことで。

そして、仕様をお気軽に変えれば、その時点で、過去のコードは
動かなくなるかもしれないよって話で。だから、

明確に仕様変更しますと宣言したもの以外は、
仕様は変えるなと。

たかがこれぐらいの話で、なぜにまとまらない。泣ける www

仕様変更しました
議論もしてないしドキュメントも無く勝手に変えたけど、ChangeLogは書いときました

こんなレベルで仕様変更できるのはRubyくらいだけどね

>>189
それをRubySpecが目指したけどそうはなれませんでした
それだけのことでしょ？

>>190
ちゃいますね
それでバグったなら報告すればちゃんと直してくれるよ

そういや昔Rubyのバグ報告で大笑いした事あったなーって
探したら見つけたw

ttps://bugs.ruby-lang.org/issues/8941


Rubyって折角バグ報告してもこんな返しされるの？www

いい、分かった。

結局のところ、CRuby開発陣は、気ままに仕様変更できる手段を
手元に残しておきたいってことだ。

それが、互換性テストは一つにしろっていうことと、
明確に仕様変更しますと宣言したもの以外は仕様を変えるな
という要求に抵抗する理由だ。

よくも悪くも、それがRubyということ。
俺もRuby を捨てはしないが、軸足はなるべく Java などの他の言語に
置くようにする。

>>135
JavaやPerlならまだ分かるけどPythonだよ？
メジャー番号でちゃぶ台返しちゃうか
マイナー番号ですらちゃぶ台返しちゃうか
という違いしか無いじゃん
50歩100歩ってやつですわ

>>194
RubyにはMRI用のテストがあるわけだし、なによりMatzがバックワードコンパチビリティを
重要視していることは色々なチャネルを使って発信している

RubySpecは、単純にMRI開発と相容れなかっただけで、それだけをもってRubyの
仕様変更に対するリアクションに対する評価にするのは正しくない

>>195
PythonもJavaに比べりゃダメだが、3系で互換性壊すまでに20年かかってる
しかもまだ2系の保守もしてる
流石にRubyと一緒には出来んわ

とにかく、
RubySpec は閉鎖してしまったようだから、
それが MRIのテストでもいいけど、Rubyの仕様を決める
互換性テストをきっちり一つに決めてほしい。

一つじゃないとダメです。一つの仕様には一つの互換性テスト。

言語の進歩には、仕様変更が不可欠というのは理解できます。
しかし、明確な仕様変更の宣言をしてから変更して下さい。

勝手気ままな仕様変更を繰り返せば、みんな Rubyを捨てますよ。
しっかりしてほしい。

>>198
MRIテストで足りないというなら、MRIテストをカヴァーするようなテスト体系を作り上げてくれよ
RubySpecを継承する形でもいいからさ

で、RubySpecで見つけたバグはMRI本体へバグ報告する
多分、明確な仕様変更の宣言をしてないものはバグなんだろうから、報告すれば直してくれる
そういう精神があってこそオープンソースというのはうまくいくんだからさ

さっきも言ったようにMatz自身はバックワードコンパチビリティを壊す仕様変更は基本的によしと
してないんだから、そうじゃないなら、ただのバグ
ただのバグは報告してつぶしてもらうべき
RubySpecはその「報告」という部分をサボろうとしたためにポシャっただけのプロジェクト

>>199
そこがひっかかるんだよなぁ。
RubySpec からどうして報告が必要なんだ？
さっきから、その発想がまったく理解できない。

一つの仕様には、一つの互換性テストと言ってるじゃないの。

二つ互換性テストがあれば、それは仕様が二つということにほかならない。
RubySpec は報告しちゃダメでしょ。

報告したら、互換性テストを二つにしてしまう行為だ。
全然理解できない。

互換性テストは一つだけ。二つあったら、もうそれはどちらも互換性テストじゃない。

これ、件のBrian氏の2.2に対するバグ報告ね

ttps://bugs.ruby-lang.org/issues/9898
ttps://bugs.ruby-lang.org/issues/10016


まあバグ報告しても直してもらえないし(>>193)、
バグ報告してもサボったことにされちゃうのがMRIってことだね

>>197
何年保守すれば満足なの？
5年？10年？３０年？
年数の問題じゃないでしょ？
後方互換を捨てた時点で50歩100歩ですよ。

MRI が新しい RubySpecであるというなら、
それはそれでいい。

だが、互換性テストは絶対に一つじゃないといけない。

だから、絶対にほかに互換性テストを作るような行為はしちゃいけない。
ほかへは絶対に報告するな。それは絶対条件だ。

つまり、RubySpec がそうしようとした行為を
そのようにしろということ。それは絶対に必要な行為だ。

>>200
RubySpecはMRI開発のためのテストじゃないからだよ
あくまで別のプロジェクトなんだ

RubySpecのテスト自体が間違ってるかもしれないし、MRIの方が間違ってるかもしれない
そこの切り分けをするのはMRIの開発者じゃなくて、RubySpecのメンテナであるべきだからだよ

で、RubySpecのメンテナが切り分けた結果、MRIの問題だと分かったらMRIにバグ報告する
これが別々のプロジェクトのありかただよね

RubySpecがMRIの上位にあるとオフィシャルに位置づけられたならともかくとして、さ

>>201
両方とも、「Applied in changeset ...」 って書かれてるけど…
直されてないの？

まあ簡単に言えば自分のプロジェクトをかまってもらえなかった人が、普通に
プロジェクトやめればいいだけのことにエキセントリックな反応しただけだよね。
そりゃ関わりたくないのわかるわ・・・

>>202
Perlも4と5で後方互換なんて無いじゃん
50歩100歩ですよ

>>205
違うよ>>193の方だよ
スルーするなよ傑作なんだから

>>208
いや、君はBrianが報告したバグがさも放置されたかのように言ってたからさ
Biranが報告したバグはきっちり直されてるけどね

ちなみに>>193の方はPythonの挙動に合わせる必要はない、って却下しただけだけど

>>199 MRIテストで足りないというなら、MRIテストをカヴァーするようなテスト体系を作り上げてくれよ

それでテスト体系を作ったら、せっせとバグ報告を繰り返せよ。バグ報告に対処するか否
かはこっちの勝手だがな。

こんなことを言われたら、テスト体系を作った本人はぶち切れるわ。

なんで MRI の連中は RubySpec を取り込むように動かないのか。その価値がないのな
ら、早い段階で そのように宣言しておくべきだろう。二つのテスト体系が並存するのを
放置していたのか。そんな村社会のような open community なのか。

>>209

# %Y - Year with century (can be negative, 4 digits at least)
# -0001, 0000, 1995, 2009, 14292, etc.

って「Rubyの」ドキュメントに書いてあるのに、Rubyで Time.strptime("1", "%Y") が通るから
「これ本当に意図通り？エラーにした方が良いんじゃない？話は違うけどPythonではエラーになるね」
って報告に対する返答が「Pythonのバグ報告は要らない」だよ？
これがマトモな返答だと思ってるの？凄いねw

>>210
> こんなことを言われたら、テスト体系を作った本人はぶち切れるわ。

うん、それでもいいと思ってやってるもんだと思ってたがな
それでブチ切れるぐらいならはじめっからやるなよって話だよ

> なんで MRI の連中は RubySpec を取り込むように動かないのか。その価値がないのな
> ら、早い段階で そのように宣言しておくべきだろう

なんでいちプロジェクトのために宣言しなきゃならないのか
あくまで一時期サブプロジェクトとして利用したにすぎないだろうに
（それとて果たして何年前なのか）

まぁ、その点ではRubySpecを公式と扱いかけたYuguiさんにも責任はあるかもしれん
かの人はRubyプロジェクト内でも（技術力はともかくリリースメンテナとしては）黒歴史化
してる部分はあるので

まあ、たぶんこれで Rubiniusというプロジェクトは
放棄されるという結果になる可能性が高いように俺は思うけど、

あれ、惜しいんだよなぁ。
Ruby 自身によってRuby を実装しようというの。
残念だな。

とはいえ、Ruby自身じゃなくて、システム開発用に
静的型のRuby のサブセットを作って、それでRuby を実装する
とかいう方向に向かわないかな。

そうすると、
Ruby の遅いという重大弱点の解消につながると思うんだけどな。
Mirah みないなRubyライクな静的型のRuby のサブセット。

>>211
想定外の文字列が与えられた場合にエラーになりますと明言されてるんならそのとおりだけどさ
Rubyの場合、単純にstrptime(3)に投げてるだけだから、想定外の文字列が与えられた場合は
そっちの仕様によるわけよ
そこまでRubyが面倒みる必要ないよね？がRubyのポリシーなわけで

>>213
そこはしょうがない
Brianという人物がオープンソースに向いてなかったとしか言い様がない

>>215
彼は相当な覚悟をもってやったはずだ。
たぶん Rubiniusは終わる。引き継ぐ人がいない限り。

誰か、静的型のRuby のサブセット作ってよ。
遅いとき、そこだけそれで書けばいいようなヤツ。

>>214
いやー、そういう理由を書いてrejectなら笑ったりしないんだわw
（本当はrejectせずドキュメントの方を直すべきだけど）

しかし、あれ読んでも「Pythonの挙動に合わせる必要はない、って却下しただけ(>>209)」って解釈になるのがMRIの文化なのか
本当に凄い

>>216
> 誰か、静的型のRuby のサブセット作ってよ。
それはRuby3.0で実現するかもしれませんよ
Matzがそういう構想を見せてましたしね

>>216
なんだよ、やっぱりCythonのrubyバージョンが欲しいんじゃねーか

Ｐｙｔｈｏｎの件は本人はジョークっぽいつもりだったのが、ほんとに失礼な返しになってしまった感じ
やっぱ母国語でないならネイティブの表面的なマネなんかしないで、出来るだけ丁寧に書いた方が
いいよな。

>>219
Cython ていうかさ、ruby にはruby 特有の事情があるんだわ。
CRuby と Jruby という二つの実装があって、その互換性は
99.9パーセントくらいかと思うけど、共通の高速化手段がない。

それぞれ、C言語で書くかJava言語で高速化したい部分を書くという
ことになると思うけど、そうしたら互換性が台無しになる。

それに、Rubiniusというプロジェクトがあって、それはRuby を
Ruby自身で書くというものだけれど、やっぱ遅いRuby でそれを
やるのはいかにも無理があるよね。

そのすべてを解決するのは、Ruby Jruby のどちらからも呼び出し
可能な 静的型のRuby のサブセットだと思う。

それを CythonのRuby 版じゃないかと言うなら言えよというか、
Cython なんてよう知らんが、いま Mirah というモデルとなるような
のがあって、あんな感じのをRuby JRuby 共通のツールに出来たら
いいなぁと。

ホント、そんなの出来たら最高なんだけどな。

MRIを開発してる連中のMRI以外への冷酷さを考えると、
MRIとJRubyの共通ツールを頑張って作っても幸せになれない気がするわ
仕様変更に追従するのに疲れ果てたりとかで

そして最後に「不満持つぐらいならはじめっからやるなよって話だよ」って言われてEND

>>222
そんなことないよ。
JRuby のナッターさんはCRuby のコミッタのはずだよ。
CRubyの仕様に文句いうためだけになってるんだと思うよ。
だって、C言語で組むわけないからね www
だから、Rubiniusの人もナッターさんのようにそうすればよかったのに。

JRubyに夢見るのはいい加減諦めろよw
技術的にはnative extensionを共通化できない理由は特にない。
そして、それに関してMRIに特に何か仕様変更を求める必要もない。
JRubyがnative extensionのサポートを諦めたのは純粋に開発リソース不足のため。
native extensionのサポートがMRIとの互換性において非常に重要であるのは>>221の言う通りであるが、
それすらも維持できない貧弱なプロジェクトだということ。

>>224
native extension？
そんなもん、いらんだろって。jvm で動いてないもの、どこがありがたいのか？？？
動かなくてせいせいしたぜ。

Javaでこっちが書いたら、それはruby で動かないのが残念だなってだけで。

要するに、mirah の完成度が上がって Java（かJavaのバイトコード）と
C言語の両方を吐き出せるようになってほしいなって話なんだな。
print文で、Java かC を構文組み上げて吐くようにすりゃいいだけだ。

誰かやりゃいいのに・・・

いいかげん観念してC覚えろよw

「MRIとJRubyとその他実装はそれぞれ別言語です」
くらいの扱いが一番楽なんじゃないの
昔のBASICやLISP的なノリでさ、その内Schemeみたいな派生が出てくるよ

>>220
その人が単にキレやすかっただけに見える
ML読み返すと英語でも日本語でも些細なことでキレまくり

彼にせよBrianにせよ、コミュニケーションを軽視する人はこういう活動に向いてないという例では

Rubyの話はRubyスレでどうぞ。 Javaと比べるのはアレだが、このスレ的には、
Rubyは品質と機能の安定性の面で、他と比べて一歩劣るという結論でいいじゃない

もうどのLLもダメだな
Pythonは3移行に失敗
PerlはPHPに取って代わられ
PHPは言語仕様がクソ
Nodeは分裂

>>230
けなっしーか？
ダメだと考える理由くらい書けよ。

<?php
　echo 'ところで?>を省略しちゃう奴なんなの？'
?>

>>232
.phpファイル末尾の ?> は省略するべき

?>の後ろに、改行・空白があると、ブラウザに表示されたり、
レイアウトが崩れたりする場合があるから

>>220
文章では表情までわからないから、
すぐ相手は気を悪くするもの

それに英語がネイティブじゃないものは、
おかしい英語を使う

この間、日本人の官僚か大使が、国連の会議で、
シャラーップって言って、
世界中で大馬鹿者として放送された

>>233
これか
ttp://php.net/manual/ja/language.basic-syntax.phptags.php
ただ、HTMLタグ中に組み込む場合は、もちろん省略できんな

/bin/shでの一時変数の使い方を教えて下さい。

>>235
シェルスクリプト総合 その24(c)2ch.net
http://peace.2ch.net/test/read.cgi/unix/1415634843/

専用スレで聞いたほうがいいよ

シェルスクリプト
変数名には、英数字,_ が使える
ただし、変数名の先頭には、数字は使えない

変数の作成。$は付けない
変数名=

値の設定、または変数宣言と同時に、値を代入する
$は付けない。=の前後に、空白などを入れてはいけない
代入すると、文字列に変換される
変数名=値

値の参照
$変数名
${変数名}
{}を使った方が、変数名の切れ目が明確

変数名の切れ目が集中力の切れ目

>>237
ありがとうございます。

Pythonには定数が無いから、
すべて大文字で変数宣言したら、
定数と扱うような、暗黙のルールがある

Rubyでは、大文字で始まる変数は定数
JSでは、const


Pythonでは、比較を簡単に書ける
if 10 < a < 20

結局perl5かなぁ。機敏で後方互換性が高い。
どれだけ面構えが醜くてもそれだけで許せる。
5年やそこらで既存コードをパーにされたらたまったもんじゃない。

それでもPerl5はホントならこんな開発スピードにならずにもっと枯れてたハズなんだけどね

互換性を捨てることで
そこに雇用が生まれるメリットはあるよね

>>241
開発者がレベル低くてperl6がろくに完成しなかったのが
結果的に功を奏した形になったよね

Perl6は型推論付きの静的型指定で方向性は正しかったんだよな
当時からブロックスコープだったし
PythonとかRubyとか今更型が必要とか言い出してるし
基本線は良かったのに、僕の考えた最強のスクリプト言語とか中二的な機能を山盛りにしようとして大失敗
obj->fooの代わりにobj.fooとか、文字列連結演算子を変更するとか、全くどうでもいい仕様変更考えたのって誰なんだろう

欲張らずに関数アノテーションだけ事前に入れたPython3は賢い

かしこいかわいいPython3

>>246
それは便利なんだけど一方、printみたいに関数になっちゃったのが多くて、昔のライブラリ書き換えが面倒。
聞いた話じゃ、filter、map、reduceを活用するためとか、・・・意味分からんw

その程度なら 2to3 使えや

確かにpython3のprintのカッコは面倒
"print(s)" を "print s" とか "p s" にする簡単な方法ってないかな

この点だけで言えばRubyはいいな〜

Pythonってシェルとの相性が良くないから
Python使うときはprint使わないでファイルに直接書いちゃうことが多いかな

phpプログラミングの現在の需要ってどんなもんですか？

もう供給過多だからやめとけ

ウェブならPHPがダントツで多いよ

仕事の求人はダントツだったが、PHP自体の人気は年々右肩下がり
日本だとRubyが右肩上がり

もうPython飽きた
もっと良い言語無いの？

Pythonは単なる道具であることを美徳とする言語であって、飽きるもクソもないわ
Rubyみたいな楽しい(笑)言語と一緒にするなよ

phpはwordpress次第なんじゃね？
今後の需要。
wordpressを追いやるものができたら、オワコン

道具としてPython
遊びとしてRustがベスト

今から始めるのはどの言語が分かりやすい？
とりあえず、特定のサイトのクッキー削除とかやってみたいんだけど・・・

>>258
PHPは終わらんよ。新人を中級上級に育てるのに便利だから。
RubyやPythonじゃそうはいかない。いきなり中級レベルが要求される。

PHPはずーっと昔使ったことあるなぁ。
日本語が十分に使えなくてi18n版とかいうのを使ってたような気が。

>>260
クッキー削除ってブラウザの?
それブラウザのエクステンションとかになるから初心者向けの課題としては全くもって不適
他のアプリを操作したいというのは極めて狭い特定の問題領域に特化した知識が必要なので
はっきり言って何の勉強にもならん

>>260
regedit でIEのレジストリから、
そのサイトのクッキーを消したら？

ウェブ開発の難しさを全部perlのせいにして迷走しまくった挙句
互換性の首を締める方向に全力疾走の言語モドキをperlの代替と言われても
冗談にすらなんねーよ。PHPはさっさとApacheと心中して欲しい。

PHPに比べてperlに依存したソフトウェアがどれだけ出回ってるか。
PHPを初心者向けにと強いられる新人がいくらなんでも可哀想だわ。

Pythonは3にする必要なかった。2で良かった。
3になってなんでユニコードリテラル復活してるのか意味分からん。
Mercurialを負け犬にしたのはpy3kのせいだと思ってる。

PythonはPHPなんかと違って本物の初心者向けのいい言語だと思う。
まずエディタの設定を変更して、ハードタブをソフトタブに
切り替えなきゃならないあたりが絶妙な初心者向けのハードルで、
それすらできない出来損ないがコミュニティを腐らせる隙を与えなかった。

スクリプト言語で残るのはJSとPHPだけだろう
ニッチな用途で他の言語も使われていくだろうけど

Webなんて大したコード書かないんだから言語なんかどうでもいいんだよ
意識高い系(笑)は関数型に手を出そうとしてるが、
不変のメリットを享受できるほどの複雑なモデルを持ち
かつ内製で完結できる程度の規模のサイトなんかまず存在しない

意識高い系って言い換えたら権威主義者だと思うんだな
これをやったらハクがつく、みたいなのを嗅ぎ取ることに夢中で
やれLISPだのSICPだのね
自分を飾るためのアクセサリーなんだね

みんな自分がやってきた | やってる言語を推すのに必死だなぁ
そりゃあまあ、今まで自分がやってきたことが無に帰したら悲しいからなｗ

perlはリファレンスとコンテキストが
許容出来ないレベルでゴミ過ぎる
それが無ければ我慢出来なくも無いのに

連想配列のキー側に文字列しか許容しない言語はゴミ

>>267
まじでこれ。言語にこだわってるのはバカ。
仕事では大事なことが他にある。

>>266
そのニッチじゃない用途ってのがWebのことなら、この板で話す理由は全くないけどな

>>272
言語も大事だよ
ドカタには分からないだろうけど

むしろ必要以上に言語に拘る方がドカタっぽいイメージだけどな
些細な言語の違いに影響を受けるのは、プログラミングの本質を理解せずにサンプルのコピペを繰り返してるだけだから

Webは単純なドカタ仕事
ドカタ仕事のWebなんてどんな言語使っても大差ない

それだけのことよ

スクリプト言語使った仕事っていうと、ほぼ全てがウェブになると思うけど

海外だとPythonがクライアントアプリに使われてたりするし
データ解析なんか基本的にスクリプトだし
サーバー管理なんてそれこそ無数のスクリプトが動いてる
世の中がWebばかりに見えるのは情報媒体がWebだからだよ

つか、Web以外の仕事って

業務系クラサバシステム開発　…　この世界の底辺
スマフォアプリ開発 … 中身のレベルはWebと大差なし


とかだから、どう見ても高度なレベルじゃなくね


デスクトップアプリ(ゲーム含む)開発も最近はLuaとかシェーダー言語だしなあ

そう?
クソ高い実験機器の制御・データ解析ツールなんて
Pythonで書かれてるのたまにあったよ

>>268
意識高い系が手を出すのは、Lisp（特にcommonlisp）じゃなくて、
Haskellだと思うけどな。

>>279
それ、ゲーム含むじゃなくてゲームのみの話じゃん…
ゲーム以外のデスクトップアプリにPython使われたりしてんだぜ？

>>280
Pythonつーても中身はほぼCだからなぁ

大規模アプリの拡張用スクリプトとしてはPythonの圧勝だよな
Luaはユーザーによる拡張用ではなくスクリプトごと固定で組み込んでしまう使い方が主だし

>>284
Pythonってアプリ同梱で配布するやり方がよくわからんのよね。
Python環境自体を別途インストールするなら問題ないのだけど。

Luaは最初からexe埋め込みだから、その点は明確で、環境依存はしづらいな。

>>285
http://docs.python.jp/3.3/extending/windows.html
やっぱりPythonのドキュメントは別格だと思う
MSに勝るとも劣らないレベル

>>286
拡張と埋め込みまでは知ってる。
その後、 exe と python.dll と *.py を同梱して配布するには？ の資料が見つからないんだ。
レジストリを見に行くようで、ファイル単体では動かないんだよ。

ほらね、結局クライアントでなんて簡単じゃない

Pythonのクライアントってそういう使い方もあるけど、そもそもPythonで作られてるパターンもあるような

py2exe

>>287
今のバージョンはどうか知らんが、1.*の頃試したときはインストールしたpython環境に
べったり依存していたように思う。luaやmrubyなんかの組み込みと違って単にCの
プログラムからpythonを呼び出せるというだけだったような。
ドキュメントを見る限りではそのへんあんまり変わってないんじゃないかな。

>>287
6.2.1. モジュール検索パス
http://docs.python.jp/2/tutorial/modules.html#tut-searchpath

Py_Initializeの前にsetenv,putenv等で環境変数PYTHONPATHを設定すればいい

お前らPHP7が出たら最強になるからな。
覚悟しとけよ。


知らんけど…。

なんかRubyだけ消えてなくなりそう。
Rails次第とういかRailsしか無いというか。
Pythonが無ければもっと・・・でもPython有るから。

Ruby には Sinatraがあるだろ。
Rails にはみんなうんざりしてるが、
Sinatra はいいんじゃないか？

Rails は山のようなapi をまず覚えないといけない。
しかし、そのapi の命も次のバージョンが出るまで www
ころころapi を変えたがるのはもう病気のレベルだものな。
いまRails を必死になってやってるヤツに言いたい。
その知識、２年後３年後にどれほど役に立つか考えろ。
Rails のapi覚えるなら、次のバーション出てからにした方がいいよ。
どうせすぐ変わるから www

Pythonこそ消えそう
使ってると飽きる

>>297
俺も飽きた感があったんだが、最近になってまた好きになってしまった
スクリプト界では一番守備範囲広いし、使えるんだよなー

地味なのは認める

一番消えそうなのはRubyだろうね
Railsで作ったサイトを作り直すときに、Raisの新しいバージョンに合わせて大幅に書き直す位ならいっそのこと別の言語にしようってなる

新バージョン移行の際に機能を壊してないことを保証できるレベルまでテストを書くとなると
もう言語の記述性なんて大した問題じゃないしな
そこまでするなら静的言語使う

Railsって元々からして立ち上げ重視でメンテしながら長期運用するのには向いてないでしょ

ジャップの過剰品質や腰の重さに合ってないだけかと

最近流行りのアジャイル開発には向いてるね
ウォーターフォールでがっちりやりたいなら静的言語だろうけど

最近流行りのアジャイル…一体何年前から思考が止まってるんだろう

>>304
実際にアジャイルは多いよ
ちょっと前まではバズワード扱いだったのが、最近では開発現場でも当たり前になってきた

もちろん、ウォーターフォールが必要な場面ではそっちがまだまだ使われてるけどね

書く手間が少ないので、Rubyはやみつきになる
ary = [10, 11]

Rubyなら、
p ary, pp ary
[10, 11]

Pythonなら、
print(ary), pprint(ary)

Rubyには関数名や括弧を補完できるエディタが無いのかな？

Rubyは、Windowsに弱いからね

漏れはWin8なので、TeraPadで書いて、
ttps://paiza.io/
にコピペして、実行している

括弧を省くべきかどうか、{}かdo-endどちらを使うべきか、といった
どうでもいい判断を毎回する必要があることが馬鹿馬鹿しい
そういうどうでもいいことに拘った最低最悪の形がRSpecだね

カッコ付ければいいとおもうし、そしたらdoか{か迷うこともないぞ

Rubyのdo-endは、{}が無いから視認性がいい

ただし、処理が1行なら、{}を使う

>>311
たとえばRSpecでletを使うとき、大抵一行で済むし、
処理(do)ではなく返す値に興味があるわけだから俺は{ }を使うことにしてる
before(:each)はその逆だからdo end
でも時々letが複数行になることがあって、そういうとき悩む

俺は複数行でも戻り値使いたいときは{}派だなー

>>308
RubyがWindowsに弱いっていつの話だよ
1.8の時代はともかく、最近じゃほとんどの機能は全プラットフォームで使えるよ

それいうならPerl、Python、NodeだってWindowsでは…となるぞ

Rubyを標準ライブラリだけで使ってる奴なんかほとんどいないと思うぞ

それ言うならRubyの用途はほとんどRailsだし、LessとUnicorn以外Winで使えないものが思い浮かばん

まずcygwinやmingwが必須な時点でWindowsでの使用に適してるとはとても言えないし、
ネイティブなライブラリに依存してるのは地獄だぞ

他のLL言語も同じでしょ？
何を言いたいのかさっぱり意味が分らん

もうさ、iOSのSwiftにWEBのHTML5(js)だけで取り敢えずはいいんじゃねえの？

Rubyさえあれば他はいらん

>>315
俺俺

Rubyメインの人でWindowsユーザーなんてほぼいないからな
全く動作確認されてないんだから、まともに動くわけない

TortoiseHgとかDropboxとかMeldとか、Python製のWindowsアプリは結構多い
Rubyと同じじゃないよ

IronPythonの次にIronRubyがあったからWindowsで2番手の印象だったんだが、Rubyは人気ないのか

TRON,Linux,GNU,Ubuntu,Mozilla,Apache,Pythonなどは、
非営利財団だろ。経営もしっかりしている

Rubyは財団か？
それとも、Matzの個人商店か？

Rubyは宗教法人

マジでRubyの後方互換問題はちゃんとしないと見放されると思う

後方互換問題がないスクリプトなんてJSとPerlぐらいだろ
JSは単に進化停止していただけだし、Perlも6に以降失敗したようなもんだ

あとRubyはもう1.8系はほぼ全滅するかレガシーになってるし、ある意味見放されたといえる

後方互換ガーなんてのはPHPとPythonだけ

>>325
Rubyは国が支援してるというね

>>328
このスレの120辺りを読んでくれ
Rubyの場合は別質

Python2もPerl5もサポートされてるし、PHPはPHP4以降で破壊的な仕様変更はほとんどない
LLの中だとRubyがダントツで互換性低いのは間違いない

>>324
IronRubyの目的はIISでRailsを動かすこと
頓挫したけどね
向こうの人にとってのRubyは完全にRailsのDSLであって、
もう汎用言語とは言い難いレベル

国内プログラマーなら黙ってRubyでオケ
国産言語ってことで行政が推してるからまあ安泰だは

確かに。
日本人がPythonやってますとか聞くと非国民かよって思う。

Ruby真理教なのか全体主義なのか知らんが
OSSには相応しくない
多様性は善ではなかったんかい！？

だから嫌われるんだよ

といいながらRailsに頼る哀れなジャップ

ジャップは白人様が作られたPythonを使えばいいんだよ
どうせRubyなんてTRONと同じく白人様に潰されて消えていくんだから
Rubyみたいな糞言語は死んじまえ、Python万歳！！










...... こんな感じですかね？

やっぱり、LINE の中の人が使ってる Python をジャップも使うべきですよね？


--
91 名前: デフォルトの名無しさん Mail: 投稿日: 2014/09/13(土) 19:33:59.26 ID: NXGUPkMv
LINEにインターンに行った人のブログ読んだ時、そこの社員さんの本が写ってる画像があって
その中にPython関係のハングル翻訳本があったのであーやっぱりと思った

92 名前: デフォルトの名無しさん Mail: sage 投稿日: 2014/09/13(土) 20:35:34.26 ID: OsadxY4P
エンジニアブログでも登場してたよ
日本語バリバリっぽいが

110 名前: デフォルトの名無しさん Mail: sage 投稿日: 2014/09/16(火) 18:17:53.70 ID: exxayQq9
>>91
これか
http://cdn-ak.f.st-hatena.com/images/fotolife/c/cocodrips/20140829/20140829091202.jpg

国産のRubyには頑張ってほしいとは思うんだが、

こんなのがいるからRubyはダメになっていくんだろうな

RubyはRails地獄、ライブラリ地獄で無理

そうそう、rubyは、初心者をバカにする

>>342
海外での評価は逆みたいだね ....
「Rubyコミュニティはnewbieに対して親切でフレンドリーだ」


--
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RubyPeople

foocampにいたとき、rubyを好きな理由がもうひとつ見つかった。
それは自分では認識していなかったものだった。
誰かがテーブルで（ごめん名前忘れた）PythonコミュニティとRubyコミュニティの
違いについての彼なりの意見を述べていた。
彼曰く、「Rubyコミュニティはnewbieに対して親切でフレンドリーだ」と。
（彼はまた、これはRubyに日本の血が流れているからではないか、とも言っていた。）

Pythonコミュニティに参加したことはないので、彼の言うことが本当かどうかは分からない。
しかし、rubyコミュニティは、私が今まで見てきたどんなオンラインコミュニティよりも
ナイスだということは言える。 なんたって、あのAndy HuntとDave Thomas
――私が非常に尊敬する2人だ――が、私をRubyの世界に連れてってくれたんだから。
Rubyコミュニティには、才能と実用主義と楽しさとがうまくミックスされていると何度も思ってきた。

>>339
それ、突っ込みどころ違うよ。
Q：何故ハングルに翻訳するとそんなに分厚くなるのか？
A：発音記号だから。

日本と日本人が大嫌いだけど、Rubyは大好きです。

慈悲深い終身独裁者、BDFL(Benevolent Dictator For Life)
が率いる組織は、成功することが多い

Linus, Ubuntuの Shuttleworth,
Pythonの Guido, Rubyの Matz など

話は変わるが、windowsでsshサーバを立てたいんだが、Cygwinとかソフトじゃなくて
PythonとかRuby辺りのライブラリで出来ないかな？

繋がったところでbashがないと意味ないだろ
UNIXと全く互換性がなくていいんならWinRMとPowerShellでも使っとけばいい

補足しとくと、、、

全部Windowsで、古〜いOSもあるLAN環境
とりあえずWinコマンド程度が使えればOK

なら>>348の言うようにWindowsの普通のリモート管理機能でいいだろ
telnetでも十分なレベル

node.jsがapacheの上で動けば何も迷わずに済んだ

node.jsはサーバー付きなのが楽でいいんだろ
ゴチャゴチャと環境弄らなきゃいけないんなら誰が好き好んでJSなんか使うかよ
あれは組み込みみたいなもんだと考えるから許せるんだ

apacheが何やってるかよく分からないのに、node.jsなんて触れない

githubもtopcoderもjsだらけ

jsのいいところって何かあるっけ？
大抵の人にとっては仕方なく使うものなんじゃないの？

fortranやpacalがイケてた時代を終わらせたのがcだとすれば、
pythonやrubyのイケてた時代を終わらせるのがjs

今ある言語でJSの代わりにブラウザに組み込めそうなものはなんだろうか

c/c++。ベンダーロックインしない標準規格があるから

開発環境でロックイン。

Apple Swift がプログラミング言語ランキングで急上昇
http://blog.livedoor.jp/cartan0216/archives/55106852.html
初心者が学ぶべき最も適切なプログラム言語は何でしょうか？
http://blog.livedoor.jp/cartan0216/archives/55045634.html

とりまSwiftとRuby(Rails)で十分ぽいな

ruby周りの動画みてるとさ、もう数年ぐらい前から登壇者たちはnode.jsの紹介しているよね

数年ぐらい前から紹介していながら今現在のこの普及度は明らかに足踏み状態だね

日本でプログラマーとして飯食うならRuby一択やろな

jsはES6からが本命だろな

altjsがこんだけある背景みてみれば

Rubyはsassで使うから入れてあるだけで全然使ってないな・・・

数年前からNode.jsやっていたような奴は、フレームワークどころかNode本体が内ゲバで
崩壊している現状に嫌気がさしてもう撤退しているだろ


>>364
ES6っていまだV8にすら採用されていないんだけど、いつ登場するの？

それに加えて、IE9/10/11、iOS678、Android45とか自動更新機能がないもので今後10年は
生き残りそうなのものがあるから、サーバーサイドという分野でのみES6は使われることになりそう

良いとか悪いとかじゃなくて、ブラウザでサポートされるのがJSだけなんでどうしようもない

IEではVBSも使える。
というかVBSに処理を部分的に投げているライブラリは普通にあると思う。

# というかIEならWindowsの設定次第でPerlでもRubyでも使えるが、まあ、これは別の話だな。

JavaScript ≒ Javaバイトコード
別途コンパイラを用意すれば良いのであって、人間が直書きする必要は無い

jsってブラウザマクロ言語でしょ

Node.jsも決して使いやすくはないし、
alt.jsがたくさんあるのも、みんなが現状のjsにNoって言ってるよう

jsを汎用言語と混同している人ってなんなんだろう
webの世界だけしか見えてないってこと？

Webどっぷりの人はそこら辺の感覚がズレてる
Webはフレームワークやプラットフォームに極めて強く依存する書き捨てコードばかりで
純粋に言語処理系を単体で動かすことってあんまりないからね

>>365
lessでいいじゃん

>>370
汎用言語だよ

言語処理系を単体で動かすって、何？学生の演習？

nodeなんてオワコンだろ。
客に納品する仕事に使えるレベルではない。

ActiveXはIEからも消えていく
今度のSpartanとか
JSしか共通して使える言語はない

jsはブラウザごとの差異が激しすぎるよな
古めのブラウザだとライブラリも切り捨てるところ多いし

IE8とかまだまだシェアがあるから簡単には切れないけど、ライブラリ側からすれば
余計なメンテコストを払いたくないからと言ってざくざく切り捨ててる

jQueryみたいなライブラリですらしょっちゅうAPI改廃したり、バージョンが細分化したりIE67切り捨てたりするからなあ
まあいまだにIE6-8使っている奴は氏ねと思うけど

IE9ですらモダンブラウザとは呼びにくい

>>377
IE67はさすがに死ねと思うが、IE8はまだシェア15%ぐらいあるからねー
さすがに切れないね

Windows 2000ならIE6
それをアップグレードできない

だいたいなぁ、最新のウェブブラウザでしかよめないウェブページなんて、どういうつもりかね？
いったいなにがしたいの。お客さんへってもしょうがない

PHPがいいね

>>380
ダサいページだと客が離れることもある
それくらい想像しろ

>>382
できることに差はあまりないよ
できることをやろうとしたときの面倒臭さに差があるだけで

>>382 できた当時からずっと2chはむちゃくちゃダサいページだな。

ワンページとかなんとか浮かれているような人たちは、もし彼らが只の雇われに過ぎないなら、極めつけのバカか狂信者だな。

SPAってデスクトップアプリのようなものをブラウザ上に提供しようってもので、
派手でダサいだけのWebサイトをjQueryで作るのとは別物だよね？

SPAはビチクソ全面Flashサイトの系譜だろ
デスクトップアプリの真似というよりはむしろ、Webらしいナビゲーションを
シングルページでどう実装するかみたいなアホらしい話が中心

モバイルの場合、ネイティブアプリで作るからそういうの要らないんだよな
帰ってきたFlashっていうのはその通りで、SEOだったり、フルFlashサイトの悪いところもそのまま
開発者の自己満足で作られてることが多いと思う

シンプルで高速なのがいい

>>384
そのレベルの事を態々書き込みに来る奴が絶えないんだから、十分成功しているな。

>>384
2chは早くからアプリベースのサービスだ
しかしそれにも関わらずユーザー離れは進んでるんじゃないのか？知らんけど
もっともダサい云々以前に質の問題だろうが

レスポンシブな便所の壁に、糞を垂れてるヤツらなら幾らでも見たけど
2chのデザインとユーザビリティほど優れたものは見たことがないよ。

IE8＝XP使いだろうから、
本来は切り捨てていいんだけど、
まだシェアがあるってのが問題だよなぁ…。

いや今の業務PCのデファクトスタンダードはWin7+IEだよ
目下Win7+IE10へ移行中といったところ

訂正
いや今の業務PCのデファクトスタンダードはWin7+IE8だよ
の間違い

cで書かれたapache+phpと、c++で書かれたツール群のnode.js
どちらがプロジェクトとして長く続くんだろう
node.jsがv8へ依存している以上、googleの都合次第ってのが気持ち悪いよね

みんな色々覚えて色々使ったらいいのに、なんで言語でケンカしてるの(´・ω・｀)？

各人に十分な時間や気力があるわけではないからね…

>>396
ここが言語でケンカしたい人のために建ったスレだからだよ

拳でケンカしたら痛いじゃないですか…

やっぱり

拳固でケンカしたら痛いじゃないですか…

の方が語呂がよかったかな？

言語って無数にあるし、スクリプト言語だけ全部覚えるとか無駄というか無理だからね

JavascriptとPHPとC++で十分。
Javascriptは方言が酷いし、C++もややそう。
PHPはビルド済み基本セットだけでなかなか行ける。

apache使う分にはluaの方がエコだよね
wiresharkやnmapだったりのバインドもあるし
皆が大好きなZed A. Shawもいる

C(組み込み)とjs(Webクライアント)とPython(その他全部)で全領域ok

jsだけでIoTで使われるような機器までイケるじゃん
Webって、wordpressだけで大抵のものは既に出来上がっているよね

jsをあえて他分野でも使いたいとは思わないんだよな

メジャーなスクリプトの中ではPythonが組み込みに強い方だと思うけど、
組込みって消費電力とかハードの値段とか設置場所の環境とか考えて
最小構成で作るようなものだから、スクリプトを乗っけれるような大げさな
機器だけしか選べないようだと困る

次世代のバズはWebとIoTだろ。大抵の組み込み機器にnode.jsが載っている
電気代よりもデバッグとメンテに掛かる人件費の方がコスト掛かる

jsこそデバッグとメンテに向いていないんじゃないのか？ 使える人間の数だけは揃えられるとは思うが
見た目はjsに近いほうが良いだろうが、型チェックなりソース解析向きのアノテーションを付与する方向に行くんじゃないか

電気代はバッテリの持ちなど利便性に直結するからな
利便性は商品の売れ行きに影響するので非常に重要で無視はできない

Javascriptは何時からか非同期、関数型が強調され出して初心者に難しい言語になってきた。
もともと早いころから関数型やオブジェクト指向を取り込んでる先進的言語だったんだろうが。
昔はそこにはそれほど触れなくても良かった気が。

>>409
組込み機器の生産数、利用者が多い場合にだけ考えれば良いことだよね
IoTで使われるような機器って多くても300個ぐらいじゃないの？

>>410
逆に大昔はお遊び言語な扱われ方だったからな
ヤリタカッタダケのユーザビリティ無視の効果に使われてる例が多かったし
解説サイトとかもページの効果の実装方法を説明するものがほとんどだった

>>407
全く意味がわかってないようだね

先に言語ありきじゃなくて、ハードに合わせて言語が決まってくるんだよ

jsとかが使える組み込みなんてホンの一部だけで、jsだけに縛られていたら
ほとんど何もできないということ

>>407
機器がどうなるかはともかく、jsを書ける人間は安価で調達できるってことが言いたかったんでしょ。
jsがインタプリタされるか、出荷時にコンパイルされるかのような違いは出るだろうが。

jsが「共通言語」になることを望んでいる経営陣やエンジニアもいるだろうし、逆の立場もいるだろう。

非同期にセンサーデータを扱うことにかけてはnode.jsは優れてると思うけどね

>>413
は？パッと見た限りじゃ、c/c++の次にjsが多いだろ

>>414
それって、何処のガラパゴス諸島のmruby族？

非同期ではソースを綺麗に書くのは無理

確かに

無数にあるマイコンどれもにスクリプト言語をバイナリにコンパイルして書き込めるの？

?よく分かんないけど、OSごと乗っかってる奴の話じゃない？

お前らが何を言ってるのか理解できません

OS上のプログラムを組み込みと言うのか......

組み込みかどうかは利用形態の違いでしかない
Windows Embedded上のC#アプリみたいな超高級ソフトウェアでも普通に組み込みと呼ばれるから

ttp://node-ardx.org/
IoTで使われる機器って、こんなのだよね？

まさかarduinoの延長レベルの話だったりするのか?!

jsが使えるかどうかなんて、ハード要件に比べればどうでもよい小さいこと

Webと繋ぐようなものなのに、コスト掛けてまでcでやらなきゃダメな場面って？

組み込みは全部webと繋げないといけないらしい......

Xeonを搭載する組み込み機器を売ってます

スクリプト言語はどうでも良いです
好きなのを使えば良いんじゃないですか？

そんなことより静的型付け関数型言語の決定版が欲しいです

スレタイを読んでもその発言ができるのか・・・

わかった、つまりpythonが最強ってことでしょ

ブラウザにはphpを載せるべきだった

Javascriptは関数型へ移行してきてるな。
メジャーな関数型として他を駆逐してしまうかもしれん。



CoffeScriptをさらに書きやすくしたLiveScript - webネタ
http://r-h.hatenablog.com/entry/2014/02/23/114659

>>433
それJavaScriptとは言わないだろ。 JVMを言語と呼ぶようなものだ。

型付きで冗長なjs方言と、型無しでタイプ数を減らせるjs方言に二極化しているというのはある。
素のjsは駆逐されてしまうかもしれない。

LiveScriptだのTypeScriptって名前に面白みがなくて試す気にならない

>>434
主流なJavascriptが先行版を取り込んでいくと見てる。


JavaScriptのクロージャ入門とECMAScript 6のletキーワードによる変数宣言
http://developers.linecorp.com/blog/ja/?p=3428

JavaScript - ECMAScript 6thで導入される機能 - Qiita
http://qiita.com/paulownia@github/items/1e0dce0bfee7c7d1c5aa

>>436
全体的に日本語がおかしいぞ。
各種AltJSの実験的な機能を本家として取り込んでいく、という意味なら同意するが。
ライブラリごとに独自実装されている部分が共通化されるのは良いことだろう。
とはいえ、他の言語では当たり前のようにできていたことに追いついただけなんだがな。

Shell Script -> Bash等のShell
Run Script -> Daemonの起動制御
AppleScript -> OSAX
ActionScript -> Flush
TypeScript -> Web browser
JavaScript -> Web browser
JScript -> WSH(WScript)
VBScript -> WSH(WScript)
PostScript -> 印刷機
VIMScript -> VIM
Drawscript -> Illustrator
AutoCAD Script(Lispとは別) -> AutoCAD
MaxScript -> FinalRender
TeleScript -> MagicCap
NewtonScript -> MessagePad
SQL Script -> OracleDB
Script-Fu -> GIMP

>>438
至る所にtypoと大小文字の間違いがあってイライラする
書き直せ

SHELL SCRIPT -> BASH等のSHELL
RUN SCRIPT -> DAEMONの起動制御
APPLESCRIPT -> OSAX
ACTIONSCRIPT -> FLUSH
TYPESCRIPT -> WEB BROWSER
JAVASCRIPT -> WEB BROWSER
JSCRIPT -> WSH(WSCRIPT)
VBSCRIPT -> WSH(WSCRIPT)
POSTSCRIPT -> 印刷機
VIMSCRIPT -> VIM
DRAWSCRIPT -> ILLUSTRATOR
AUTOCAD SCRIPT(LISPとは別) -> AUTOCAD
MAXSCRIPT -> FINALRENDER
TELESCRIPT -> MAGICCAP
NEWTONSCRIPT -> MESSAGEPAD
SQL SCRIPT -> ORACLEDB
SCRIPT-FU -> GIMP

xlisp -> audacity
S-lang -> JED

>>436
ブラウザ開発者間の綱引きが激しいのでJavaScriptは基本的に成長が遅いよ
だからAltJSみたいな発想になるんだから

altJSで一番オススメは何？
LiveScript? Elm?

現実的にはCoffeeScriptとTypeScriptの2択だよ
あとは一ヶ月したら話題にも上らなくなるゴミ

Railsに採用されてるCoffee,MSが作ってるType
それらが将来性を担保する要素として足るかどうかはともかくとして、
他のカス共は本当に全く「何も無い」からな

>>445
実はcoffee script使った方が、ecma scriptの仕様が改訂されてもソフトウェアを保守できる
github製のatomなんて、長期に渡って保守する必要があるだろうから、
素のjsで書くよりもトランスレーターを介した方が良い

coffeeもtsも仕様は思いっきりJavaScriptに依存してるぞ
互換性に厳しいMSならJSの仕様変更を回避するためにコード生成ルールを弄るなんてこともやりかねないが、
coffeeがそんなことするのはまず考えられない

MSなら大丈夫って何の根拠もないタダの印象論だよね？
tsみたいな複雑なものよりも、csのような単純なトランスレータの方がバグは見つけやすいのに
csって、配列末尾の","みたいな瑣末な違いを吸収してくれるんでしょ。たしか。

js → やわめ → CoffeeScript
js → かため → TypeScript
どちらも需要は理解できるし、勝ち負けの話じゃないだろう
個人で手早く書きたいときは やわめ のほうがいいし、
企業で品質を客観的に保証する場合は かため のほうがいい

ただ、ES6がまともにリリースされた時には、残る利点もあるけど
js本体に吸収されてしまう部分もあるだろうなとは思う

TypeScriptよりCoffeeScriptの方が単純って、
とてもTypeScriptを触ったことがあるとは思えないな…

TypeScriptはトランスレータとしては非常にシンプル
型検査やMSお得意のIDEサポートのために処理系は超複雑だけど、
MSのコンパイラに品質の心配は無用だろう

>>446
ECMAScriptは後方互換性を壊すような変更は絶対に入らないし

そもそも新しい仕様が追加されてもそれでコード書き直すなんてことはないからな

つまり、現状動いてるAltJS処理系の開発が終了したとしても、
動かなくなる心配は無用ってことだから、
現時点で純粋に優れている言語処理系を選べば良いわけだね？

C#のdynamicObject使えば動的型言語要らなくね?

>>454
C#のdynamic objectは静的型言語の不便さを解消するために後付けで作られたものであって、
そこには動的型言語のメリットであるお手軽さはカケラも存在しない

むしろC#のdynamic objectは静的型言語の限界が露呈した結果でしかない

PerlもPHPもRubyもPythonも静的な型を宣言できるようにしようとしてる
ある規模越えると型は宣言できた方がよい

C#のdynamicはCOMや他の動的言語(ブラウザ上のJavaScriptとかPythonのバインディングとか)
と透過的にやりとりするためのものだから静的型が不便だから動的型入れたというのとはちょっと違うかと

アプリケーションの一部をスクリプト側に追い出すのが流行って、そのためのホスト側の仕組みがdynamicだということね。
スクリプト側に追い出すこと自体を「静的型言語の限界」と言えなくも無いが、
昔ながらの設定ファイルにロジックを埋め込めるようなったという解釈もできる。
既にあるかどうか知らないけど、 .ini やJSONを扱うだけの DynamicObject も作れるんだろう、きっと。

C#はCodeplexとかReference Sourceとか作ったのに今更GitHubに一部移行してるのがなあ
多くの古いプロジェクトがリポジトリーやイシュートラッカー複数作りたくないからGitHubはミラーにするかGitHub1本に乗り換えてるつーのに、
Rubyみたいに複数サイトにまたがって行うバカどもがいて、MSも同じ轍を踏んだｗ

Swift一本で十分過ぎるほど飯食っていけると確信したので専念するはさようなら＾＾

日本語のハイプだけでも、十分過ぎるほど飯は食えるだろ

PHP7「俺が登場すればすべて勝利」

一年くらい前まではJSの一人勝ちかなって思ったけど、
なんだかんだでPythonが最強っぽい感じになってない？

ないわー

2008,9年頃にPythonの1人勝ちだったけど、もう今はjsとgolangの時代だよ

世界的にはlessの方が普及しているのに、ガラパゴス諸島だけSCSS贔屓

LESSはWindowsでは使えないからな
LinuxとかMac使っているやつらは現実にもかかわらず自分達が世界の中心とか言い出すけど

スクリプト言語はメインストリームはJSで間違いない
PHPは簡易なウェブサイト専用で当分残るだろうけど、その他はニッチな用途のみだな

>>467
＞ LESSはWindowsでは使えないからな
え？

LESSって何。ページャ？

numpyがある限りPythonは不滅

将来、numpyを使う職に就けるか、どうかなんて分からないんだよ？

>>467
ttp://winless.org/
やっぱ、メインストリームは違うよね

numpyを使う仕事か事業を興せばいいんじゃね？

国内で働き続けるつもりならこれからも行政をバックボーンに持つRubyとiOSデバイスのSwiftだけで十分金稼げるやろ阿保

Rubywwww

現実にPythonの案件なんてほぼないしな、日本では

Swiftはなぜかここで良く名前が挙がるが、スクリプト言語じゃないよな？
新興言語の中ではJavaScriptっぽいから、比べる人が多いのか？
GoやRustは癖が強いから人を選ぶのかもしれない。

backbone.行政の無料で読めるtutorialって、何処かにない？

Rubyは2008年頃にComplexFloat組込みを拒否ったときに
スクリプト言語が数値計算に使われるわけ無いじゃんって
空気を露骨に出したのが失敗だった
あれでnumpy的ライブラリが出現する可能性が無くなった

コア開発者達の先見の明が無さ過ぎたね

numpyって、fortran製libraryのラッパーじゃないの？
設定面倒だし、Rかoctaveでいいよ。バカみたい。

pip install numpy で直ぐ使えるようになるし、設定なんて不要
第一numpyがインストール出来ないレベルじゃRもインストール無理だ

>>482
こういうのはデフォルトじゃパフォーマンス出ないんだぜ
行列計算は年季の入った定番のクソ速いライブラリ群があるので、それを環境に合わせてビルドし直す必要がある

何も設定せんでもBLASやATLASとリンクしてくれるじゃん
OpenBLASあたりを入れるのが若干面倒なのはまた別の話
それに、そのレベルじゃRでもリンクできねーって

たまたま、自分の環境ではpip一発で入ったからってドヤ顔されても
numpy使うのってラッパーのラッパーみたいに幾つもレイヤーを跨いでいて気持ち悪いし
python自体が行列演算に向いた言語だとも思えないから使うだけのメリットないお

Pythonで数値計算してると動的型である必要性は全く感じないな
数値計算というのは基本的に配列に対してループぶん回して単純な計算するだけだから、
FORTRANですらそれほど不自由はないんだよね

さっさと、juliaが普及すれば良いのになぐらいの感覚なんだけど

いくらグルー言語とはいえ数値計算に使うならせめてN^2(N〜数千程度)くらいの処理は手軽に書けないと不便だよね
C++やfortranでは大袈裟すぎるが動的なスクリプトじゃ遅すぎる状況は意外と多い

RubyとSiwiftだけでいいっす
オマケでjsくらい

>>488
Cython

数値計算分野のスクリプト言語はもはやRで決まりと言っていいだろう

統計ならRだけど、数値計算全般と言われると微妙

ロクに数値計算やった事ないのに
Pythonにケチをつけたいだけの奴等の
批判が浅過ぎて笑える

Rは統計関連のパッケージ揃っていて便利だけど計算が遅すぎる

>>493
同意

オマエは、今までにpythonのlistとnumpyの行列を間違えたようなデバッグに掛けた時間を覚えているのか？
matlab, octaveでいいじゃん

>>495
listとnumpy.ndarrayを間違える頻度は
strとintを間違えて演算する頻度と同じか、もっと少ないくらい

それを多いと感じるか少ないと感じるかは
当人のヘボさによって変わるから何とも言えない

numpyが有用かどうかは一口に数値計算といっても何するかによるわな
うまく巨大な行列計算に落とし込めないような処理をすることが多い人にとっては実際クソ遅いだろうね

>>497
本当これ
C++だと一秒で終わる計算を10分以上もかけててワロタ。遅すぎて使えない

ublas使う方がマシ
データの出力にだけ、gnuplotかmatplotlib使え

>>498は数学のセンスが無くて行列演算に落とせる処理を
無駄にループで書いてるタイプ

じゃあ例題やるから行列で効率的に解いてくれ
多数の三次元ベクトルが与えられていて、それぞれは空間上の点を表している
その全ての点に対して、各点を中心とした半径Rの球内に含まれる他の点の数を数えよ
粒子のシミュレーションでありがちなケースだ

ベクトルである必要性は?
3次元上の点、座標とどこが違う?

空間内の点の座標(x,y,z)でいいよ
もちろん各成分は単なる数値としてバラバラに扱って構わない
点の位置について法則性などの前提知識は特に無いものとする

＞数学のセンスが無くて行列演算に落とせる処理を
＞無駄にループで書いてるタイプ

ってのは「適切な処理方法が分からず非効率な処理方法を選んでしまうタイプ」という意味にしか読めないんだが
行列って字面だけ額面通り受け取ってどうすんだよ…
例えば「8分木で解く問題」を全検索ループで解こうとするのは全く同じことだと思うの

盲目的に二重ループ回してもCなら一瞬で終わる計算を、
わざわざ空間分割してまでスクリプトでやるのが賢明か?
そもそもスクリプト言語の有用性は「パフォーマンスよりもコーディング効率が重要な場面は多い」という仮定に保証されてるんだから、
複雑でも常に効率的なアルゴリズムを選ぶべきだというのはそれを否定してるようなもんだ

え？cで複雑なアルゴリズム実装するなら、先にpythonで実装するよ

決めようぜ最強のプログラミング言語を綱引きで
http://portal.nifty.com/kiji/150203192687_1.htm
http://portal.nifty.com/2015/02/05/b/img/sp/000.jpg

なんだこれ

数値計算なんてFORTRANがかろうじて生き残ってた世界なのに、そんな世界での優位性を
主張するなんて、PythonはFORTRANの後釜でも狙ってるというのだろうか？

>>505
盲目的にCで二重ループ回せば終わるような計算は
Cythonを使えばCと完全に同等のパフォーマンスが出せる
ボトルネック以外は普通のPythonコードで書けるから開発効率も抜群

Pythonは物臭な大学生が課題用に沢山モジュールを作ってくれてるから
理論やアルゴリズムがわかっていれば使えるものがいっぱいあるからね。
自分でプログラミングできない人達には最適だよ。

もちろん自分でプログラミングできる人達にも最適だけどね

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Rubyが20位
消え去りそう

更に下にもランキングがあるから大丈夫

ttp://elementscompiler.com/elements/silver/
2014年、プログラム言語の人気はユーザーが如何にお金を落としてくれるかに再定義された。

俺はPythonistaなんだが、、、

Ruby頑張ってくれよ

Rubyみたいな足場の脆弱な言語は一度落ち目のイメージが付くとあっという間だよね

もうすぐCOBOLに負けるのか…
感慨深いものがあるね

世の中がRubyだのHaskellだの騒いでた時代から、俺はnode.js推しだったよ
もうじき、WordPressもPHPも時代の流れと共に過去の遺物として姿を消すんだろうね。
だけど、Railsなんて使う人たちは最初から闇に属していたんじゃないかな
脚光を浴びなくなったところで、闇は彼らを優しく包んでくれる

Rubyはこのスレにある主要スクリプト言語の中で一番早く消えそうと思うけど、さすがに現状でRやPascal以下って事はないだろ

2000年頃ってDelphiが謳歌していて、VCLがイケてた時代だったから、
当時、作られた遺物の保守・改修があるんじゃないの

VBが浮上したのはもしかして Windows10 への移植か・・・

マジレスすると、tiobeはVB.NETとVB6以前を区別できないから

toibeはあてにならない
まだredmonkのほうが参考になる

c/c++も両方合わせてのカウントなんだろうね

そう考えると、スクリプトが上位を占めてる

ABAP て何？10位以下は誤差の範囲だな

業務システムのDSLだよ
この中じゃ開発サイドの利益率は一番高いんじゃないかなw

>>518
じゃあブログは何が取って変わるの？
node.jsでブログ作るの？無理でしょ

無理ではないでしょ
はてななんかPerlだよね
ブログ書く人にとって開発言語なんてどうでもいいことだし

>>527
ぜんぜん問題ないだろ。ウェブサーバになれてファイルアクセスもできるんだから。
というか、ソケットとファイルを扱えるならどんな言語だって可能だ。

無理なことと、無駄なこと（既存のものがあるから）を混同していないか？

>>527
ghost, keystone, cody, ...
node.js cmsでググれば、もう1ダース近く出てくるよ
どのぐらい堅牢か分からないし、しばらくはwordpressが続くだろうけど

hatenaがperlなのは、今更、可動しているシステムを止められないからだろw
ebay,myspace,microsoft,yahooと、既にnode.jsに以降した後だよ
railsやwordpressがmeteorに取って代わられるのは時間の問題だよね

ブログはサービスを今新しく作るならJavaかC#でいいんじゃないかな
やることが決まりきってるんだし、
ブログだとクライアント側で凝ったことするのには向かないし、
それほどnode.jsに比べて開発コストがかかるとも思えん

冗談でしょ？ebayだったか、myspaceはjavaで書かれてたものをnode.jsに移行したんだよ

こいつまだnode.jsとか言ってんのか
主要メンバーio.jsに移ったのに

noderが以前の勘違い系Rubyistみたいになってる

ちなみに
ttps://www.google.co.jp/trends/explore#q=meteror%2C%20rails%2C%20%2Fm%2F02vtpl&cmpt=q&tz=
ttps://www.google.co.jp/trends/explore#q=meteror%2C%20rails&cmpt=q&tz=

どちらにしてもJavascript界隈は活発だな

io.jsは流行らないよ。そもそも、forkして流行ったようなものって何かあった？
xemacs,plan9,golang,rubinus,cakephpやcodeignitorの派生と失敗しか思い当たらない

>>536
meteror を meteor とスペルミスしてるのはワザトかと思ったが、
訂正して再検索しても結果は同じだった（Meteor 息してないよ >>536）

https://www.google.co.jp/trends/explore#q=JavaScript%20Meteor%2C%20Ruby%20Rails%2C%20Python%20Django%2C%20PHP%20CakePHP&cmpt=q&tz=

なおキーワードが "Rails" だけでは鉄道関係も含まれて不公平なので、"Ruby Rails" とし、
WordPress はアプリケーションであってフレームワークではないので、"PHP CakePHP" とした
同様に他の LL についてもそれぞれ "JavaScript Meteor" "Python Django" としている

目立つのは 2006..2008 近辺における Rails への爆発的なトレンド
それだけ Rails の登場は Web フレームワークにおける革新的な存在であったのだろう
その後、緩やかに Rails のトレンドは低下しつつあるが、
それでも Rails と比較すれば他のフレームワークのトレンドは誤差(ゴミ)に等しい
３年や５年そこらで逆転するとは、とうてい予測できない
データは冷酷だね

perlの凋落なんて、あっという間だったろ？誰か、catalystって憶えてる？

いつものjs厨
スルー推奨

>>538
DjangoみたいなオワコンとRailsで3倍くらいしか差がないやんけ
思ったよりRails落ちて来ててワロエナイ

Python, PHP, Perl, Ruby, Javascript に programming をつけて google trends

http://www.google.com/trends/explore#q=Python%20programming%2C%20PHP%20programming%2C%20Perl%20programming%2C%20Ruby%20programming%2C%20Javascript%20programming&cmpt=q&tz=

伸び率予想も含めて、

python>>>>>>js>>>>>ruby>php

グダグダいうよりデータ

>>542
python が増えてるのは、他が落ち込んだ影響だね。
PHP や Perl は減ってるけど、資産があるだろうから検索が減ってるからと言って利用が減っているとは限らない。

2007年ごろに Ruby なども上昇してきたけど、その時に Python が選ばれたっぽい。
しかし、Phthon は 2.x と3.x で分かれてるから・・・

それって、Webサイトに選ばれてるの？

> 数値計算なんてFORTRANがかろうじて生き残ってた世界なのに、そんな世界での優位性を
> 主張するなんて、PythonはFORTRANの後釜でも狙ってるというのだろうか？

流石、バカは物事の技術的背景を全く考えない発想をするんだなwwwww

JSはプラグマ指定でクラスベース型付言語になるし、
もうJSで"use python"とかできるようにすればこの論争は終結じゃね

数値計算云々の話なら、Pythonには良いネイティブライブラリのラッパーがあるって文脈だから
ウェブブラウザというサンドボックスしか与えられなければ、Pythonの利点は無くなっちゃうよ

Pythonは文法が極めて平易で、妙な罠仕様も少ないから
教科書に載ってるような擬似コードがほとんどそのまま動く
そして、関数型やRubyの世界と違って平易なコード=良いコードという共通認識がある
それがプログラミングを専門としない人達に好まれる理由だよ

機械学習とか統計ものとか、色んな本でよくPythonが選ばれてるよね

可読性とシンプルさを重視してる分、いろんな分野の人がとっつき易いし
紹介する側も楽なんだろね

Pythonて地味にいいんだよな

でも国内で飯食うならRuby一択なんすよね＾＾
国産言語で国が行政が後押ししてるんで安心なんすょぶっちゃけ＾＾

IT業界全体が英語圏の後追いでしかないから、行政の後押しなんか寧ろ無駄にRubyを延命してしまって日本の開発事業をガラパゴス化させる要因になりかねない
まぁRubyに限らず、IT業界だけは日本製に慣れ親しんじゃダメだと思う

小さな島国の馴れ合いコミュニティに頼らなきゃ食えないレベルなら
JavaやCOBOLでもやってたほうがよっぽど効率良く稼げるよ

しかしITの本場である米でRubyは未だ一大勢力である事実
日本より使われてるというねw

>>550 可読性
いや、逆に窮屈に感じる。ライブラリとしては、スタイルが重要ですが…

むかし、Cがはやりだしたころ、Cのよさとして、自由なスタイルでかけるというのがあった（よめない！）
製品は、高価でかえなかった。フリーソフトウェアは、自由にかかれていた

いや、WordPressは当分残ると思う

>>554
日本以上に使われてるのか
Ruby最強じゃん

Rubyは日本ではあまり使われてない。

Rubyistは自分の故郷では敬われないものだ

RubyはいいんだけどRailsどうにかならんかな
プログラミングするってかAPIの使い方ばっかり探してる

探して見つかるものならまだいいが、Railsは動的に定義される(orされてると見なせる)メソッドが多いから
大量の約束を丸暗記しなきゃいけない

>>549
その「平易なコード」が「手続き型プログラミングによるコード」を指すのならば、主旨に同意する
実際、(>>549 にもあるように)「教科書に載ってるような擬似コード」の多くは、
(常識的な)手続き型プログラミングのスタイルで書かれている

そして手続き型プログラミング言語として Python は簡潔な言語仕様で設計されているから、
初心者へのプログラミング教育に最適である
くわえて「プログラミングを専門としない人達」が道具として扱うプログラミング言語としても適している
彼らは道具がもたらす結果が重要であって、道具そのものの優劣には無関心であることが多い
実際、ビジネス分野では COBOL や VB、技術計算分野では FORTRAN や C が未だに現役である
そんな人達がスクリプト言語に手を出すとしたら、Python が最も違和感無く短期間で習得できるだろう

こうした Python への高評価が、>>542 のトレンドに表れたと言えるだろう
そして、この傾向は今後も継続し、少なくとも３年や５年といったスケールで Python が凋落することはない

>>551
> でも国内で飯食うならRuby一択なんすよね

いや、Ruby は Rails への求人は比較的多いが、Ruby そのものへの求人や案件はほとんど無い
しかも Rails 求人が比較的多いといっても、Webアプリ求人の大半は PHP(および Java)であって、
意外性で(ごく少数の) Rails が目立っているにすぎない
またシステム運用管理の求人であれば、(Ruby よりも)Perl のほうがずっと多い


> 国産言語で国が行政が後押ししてるんで安心なんすょぶっちゃけ

いや、国や行政が後押ししてるという事実は、残念ながら存在しない
まれな例外として島根県の松江市が Ruby 案件を扱う地元企業を支援しているけれど、
これは(Ruby 発祥の地である)松江市という地方自治体による後押し or 町おこしの一つにすぎない

類似のケースとして、長崎県では Open COBOL 案件を扱う地元企業を支援している
そして(現在のメンテナは海外へ移転しているが)Open COBOL の開発者は日本人であり、
しかもその開発の過程では IPA という国の機関から支援を受けている
　　http://ossipedia.ipa.go.jp/doc/14/　　--　オープンソースCOBOLコンパイラの開発
しかし、これだけの類似性があっても：
　　Open COBOL は、国産言語で国が行政が後押ししてるんで安心なんすょ
などと語る人はいないし、マジで主張しているなら妄想扱いされるだろう

>>563
> いや、国や行政が後押ししてるという事実は、残念ながら存在しない

刑務所作業で Ruby が選択されている。
刑務所を運営するのは国。

昔からRubyを「ツール」として愛用してきた身としては
RailsからのRuby界隈の流れは何だか複雑な気持ち
RoRが出た当初ぐらいはまだ良かったけど、Rubyで便利にRoR、じゃなくて
まずRailsありき、の人がやたらと増えちゃった、ここの評価もそうだし

rubyの思想はアメリカには受けそうだが、実際のところどうなの？
データとかない？

道具としてはpythonだな

上の「飯食うためにRuby」って人もたぶん意味するところはRubyでなくRailsなんだろうし…
RailsってカルトでRuby信奉されても正直困るし、そんなカルトを基準にRuby叩かれてもって感じ

カルトは Ruby で Rails は現実解だろ

Ruby 地域別人気度
フィリピン 100
アメリカ合衆国 73
ニュージーランド 61
オーストラリア 52
トリニダード・トバゴ 51
ブルネイ 46
香港 45
http://www.google.co.jp/trends/explore#q=Ruby&date=today%2012-m&cmpt=q&tz=

Python 地域別人気度
中国 100
アイスランド 39
アメリカ合衆国 31
イギリス 24
イスラエル 23
セントヘレナ 23
シンガポール 22
http://www.google.co.jp/trends/explore#q=Python&date=today%2012-m&cmpt=q&tz=

COBOL地域別人気度
インド 100
日本 68
フィリピン 63
南アフリカ 51
スペイン 30
アメリカ合衆国 28
ブラジル 24
http://www.google.co.jp/trends/explore#q=COBOL&date=today%2012-m&cmpt=q&tz=

"pythonのパラドクス"なんて記事があるけど、
これって、phpやjavascriptにも当てはまるよね

>>568
Rails時代になるまではカルトと言われることはほぼ無かったよ
(作者がカルト信者、と言う人は居たけど)
しきりにそう呼ぶ人が出たのもまたRailsのイメージで語られるようになってから

PythonとRubyでは、どちらがJavaに似ているの？
Javaの次に学習したいんだけど、学習コストの面で似ている方の勉強をしたい。

RubyとJavaの相性はいいよな
Javaやった後にRubyさわるとおしっこ漏らす

>>569
ウソだろと思ったらウソだった。
Python に Windows か Linux をくっつけて検索したら、インドが上位に入ってくる。

Ruby に Windows をつけると、４つしか出てこない
日本　100
インド　72
アメリカ合衆国　54
イギリス　42

ttp://ja.wikipedia.org/wiki/%E3%83%AB%E3%83%93%E3%83%BC
> 天然ルビーは産地がアジアに偏っていて欧米では採れない

Perl と違って Ruby や Python は 有名な現物と同じ綴りだから、検索は絞り込みしないとおかしくなる。
宝石の Ruby で検索すると、プログラミング言語の Ruby や Python はないに等しい
ttp://www.google.co.jp/trends/explore#q=Ruby%20%20windows%2C%20Ruby%20%20%20%20%20linux%2C%20Python%20windows%2C%20Python%20linux%2C%20Ruby%20-windows%20-linux&date=today%2012-m&cmpt=q&tz=

Ruby＋Linux
100　日本
59 　アメリカ合衆国

Ruby＋Windows
100　日本
72 　インド
54 　アメリカ合衆国
42 　イギリス


railsを開発した Jason Fried 氏がアメリカで広めただけか。
広がっていく可能性はあるけど。
ttp://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work?language=ja

石を裏返してみよ。シリコンバレーはそこにある。
木の側をひっぺがしてみよ。シリコンバレーは、そこにある。

>>572
明らかにPython
3つとも使っててどの信者でもない人に聞けばほぼ満場一致だと思う
細かい根拠を挙げればキリがないが、
Pythonは開発陣がJavaをリスペクトしてるし、Javaを参考にして作られたライブラリも多い
Ruby世界ではJavaはいわゆる楽しくない言語の最大派閥であり
憎むべき敵だからね

>>573 >>577
ありがとう！とても参考になったよ。
派閥という観点は興味深いですね。

あ、検索がおかしいだけか

"ruby on rails"

100　インド
66 　アメリカ合衆国
58 　台湾
57 　フィリピン
52 　カナダ
52 　ウクライナ
48 　ポーランド
46 　オーストラリア
42 　ロシア
41 　日本

なんで日本はフィリピン以下なんだ？

"ruby on rails"

2005　100　アメリカ合衆国

2006　82 　アメリカ合衆国
　　　　67 　オーストラリア
　　　　64 　カナダ
　　　　61 　日本

2008　100　インド
　　　　44 　日本
　　　　41 　アメリカ合衆国

2011　100　インド
　　　　66 　ロシア
　　　　58 　アメリカ合衆国
　　　　47 　日本

2013　100　インド
　　　　62 　中国
　　　　60 　アメリカ合衆国
　　　　53 　フィリピン

>>565
そうなの？
おれにとってもRubyはツールだよ
Rubyでちょこちょこ小銭稼いでるけどそれはwebにすら関係ないし

Railsはではじめのころからまったく他人事、いまも他人事、まったく関係がない

ぶっちゃけどれも似てない。
Pythonが似てるというのならJavaScriptでさえ似てると言えるだろう。

Python と似てるのは C言語のはず。見た目違うけど。

インデント構造は珍しいけど
C言語にインラインで組み込む MASM では普通にあんなインデント使うし
GOTOのラベルと制御文のコロンが一緒。

C++使っていてPythonに始めて触れたときは、C++を自然にした感じに見えたなぁ。
instance.method で self がバインドされた関数オブジェクトが返るところとか。
演算子も同じようにオーバーロードできたし。

JavaScriptはLuaにPerlの悪いところを取り込んだ劣化版にしか見えなかったが、
ブラウザでもサーバーサイドでも動くから、学習 / 教育コストを減らすために
どうしたって今後はjsが増えていくのは確実だろうな。

jsはschemeにcの構文取り込んだんだよ
最初、schemeを載せるつもりだったのに猛反発うけたわけ

JavaScriptの構文と言ってもES6でだいぶスマートに書けるようになったし。
もうほかの言語と余り変わらないと思うよ。

>>579-580
Rubyは英語みたいなもんだから、日本人には不利。
一方、英語人には自然と話すように、
簡単にプログラミングできる

でも、日本のコミュニティは世界一。
Rubyistが優しいのは、日本人が多いから。
他の言語では、自己虫が多いし、もっとギスギスしている

そもそもコミュニティが作っている言語とそうでない言語ではいろいろと違うだろう。

パイソンはパスカルじゃね？

以前は偏見は無かったつもりなんだが >>587 みたいなのを多く見てRubyに不信感を抱くようになったんだよなぁ……

Rubyコンに行った多くの人が、
優しくてすばらしい人が多いと言っている

他のコミュニティとは違うらしい

まあ実際のところは2chの質問スレを見れば大体わかるよな。

ああいうコミュニティって面倒くさい
新顔か？とりあえず●●さんに挨拶しとけよ、みたいな

>>563
っ福岡
福岡はメチャンコRubyとmRubyに力入れている

Ruby信者さんてRubyは自由だ多様性は善だと言っておきながら、
Ruby以外は認めないっていう矛盾したことを平気でいう人が多い

>>595
たとえば、こんな人達のことかな？

>Ruby世界ではJavaはいわゆる楽しくない言語の最大派閥であり
>憎むべき敵だからね
(>>577 から引用)

Python信者のRuby叩きってなんなの？目の敵にしすぎでしょ
RubyistはPythonなんてなんとも思ってないのに・・・。（むしろそこが気に喰わないのか？）

Ruby叩きなんてしてないよ
信者の方

>>597
坊主(ぼうず)憎けりゃ袈裟(けさ)まで憎い

>>598 みたいなのは典型的な島国根性気質だから、ほっとけばいいw

JRubyの出来はカナリ良いので
Java使いの次の選択肢として悪く無いんだけど、
Rails以外の理由でRubyを選ぶような人は意識高い系なので
Clojureとかに行ってしまいがち

どっちかというと他を認めないのはPythonの方だと思うけどなぁ…
かつては永久凍土問題とも言われてたし、そういう文化が根強い感じ

Py厨はガラが悪い。まるでヤクザのよう。
Ru厨は知識がない。まるでお山の大将。

>>600
×意識高い系　⚪︎手段が目的化してる系

>>597
Python と言うすぐれた言語があるのに国策で無理やり Ruby をやらされるからだよ

JRuby使うくらいなら標準サポートのJS使えばよくね。
Rubyist以外が意識高いとわざわざRubyを選択する理由があるかねぇ。

>>604
>>564
ワロタ

不毛な議論になりがちだね

ちょっと趣向を変えて......

分野別
www.google.co.jp/trends/explore#q=Ruby%20web%2C%20python%20web%2C%20javascript%20web%2C%20node.js%20web&cmpt=q&tz=
www.google.co.jp/trends/explore#q=ruby%20scraping%2C%20python%20scraping%2C%20javascript%20scraping%2C%20node.js%20scraping&cmpt=q&tz=
www.google.co.jp/trends/explore#q=ruby%20embedded%2C%20python%20embedded%2C%20javascript%20embedded%2C%20node.js%20embedded&cmpt=q&tz=
www.google.co.jp/trends/explore#q=Ruby%20science%2C%20python%20science%2C%20javascript%20science%2C%20node.js%20science&cmpt=q&tz=

国別
www.google.co.jp/trends/explore#q=Ruby%2C%20python%2C%20JavaScript%2C%20node.js&geo=JP&cmpt=q&tz=
www.google.co.jp/trends/explore#q=Ruby%2C%20python%2C%20JavaScript%2C%20node.js&geo=US&cmpt=q&tz=
www.google.co.jp/trends/explore#q=Ruby%2C%20python%2C%20JavaScript%2C%20node.js&geo=CN&cmpt=q&tz=

結構意外な結果も多い

>>607
Ruby science に関してだけど
Ruby laser と少し同期してるんだけど
ttp://www.google.co.jp/trends/explore#q=Ruby%20science%2C%20Ruby%20%20laser%2C%20Ruby%20science%20laser&cmpt=q&tz=

Ruby science
100　アメリカ合衆国

Ruby laser
100　インド
19 　アメリカ合衆国
17 　イギリス

Ruby laser windows
0


そういえば Python の実物がいるのもインドだっけ。

>>605
JRubyとJSってかなり方向性違うと思うのだが、なぜ代替になると思った？

Ruby Python JavaScript Node.js 各言語＋mathematics
Python がわずかにあるだけ
ttp://www.google.co.jp/trends/explore#q=Ruby%20mathematics%2C%20python%20mathematics%2C%20javascript%20mathematics%2C%20node.js%20mathematics%2C%20%22Scientific%20computation%22&cmpt=q&tz=

科学技術計算の英訳は Scientific computation （Google翻訳）だけど、一件も出てこない。

scientific computation も決して間違った言い方じゃないんだけど
scientific computing の方が良く使われるから、そっちなら出るかも

もうちょっと広い意味ではnumeric computing
どれも出なかったけど

意味は広いかもしれないけど、そういう言い方はあんまりしない
Numerical analysisなら使う

検索で宝石のRubyを省くなら蛇のPythonも省いて統計取らないと

蛇（パイソン）とか悪魔（デーモン君）
ゾンビプロセスとか
Guile（腹黒い[陰険な]ずるさ,悪知恵,狡猾(こうかつ); 二枚舌,二心.）とか
Unix系は、悪趣味だな！
悪の権化

悪魔はdemon、Unixのはdaemonな
とマジレス

>>615
そうだよ。Windowsがキリストの十字架に見立ててるんだ。XPなんてまさにそれ。
Gnashなんて、M$の楽園の提供する楽園に入れず、傲慢、無精、怠惰だけが取柄の地獄で歯ぎしりしてる連中だね。

>>616
デーモン「君」なのだからFreeBSDのマスコットキャラクターのことだろ

ここだけの話し、ダンコガイや堀江がperlのプロパガンダを振りまくことになったのも、
高価な真珠を豚に与えてはならないっていう預言が実現するためのものだったんだ。

なにそれこわい

勢力争いみたいなのは、JS勝利で確定なんだから、今さらどうでもいいだろ

カテゴリが選べるんだった　失礼

"プログラミング"
www.google.co.jp/trends/explore#cat=0-5-31&q=Ruby%2C%20python%2C%20JavaScript%2C%20node.js%2C%20php&cmpt=q&tz=
アメリカ
www.google.co.jp/trends/explore#cat=0-5-31&q=Ruby%2C%20python%2C%20JavaScript%2C%20node.js%2C%20php&geo=US&cmpt=q&tz=
日本
www.google.co.jp/trends/explore#cat=0-5-31&q=Ruby%2C%20python%2C%20JavaScript%2C%20node.js%2C%20php&geo=JP&cmpt=q&tz=
中国
www.google.co.jp/trends/explore#cat=0-5-31&q=Ruby%2C%20python%2C%20JavaScript%2C%20node.js%2C%20php&geo=CN&cmpt=q&tz=

"ネットワーク"
www.google.co.jp/trends/explore#cat=0-5-311&q=Ruby%2C%20python%2C%20JavaScript%2C%20node.js%2C%20php&cmpt=q&tz=
アメリカ
www.google.co.jp/trends/explore#cat=0-5-311&q=Ruby%2C%20python%2C%20JavaScript%2C%20node.js%2C%20php&geo=US&cmpt=q&tz=
日本
www.google.co.jp/trends/explore#cat=0-5-311&q=Ruby%2C%20python%2C%20JavaScript%2C%20node.js%2C%20php&geo=JP&cmpt=q&tz=

"インターネット　ソフトウェア"　アメリカ
http://www.google.co.jp/trends/explore#cat=0-5-32-807&q=Ruby%2C%20python%2C%20JavaScript%2C%20node.js%2C%20php&geo=US&cmpt=q&tz=

やっぱりアメリカが先を行ってて他が後追いしてる感じがする

apacheやnginxにluaのモジュールって、何となく気持ち悪いよね
このぐらいならperlの方がマシ

js勝利で確定らしいよ

>>623
perlってC/C++の実行ファイルへの組み込みってできるの？
luaの利点ってそこでしょ？

勘違いしてる人が多いけど、luaでいう組み込みってスクリプトも含めた組み込みな
ユーザーにスクリプト書かせる用途では、luaでは少;々不便なのでPythonなどもっと豪華な言語が好まれる

>>626
一昔前は確かに組み込みといえばPythonだったけど、最近でもPythonを組み込んだものって開発されてる？
Pythonの豪華さって、ライブラリの豪華さであって、
アプリ内の環境とファイルに多少触れれば十分な用途では、そこまでの差を感じられるのかね？