Rubyの世界的人気度、TIOBE 9位に上昇 49
ストーリー by mhatta
Perlは長期低落傾向か 部門より
Perlは長期低落傾向か 部門より
Ruby好き 曰く、
RubyInsideの記事によると、プログラミング言語の「人気度」をエンジニア数や教育コース数、扱うサードパーティベンダ数などから毎月算定しているTIOBE プログラミングコミュニティ指数の2007年度11月版において、RubyがJavaScriptを追い抜き初のトップ10入り(9位)を果たした。折れ線グラフで中長期的な傾向を見ても、2007年に入ってからRubyの人気度が急伸したのが見て取れる。
タレコミリンク先…… (スコア:4, おもしろおかしい)
Re:タレコミリンク先…… (スコア:1, おもしろおかしい)
Re:タレコミリンク先…… (スコア:1)
と、書いてみたもののやはり女王はLispかなぁ。
Re:タレコミリンク先…… (スコア:1)
JavaScriptは全てを統べ、
JavaScriptは全てを見つけ、
JavaScriptは全てを捕らえて、暗闇の中に繋ぎとめる。
影横たわる(以下略)
Re: (スコア:0)
3つの言語(Scheme, Prolog, Haskell)は、数学畑の象牙の塔に。
7つの言語(Perl, Python, PHP, Ruby, ActionScript, HTML, XML)は、Webのページのクリエイターに。
9つ（FORTRAN, COBOL, PL/I, Ada, C, C++, Java, Visual Basic）は、死すべきデスマ（さだめ）のプログラマ（ひとのこ）に。
Re:タレコミリンク先…… (スコア:0)
Re:タレコミリンク先…… (スコア:2, すばらしい洞察)
Re:タレコミリンク先…… (スコア:1)
ひょっとして、見えてないので気付いていない何かが表示されてないのかな??
玄人向け言語だと思う (スコア:3, 興味深い)
どこにも明示的に定義されていないメソッドや変数なんてものが山ほど出てくる。
（ぜんぶ動的に生成してる）
さらに、既存のクラスに対していろんなところで拡張や変更を加えていて、
実行時に、あるクラスの中身がどうなっているのか追うのが異常に困難。
「設定より規約」というけど、実際には「規約が全て」で、
規約（＝仕様）を知らないとそれが即死亡を意味している。
たしかに馴れれば効率はいいかもしれんが、こんな黒魔術はどう見ても
絶賛されるようなもんじゃないと思ったよ。
あれがRuby文化なら、これ以上流行ったらとんでもない地獄が待っていそうだ。
それともRailsが異常なだけ？
Re:玄人向け言語だと思う (スコア:1, 興味深い)
素人を業界から駆逐する罠なのかも。
玄人な人にとってはむしろ朗報だけどね。
もともとRailsって「Hackとして」(たとえばGoogleに)賞賛されたわけでしょ。
むろんGoogleの中にはHackerが一杯いるのでしょう。
凡人かそれ以下の有象無象がどろどろしてるような場末の企業を支援するためのツールではないよね。
Re:玄人向け言語だと思う (スコア:1)
まあ、単純に言って、ソースコード中に明示的に現れないようなメソッドがあるなら、ドキュメントに書いておくべきだよね。Agile方法論では「ドキュメントとしてのソースコード」という考え方を持っているけど、ソースコードがあればドキュメントは不要とは言ってない [capsctrl.que.jp]し。
ところで「既存のクラスに対していろんなところで拡張や変更を加えていて」っていうけど、Rails的には何のコードをどこに置くかはかなり決まっていて、おかげて探しやすくなっていると思うけど。既存のクラスに拡張や変更を行なったのなら、それもドキュメントに書いておけばいいんじゃない？ 少なくとも拡張した張本人は、どこでどう拡張したか覚えているよね？
Ruby はもっと評価されていい (スコア:2, 参考になる)
いくらなんでも Delphi よりは評価されていいと思う。今まで Delphi より下だったという事の方がショックでした。
しかし、C++ が Visual Basic に抜かれた、という事の方が興味が。VB6 から VB.NET への移行、特に .NET Framework 2.0 以降への対応などによる人気なのでしょうか。
.NET Framework 2.0/Visual Studio 2005 が出る少し前にかなり低下 (6.0% 程度) していつつ、その後の急上昇っぷり (最大 11% 超) がなかなか興味深いところです。
# 最低でも 6% ってのは、やっぱり結構人気がある (Nov 2007 の順位でも 6% あれば 5 位以内) のか。
Re:Ruby はもっと評価されていい (スコア:3, 興味深い)
Delphi は Windows 向け GUI Builder なので、Ruby の領域とは重ならないというのが実感です。
評価軸が違えば結果も違ってくるでしょう。
Win32 向けの GUI つくるなら、各種コンポーネントライブラリも充実しているので、いまでも Delphi が最速じゃなかろうか。
Vista への移行が進まないので、結果として Delphi Win32 の活躍の場も延命してるなあ。
Re:Ruby はもっと評価されていい (スコア:1)
Delphiの場合、言語の評価というよりもIDE込みでの快適さや早さなんかが重要なので直接比べるものではないですね。
原始Pascalと比べればRubyのほうがリッチでしょうが、ObjectPascalはJavaぐらいの柔軟さはありますし。
そういえば世界最古のDIコンテナはdelphiだという話もありましたね。
Re:Ruby はもっと評価されていい (スコア:1, 興味深い)
驚かされてしまうのもDelphiです。
Javaに遜色ないメタ機能を有する言語なんだけど、そういう情報にアクセスするたびに、アクセスに要した構造体だのなんだのを「さて、これいつ開放しようか？」と悩まないとならないので、そういう機能を使うのに二の足を踏んじゃいます。
実際メタ機能を使いまくるクラスを書いてみたりしたけど、綺麗に書けない傾向にあります。残念だ。
>世界最古のDIコンテナはdelphi
そうです。
オブジェクトやその組み合わせや属性について、
コード中で生成＆接続するんじゃなく、
別のファイル(Delphiでいえばフォームファイル)の設定情報に基づいて
コードの外からオブジェクトを組み立ててあげる。
これすなわちDIです。
フォームファイルのようなものはどこのGUIビルダにも有るし、
GUIビルダとしての良さだけ考えるならば
先輩のVBだのHyperCardだのに勝っているかどうかも微妙です。
が、
フォームファイルというものの位置づけと、
プログラミングというものの
「組み合わせ」を旨くデザインしたという意味では、
Delphiが前代未聞の出来だったとは言えるでしょう。
いっぽう、RubyだのPythonだのに、
そういうフォームファイル的なものを与える
というアプローチは原理的には十分可能だと思われます。
それだけ言語が強力ですから。
あとは実際にそれを実装する人が現れるかどうか、でしょうね。
WebでRailsが出たように、良いGUI構築環境を作れば、
Rubyはそっち畑でもブレイクし、
「領域とは重ならない」
という言葉も過去のものとなることでしょう。
Re:Ruby はもっと評価されていい (スコア:1)
Re:Ruby はもっと評価されていい (スコア:1)
といいつつランキングよく見てなかったので見てみました
COBOL以下、Ada以上というのも何となく歴史を感じます
間に挟まってるABAPって知らなかったんですが、SAPのPL/SQLみたいなものなんですね。これ以下ってのは嫌だなあ
Re:Ruby はもっと評価されていい (スコア:2, 参考になる)
>VB6 から VB.NET への移行、特に .NET Framework 2.0 以降
>への対応などによる人気なのでしょうか。
予算に余裕のあるプロジェクトならGUIを実装するという単調な仕事
はVBを使い、コアな実装のみVC++となることがおそらくMSの望みなの
で、Windowsプログラマの場合、VBを使っている層がVC++使ってる層
より「頭数」が多い。分業が進んだのかも。
Re:Ruby はもっと評価されていい (スコア:2, すばらしい洞察)
それは C# を見落としすぎではないかと。C# 3.0 の強化を見ると VB との差がつきすぎですから。
どうしてもネイティブな処理を各部分では C++ を使うようにして、それ以外は C# というのが MS の方向性に思えます。もっとライトな部分には Ruby とか Python とか。
# さすがに IronRuby で XAML を動的生成とかはきもいと思いますが。
Re:Ruby はもっと評価されていい (スコア:0)
そしてそれを高みから見下ろすRuby(ｗ
パーシャルクラスだの、
クロージャだの、
LINQ(DSLと捉えるならば)だの、
良くも悪くも近年のC#は
「なにこのRubyの後追い言語は？」
と思われる節が散見しますね。
(もちろん強型言語としてのスジも通ってるんだけど)
「みんながRubyを理解したらC#(当時の)はソッポを向かれてしまう！」と
あのMSをすら怯えさせたわけだから、
そういう意味でここ最近のRubyの影響力の強さは、すさまじいの一言だと思います。
対MS戦を一個人(Matz氏)でやってのけた点だけ見ればJava以上だ。
>IronRuby で XAML を動的生成
XAMLそのものじゃなく、XAMLのDOM(?)を生成すればいいと思う。
いちいちXMLというNotationレベル(ないしはシリアライズ形式)まで降りるのは無駄。
Re:Ruby はもっと評価されていい (スコア:1)
元々 C# が Java のおいしいとこ取りである (そして現状とっくに抜いてしまっている) ところを考えれば、Ruby のおいしいとこ取りをしたところで全く違和感がない、というのもあったりしますね。
C# 3.0 で追加された機能は、フレームワークレベルでは .NET Framework 2.0 の機能を総動員で実装している (ので、3.5 になっても根幹部分が変わってない) というのも肝だと思ったりします。それだけの機能を実装するための下地が揃っている、というか。
C# Generics が C++ Template 並の使いやすさがあればもうちょっと楽なのですが、そこまで行くと他の言語が同じフレームワークを使えなくなりそうなのがアレでソレ。
# フレームワークがコンパイラを内蔵しているので、スクリプトと称して C# なり VB なりで直接記述→動的にコンパイルして DLL を生成し実行、なんて荒業も簡単にできるのが微妙と言えば微妙です。
Re:Ruby はもっと評価されていい (スコア:1)
実業務での適用範囲が違いすぎるし。言語というか「開発環境」として。
なお、私は両方とも好きです。
--- （´-`）｡oO(平和な日常は私を鈍くする) ---
全米が泣いた (スコア:2, 参考になる)
ほとんどRubyにふれた話題らしいものが全くといってよいほどない
スラドに全米が泣いた。
Re:全米が泣いた (スコア:2, 興味深い)
Copyright (c) 2001-2014 Parsley, All rights reserved.
一方はてなでは… (スコア:1, 興味深い)
次のバズワードは (スコア:1)
Re:次のバズワードは (スコア:0)
Re:次のバズワードは (スコア:1, すばらしい洞察)
割り算 (スコア:1, 興味深い)
ちょっとした計算をするプログラムが書き難い気がする。
特に、割り算(/)の定義がCに合わせてあって、整数と実数とで扱いが違うのが不自然。
たとえば、この三角形の面積を計算する関数が間違いだというのは、どうも納得がいかない。もちろん、to_f とか quo を使ったり、引数に整数が来ないように気を付けたりすればいいんだけど、
そういうことに気を使わなければならない必然性が良くわからない。
元のCの場合にはこの問題は起きないわけだから、単純にCに合わせるというのは合理的でないし、
実際PerlやPythonではCに合わせなかった。そこを敢えてこのようなふるまいにしたのは何故なのでしょうか？
Re:割り算 (スコア:3, 参考になる)
何故かって言われても、二項演算子の正体がメソッド呼び出しのシンタックスシュガーだから、としか言いようがない気が。
というか戻り値を浮動小数にしたいなら、base * height / 2.0って書けば良いだけで、すぐに慣れると思うけど。
Re:割り算 (スコア:1, すばらしい洞察)
いや、メソッドだろうがオペレータだろうが関係なく、オーバロードしてある(デフォルトの)動作に一貫性が無いってことなんじゃない? 何を以って一貫してるとするかは議論の余地があるけど、これに関してはCの悪い面を引きずったと言えるんじゃなかろうか。(「Cの仕様と一貫性がある」とは言えるだろうけど。ほんとに便利?)
尤も、万人が納得する解決は無いだろうけどね。正確に割り切れない時は浮動小数点数に型変換する、という仕様だと、思わぬところで制度が落ちることがある。両方が正確な数なら分数で計算する、という仕様だと、うっかりしてると計算のほとんどが分数のまま進行して(浮動小数点数演算に比べて)がくんと性能が落ちることがある。
Re:割り算 (スコア:0)
もちろんそうですが、なぜデフォルトの定義がそうなっているのかという質問です。
> というか戻り値を浮動小数にしたいなら、base * height / 2.0って書けば良いだけで、すぐに慣れると思うけど。
なるほど、例が良くありませんでした。
長方形の面積(area)と幅(width)から高さを求めるときに、area / width と書くのが間違いという話でもいいです。
たぶん私が言いたいことは、その場に 2 とか 2.0 とか書いてあれば挙動はわかるけど、
変数にして
Re:割り算 (スコア:1)
なるほど。そういうフィーリングを持っている人はいるでしょうね。自分はそういうフィーリングではないんだけど、それはそれでわかります。
僕としては、面積を求めるような処理の場合は各数値を浮動小数で持つことが前提になると思うんですね。浮動小数と整数はかなり挙動が違うので、暗黙の型変換はできるだけない方が良い、と考えるのはそんなに不合理ではないと思います。Matzの考えはここ [nikkeibp.co.jp]あたりによく出ているかな。
Rubyの場合、BigDecimalやRationalも用意されているので、割り切れない割り算の結果が自動的にFloatに決まるのはちょっと問題ではないかという気がします。
Re:割り算 (スコア:0)
主な原因はソースコード内の演算子そのものは1文字しかなくて圧倒的に情報量が足りないせいだから、メソッド名と同じくらい自由に名前を付けられるようにすれば解決すると思うんだけど、そういう言語ってめったにない。
最低でもOcamlみたく、浮動小数演算子は「+.」とかにすればいいのに。
Re:割り算 (スコア:0)
それは違います。どの演算子にどのような演算を割り当てるかを明確にしてさえいれば、
その定義がどれほど奇抜なものでも、言語を学ぶ段階でわかります。
Rubyの問題は「/」という演算子にどのような演算を割り当てるかを明確にしていない点にあると思います。
おそらく「/」は「割り算」だと考えているのだと思いますが、「割り算」という言葉には「通常の除算」と
「整数を商とする除算」の二つの任意性があるのに、どちらを選択するか明確にしていないということです。
どちらを選択するかはどうでもいいことですが、どちらかを選択していないことが奇妙な型変換を要求することになるわけです。
ただ、結論として、浮動小数点「的」な演算子を「+.」のようにするというのは一つの正しい解決策だと思います。
Re:割り算 (スコア:0)
変数が整数だろうが知らないオブジェクトだろうが平気という方向で考えてみてはどうでしょう。
Re:割り算 (スコア:2, 参考になる)
現時点の最新版であるPython 2.5では、除算"/"を使うと
$ python -c "print 3/2"
1
となります。オプション等で変更すれば
$ python -Qnew -c "print 3/2"
1.5
となりますけど。
# ちなみに、切り捨て除算は"//"ですね。
# 個人的には修正し忘れがちょっと怖い(^^;)
Re:割り算 (スコア:0)
Re:割り算 (スコア:0)
（それ不倫の公式）
Re:割り算 (スコア:0)
Re:割り算 (スコア:0)
すればいかがでしょう？
数学の数式を書いているつもりでRubyの式が書けますよ。
人気はともかく性能は (スコア:1, 興味深い)
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=... [debian.org]
CPU時間でざっくり順位付けをすると以下；
性能面では平均以下。
Basicは意外に性能がいいのには驚いた!
ソース効率では、Ocaml良かったと思う。
C gcc>C++
>Basic>Pascal,Ada,Ocaml
>Java6serv>FortranG95>SmalltalkVW
>Python>Perl>PHP
>Ruby,JavaScr,TCL
TOP10圏外から9位に入るにはJavascript以外も抜く必要がある (スコア:0)
DelphiとSASとやらが落ちたようだがSASってなんじゃらほい？
Re:TOP10圏外から9位に入るにはJavascript以外も抜く必要がある (スコア:2, 参考になる)
13位のPL/SQLと22位のTransact-SQLのSQLのストアドプロシージャ系とか24位に数値計算等に使うMATLABが入ってるので不思議じゃないかな。
Re:TOP10圏外から9位に入るにはJavascript以外も抜く必要がある (スコア:0)
Re:TOP10圏外から9位に入るにはJavascript以外も抜く必要がある (スコア:0)
Re:TOP10圏外から9位に入るにはJavascript以外も抜く必要がある (スコア:0)
○Simulink
MATLAB/Simulinkだけじゃなく，LabVIEWやVisSim，SystemVueも忘れないでね
好き嫌いじゃないよ (スコア:0)
俺はrubyもpythonもVBも好きではないが、問題解決に一番便利であれば迷わず使うしね。
Re:好き嫌いじゃないよ (スコア:0)
一位がJava（笑）なあたり、それには同意しかねる。