Rubyについて(アンチ専用) Part005
なかったので オブジェクト指向スクリプト言語Rubyが嫌いな人のためのスレッドです。 他言語の一方的なあげ足取りが好きな最強厨御用達言語Rubyについて。 1. 他の言語で満足している人を「楽しさ」「美しさ」とか主観的な基準で煽る 2. Ruby より機能が絞られている言語に対しては「不足」「楽しさが(ry」「快適さがない」「こんな機能がないなんて」 3. Ruby より機能が豊富な言語に対しては「大きすぎる」「美しくない」「そんな機能不要」 うっとおしいRuby厨やRails厨の迷惑や気持ち悪い主観の押しつけ、腐れ言語や不安定ライブリについて語り合いましょう。 ■関連スレ Rubyについて Part 36 http://pc12.2ch.net/test/read.cgi/tech/1246174168/ ■前スレ Rubyについて(アンチ専用) Part001 http://pc11.2ch.net/test/read.cgi/tech/1190559748/ Rubyについて(アンチ専用) Part002 http://pc11.2ch.net/test/read.cgi/tech/1200210768/ Rubyについて(アンチ専用) Part003 http://pc12.2ch.net/test/read.cgi/tech/1207233348/ Rubyについて(アンチ専用) https://mevius.5ch.net/test/read.cgi/tech/1249737531/ $とか@ってシェルスクリプトが起源だからさ PerlとかRubyはしれっと盗まないでくれないか? @_ なんかにコンテキストで意味変わるようなものをドカドカ詰め込んだのは perlが最初だぞ。もちろん最悪のやり方だと思うが。 Rubyも同じようなの導入しようとして 失敗してるしな > 「愚者は経験から学び賢者は歴史から学ぶ」。 > 結論から言うと、これは誤訳である。 ワロタw 歴史=他人の起こした出来事って意味がわからんやついるんだな 読解力がなさすぎるか日本人じゃないか だからその「歴史」が誤訳なんだがな。もともとは歴史なんて言ってない すみません、初学者で苦労してまして・・ Rubyxlでエクセルのテンプレートを編集したく そこで、特定のセルをコピーして特定のセルに貼り付ける 操作を行いたいのですが、ネットで検索しても全くヒットせず 有識者のかたいらっしゃれば、ご教授いただけましたら幸いです。。 5ch では、マルチポストは禁止です! 同じ質問を、複数のスレに書き込んではいけません! ここで質問せず「Ruby 初心者スレッド Part 65」の方を使ってください! >>183 ,184 ビスマルクとは知らなかった、あのビスマルクの言葉だったとは…これは勉強になりましたね、 rubyXLでエクセルいじってるが 印刷範囲を設定したいときは、どのようにすればよいのでしょうか? いろいろ探しても見当たらず・・ まつもとはtraitの仕様を入れたけど そもそもなんのために入れたんだか忘れたって後から言ってる まつもとのバグはrubyのバグと言っても良い 特定の独裁者が仕切る開発はもう時代にあってないよね 言語の与える影響があまりに大きくなりすぎた そう言えば、GuidoとかRMSは生前退位したんだっけ >>200 独裁は必要。 でないと、決めればいいところが決まらん。 いつかLinusもしんどくなって生前退位する日が来るのだろうか >>203 FSFの前に、Emacsは先に人に任せてなかったけ。あれもなんで降りたのかは忘れたけど >>205 何年か前に、暴言きっかけかなんかで、しばらく休んでたやん? 来るべき引退に向けての予行演習でもあったんでは。 >>207 あー、あったなあ…たしかに意図したかどうか予行演習になったなあ 右代入が酷い 俺の記憶が正しければ 末尾に追記することで変数への代入ができるのが右代入だったよな 1+2=>x がエラーになるんだがコレ何の意味があるんだ? >>196 taintのこと? >>211 Rubyの構文解析器の気持ちになればわかるよ! 君のコンピュータに近づこう コンピュータはルール通りのことを間違いなくやる そのルールに人間が合わせればいいんだよ! Ruby の使い過ぎで凋落なのかな? 2020.06.08 06:10 クックパッドの凋落、利用者1千万人減で赤字転落…人気のクラシルと真逆の方向 https://biz-journal.jp/2020/06/post_161220.html?utm_source=rss20& ;utm_medium=rss 坊主憎けりゃ袈裟までで中身は無いな これに関係なくRubyはオワコンコースだと思ってるけどな 作者のふるまいを気にするなら、Linuxもダメだな。 Linusは暴言家だからな。 Guidoもなんかなかったっけ? Larryはいい人そうだ。 なお、ワイもMatzはキライ。 昔、C++とPerlに言いがかりをつけていたことは忘れん。 Windows も dis ってたよ 漏れも Windows 嫌いだから良いけど 採用や仕事でRubyは嫌いだ使いたくないという人がいて 技術的理由説明しないで作者の政治思想が 嫌いだからとか言い出したら帰ってもらうのは 間違いない キリスト教の事を言い出したら、米国人は皆、キチガイじゃん 誰も進化論を信じていない。 人間は元から、猿じゃなかった。人間の姿のままだった 地動説も信じているかどうか、怪しい 中絶・同性婚を認めてはならない 結局PythonとJavaScriptの二強になってしまったな 次点でGoか この3つの流行に食い込むのはもう無理そう Ruby3の型ヒント実装あんなのエコシステムとして成立するのか? ローカル変数がちゃんと使いたいので、 Rubyからnode.jsに乗り換えようと努力している最中だったが、 node.jsはファイル関連が分かりにくい。 Rubyだとstdoutとファイルが対象になっていて、 print を fp.print に変えてやれば、ほぼそっくりそのまま動作してしまうが、 node.jsだと複雑そうだ。 あと、ファイル操作が基本的に非同期推奨なのも辛いし、非同期と同期の二系統あるので混乱が生じ易い。 複数ファイルのコピーもRubyは簡単に出来るが、node.jsだとncpという モジュールでやるが、これも非同期なので、promiseでthenやawaitを使った待機が必要になる。 しかし、それをしだすと、すべてがasync,await,thenなどを前提に書くことが必要になり、 非常に複雑になる。 >>226 誤: Rubyだとstdoutとファイルが対象になっていて、 正: Rubyだとstdoutとファイルが対称になっていて、 >>226 その辺がサーバーサイドでは使いにくい理由だよね 従来のシステムコールとはかけ離れてる ファイルを非同期で読み取りたいケースなんてほとんどないし あともう一つ、Ruby だと list の要素に対する繰り返しは以下の様に簡潔に書ける。 for elem in list do elem に対する処理; end しかし、Node.js だと、 list.forEach( function(elem) { elem に対する処理; }); か list.forEach( elem => { elem に対する処理; }); としか書けないらしく、なんだか見にくい。 list.each{elem| elemに対する処理} 似たようなもんやで >>226 streamが標準出力にもファイルにも使えるでしょ。 consoleオブジェクトに出力してる事自体がイレギュラーかと。 async awaitを使えば、thenは必要ないと思うが、混同してないか? Promise.allでコピー処理を待てば、複数ファイルでもたいしてかわらんかと。 >>229 for(let elem of list)で充足できない理由は? for elem in list do elem に対する処理; end が簡潔で、 list.forEach(elem => {elem に対する処理;}); や for (let elem of list) { elem に対する処理; } が見にくいの?w 老眼では?ww Rubyでforループ使うか普通? 特殊なポリシー持ってるか全然使ってないのでは >>232 ほんの些細な違いだろうという指摘は理解したいけど、楽しく書ける(= 思考を妨げない)ことをポリシーとしている Ruby に慣れ親しんでいると、そんなことも気になってしまうんだよなぁ xs.each { |x| # スコープを作る(関数型スタイル) x に対する処理 } または for x in xs # スコープを作らない(手続き型スタイル) x に対する処理 end それが JavaScript になると: ・なぜ丸カッコと波カッコを入れ子にしなきゃいけないのかなぁ どちらか一つでいいはずだし面倒くさいよね? xs.forEach ({ x => # スコープを作る(関数型スタイル) x に対する処理 }) ・なぜ変な予約語 let が必要なのかなぁ、あってもいいけど蛇足だよね?(>>231 ) for (x in xs) { # スコープを作らない(手続き型スタイル、従来からある構文) x に対する処理 } または for (let x of xs) { # スコープを作る(一見関数型に見えるが、手続き型スタイル) x に対する処理 } もちろん JavaScript が「後方互換性の維持」を厳守しつつ、機能(構文と意味)を発展させてきた成果は大いに評価している とはいえ、「老眼では?ww」という批判は、ちょいと低俗で低レベルな発言ではないかと思われ もっとも客観的には >>229 の注文が高尚すぎて(w、他言語ユーザーにはあまりにも厳しすぎるだろ、とは感じてる >>234 あとfor inをプロトタイプ汚染されたオブジェクトに対して回すと恐ろしいことが起きるから基本的に非推奨だよ 書き方多過ぎるしアロー関数のthisの違いなど もはや罠が多過ぎて初心者に勧められる言語ではないと思う 好き好きとしか。 個人的には、C#とかC++(最近版)とかの論理的整合性のほうがはるかに。 Rubyも、えらそうなわりに、細かいところでいいかげんなところがちょくちょくあるんだよなあ。 えらそうでなければあまり気にならなかったのにな。 そういう文法の癖をあげつらう方向なら Rubyも出てくると思うぞ >>234 > 一見関数型に見えるが、 どこが?また半可通か。forで関数型とかあり得ないだろマヌケ。知らないなら黙ってろよww >>235 >あとfor inをプロトタイプ汚染されたオブジェクトに対して回すと恐ろしいことが起きるから基本的に非推奨だよ あえて触れなかったのですが、こう書くべきでしたね for (x in xs) { if (xs.hasOwnProperty(x)) { x に対する処理 } } 以下より引用:JavaScript: The Good Parts - 良いパーツによるベストプラクティス, C.10 for in 文, p140 >>236 >細かいところでいいかげんなところがちょくちょくある 同感ですね、自分もちょくちょくあります そういった事柄はこちらで遠慮せずに発言されてはいかがでしょうか? Rubyはバグりやすい言語だよ。 ・型安全でない ・前後の文脈を見ないとその部分単体ではローカル変数とメソッド呼び出しの見分けがつかない書き方ができ、しかもその書き方(メソッド呼び出しに()付けない)のほうが主流 ・reduce/inject、map/collectのように同じことするメソッドの単なる別名と、Array#delete_if/Array#reject!のようにほとんど同じなくせして削除失敗時だけ挙動が異なるみたいなべつものメソッドが入り乱れててカオス ・Procオブジェクト(手続きオブジェクト)を作る方法が多すぎ。しかも作り方で挙動が異なる。Rubyの書籍を書いた人でさえ頭を抱える始末 ・簡単に「見せかける」ために省略記法を行き当たりばったりで導入しまくった副作用で、直感的な記述が逆にエラーとなることが多い(例: p {foo: 1, bar: 2}はエラーwブロックとして解釈されるため) まだまだあるよ Rubyは最も一般的な方法で定義した関数(関数じゃないw)が値として取り回せない(第一級関数でない)クソ言語wwwww def add(a, b) a + b end def opTwo(a, b, func) func(a, b) end p opTwo(1, 2, add) => Line 9:in `add': wrong number of arguments (0 for 2) (ArgumentError) from t.rb:9 プギャーm9(^Д^ ) ちなみにPython: def add(a, b): return a + b def opTwo(a, b, func): return func(a, b) print(opTwo(1, 2, add)) => 3 ちなみにJavascript: function add(a, b) { return a + b; } function opTwo(a, b, func) { return func(a, b); } console.log(opTwo(1, 2, add)) => 3 >>241 まあそこは言語の特徴だから そういう用途にはブロックを使えってこと 関数呼び出しに()が必要じゃないのはDSLを書くためには優れた仕様 他の言語で言語内DSLは実質不可能 明らかに他の言語どころかRubyの理解も 怪しいのがわかる >>233 自分はすっかり関数型プログラミングに慣れてしまったので、近頃だと for/while 文を 使うのは、古い Pascal や Perl のコードを Ruby へ写経(移植?)する時くらいですかね ちなみに Ruby のブロック構文ですが、副作用がなければ波カッコ { … } で、 副作用(破壊的代入やI/O処理)があれば do … end と使い分けています 以下は定石(パターン化した)コードの雛形(スケルトン)です result = xs.select { |x| … }.map { |x| … }.inject( … ) { |acc, x| … } xs.select { |x| … }.map { |x| … }.inject( … ) { |acc, x| … }.each do |x| … # 副作用(破壊的代入やI/O処理)を含む処理 end 具体的なコード例はこちらへ:https://ideone.com/PKMUhx また、関数型プログラミングに興味がある方は以下をお読みください ・Rubyによる関数型プログラミング http://xtmlab.com/misc/FPwithRuby.html ブロックとProc.newとprocとlambdaと->があるRubyはやり過ぎ rubyの可読性は高くない。 pythonの「書きにくく読みやすい」と比較して「書きやすく読みにくい」と言われる。 そうなってしまう理由はたくさんあるが、ひとつのことをするのにやり方がたくさんあるというperlとかいう糞言語の信条をそのままパクってしまってることがひとつ。 またよくも悪くも設計が完全なオブジェクト指向にこだわっており、 javascriptなら関数ひとつで実現できることがblock、proc、lambdaと酷い有り様になっている。defで簡単に定義できまーすとかまさに初心者騙しもいいとこ。 また、流行り機能の無節操な取り込みが酷い。記号が足りなくなり、例えばオプショナルチェーンは他言語が?.のところrubyでは&.である。phpで文字列結合が"foo"+"bar"ではなく"foo"."bar"であるようなキモさ。 あとpythonと比べ多分野の優れたライブラリがない。あってもメンテされてない。作ってるやつが実用主義ではなく趣味だから。rubyでもできる!って言いたいだけ。よくも悪くもweb分野、しかもrails使うというやつ以外にはおすすめしない。 事実上rails専用言語。railsのDSLとして以外に存在価値はない。 初心者に勧めるなんてとんでもない。 >>231 >streamが標準出力にもファイルにも使えるでしょ。 どうやればいいの? 出来ないと思うけど。 Rubyは簡単に出来るのに node.jsは単独でディレクトリのコピーすら出来ない。 行うためには、 1. copySync()を使うためにはfs-extraモジュールのインストールが必要だが npm install -g fs-extraででインストールしても環境変数NODE_PATHに パスが通ってないため最初は使えず混乱する。 じぶんのためだけならいいが、作ったjsプログラムを初心者に使ってもらう のはこれだけでも不可能となり、一般人への自作プログラムの配布は絶望的となる。 2. copy、xcopy、robocopyなどの外部コマンドを呼び出せればコピーできるが、 RubyならC言語の伝統的なsysytem()関数をより強力で便利にした関数をサポートしている が、node.jsはしておらず、非常に使いにくいexec()やspawn()関数を非同期で使わなく てはならない。 以上により、node.jsは自分用としては使えるが、一般人に作ったプログラムを 配布して使ってもらうのは絶望的といえる。 >>234 eachがどう関数型なのか知りたいんだが。 mapならわかるけど。 ただのイテレータだろ。 その中括弧要らないよ。なんか勘違いしてない? >>252 node.jsで、streamを使ってstdoutへの出力をする方法を具体的に書いてみてください。 なお、書き込む関数もファイルと全く同じ関数群が使えなくてはいけません。 >>252 どこの知識不足なのか具体的に書いてください。 Rubyは、ディレクトリコピー、sysytemや外部コマンドの実行でネット検索すれば それぞれすぐに答えが出てきます。 node.jsは英語で検索しても埒の明かない答えばかりで、現実にはまともに 対応できてないものと思われます。 リンク見たら普通にlsとpipeの例書いてあるやん >>255 パイプではなく、自分のプログラム、例えば、Hello Worldのプログラムで node.jsにおいてstreamを標準出力に書き込むための手段として使う方法を聞いています。 もちろん、元祖C言語ではFILE系のstreamはstdoutに当然対応していますが、 node.jsでは不明確です。 ファイルをオープンする際のファイル名に何かを指定すれば出来るかも知れませんが。 C言語のstdoutに相当するものがどこにあるのか不明です。 番号の0や1なのでしょうか。 つーか何言いたいんだ? お前のやりたいことが 直感的に言語XでRubyと同様にできないからと言って だからどうしたという話なんだが Rubyアンチスレがモダン言語アンチスレになってきたな process.stdout.fd が fd の int 整数の「1」になっていて、 これを fs.writeSync()の第一引数に渡せば標準出力に 出力できることが分かりました。 しかし、ドキュメントが不十分でめちゃくちゃ分かりにくいです。 Rubyのドキュメントは非常に分かり易いです。 node.jsは、自慢で立派そうなnpmコマンドがあっても、NODE_PATHという 基本中の基本の環境変数すら設定されません。 これでfs-extraモジュールを追加インストールしなければ同期コピーすら出来ないのに。 同期的な外部コマンド実行も同様だと予想されます。 サーバーサイドの裏方として用いるならともかく、これをデスクトップマシンの BATファイルの代わりやスクリプト言語として、一般人向けに配布することは この段階で不可能となります。 その分野では現段階ではRubyが一番適切です。 >>240 >・型安全でない 型付けに関しては、話が長くなるからまた後で >・前後の文脈を見ないとその部分単体ではローカル変数とメソッド呼び出しの見分けがつかない … (後略) これは同意ですね、だから自分はメソッド呼び出しであれば self.hoge みたいに self を省略せずに書きます >・reduce/inject、map/collectのように同じことするメソッドの単なる別名と、 Lisp 文化と Smalltalk 文化の融合ですが、そもそも Ruby は最初から手続き型/関数型/オブジェクト志向を融合した マルチパラダイム言語として設計されていますし、コミュニティも多文化共存共栄(多神教?)みたいな空気がありますね 他の言語、たとえば手続き型原理主義(一神教?)で「聖典こそ真実であり、否定するものは異教徒」みたいな信者からすれば 違和感があるのかもしれませんね >Array#delete_if/Array#reject!のようにほとんど同じなくせして削除失敗時だけ挙動が異なるみたいな … (後略) 関数型プログラミンングだと mutable な操作は使わないのでよう分からんですが、一度に全てを理解しようとせず、 必要になった時に必要なメソッドを使うよう思考を単純化したほうがよろしいのではないかと >・Procオブジェクト(手続きオブジェクト)を作る方法が多すぎ。しかも作り方で挙動が異なる。 … (後略) これも同意、自分は基本がブロック構文、もし稀に明示的なProcオブジェクト(いわゆるクロージャ)が必要になった時には 組み込み関数の lambda を使うくらいですね 前段でもお話したように、他の「作る方法」は(今のところ)必要がないので気になりません >・簡単に「見せかける」ために省略記法を行き当たりばったりで導入しまくった副作用で、 >直感的な記述が逆にエラーとなることが多い(例: p {foo: 1, bar: 2}はエラーwブロックとして解釈されるため) 波カッコを使うブロック構文とハッシュ構文を誤読する問題は、少なくとも自分が Ruby を触り始めた 1.6 の時代から 存在しますから、「行き当たりばったりで導入」した例としては不適切です 「直感的な記述が逆にエラーとなることが “多い”」のであれば、別の例を挙げるべきでしょう 後、変数someの展開を文字列の中で行いたい場合 Ruby: "some=#{some}" JS: `some=${some}` の書き方もRubyの方が便利。 逆引用符は入れにくいし 他が普通の二重引用符なのに一部だけ逆引用符なのは 分かりにくくなりやすい。 それから、\ からエスケープシーケンスの働きをなくして単なる文字として扱うのが Rubyだと一重引用符を使って 'aaa\bbb\ccc' のように書けるが Node.jsだと String.raw`aaa\bbb\ccc` としか書けなくてとても不便。 後、変数someの展開を文字列の中で行いたい場合 Ruby: "some=#{some}" JS: `some=${some}` の書き方もRubyの方が便利。 逆引用符は入れにくいし 他が普通の二重引用符なのに一部だけ逆引用符なのは 分かりにくくなりやすい。 それから、\ からエスケープシーケンスの働きをなくして単なる文字として扱うのが Rubyだと一重引用符を使って 'aaa\bbb\ccc' のように書けるが Node.jsだと String.raw`aaa\bbb\ccc` としか書けなくてとても不便。 >>262 まあそれは後方互換維持のための苦肉の策ですし使い勝手は悪いですね Rubyのは全言語の中でも1番便利ですね 関数呼び出しも展開してくれるし まつもと:それから「Backquotes」の地上げも考えていたんですけども、Backquotesをするとシェルで実行して結果を文字列で返すってやつですね。 (参加者から「いける、いける」の声) まつもと:なんかあの辺で「いける、いける」って言ってる人がいますけど、信じない(笑)。なので、これももうちょっと先で、もう1回くるかもしれませんが、少なくとも3.0では死なないということです。 https://logmi.jp/tech/articles/321308 バージョンによって使えてたクォートが使えなくなったりするクソ言語 >>253 書いてあるでしょ、リンク先に。 ファイルと同じ関数群使えます。 nodejsもググればprocessモジュールに行き着くかと。 外部コマンドは普通はあんまりつかわんけど。 環境依存させたくないので。 基本的にクロスプラットフォームな物を叩くけど、そういうのはそもそもnodeだったりする。 ディレクトリコピーも、cpxあたりだとサッと行くと思うかと。 まぁコピーぐらいは中でやるもんだけど。 >>260 環境変数なんか必要ないんよ。 というかグローバルインストールしてそうなってる?もしかして。 >>269 ローカルにインストールするなんて馬鹿。 ストレージの無駄使い。 差分バックアップが流行ってるかも知れんけど 一箇所でも壊れるとそれ以前(または以後)の全てのバージョンが再現できなくな るのでディスクの故障に対して無力で、バックアップの意味が無い。 不具合があったとき以前のバージョンとWinDiffなどで比較すると原因箇所の 絞込みが出来るが、差分バックアップではそれがやりにくい。 比較ツールがその差分ツールの俺々ツールに限定されてしまうし。 ruby界隈のしょうもないシンタックスへのこだわりとか オブジェクト思考の過剰な押し付け感はやっぱ嫌いだわ。 >>270 アホか。 dll hell起こしたいのか? イマドキなんでもサイドバイサイドだろ。 dedupの効くファイルシステム使えばよかろう。 そういう所ついていけてないから、NODE_PATHがどうとか言っちゃうんだよ。 嫌なら、一つ上のフォルダでnpm i しておけ。 read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる