1. Ruby on Railsでなければできないことは実は無い “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.” 2. 社内にPHPの利用者が多く、Railsに移行するには再教育が必要 OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
3. Railsは冗長 DON’T WANT WHAT I DON’T NEED
4. phpは小さくて早い IT’S SMALL AND FAST
5. phpは自分好みにいじれる IT’S BUILT TO MY TASTES
6. phpだと自分でSQLを書ける I LOVE SQL
7. Ruby on Railsを学んだことでphpでもっといいコードが書けるようになった PROGRAMMING LANGUAGES AR
翻訳 (スコア:5, 参考になる)
“IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”
2. 社内にPHPの利用者が多く、Railsに移行するには再教育が必要
OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
3. Railsは冗長
DON’T WANT WHAT I DON’T NEED
4. phpは小さくて早い
IT’S SMALL AND FAST
5. phpは自分好みにいじれる
IT’S BUILT TO MY TASTES
6. phpだと自分でSQLを書ける
I LOVE SQL
7. Ruby on Railsを学んだことでphpでもっといいコードが書けるようになった
PROGRAMMING LANGUAGES AR
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1)
“IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”
PHPとRubyの対比という全体的な意味で捉えると、
この文には「PHPでのオブジェクト指向」なども含まれてるのかな。
個人的には、何でもオブジェクト化する必要は無いと思ってます。
特にWEBプログラミングは、文字列操作と組み込み型(リスト、ハッシュ)操作、
共通部分の関数化で済んでしまう、わりあい平坦な構造のプログラムが
多いです。こういうとき、OOPは単に冗長なことが多いです。
名前空間としてOOPするなら別ですが、本格的なOOPの導入は、
手続き型のコードでは可読性が損なわれてしまう程度に
複雑な処理が必要になってから考えればいいことだと思います。
その場合でも、ライブラリだけOOPするとか、段階的な
導入のほうが上手くいくと思います。
金槌で全てを叩くだけが方法ではないのです。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1, 興味深い)
C++やJavaみたいに「オブジェクト(とかクラスとか)を構築するのにかかる手間」が大きい言語では、回避したくなる気持ちも判りますが、
Rubyについてはそういう無駄なストレスが極限まで減らせれるよう言語デザインされてるんで。
そういう意味では、「オブジェクト指向」「スクリプト」言語っていうRubyの立ち位置は秀逸です。オブジェクト(指向)を気楽にスクリプティングできる言語。本当に必要な最小限の手間だけでオブジェクトをいじれる言語。
>文字列操作と組み込み型(リスト、ハッシュ)操作、共通部分の関数化で済んでしまう
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:2, 興味深い)
この前後のコメントで「いわゆるOOP」の利点について述べていると思われるところを拾ってみると(表現はちょっと変えていますが)、
始めの2つは少々抽象的ですが、3つ目は
の表現から、 おそらく、 「いわゆるOOP」によりプログラムのモジュール化ができる、 ということを述べているのだと思われます。 上に列挙した1番目の考えも、同コメントに 「名前空間としてOOPするなら別」「ライブラリだけOOP」といった表現があることから、 やはりモジュール化についての考えを述べているようにも読めます。実はこのコメントで主張したい二つの点の内の一つはここなのですが、 「プログラムを綺麗にモジュール化するために、 『オブジェクト指向』は本当に必須なのか」を考えてみて欲しいのです。
確かに、C++やJavaといった、いわゆる「オブジェクト指向言語」では、 モジュール化の仕組みとクラスベースオブジェクトシステムが密接に関係しています。 というより、むしろ、モジュール間の階層構造等の関係や、 名前空間の分離、名前の隠蔽や公開といった仕組みが言語仕様上大幅に省略され、 代わりにクラスベースオブジェクトシステムの上のクラスの階層構造や クラスの定義が、そうしたモジュール機能を肩代わりしています。 このため、プログラマは、自分が 「オブジェクト指向」による恩恵を得ているのか、 「モジュール化」による恩恵を得ているのか、 明確に意識することが難しくなっています。 本当に必要だったのは、「オブジェクト指向」ではなく、 「モジュール化」だった可能性はありませんか?
さて、「いわゆるOOP」の機能の一部を 「モジュール」と言い換えるかどうかはともかくとして、 それ以外の部分に「オブジェクト指向」を導入して失うものが無いなら、 それはそれで問題はないはずです。 では、実際に「オブジェクト指向」で失うものは有るのでしょうか?
元コメントの前後を見ると「とりあえず動くモノを早く提供する(#1224227)」ために OOPしないのだ、という意見があるようですが、 ここではその考えは採りません。 最初に述べたように、このコメントでは「事前にしっかりとした設計」という大前提で考えます。
一旦立ち戻って、そもそも「オブジェクト指向」とは何でしょうか。 これは人により様々なことを言う人がおり、 前述の「モジュール化」の機能もオブジェクト指向に含めて述べる人もいます。 とはいえC++やJavaにおけるモジュール化機能は、 「オブジェクト指向」は「オブジェクト指向」でも、 クラスベースオブジェクトシステム前提となっているので、 例えばJavaScriptのようなプロトタイプベースオブジェクトシステムではそのまま当てはまらない要素が多く、 そのためこのコメント中では、「モジュール化」は「オブジェクト指向」の必須機能ではないとしました。
クラスベースオブジェクトシステムとプロトタイプベースオブジェクトシステムで共通する要素はいくつかありますが、 私の知る限りほとんどすべての「オブジェクト」の定義に登場する要素は、
私がここで「オブジェクト指向にしない理由」の一例として挙げたい点が、 正にここにあります。
つまり、「オブジェクト指向」の設計においては、 「内部状態の変化するオブジェクト」がお約束のように登場してきます。 「オブジェクト指向プログラミングは綺麗なプログラミング」と思い込んで設計をすると、 そこに何の疑問も生じないのですが、 実はここで「綺麗なプログラム」と考えられる性質の一つを、 無意識に捨てているのです。 そのパラダイムとは、「参照透過性」です。 このコメントの主張の二つ目がこの点です。 「オブジェクト指向にしたために失なう物」もまたあるのです。
もちろん、参照透過性が無くても分かりやすいプログラムは書けますし、 実際「オブジェクト指向プログラミング」は参照透過性を諦めた上で、 以前からそれなりに「きれいな」プログラムを作ってきました。 しかし、プログラムを「きれい」にするもう一つの性質は、 確かに失なわれているのです。 「だからオブジェクト指向を捨てるべきだ」という主張をするつもりはありません。 でも、無自覚に「オブジェクト指向にしない必要も無い」と思い込んでしまう前に、 「別の選択肢もあるのではないか」と考えてみることには価値があると思います。 プログラムの「綺麗」には何種類かあり、その一方を捨てる前に、 自分がそれを捨てていることに気付いてあげてもいいんじゃないかと思うのです。
元コメントのAC氏も、せっかく
とおっしゃっておられるのですから、 「オブジェクト指向」一辺倒ではなく、 参照透過性を保ちつつ、「関数型」の考え方を取り入れた設計についても、 一通り検討をしてみては如何でしょうか。このスレッドの中、#1224082でも、
という意見が出ていますね。 boost前提で良いのなら、 「オブジェクト指向」だけでなく、 かなり「関数型」の考えを取り入れたプログラミングが (さすがにベースがC++なので厳しい制限はあるものの)可能となります。 同コメントにあるように 等と思い込まずに、 他のパラダイムにも手を出してみては如何ですか?なお、ここでは論旨の都合上、 あたかも「オブジェクト指向」と「関数型」が対立するかのように書きましたが、 これを合わせ持つ言語も沢山あります。 前述のC++はBoostに見られるように関数型プログラミングが可能な方向を目指していますし、 Javaも 同様な方向 [srad.jp]を目指しているように思われます。 逆に元々関数型の言語がオブジェクトを取り入れた例としては、 OCaml [inria.fr]等があります。 OCamlのオブジェクトは参照透過性をあっさり捨てているので、 プログラムの部分部分で、結局どちらかを選択することになりますが。 とはいえOCamlはまた、モジュールシステムも面白いので、 本コメントの上の方で「じゃあクラスベースオブジェクトシステム以外のモジュールって何よ?」と思った人は、調べてみると面白いと思います。 他に関数型かつオブジェクトというと、 古くはSmalltalkに少々遅れたもののほぼ同時期に成立した オブジェクトシステムFlavorsはLispベースですし、 近頃流行りの言語で言えば、Haskellベースの O'Haskell [chalmers.se] なんてのもあります。
ここで言いたいのは、「前述したような言語を使え」ということでは無く、 パラダイムとして、「オブジェクト指向」一辺倒でないパラダイムがあるということです。 そうしたパラダイムは、明確に意識できてさえいれば、 C++なりRubyなりでも、設計に取り入れていくことができ、 それによってプログラムの見通しや、設計そのものの手間すらも、 改善していくことができると思っています。
というわけで、 「オブジェクト指向」は唯一の選択肢でもなければ、必ずしも最善の選択肢でもない(場合もある)という主張でした。 ――本ストーリーとはあんまり関係ないですね……。
無理矢理本ストーリーの方向に振れば、 Firstclass objectとしてのcontinuationや、 monadは、案外web application開発と相性が良いのではないか、 なんてアイデアもあるようです。 RubyやPHPだけでなく、 その他の(例えば関数型などの)パラダイムを考慮してみるのもいいかもしれません。 そして結局PHPに戻って、2年後に/.のストーリーになる、とか…… :-)
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:2, 興味深い)
>「いわゆるOOP」によりプログラムのモジュール化ができる、ということを述べているのだと思われます。
元の人がどう意図したかは知りませんが、その解釈は違うかも知れませんね。
OOPがアクセスを抑止(あるいは警告?)するのは、
ほかの「クラス」へのアクセス(だけ)じゃなく、
ほかの「インスタンス」へのアクセスも、です。
もっとも、C++/Javaがそういう設計なもんだから誤解されることが多いですね。
privateなのに「ほかのインスタンス」へアクセス可能だってのは、まずい設計だと思っています。
それこそC++/Java作者がOOPとモジュールプログラミングを混同してたんじゃないの?と疑ってしまう。
この面はそれこそRubyのほうがマシです。
>オブジェクトは内部状態を持つ。
データベースも含めて「状態」を考えると、
少なくともRailsがターゲットとしてるような「普通のWebアプリ」において(も)、
「内部状態を持つ」はそれなりに成り立ってると思います。
RailsのObjectが、というよりは、細かくいえば「(RailsのO/Rマッピング機能である)ActiveRecordのObjectが」ですね。
>「参照透過性」
たしかに完全な参照透過性とOOPは相性が悪いですが、「関数型もどきコーディング」のご利益とOOPとくらいならば両立できるように見えます。
まさにその実例のメジャー(今となっては)なものが、Rubyのコーディングだと思われます。
そういう意味では、「ほかのメジャー言語と似てない機能は使わない」という方針で書かれたRuby入門書は、筆者には悪いけどゴミだと思っています。初心者だっていうならむしろ「最初から」Rubyの関数型っぽい面とかを使いまくったほうがいい。あれはJavaとかに染まった人のほうが抵抗感を感じるはず。
>boost前提で良いのなら、「オブジェクト指向」だけでなく、かなり「関数型」の考えを取り入れたプログラミングが
ああ。それはありますね。
もっともコーディングの面倒&難解さから、Rubyの楽さと比べる気にもなりませんが。
>Firstclass objectとしてのcontinuationや、 monadは、案外web application開発と相性が良いのではないか、なんてアイデアもあるようです。
Continuationについては、KahuaというかGauche…の中の人…の話が、猛烈に秀逸なうえにNativeジャパニーズで読めるので、凄くいいです。Shiroさんは日本の宝の1つだと思う。あとコミュニティもね。
あの人のサイトを骨の髄まで読むといいと思います。Kahuaでは実際にCont.が Webアプリ構築フレームワークの中の中心(!)に据えられてますし、いっぽうで「(Gaucheを実装してる)Cのいわゆるスタックは、Cont.と相性最悪である」などといった現実面での嘆きとか、そういう色々な視点からの話が読めます。
>結局PHPに戻って、2年後に
PHPじゃなくRubyに戻る、っていうコースも有るかも。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1)
> OCamlのオブジェクトは参照透過性をあっさり捨てているので、プログラムの部分部分で、結局どちらかを選択することになりますが。
とありますが、OCamlのオブジェクトで実質的に参照透過性が失われるのは、あくまでもmutableなインスタンス変数を含みその値を変化させた場合です。逆に言えばmutableを一切指定しなければそれだけで参照透過性を保ちながらオブジェクト指向することが出来ます(これは例えばレコード型におけるのと同様のことです)。このため参照透過性を理由にしてモジュールとクラスの二者選択を迫る必要性はありません。これがオブジェクト指向的であるのかについては多少疑問の余地が残るところであり、また現実的にはそんなところで頑張るなら全部モジュールだけで書いちゃっていいんじゃない?と思ったりもしますが、クラス継承の側面だけを利用したい場合やstructural subtypingによる柔軟な型運用だけを利用したい場合などには、実際私はこうしたことを行なっています。
なので、一応、OCamlにおけるオブジェクトが参照透過性を完全に捨てているわけではないことを補足しておきます。もちろんプログラマがそれを捨てることを選択しても全然構わないし、実際捨てる場面の方が多いかも知れませんが、それを保ちながら書くことは出来ます。また他の言語においても同様の制約を課せば実質的に参照透過性を保ちながらオブジェクト指向ができるのだろうと思います。ただ、こんなのOOPじゃない!と言われても仕方ないような気はします。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
プログラムの内部状態という「猛獣」と如何に付き合うか?について人類が考えた、
2つの方法論ですね。
2つで全てではないですが、メジャーな2つであるのは確か。
その2つがたまたま技術的に水と油で相容れないのは、不幸で残念な(残念ですが)事実ですね。
かたやOOP。
はっきり言って古典的なやり方の延長でしかないが、
状態を持つ「単位」を小さくすれば把握しやすくなるだろうと踏んで小さくし、
ついでにキャッチーにするため(?)にそれらを「モノ」として捉えることを推奨するという、
論理的裏づけは薄いが感性には訴えやすいやり方。
かたや参照透過性。
状態…の変化…が有る
今だ、つっこめ! (スコア:0)
技術的にではないですよね?
方法論的に違うんだから、必然的に相容れないのではないでしょか。
> そして、やりようによってはハイブリッド派も成立可能。
興味本位でお聞きするのですが、
例えばどんな方法をさしてますか?
Re:今だ、つっこめ! (スコア:1, 参考になる)
元コメントのACさんではありませんが、
の答になりそうな方法を知っている範囲で……。例: Flavors, CLOS, OCaml等のオブジェクトシステム
実例は無さそう。 OOPではないけれど、副作用のある処理をstreamで扱うのは昔のHaskell (Haskell 1.0のStream-based I/O)の方法。
参考: Lazy Functional State Threads [gla.ac.uk]
余談: Web applicationのような一見非関数な処理も、DBに対するstate transformerと見れば、関数的に記述できる。
例: Clean言語は"uniqueness types"を使うことでこれを実現している。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)