Rubyに'end'って要らないよな
■ このスレッドは過去ログ倉庫に格納されています
2019/07/14(日) 10:11:47.62ID:aojaqLwq
インデント揃ってればそのままend無くしても読めるし誰かそういうの作ってくれよ
2021/08/27(金) 00:29:20.60ID:b4Lxoyu9
>>76
endを省略するだけの話と
endを省略する代わりにインデントを使う
のとでは意味が違う
結局はインデントを使わなければいけないだけ
{} や begin end 方式だとインデントを入力しなくていい
エディタが勝手にやってくれるし整形もしてくれる
インデントに二つの意味、見やすくするのとブロックの終了をもたせると
自動整形ツールが信用できなくなる
endを省略するだけの話と
endを省略する代わりにインデントを使う
のとでは意味が違う
結局はインデントを使わなければいけないだけ
{} や begin end 方式だとインデントを入力しなくていい
エディタが勝手にやってくれるし整形もしてくれる
インデントに二つの意味、見やすくするのとブロックの終了をもたせると
自動整形ツールが信用できなくなる
78デフォルトの名無しさん
2021/08/27(金) 02:49:34.51ID:NGc2JSym Rubyのコードを書いていて、ときどき indent mismatch のエラーになる
そういうときはどこでmismatchが発生しているのか探すのが大変
(一番最後のendでmismatchが検出されるけど、
それ以前のどこかにあることしかわからないから、
コードをすべて読み直すことになる.)
結局、インデントに意味を持たせなくても(現状でも)、
インデントが狂うと(そしてdo end がmismatchになると) syntax errorになるし、
インデントは正しく保つ必要がある.
(ので、人間の手間としては同じだし、
むしろmismatchをしっかり検出して将来のエラーを減らせるので、人間の手間は減る.)
(現状、indent の mismatch の場合は warning が出る. do end の数が mismatch だと当然ながら error.)
まあ、ただ、機能をあとからあれもこれも追加すると
手に負えなくなって言語が死んでしまう原因となる可能性はある.
endless method定義でさえ、少し中途半端には感じるし、
=で終わるmethodには使えないというのも一貫性に欠ける.
(後方互換性がなくなること、より正確には、syntaxが変わることは
スニペットをsyntax highlightしたいときに困りそう. ウェブサイト等で.)
end が省略できるメリットというのは実際、ごく小さいので、
それに比べるとリスクが大きいよなあ、と思う
あと、RubyはPythonよりも純粋なオブジェクト指向言語で、
method chainを多用するので、
end 省略のメリットはさらに小さい.
大きすぎるリスクを考えると、Rubyはこのままで、
将来、別の言語を作るときに採用、というのが妥当かな.
それに、根本問題として、本当に閉じカッコなしの方がよいのか、というところは
もう少し考えたい. Pythonを数年間使ってみてから結論を出そうと思う.
そういうときはどこでmismatchが発生しているのか探すのが大変
(一番最後のendでmismatchが検出されるけど、
それ以前のどこかにあることしかわからないから、
コードをすべて読み直すことになる.)
結局、インデントに意味を持たせなくても(現状でも)、
インデントが狂うと(そしてdo end がmismatchになると) syntax errorになるし、
インデントは正しく保つ必要がある.
(ので、人間の手間としては同じだし、
むしろmismatchをしっかり検出して将来のエラーを減らせるので、人間の手間は減る.)
(現状、indent の mismatch の場合は warning が出る. do end の数が mismatch だと当然ながら error.)
まあ、ただ、機能をあとからあれもこれも追加すると
手に負えなくなって言語が死んでしまう原因となる可能性はある.
endless method定義でさえ、少し中途半端には感じるし、
=で終わるmethodには使えないというのも一貫性に欠ける.
(後方互換性がなくなること、より正確には、syntaxが変わることは
スニペットをsyntax highlightしたいときに困りそう. ウェブサイト等で.)
end が省略できるメリットというのは実際、ごく小さいので、
それに比べるとリスクが大きいよなあ、と思う
あと、RubyはPythonよりも純粋なオブジェクト指向言語で、
method chainを多用するので、
end 省略のメリットはさらに小さい.
大きすぎるリスクを考えると、Rubyはこのままで、
将来、別の言語を作るときに採用、というのが妥当かな.
それに、根本問題として、本当に閉じカッコなしの方がよいのか、というところは
もう少し考えたい. Pythonを数年間使ってみてから結論を出そうと思う.
2021/08/27(金) 04:16:45.56ID:aA7lb4P9
2021/08/27(金) 09:39:59.97ID:NGc2JSym
2021/08/27(金) 10:13:56.72ID:NGc2JSym
Python と Ruby どちらが好きか、という質問への答え
一番上の回答に完全同意
Quoraについての質問: RubyとPythonではどちらが好きですか?
https://jp.quora.com/Ruby-to-Python-deha-dochira-ga-suki-desu-ka
パイソンの方がルビーよりライブラリが充実しているが
それを除くと言語としてパイソンの方がうらやましいところはインデントだけ
(他の人が書いている型チェックは場合によりほしいというのは同意.
最近ルビーでもできるようになったようだが.)
まあしかしよく考えたら、インデント方式にするには行末にコロンなどつける必要があるかもしれず(あるいはないかもしれないが)、
行末のコロンはちょっと美しくない
(昔はdo end なんじゃこれと思ったものだが、完全にルビー脳になったなあ)
まつもとゆきひろさんが書いているように、
https://jp.quora.com/Ruby-ni-deki-te-Python-ni-deki-nai-koto-ha-nani-desu-ka?top_ans=142958781
ルビーでは(ほぼ?)すべてオブジェクトだし、式と文の区別もない
何でも繋げられる
その思想からすると区切る意味を持つコロンは、一貫性がなくなって美しくない
(ruby では } や end の後にも chain できる. :の後はできなくなりそう.)
コロンなしでエンドレスが導入できるなら興味はあるが.
好みの問題ということになるのだろうけど、
Rubyは本当に素晴らしい言語
この言語がなければ私は今ほど幸せではなかっただろう
そしてこの素晴らしい仕様の言語をよくここまで作ってこられたなと思う
携わってこられた方々に感謝. これからも使いやすい言語でありますように.
一番上の回答に完全同意
Quoraについての質問: RubyとPythonではどちらが好きですか?
https://jp.quora.com/Ruby-to-Python-deha-dochira-ga-suki-desu-ka
パイソンの方がルビーよりライブラリが充実しているが
それを除くと言語としてパイソンの方がうらやましいところはインデントだけ
(他の人が書いている型チェックは場合によりほしいというのは同意.
最近ルビーでもできるようになったようだが.)
まあしかしよく考えたら、インデント方式にするには行末にコロンなどつける必要があるかもしれず(あるいはないかもしれないが)、
行末のコロンはちょっと美しくない
(昔はdo end なんじゃこれと思ったものだが、完全にルビー脳になったなあ)
まつもとゆきひろさんが書いているように、
https://jp.quora.com/Ruby-ni-deki-te-Python-ni-deki-nai-koto-ha-nani-desu-ka?top_ans=142958781
ルビーでは(ほぼ?)すべてオブジェクトだし、式と文の区別もない
何でも繋げられる
その思想からすると区切る意味を持つコロンは、一貫性がなくなって美しくない
(ruby では } や end の後にも chain できる. :の後はできなくなりそう.)
コロンなしでエンドレスが導入できるなら興味はあるが.
好みの問題ということになるのだろうけど、
Rubyは本当に素晴らしい言語
この言語がなければ私は今ほど幸せではなかっただろう
そしてこの素晴らしい仕様の言語をよくここまで作ってこられたなと思う
携わってこられた方々に感謝. これからも使いやすい言語でありますように.
2021/08/27(金) 13:12:03.95ID:lxI1gnNr
その昔のlispにはスーパーカッコというのがあって
閉じカッコとして ] を使うとすべてのカッコを閉じて
プログラムの終了を意味するというのがあった
エディタがカッコの対応を示してくれるので
結局、流行らずに忘れ去られてしまった。
閉じカッコとして ] を使うとすべてのカッコを閉じて
プログラムの終了を意味するというのがあった
エディタがカッコの対応を示してくれるので
結局、流行らずに忘れ去られてしまった。
83デフォルトの名無しさん
2021/08/27(金) 14:22:53.16ID:8dQk5Ix1 >>81
>RubyはPerlの文脈を背負っているので、TMTOWTDIといって「同じことをやるのにも複数のやり方がある」という自由主義的なのに対し、
>PythonのほうはZen of Pythonに宣言されているように、反TMTOWTDI主義とでもいうべき
> “There should be one—and preferably only one—obvious way to do it.”
> (同じことをやる唯一の書き方があるべきだ)という教条主義的な思想があります。
こんなこと書いてる時点でこいつPython触ってないだろってのが判る
ただのしったか野郎
別にrubyを否定はしないがデタラメ書くなよとは思う
>RubyはPerlの文脈を背負っているので、TMTOWTDIといって「同じことをやるのにも複数のやり方がある」という自由主義的なのに対し、
>PythonのほうはZen of Pythonに宣言されているように、反TMTOWTDI主義とでもいうべき
> “There should be one—and preferably only one—obvious way to do it.”
> (同じことをやる唯一の書き方があるべきだ)という教条主義的な思想があります。
こんなこと書いてる時点でこいつPython触ってないだろってのが判る
ただのしったか野郎
別にrubyを否定はしないがデタラメ書くなよとは思う
2021/08/27(金) 18:54:27.55ID:aA7lb4P9
だろうなw
Pythonのインデントが羨ましとか言ってるのは使ったことがないか
Pythonしかしらないやつだけ
デバッグのためのインデントをわざとずらすとか
コードブロックをインデントが異なる場所に移動するとか
条件を追加するとか、やったことがないから
インデントの方がいいとか思うんだよ
あれだろ?インデントって意識せずに普通にやることだけど
初心者はインデントする理由すらわからない、そのレベルの人がうじゃうじゃいる場所で
「インデントを強制される」からマシなコードになる(えぇ?その程度で!?)
みたいな話だろ
Pythonのインデントが羨ましとか言ってるのは使ったことがないか
Pythonしかしらないやつだけ
デバッグのためのインデントをわざとずらすとか
コードブロックをインデントが異なる場所に移動するとか
条件を追加するとか、やったことがないから
インデントの方がいいとか思うんだよ
あれだろ?インデントって意識せずに普通にやることだけど
初心者はインデントする理由すらわからない、そのレベルの人がうじゃうじゃいる場所で
「インデントを強制される」からマシなコードになる(えぇ?その程度で!?)
みたいな話だろ
85デフォルトの名無しさん
2021/08/28(土) 05:55:06.93ID:Uz5at9mY >>83
それはPython作成のmajorなcontributor自身が言っていることかと
Python aims to be simple and consistent in the design of its syntax, encapsulated in the mantra "There should be one? and preferably only one ?obvious way to do it", from the Zen of Python.[2]
This mantra is deliberately opposed to the Perl and Ruby mantra, "there's more than one way to do it".
https://en.wikipedia.org/wiki/Python_syntax_and_semantics
>>82
一度だけ使える奥義みたいな感じだね
インデント方式か、括弧方式かについて考えているけれど、
閉じ括弧なし強制、閉じ括弧あり強制、閉じ括弧はoptional の3つで考えた場合、
閉じ括弧はoptionalというのは一見良さそうに思えて、実はバグの温床になりやすいものかもしれない
そのあたりは(紙に書いて)もう少し考えてみないとわからない
もし 閉じ括弧はoptional がよくないアイデアの場合は、
閉じ括弧なし強制 or 閉じ括弧あり強制 の二択になるけど、その場合は後者の方が明確に良い
Method chainが使えるから.
Endless method定義の導入が検討されていたときに、
do end の end を省略可にするアイデアはあるかと聞かれて、ないとMatzが即答していた.
私自身でもう少し検証してみるつもりだけど、Matzは当然end 省略についてよく考えた上で言っているのだろうし、
Matzが言うのならやはり現状がベストなのかもしれない.
それはPython作成のmajorなcontributor自身が言っていることかと
Python aims to be simple and consistent in the design of its syntax, encapsulated in the mantra "There should be one? and preferably only one ?obvious way to do it", from the Zen of Python.[2]
This mantra is deliberately opposed to the Perl and Ruby mantra, "there's more than one way to do it".
https://en.wikipedia.org/wiki/Python_syntax_and_semantics
>>82
一度だけ使える奥義みたいな感じだね
インデント方式か、括弧方式かについて考えているけれど、
閉じ括弧なし強制、閉じ括弧あり強制、閉じ括弧はoptional の3つで考えた場合、
閉じ括弧はoptionalというのは一見良さそうに思えて、実はバグの温床になりやすいものかもしれない
そのあたりは(紙に書いて)もう少し考えてみないとわからない
もし 閉じ括弧はoptional がよくないアイデアの場合は、
閉じ括弧なし強制 or 閉じ括弧あり強制 の二択になるけど、その場合は後者の方が明確に良い
Method chainが使えるから.
Endless method定義の導入が検討されていたときに、
do end の end を省略可にするアイデアはあるかと聞かれて、ないとMatzが即答していた.
私自身でもう少し検証してみるつもりだけど、Matzは当然end 省略についてよく考えた上で言っているのだろうし、
Matzが言うのならやはり現状がベストなのかもしれない.
2021/08/28(土) 06:38:28.25ID:pTyUgQRH
インデントでブロックを作るメリットがないんだよな
どちらにしろRubyでもインデントはするから見やすい
入力の手間も変わらない
意味があるとするなら、メモ帳でプログラミングしてる
矯正されないとインデントできない
超超超低レベルな人ばかりいるところぐらいでは?
どちらにしろRubyでもインデントはするから見やすい
入力の手間も変わらない
意味があるとするなら、メモ帳でプログラミングしてる
矯正されないとインデントできない
超超超低レベルな人ばかりいるところぐらいでは?
2021/08/31(火) 03:49:59.86ID:kXeFL5NO
機能的な意味は皆無で、単にちょっと入力文字数が減るだけですね。
(括弧のmismatchが起こり得なくなるという効能もあるけど、
end 省略をオプションにしてしまうと、85で書いたように、バグの温床になりそうな気もしてきたので検証中。)
>>69-85 で end 省略導入を検討してほしいと書いてきた者だけど、
現在の結論についてアンカー付きで再度書いておこうと思う。
(今後来て読むかもしれない人がレスポップアップですぐ気付けるように。)
閉じ括弧省略には、次の3種類ある:
1. 閉じ括弧なし強制(Python の方式)
2. 閉じ括弧あり強制(Ruby の方式)
3. 閉じ括弧はオプション(Slim の方式)
このうち、1 と 2 なら 2 の方が明確に良い. Method chain が使えるから.
(純粋度の高いオブジェクト指向言語のRubyの場合. Pythonの場合は言語仕様が異なるので結論も異なりうる。)
また、2 と 3 なら 3 の方がよいのだけど、意図的な省略かうっかり忘れかをインタプリタが判別できない場合、
バグの温床となる可能性がある(要検証)。もしそうであるならば 3 は論外。その場合、2 が一番良い。
(括弧のmismatchが起こり得なくなるという効能もあるけど、
end 省略をオプションにしてしまうと、85で書いたように、バグの温床になりそうな気もしてきたので検証中。)
>>69-85 で end 省略導入を検討してほしいと書いてきた者だけど、
現在の結論についてアンカー付きで再度書いておこうと思う。
(今後来て読むかもしれない人がレスポップアップですぐ気付けるように。)
閉じ括弧省略には、次の3種類ある:
1. 閉じ括弧なし強制(Python の方式)
2. 閉じ括弧あり強制(Ruby の方式)
3. 閉じ括弧はオプション(Slim の方式)
このうち、1 と 2 なら 2 の方が明確に良い. Method chain が使えるから.
(純粋度の高いオブジェクト指向言語のRubyの場合. Pythonの場合は言語仕様が異なるので結論も異なりうる。)
また、2 と 3 なら 3 の方がよいのだけど、意図的な省略かうっかり忘れかをインタプリタが判別できない場合、
バグの温床となる可能性がある(要検証)。もしそうであるならば 3 は論外。その場合、2 が一番良い。
2021/08/31(火) 06:58:29.39ID:UqDTQOtm
Pythonのインデントでブロックを作るのがいいって
言ってる人って、どんな人なんだろう?
正直プログラミングの初心者だと思ってるんだが
自転車に補助輪があったほうがいいと言ってるようなもの
言ってる人って、どんな人なんだろう?
正直プログラミングの初心者だと思ってるんだが
自転車に補助輪があったほうがいいと言ってるようなもの
2021/08/31(火) 08:30:03.95ID:+G3EK1zI
自転車に補助輪があったほうがいいと連呼し
理想の補助輪についてアツく語り
ツールドフランス帰りの人間に意見するのがインターネッツ
理想の補助輪についてアツく語り
ツールドフランス帰りの人間に意見するのがインターネッツ
2022/01/27(木) 12:31:54.83ID:zYcyjosR
意味が分からん
波括弧でブロック作るタイプの言語で自由なインデントを決め込んで読み辛いとブチ切れるのがお前らだろうが
それにPythonを使ってて不便に感じた事なんて一度もない
波括弧でブロック作るタイプの言語で自由なインデントを決め込んで読み辛いとブチ切れるのがお前らだろうが
それにPythonを使ってて不便に感じた事なんて一度もない
2022/01/27(木) 21:26:39.43ID:nqLNKhKI
なんとなくどういう人かわかったw
2022/11/30(水) 04:09:07.15ID:DZmWhP6T
そもそも行数の違いで{}とdo end 分けるのが鬱陶しい
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 日本行き空路49万件キャンセル 中国自粛呼びかけ 日本行きチケット予約の約32%に相当 ★4 [ぐれ★]
- 中国の局長は「両手をポケット」で対峙 宣伝戦で国民に示す ★3 [蚤の市★]
- 【音楽】Perfume・あ~ちゃんの結婚相手「一般男性」は吉田カバンの社長・吉田幸裕氏(41) 高身長で山本耕史似 [Ailuropoda melanoleuca★]
- 【大分】佐賀関で大規模火災、170棟以上が延焼中 70代男性1人と連絡取れず [ぐれ★]
- 【サッカー】U-17日本代表、激闘PK戦制す 北朝鮮撃破で6大会ぶり8強入り U17W杯 [久太郎★]
- 「クマはなるべく山に返す努力を」「クマと戦争は間違っている」動物保護活動家の主張 棲み分けと学習放獣でクマ被害なくなるのか?★7 [ぐれ★]
- とらせん IPあり
- 巨専】
- こいせん 全レス転載禁止
- 【DAZN】ワールドカップ欧州予選総合 ★5
- 侍ジャパンシリーズ2025「日本vs韓国」その12
- 【ATP】テニス総合実況スレ2025 Part 211【WTA】
- アンケート調査で「高市発言は問題なし」 93.5%wwwwwwwwwwwwwwwwwwwwwwwww [279254606]
- 自閉症が「んなっしょい」と連呼するお🏡
- 【悲報】大分市佐賀関の火事、20軒→170軒に延焼🔥 [481941988]
- 両手でフレミングの法則やってくれ [577451214]
- 日本人の海外旅行したきのマナーよくなったのはいつから
- へそグリグリ
