  |
はてなキーワード: RUBYとは
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
いろいろあるけど、自分の観測範囲ではRuby（やそれっぽい言語）が好きな人間ほどgolangを嫌う。
自分はRubyを書かないけど、なんとなく気持ちはわかる。詳細は書かないけど「Rubyを書く上でプログラマが気持ちいいと感じる」要素をgolangはことごとく否定しているから。
Rubyが綺麗に着飾ったキャバ嬢だとしたら、golangは出産以降、色気のかけらも無くなった嫁の様なものだ。
その2人に対して、「一緒に飲みに行くならどっちがいい？」と「家族にするならどっちがいい？」を各々勝手に選んだ者同士が言い争いしてるんだろう。
実際のところ、MatzがRubyを作るにあたってどれだけ「仕事目的のプログラミング言語」というものを意識していたのかはわからないが、golangは完全に「Googleが自分の仕事のために作った言語」という認識なので、キャバ嬢が「お酒で接待する専門家」としたら、嫁と対比した例えは、もしかしたら逆になるのかも。
偶然にこの会社の本を本屋で手にとってしまって、その場でチラチラ読んでいったら、色々な大学のインターン生が各々「リライト」したような感じの記事を書いていて、最後に「感謝！」みたいなポエムを社長が書いてあって、すごく腹がたったんだよ。プログラマー界隈だと、PHP, Perl, Ruby, Java, Python, etc を使って毎度似たような本を書くライターがいるのは知られている。で、まぁ、そんな彼らでも評価すべき箇所は、一応は自分でコードを書いていて、コードに責任を持っていることだ。なのに、こいつは自分はコードは書いてないけど、本を出して売れたオレは凄いって手法を使ってビジネスをしようとするのみえすぎる。つまり、投資家に信頼させる根拠に出版されたという本を使い、インターンは単位のために「書かない」という選択肢がないのに著名させられるって、一時期問題になった量産型ブログと何が違うんだ、って思ったのさ。なんというか、奴隷の書いたテキスト、現代版の『アンクルトムの小屋』みたいな悲哀がきつい本が流通されているのを認めてしまったときに、怒るなっていうのが無理だろ？
Python が流行して C と Java と Ruby を勉強した自分としては肩身が狭いのだけど、高校物理ができたら機械電気に行ったほうが良いよ、って言いたい。311以前は物理工学も含めたけど、今は語るまい。未来はわかんないけど、物理学のセンスがあるなら、工学部に行こうと言いたい。つまりは「プログラミングは独学できる」から、大学では「別のことを学ぶ」のもアリだよ、って言いたい。あんまり大学のプログラミング界隈に夢を持つと、プログラミングしかできない人間になっちゃうからね。たとえばさ、ビル・ゲイツやベゾスやマスクとオラクルの社長が「プログラミング」の学部を出ていないのに、三木谷や孫やホリエモンなんかもそうだけど、彼らは「プログラミングの勉強をセカンダリ」にしたから成功したのよ。計算機科学の勉強は、音楽と同様に「ピアノがあればできる」ようなもんで、高価な機材を必要としないのよ。だから、理系だから「プログラミング」を選ぶ必要は何もないよ。
RubyやRailsでどう書くかを知っているか知っていないかだけでそれがプログラミング能力だと勘違いしてる人が多い。全員というわけではないが……
「このライブラリでこう書ける」とか「こういう書き方がある」とか「こっちに書くとここがこうなる」とか、そういった規約覚えゲー的なところに目を取られて、どれだけRuby on Rails関連の規約をたくさん覚えているかでプログラミングスキルが高いか低いかを考えてる人が多い。もちろんそうした覚えゲーもある種プログラミング能力の一部なのだが、一方でライブラリを単に入れただけでは実現不可能なパフォーマンスを考えたコードを書くときやアーキテクチャ設計の段階では、何年も経験しているはずなのに役立たずになる。
ググるのが面倒なシンタックスシュガーや、ライブラリを導入した人しか辿り着けないconfigなど、規約（笑）とかいう発見非可逆なルールによって、それを導入した人だけが知っていて既得権益を得られるような構造になっている。そのために、ある機能を新しく利用したときに、それを知らない人にRails知識マウントを取れるようになっている。この気持ち悪さは、例えるなら、刑法を全部読んでからじゃないと街を歩くだけで逮捕されて、しかも何の罪で逮捕されているのか教えてもらえないようなものだ。
それで、全員というわけではないが、そういったRailsしか書けないおじさんは別言語で書くときに平気で今までプログラミングしたことないかのようなレベルの最悪のクソコードを生み出してくる。そもそも他言語が書けないおじさんも多い。
なぜなら、Rails知識こそがプログラミングスキルだと考えていて、Rails知識すごいワールドでしか生きてないからだ。覚えゲーをやっていただけで、スキルとしてはポケモンの名前を覚えただけにすぎない。社内スキルのようなものだ。
自分としてはRubyやRailsが直ちに滅びるとは思っていないが、Railsをメインで使ってる会社からしても、こうしたRailsしか書けないおじさんは今後不要になってくると思う。
「#駆け出しエンジニアと繋がりたい」というハッシュタグが詐欺に使われる日本に Hagex はいない。なぜなら、Hagex は殺されたからだ。
Hagex は天才だった。インターネット初期に技術を得て、しかも「ニヒルなやり方で、間違いを自覚させる」手法は天下一品だった。特に彼の「技術的なバックグラウンド」を持った上で、この手の「WordPressで一千万！」とかいう詐欺師の戯言を「テクニカルな背景と、類まれな文才」をもって否定できる人材は、令和の日本のインターネットにはいないようだ。
ひろゆきやホリエモン、山本一郎も才能はあるし、インターネットに詳しいという点では、ネットの評議者として認めてやってもよいかもしれないが、ただ「なんとなくテック業界で生きてきた」という感だけで物事を語るだけで、なんというか技術的な背景を持ってして「イケダハヤト」の理論的な矛盾点をつく、というネットの論客で Hagex を超えてきたやつはいない。
Hagex が生きていたら、きっとインフルエンサーの「WordPressでイッセンマンは堅いかなーと」という語調の裁判から逃げやすいポイントを見破って、「WordPressを編集できるエンジニアの年収は WebDesigning の統計から、だいたい400万ぐらいだけど？」とか返せたり、「SEOでイッセンマン」というマナブの主張も「2000年頃の過渡期の昔はともかく、SEOだけの専門会社があって、値段もこなれているのに頼む理由がない」現状を語れて、「Ruby の次は Scala だ」という勝又の嘘も「Scala ができるやつは SQLやTCP/IPにも精通しているから給料が高い」という合理的な説明もできちゃうだろうな、って思う。なぜ、Hagex は殺されないといけなかったのだ。
「罪を恨んで人を恨まない」と世界は言う。ただ、やっぱり代替不可能な人材はいて、Hagex という存在がいることで平成の末に「フリーランサーで年収一千万、それをプログラミングで」という【頭の弱い】ヤツが引っかかる嘘を「徹底的に茶化して」日本国に「騙されてエンジニアになる」というかわいそうなやつが消えてくれたのだ。たかだか、無料の Rails Tutorial モドキを一周して「年収一千万」になるなら、東大や東工大をでた連中が日夜 SIer で虐められて鬱になって自殺するわけ無いだろ。
頭の悪い KKO の俺だって、勝又が「ソシャゲバブルの果にグリーにいれなくなってきて、『ゆるふわエンジニア』なんて存在できないのに、Scala だ Go だ」と言って金をくすねているのは想像できる。マナブが「あの反社が多い界隈の広告業界の検索版がSEOで、タイにいないと命がヤバいくらいの主張をして、しかも間違っている」ということぐらいわかる。だけど、俺には「テクニカルに間違っていること」は理解できても、Hagex にできた「テクニカルな背景を持ってして、インフルエンサーをニヒルに否定して、バカ信者を改心する」なんていう高等スキルは持ち合わせなかった。残念なことに。
Hagex よ、令和にあなたがいないせいで、哀れな仔羊がインフルエンサーのカモにされています。人間だから、死という限界はある。だけれども、平成の末には「Hagex という抗生物質が存在」していて、しなくても良い犠牲が無かった、というのは Hagex さんの死があってはじめてわかったんだ。申し訳ない。
だから、私は匿名の「増田」でインフルエンサーを徹底的にこき下ろすと決めたのだ。この不退転の覚悟で、マナブや勝又といった、技術を間違って使う貴様らを Hagex の代わりに裁こうと私は思うのだ。金をとってカモを地獄に落とした貴様らの罪は大きい。覚悟しろよ。
当方、Ruby と Java と JavaScript と C を書くエンジニアでござる（コポォ）。Python を書く連中にものを申したく、増田に参上した。Python だけを勉強するのはやめい、と言いたいのでござる。拙者は Python が嫌いなのではなく、AI の冬が再来して、Pythonista が路頭に迷うのを不安に思って心配してるのでござる。なんのことかと申せば「インターフェイスやクラスは無くてもプログラミングはできる」と考える傾奇者が巷に溢れている現状を憂いているのでござる。どうかその世迷ごとを信じることなく、己の信じるとをコードにして昇華していただく、この書を認めに、今日この増田に拙者は参上したのでござるよ。ベルハラで、お前らの活躍を見ているからな！アディオス！
それが必要なんだよ。たとえば f(x) という関数があって、f(2) = 4 に束縛されたらメモリ上では定数にできて嬉しいのだよ。最近だと、イミュータブルっていうやつで。既存の Ruby や C だと、f(2) が確実に 4 と返すことができなくて、困っているのだ。
そうだね。でも計算機にかける前に、オーダーを出しておく必要なんだよ。計算機は演算にコストがかかるから、前もって結果を推定しないといけないの。だから、元の関数の中身を吟味したいの。
∞と∞を不等号で比較することはできないんだ。
それは事実。∞/∞ は定義されてないよ。知ってるよ。でもさ、数式的にわかっているときに発散具合で、関数自体は比較できるのじゃないの？
④の式を計算機で処理することはできないというあなたの説に反論する為に、WolframAlphaに④の式を計算させるリンクを張ったのだけれども、意図を全く理解してないようだな。
そりゃ、そうだろ。WolframAlpha が数式を表記できなかった誰も使わねえ。アホか。俺は電卓までは否定しないよ。違うってば。オレっちは「制限のあるメモリ（=有限）上では ∞ は定数としか扱えない」から、「数学=計算機科学」ではない、と言いたいの。「反例の反例」で書いたけど、遅延評価のような手法を使うと数学の問題もプログラミングで解けるよ。なんなら、虚数や分数でも Haskell や Ruby を使うとプログラミング上は解けるよ。それは言語製作者がパフォーマンスを落として実現しているだけで、メモリやプロセッサでは直接演算してないのよ。まさかだけど「物理学で小数と分数を同じものとして扱ってはいけない」ことを知らないとかじゃないよね？
