レス数が1000を超えています。残念ながら全部は表示しません。

rubyを語るスレッド

1 ：名無しさん＠お腹いっぱい ：02/04/16 23:24

語ってみましょう

2 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:25

2

3 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:25

SUN

4 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:29

死！

5 ：名無しさん＠お腹いっぱい ：02/04/16 23:32

rubyの入ってる鯖ってたくさんあるの？
まだまだ少なくないですかね？

6 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:35

俺のおちん○には パール しか入ってねーな。

7 ：５ ：02/04/16 23:35

CGIの置ける鯖ね

8 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:37

eruby.cgi とか mod_ruby とかがあるけど。
使い方わかんない。

9 ：禿しく板違い ：02/04/16 23:39

プログラム技術板へGo
http://pc.2ch.net/tech/

10 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:44

正直いって、あんまりRubyって好きじゃないんだけど...

mod_ruby
http://www.modruby.net/index.html.ja.jis

erb
http://www2a.biglobe.ne.jp/~seki/ruby/erb.html

Ruby Home
http://www.ruby-lang.org/en/index.html

eRuby って?
http://kahori.com/ruby/earrings/earrings1.html

11 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:45

Gtk+はだんぜんrubyかな

12 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:46

rubyってミスあっても動いちゃうのが厄介かも

13 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:49

＞ミスあっても動いちゃうのが厄介かも

Rubyに限らないような気が...
ていうか、プログラムって、なんでバグがあっても動くんだろう
(なんでこんなバグがあったのに動いてたんだろう)
と思う今日このごろ。

14 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:50

>>10
イテレータ はなかなかいいとおもうが？

15 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:52

>>13
そうっすね。
バグがあっても動くからMSはあんなに金儲けできるんやよね

16 ：名無しさん＠お腹いっぱい。 ：02/04/16 23:57

>>15
(ﾟДﾟ)ﾊｧ?

17 ：名無しさん＠お腹いっぱい。 ：02/04/17 00:03

ｱﾝﾁ MS ｶｺﾜﾙｲ

18 ：名無しさん＠お腹いっぱい。 ：02/04/17 00:04

オブジェクト指向逝ってよし

19 ：名無しさん＠お腹いっぱい。 ：02/04/17 00:05

UNIXの実装はオブジェクト指向取り入れまくりですが、何か？

20 ：名無しさん＠お腹いっぱい。 ：02/04/17 00:06

>>11 こんなとこ？
http://www.ruby-lang.org/gtk/en/
http://ruby-gnome.sourceforge.net/
http://ruby.freak.ne.jp/gtk/

21 ：名無しさん＠お腹いっぱい。 ：02/04/17 00:07

>>14
イテレータは確かにいい

22 ：名無しさん＠お腹いっぱい。 ：02/04/17 00:11

日本語の正規表現がまぶい。

23 ：名無しさん＠お腹いっぱい。 ：02/04/17 00:14

dRubyとか強力そうだけど，まだ勉強中．
俺は好きだよ，Ruby．
ただPerlが好きになれなかっただけなんだけど．

24 ：名無しさん＠お腹いっぱい。 ：02/04/17 00:16

Objective-Cがまぶい。

25 ：名無しさん＠お腹いっぱい。 ：02/04/17 00:17

>>24なにそれ？

26 ：名無しさん＠お腹いっぱい。 ：02/04/17 00:24

静的なチェックが弱い言語だなとは思う。

27 ：名無しさん＠お腹いっぱい。 ：02/04/17 00:37

言語ネタはム板でやってちょんまげ

28 ：名無しさん＠お腹いっぱい。 ：02/04/17 01:13

ム板でRubyネタ出すと100%荒れるからなあ。
UNIX板でオーディエンスを限定してやりたい気持ちは分かる。
Rubyって、ライブラリを見てもUNIX指向はすごく強いし。

やるならsage進行でﾏﾀｰﾘとおねがいってことで。

29 ：名無しさん＠お腹いっぱい。 ：02/04/17 01:41

とにかくも先に憶えちゃったのがperlだからなぁ……

Perlが使える、という条件で、Rubyが書けるとどんな利点がありますか？

30 ：名無しさん＠お腹いっぱい。 ：02/04/17 02:02

$ だらけにしないでスクリプトを書ける

31 ：名無しさん＠お腹いっぱい。 ：02/04/17 02:16

それはありがたいかもしれない…いやマジで

32 ：名無しさん＠お腹いっぱい。 ：02/04/17 02:54

一般的に言語を学ぶ楽しさってのは、同じことを解決するのにいろいろなやり方があることを再発見するところにあると思う。

Rubyは、オブジェクト指向言語のエレガントさに手続き型言語のパワフルさや関数型言語のスマートさをミックスしていて、再発見の楽しみには事欠かないよ。 :)

UNIXの機能もほぼそのままの名前で提供されてるから、UNIX使いの人は特に、すんなりと楽しみだけ享受できると思う。

33 ：名無しさん＠お腹いっぱい。 ：02/04/17 07:18

>>32
rubyかperlか、どちらを勉強するか迷っている厨房ですが
rubyがお勧めですかね？

34 ：名無しさん＠お腹いっぱい。 ：02/04/17 10:32

>>29
type globとreferenceの山から逃げられる。あとはPerlで言語組み込み
になっている多くの機能がライブラリに追い出してあるから調べるのが
楽。「この機能はこのクラスで実装されてるだろう」と当たりをつけれ
ば大体合ってる。

35 ：名無しさん＠お腹いっぱい。 ：02/04/18 07:02

>>29
> Perlが使える、という条件で、Rubyが書けるとどんな利点がありますか？

perl でオブジェクト指向をやろうとして、
「bless ってなんだよﾜｶﾝﾈｰﾖ」と思ってたけど、
ruby ならすっきり理解できて書けた。

library 使うだけなら perl でも良かったけど、
自分で書くなら、ruby のほうが素直に書ける。

36 ：名無しさん＠お腹いっぱい。 ：02/04/18 07:06

ruby のイテレータ、マンセー。
でも、Perl や Python の library はうらやまし。

37 ：名無しさん＠お腹いっぱい。 ：02/04/18 11:36

漏れはPerl -> Ruby -> Perlと戻ってきた。 あちこちにbare word書けたり いちいちnil?しなくてもfalseっぽいのは適当に扱ってくれる 徹底したいい加減さが最高。 quick hackするならPerlは心地よい。

38 ：名無しさん＠お腹いっぱい。 ：02/04/18 12:45

>>35
Cによる拡張のしやすさという点では perl,python よりも
やりやすいと思うよ。あとは、perl拡張ライブラリ読み込みとかの
機能がついたらいいんだけど、こればかりは大変だろうなあ。

＃ほかに、Rubyになれると、perlやCに戻ったときに
　文法エラーを頻発するようになるという副作用もあります。(^_^;;

39 ：名無しさん＠お腹いっぱい。 ：02/04/18 12:48

one liner ってかけるの?

40 ：名無しさん＠お腹いっぱい。 ：02/04/18 13:09

書けるよ。コマンドラインオプションはPerlとほとんど同じだし、
$_とか$.の特殊変数もある。BEGIN{} とか END{} みたいな
awk 由来の構文もある。sub/gsub って名前は awk から来てるしね。
(でも通常プログラムでの使用はあまり推奨されてない)

一応、RubyはPerlを置き換えることができるように作ってあるみたい。
Perlにある機能は整理してほとんど取り入れてあるし、正規表現もPerl互換。

41 ：名無しさん＠お腹いっぱい。 ：02/04/18 13:10

あ、推奨されてないってのは$_とかEND{}に掛かってる。念のため。
文字列に対するsub/gsubは通常も使いまくり。

42 ：名無しさん＠お腹いっぱい。 ：02/04/18 13:14

>>40
Rubyにそういうのが推奨しないと言われつつ存在するというのが、好みではない。

43 ：名無しさん＠お腹いっぱい。 ：02/04/18 13:38

Ruby って、なんか Perl のユーザ層を分断してるようにしか見えない。

44 ：名無しさん＠お腹いっぱい。 ：02/04/18 13:51

>>42
one-linerや使い捨てスクリプト以外では使う必要ないし、
実際使われてないけどね。

>>43
Perlのユーザ層の一部が分断されたということなら、それは
Perlを使いながらもPerlに不満を持っている人がそれなりに
多かったということでは。嫌々Rubyを使うなんてことはない
わけだし。(Pythonくらいビジネスの場に出てくると、そうも
言えないけど)

45 ：名無しさん＠お腹いっぱい。 ：02/04/18 14:17

他の言語との細かい比較なら、それこそム板でやっちくり。
UNIX板ではもっと大きな話を。

個人的には、Perlみたいなスケールしない言語がここまで広まったのは
いかがなものかと思うが、CGIが火付け役だからねえ。

やっぱ、UNIXで天下を取ると天下なんだろうか。BorlandやMicrosoftも
LinuxやFreeBSD向けに手を回してるしねえ。

46 ：名無しさん＠お腹いっぱい。 ：02/04/18 16:59

multics:unix = perl:ruby

47 ：名無しさん＠お腹いっぱい。 ：02/04/18 17:06

Unixで開発しやすい環境を作ると、良質なオープンソース
プログラムが増えて、それが defact standardになる傾向
があるからでないの？
私の偏見:

趣味・知的興味のプログラミング -> Unix, Ruby, コードが奇麗
お仕事でのプログラミング -> Win, C++ or perl,コードが汚い

48 ：名無しさん＠お腹いっぱい。 ：02/04/18 17:35

フレームの元:-1 >>46 >>47
multicsやwinとperlを一緒にするのはシツレイだぞ。
perlはシンプルとは言えないが実用性はあるし哲学もある。

ただ、初期UNIXとRubyは似た所があるのは同感じゃ。
・ 既存技術より少ない基本概念で同等以上の機能
・ 枯れた概念をうまくまとめなおした
・ 新奇な要素はないのにナゼか新鮮味がある
・ 理論倒れでなく実用志向、でも美しい
・ 一流のバランス感覚

49 ：名無しさん＠お腹いっぱい。 ：02/04/18 17:40

基本的に perl ではもう何も書きたくはない、全部 ruby にしたいんだが
やっぱり世の中の機械に ruby が default で入ってないというのが大きい。
自分だけのことなら ruby でいいんだけど、他人が少しでも絡むとね。

50 ：シャロン首相 ：02/04/18 19:16

ageてるのはム板から追い出されたルビ厨ですか？

51 ：名無しさん＠お腹いっぱい。 ：02/04/18 19:45

ルビ注は、2 行以上のレスを付けることはない。

52 ：名無しさん＠お腹いっぱい。 ：02/04/18 20:20

取りあえず誰か"るびきち"を頃してくれ。
rubyのMLってキモい奴が多いよな…そう思うのは俺だけか？

53 ：ひろゆき ：02/04/18 20:40

ひろゆきです

In message ">>52"
on 02/04/18 20:20, 名無しさん＠お腹いっぱい。<sage> writes:

|取りあえず誰か"るびきち"を頃してくれ。
|rubyのMLってキモい奴が多いよな…そう思うのは俺だけか？

修正しておきます。

54 ：名無しさん＠お腹いっぱい。 ：02/04/18 21:00

>>53
コードでも書き換えてくれるのか?

55 ：名無しさん＠お腹いっぱい。 ：02/04/19 01:04

>>そうそう変化は螺旋的に進行するよな。

56 ：55 ：02/04/19 01:06

スマソ。>>37へのレスでした。

57 ：名無しさん＠Ｅｍａｃｓ ：02/04/19 02:24

イテレータってのはそんなに綺麗じゃないよなあ．
素直に関数もファーストクラスなほうが綺麗だと思う．

58 ：名無しさん＠お腹いっぱい。 ：02/04/19 02:48

Rubyの関数はファーストクラスだと思うけど。
イテレータブロックを受けとる側は

def apply(x)
return yield(x)
end

と仮引数には書かずに yield でブロックを呼べるほか、

def apply(x, &func)
return func.call(x)
end

と明示的に Proc で受け取ることもできる。渡す側も、

apply(3) { |x| x ** 2 } # 9 が返る

と渡せるほか、 Proc を作って

func = proc { |x| x ** 2 }
apply(3, &func)

とできるよ。

59 ：名無しさん＠お腹いっぱい。 ：02/04/19 02:56

http://linux.rice.edu/~rahul/hbaker/Iterator.html
挑発age

60 ：名無しさん＠お腹いっぱい。 ：02/04/19 04:29

本当にその論文読んだ？日付を見るとRubyの生まれる一年前だけど、
RubyのiteratorのデザインはまさにこのG.項前段への答えでしょう。
作者がこの論文を読んだかどうかはともかく、当然ここで論じられている
内容は踏まえていると思う。

Rubyはその後continuationを実装したり、さらにtail recursionの
最適化もやるようになったりと、FPの良さも取り入れてる。
(開発陣はかなりいろんな言語に通じているようだ)

関数型言語というと、UNIXでポピュラーになったのはSchemeくらいかな。
(elispは関数がファーストクラスじゃないから却下:-)

Rubyと反対に、FP側からOOにアプローチした言語としてO'Camlが
おもしろそうなんだけど、誰か使ってる？

61 ：名無しさん＠お腹いっぱい。 ：02/04/19 05:23

elispの関数が first classじゃないってどういうことだ?
十分 first classだと思うが..
Common Lispのような関数objectがないっていいたいのかしらん?

が、Rubyと関係ないのでsage

62 ：名無しさん＠お腹いっぱい。 ：02/04/19 07:43

>>60
> tail recursionの最適化もやるようになったりと
なっていないのでは？
http://www.ruby-lang.org/~shugo/ruby-tail-recursive.diff
パッチはありますけど。

Ocamlは一種のMLとして使う人が多いようです。

63 ：名無しさん＠Ｅｍａｃｓ ：02/04/19 12:15

>>58

確かにブロックを値としていろいろ使えることは分かるけど，なぜあの
文法なのとかとゆーこと．

> def apply(x)
> return yield(x)
> end
>
> と仮引数には書かずに yield でブロックを呼べるほか、

これがちょと気持ち悪いな．なぜブロックだけ仮引数に書かないでもよ
いの？他のオブジェクトと (文法上) 同じようには扱ってないよね．

> def apply(x, &func)
> return func.call(x)
> end
>
> と明示的に Proc で受け取ることもできる。

def apply(x, f)
return f(x)
end

と書けたほうが俺は「綺麗」だと思うのです．「オブジェクト」を意識
するというなら，許せるのは

def apply(x, f)
return f.call(x)
end

かなあ，なぜブロックだけ仮引数に & を付けなくてはいけないのか．

ちなみに俺は O'Caml ユーザーなので，綺麗か否かの基準は多くの人と
は違うのはしょうがないけど，「関数型言語のスマートさをミックス」
なら，もっと「綺麗」にミックスしてほしかった．

64 ：名無しさん＠お腹いっぱい。 ：02/04/19 12:32

一つだけイテレータブロックを(引数と別に)オプショナルに受ける、
というところが肝なのではないかな。渡すときに特別扱いならば
受け取る側も特別扱いするのが妥当かと。

気持ち悪さというのはよく理解できるけど、それ用の構文を
最適化することによってループ本体、ハンドラプロシジャ、
ソートなどにおける比較関数などに幅広く使えて便利だったと。
もし、

apply(x, proc { |x| x ** 2 })

def apply(x, f)
return f.call(x)
end

だけでよしとしていたらRubyはRubyでなかったと思う。(よくも悪くも)

65 ：名無しさん＠お腹いっぱい。 ：02/04/19 12:50

Rubyに末尾再帰が！
と思ったら入ってないのか。

何か問題があったのかな。

66 ：名無しさん＠Ｅｍａｃｓ ：02/04/19 15:17

>>64
> 一つだけイテレータブロックを(引数と別に)オプショナルに受ける、
> というところが肝なのではないかな。渡すときに特別扱いならば
> 受け取る側も特別扱いするのが妥当かと。

「特別扱い」なら素直にファーストクラスとは言えないよね．これが俺
の最初の発言 (>>57) の意図です．

> 気持ち悪さというのはよく理解できるけど、それ用の構文を
> 最適化することによってループ本体、ハンドラプロシジャ、
> ソートなどにおける比較関数などに幅広く使えて便利だったと。

せっかく便利なものなのだから，{|x| ...} のままで lambda {|x| ...}
と同じオブジェクト (一級市民) になってほしいわけですよ．確かにルー
プの本体が毎回メソッド呼出しになってしまうのはアレですが，そこは
末尾再帰呼出しの最適化とかをがんばって．

67 ：Pythonユーザ ：02/04/19 15:36

> 確かにブロックを値としていろいろ使えることは分かるけど，なぜあの
> 文法なのとかとゆーこと．

同意。Ruby にはアドホックな構文が多いと感じる。
ほかにもグローバル変数には $ がつくとか、便利かもしれないけど
「便利なら汚くてもいい」という Perl 的な思想に毒されてると思う。

便利さと美しさのトレードオフという観点からみると、

　シンプルな構文だが、あまり便利じゃない言語 (ex. Scheme)
　　　　　↑
　　　　　↓
　便利だが、構文が複雑すぎる言語 (ex. Perl)

という両極端があるとすれば、Ruby はかなり Perl に近い。
(Ruby ユーザは「Perl よりずっときれいだ」と主張するだろうけど、
構文だけを見るとそうは思えない)

68 ：名無しさん＠お腹いっぱい。 ：02/04/19 18:22

>>67
そのあたりはRubyユーザは特に争う気はないと思うよ。
「Perl由来の汚い機能には、必ずきれいな代替手段を提供する」の
ポリシーがあるから、Perlから移ってしばらくすると、Perlの流儀を
(Rubyを使ってる間は)忘れることができる。


Python にも __XXX__ 特殊関数とか、メソッドがいちいち self を受ける
ところとか、インデント指向の構文とか、関数とステートメントの区別が
あるとか、気に入らない人もいるだろうけど、それでいいと思う人がユーザに
なってるわけでしょ。

それはそうと、 Python は文法レベルで後から機能を付け足しすぎと思う。
OO も後付けだったというのは有名だけど、 2.0 以降も closure や generator を
導入したし、IOオブジェクトがあるのに >> なんて用意するし、(読みづらい)
[ for ] 演算式ができたし、ついこないだも boolean を導入したよね。
こういう節操のなさは俺の好みには合わないけど、Pythonファンからすると
たまらないんだろうな。(俺もはたから見てる分にはおもしろいが。:)

# Linux 各distro や FreeBSD ports には四つくらいのバージョンが
# 同時に入ってる..

69 ：名無しさん＠お腹いっぱい。 ：02/04/19 19:40

>>68
Python, Ruby, Perlはそのへん五十歩百歩。

70 ：名無しさん＠お腹いっぱい。 ：02/04/19 19:44

>>58
def f(x) x + 1 end
g = f
p g(1)
とかできないとファーストクラスな扱いって感じがしない。

71 ：名無しさん＠お腹いっぱい。 ：02/04/19 19:51

>>66 ループ本体は実際、毎回メソッド呼び出しですよ。
& で受けたときだけ、もらったブロックを Proc オブジェクト化します。

apply(x, f) で受ける仕様にした場合の不都合と言うと、Rubyは静的
片付けが弱い言語なので、コンパイラがこれを見て f がブロックを
受ける仮引数であると分からないところですね。

たとえば、この関数が x の値によって f を呼んだり呼ばなかったり
するとき、 apply(1, 2) のような誤用がエラーにされません。
イテレータブロックを大々的に採用し多用する言語としては、
ブロックと一般引数の混同を招くような仕様ではまずい。
よって、明示的に受ける場合は一般の引数と区別できるよう、
& をつけて静的に判断できるようにした、という説明はどうでしょうか。
(実際は逆で、実装を素直に反映したのだと思います)

72 ：名無しさん＠お腹いっぱい。 ：02/04/19 20:21

>>70
それは第一級ファーストクラスとかいうやつだっけ。Pythonはそうなってるね。
Rubyはメソッド呼出しの括弧省略を容認している都合上、オブジェクトは
method(:f) で得る仕様。(f はローカル変数 f があれば f, なければ f() 扱い)

とかやってると、ム板で激しく既出な話題に向かっていくような気がする。
UNIX板では、こんなスクリプト書いて使ってますとか、そういう話もきぼん。

漏れは日本語OKな zgrep 書いて使ってまふ。

73 ：名無しさん＠お腹いっぱい。 ：02/04/19 20:44

#スレ違いだけど
>>72
> 漏れは日本語OKな zgrep 書いて使ってまふ。
lgrep じゃダメなん?

74 ：名無しさん＠お腹いっぱい。 ：02/04/19 21:10

>>67
グローバル変数には $ が付くってのは、
そうなると汚くなることを承知の上で
グローバル変数を減らす圧力として採用してるんでは？

read.cgi ver5.26+ (01/10/21-)