Rubyに'end'って要らないよな
インデント揃ってればそのままend無くしても読めるし誰かそういうの作ってくれよ Ruby は、アマゾン・Google, Heroku で、採用されてる! Ruby on Rails 6 (Ruby 2.5 以上)では、GitHub 中心で、 複数データベース(レプリカ)接続の大規模サービスと、 テストの並列実行など、別次元へ行ってしまった! モジュールバンドラーも、Webpack になりました! Coffee Script は、無くなった メール送受信の機能と、 ブラウザの入力フォームが、ドラッグ&ドロップで、ファイルも受け付けるようになった GitHubのRails離れと、迫りくるMicrosoft https://yakst.com/ja/posts/5290 > プラットフォーム改造で変わる「Ruby専門店」。今後はGo、Java、Kubernetesへ。 > 昨年始まったアーキテクチャレベルの改革も現在は三分の一ほど進んでいる。 同社はRuby on Railsから離れ、もっと異種混合で使い捨てのきくインフラへとシフトしていっている。 GitHubを「Ruby専門店」と称する同氏によると、GitHubにRubyの居場所はまだあるが、GoやJava、さらにはHaskellの方が多くデプロイされているそうだ。 日本では使われてるんだから海外の持ち出してもしょうがないだろ Rails の作者、DHH(David Heinemeier Hansson)率いる、Basecamp 社から、 Eileen Uchitelle が、GitHub へ移籍した そのEileenが、大規模サービス用の、 複数データベース(リードレプリカ)接続を作った > Eileen Uchitelle が、GitHub へ移籍した ちゃんとMicrosoft社って書こうよ Microsoft は、GitHub の一株主って言うだけだろ >>1 end はとても重要です。 空白だけだと人間にはブロックの位置がとても判読しにくいため、 end や } と空白によるインデントが全部合ってこそ、間違いが防げる のです。 Pythonのように空白だけで命令文の入っているブロックの位置を識別する設計だと、 命令文を書く位置を間違い、原因不明の不具合に悩まされることに成る確率 が高くなります。正確に書こうと思うと、書くべき位置の割り出しに時間が かかり、間違っていた場合に原因を見つけ出すのにとても時間がかかります、 >>1 end はとても重要です。 メモ帳で書いてみなさい。 空白だけだと人間にはブロックの位置がとても判読しにくい python はインデントを義務付けるなら {} も義務付けてほしかったな その方が可読性が高くなるし エディタも助けやすくなる if の終わりは fi みたいな 遊び心を持ってほしかった >>40 え、そうなの? 「将来性のないプログラミング言語5選」の内容に各所からツッコミ https://internet.watch.impress.co.jp/docs/yajiuma/1200/475/index.html > 海外はともかく日本から見るとやや違和感のある内容ということで、Twitterでは主に日本からのツッコミが入りまくっている。 > 記事が公開されたのは先月末で、海外ではRedditを除けばそこまで注目されていなかったにもかかわらず、思わぬところで火の手が上がった格好だ。 海外からしたら日本なんて知ったことかよwww まるで韓国みたいな反応www 「世界中の国が日本の輸出規制を非難している!」 → 韓国が騒いでるだけ。世界は異常な反日パフォーマンスにドン引きw 「各所からツッコミ!」 → 日本のみに生息するRubyキチガイどもが難癖つけてるだけでしたwww そりゃ、Ruby は、アマゾン、Google, Heroku でも採用されているから! Node.js も、Ruby実装系のコピーだし、 npm, yarn も、Bundler のコピー 元々、Vagrant, Chef, Homebrew, SASS も、Github, twitter, cookpad も、Ruby製 ここ10年、時価総額が大きくなった企業は、皆、Rubyで小さく始めてる。 大きくなったら、Go などへ変える ビジネスチャンスでは、他の言語よりも、数年速い。 今世紀最大の起業家、vagrant の作者、Mitchell Hashimoto(hashicorp)は、Go へ行ったけどw 仮に、Python で先に実装されても、JavaScript の開発者がPython からコピーしないw 可読性が高い、Rubyで実装されるのを待って、Rubyからコピーするw 机上討論では模擬コードとして、可読性が高い、Rubyが使われる Pythonには、カッコ・end が無いから、インデント幅だけで決まるから、対応関係がわからない 普通に関数の粒度を間違ってるバカがインデント批判してるだけだろ。 >>58 おそらく「ぼくはRubyしかよめない」ということかと。 GitHubのRails離れと、迫りくるMicrosoft https://yakst.com/ja/posts/5290 > プラットフォーム改造で変わる「Ruby専門店」。今後はGo、Java、Kubernetesへ。 > 昨年始まったアーキテクチャレベルの改革も現在は三分の一ほど進んでいる。 同社はRuby on Railsから離れ、もっと異種混合で使い捨てのきくインフラへとシフトしていっている。 GitHubを「Ruby専門店」と称する同氏によると、GitHubにRubyの居場所はまだあるが、GoやJava、さらにはHaskellの方が多くデプロイされているそうだ。 >>60 わいはjs4年の実の娘と一緒にお風呂に入って対面座位で抱きしめ合ってベロちゅう唾飲みせっくすしてる。つるぺたとつるまんが気持ち良すぎて抜かずで連続3回中出しした。 禁断を犯した事実が興奮をさらに煽りもう近親相姦は当分やめられない。妻にはもちろん内緒。娘がいて本当に良かった。 >>1 お望みのものなら、既にRing-langがあるんだけど、何か? まぁ、開発者が燃え尽き症候群と長期休暇で 1.11のリリースが延期に、翻訳者が言語仕様にキレて翻訳が放置されたままなのが難点ではあるが。 rubyXLでエクセルいじってるが 印刷範囲を設定したいときは、どのようにすればよいのでしょうか? いろいろ探しても見当たらず・・ 5ch では、マルチポストは禁止です! 同じ質問を、複数のスレで聞いてはいけません! Ruby のスレの方で、聞いてください! endより{}のほうがチェックしやすい __END__はあったほうがいい endlessメソッド定義も導入されたし、 インデントでendの代わりは本当に検討してほしいな endはオプショナルでメソッドチェーンしたいときに使用できる感じで 実際のコードではインデントがミスマッチなことは ミス以外ではないので、 実現は十分可能と思う (インデント分endを補完して解釈すればいいだけなので) とはいいつつも、endを省くだけならまだしも、 {}の閉じカッコが省かれるのは気持ち悪いかもしれないし、 エディタ上でsyntax highlight等で対応が難しい点があるかもしれない (do endだけ省ける、とかにしたらいいかもしれない) マジックコメントを書くことでend lessの書式にする、 ということにすると後方互換性も失われない > 実際のコードではインデントがミスマッチなことは > ミス以外ではないので、 ある 一時的にデバッグコードを入れる時に わざとインデントをずらしてわかりやすくする 行を移動したりする時にインデントは簡単に変更になりやすい 条件分岐を一つ追加するとその後全部インデントがずれる インデントがブロックの終わりだとその時に自動で整形できない 人間にとって使いづらい Python, Slim, Hamlなんかはインデントで閉じカッコの代わりが完全にできているので、 原理的にRubyでもできるはず 一時的にデバッグコードを入れる時 や、 行を移動したりする時 は、 編集途中なだけで最終的にはインデントも修正されるので問題ではないかと 上述の言語にも当てはまるけれど、全く問題ではないし まあ、インデントのミスマッチは、ミス以外では、 コードの可読性を上げるために式を複数行にわけて記述する場合があるけど、 これは1つの式だと文法的に判別できるので、問題にはならない assert_equal expected, value みたいな書き方 インタプリタからは1行に見えるので. {}の閉じカッコが省略される(人間にとっての)気持ち悪さを解消するために、 :なり何なり(既存の文法と整合性がとれるもの)で{ の代用ができるとよいかもしれない Pythonのマネだけど これは、人間のためというよりは、エディタ(Rubyの文法を解さない)が カッコのマッチでsyntax highlightするのを容易にするため. まあ、エディタもマジックコメントで判別すればいいだけだけど、 コードのスニペットの場合でも困らなくなる. (とはいえ、end less 導入以前の書式かどうかの判別は困るかもだけど.) まあ、最初にも書いたように、 {}の場合は省略不可で、end の場合だけ省略可 とするのがシンプルで簡単かもしれない. (エディタでの対応カッコ検出が簡単かどうかはわからないが.) これだけの変更なら、自分でプリプロセッサを書いて比較的簡単に実装できるかも. ソースファイルをload/requireする箇所にフックして、 end less のコードをend 有りに変換 >>71 できるできないの話じゃなくて インデントでブロックを表すと使いづらい言語になる コードが完成したら整えるのは当然だが コードを書いてる途中でもいちいち整えないといけない {} でも begin end でもどちらでもいいけど 自動整形でインデントを整えることができる インデントを下げるとか人間がやることじゃない だれも指摘していないので年寄りがひとこと言っておこう。 FORTRAN の時代は、「END.」でプログラムが終わる (つまり、最短のプログラムは「END.」だった)という約束があり、 Java もそうだが戻り値が void でも、「return;」を書くのが 作法だった。 まぁ、「いまのところ、そうなっている」というだけで、 将来は省略できるようになるんじゃないか? >>76 endを省略するだけの話と endを省略する代わりにインデントを使う のとでは意味が違う 結局はインデントを使わなければいけないだけ {} や begin end 方式だとインデントを入力しなくていい エディタが勝手にやってくれるし整形もしてくれる インデントに二つの意味、見やすくするのとブロックの終了をもたせると 自動整形ツールが信用できなくなる 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を数年間使ってみてから結論を出そうと思う. >>78 Rubyのコードを書いていて、ときどき indent mismatch のエラーになる そういうときは、整形ツールで一発で直せる 間違ってたので訂正しといた >>79 ああ、たしかに。 独自の書式にしている部分まで直されるので使ったことなかったけど、 mismatch の箇所を探す用途として使えばよさそう。 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は本当に素晴らしい言語 この言語がなければ私は今ほど幸せではなかっただろう そしてこの素晴らしい仕様の言語をよくここまで作ってこられたなと思う 携わってこられた方々に感謝. これからも使いやすい言語でありますように. その昔のlispにはスーパーカッコというのがあって 閉じカッコとして ] を使うとすべてのカッコを閉じて プログラムの終了を意味するというのがあった エディタがカッコの対応を示してくれるので 結局、流行らずに忘れ去られてしまった。 >>81 >RubyはPerlの文脈を背負っているので、TMTOWTDIといって「同じことをやるのにも複数のやり方がある」という自由主義的なのに対し、 >PythonのほうはZen of Pythonに宣言されているように、反TMTOWTDI主義とでもいうべき > “There should be one—and preferably only one—obvious way to do it.” > (同じことをやる唯一の書き方があるべきだ)という教条主義的な思想があります。 こんなこと書いてる時点でこいつPython触ってないだろってのが判る ただのしったか野郎 別にrubyを否定はしないがデタラメ書くなよとは思う だろうなw Pythonのインデントが羨ましとか言ってるのは使ったことがないか Pythonしかしらないやつだけ デバッグのためのインデントをわざとずらすとか コードブロックをインデントが異なる場所に移動するとか 条件を追加するとか、やったことがないから インデントの方がいいとか思うんだよ あれだろ?インデントって意識せずに普通にやることだけど 初心者はインデントする理由すらわからない、そのレベルの人がうじゃうじゃいる場所で 「インデントを強制される」からマシなコードになる(えぇ?その程度で!?) みたいな話だろ >>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が言うのならやはり現状がベストなのかもしれない. インデントでブロックを作るメリットがないんだよな どちらにしろRubyでもインデントはするから見やすい 入力の手間も変わらない 意味があるとするなら、メモ帳でプログラミングしてる 矯正されないとインデントできない 超超超低レベルな人ばかりいるところぐらいでは? 機能的な意味は皆無で、単にちょっと入力文字数が減るだけですね。 (括弧の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 が一番良い。 Pythonのインデントでブロックを作るのがいいって 言ってる人って、どんな人なんだろう? 正直プログラミングの初心者だと思ってるんだが 自転車に補助輪があったほうがいいと言ってるようなもの 自転車に補助輪があったほうがいいと連呼し 理想の補助輪についてアツく語り ツールドフランス帰りの人間に意見するのがインターネッツ 意味が分からん 波括弧でブロック作るタイプの言語で自由なインデントを決め込んで読み辛いとブチ切れるのがお前らだろうが それにPythonを使ってて不便に感じた事なんて一度もない そもそも行数の違いで{}とdo end 分けるのが鬱陶しい read.cgi ver 07.4.7 2024/03/31 Walang Kapalit ★ | Donguri System Team 5ちゃんねる