アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
フレームワークは嫌いです (スコア:5, 興味深い)
RoR は使ったことがないけれど、Java 界隈ではそんなことの繰り返しのような気がする。そして PHP も。
Joel on Software に、私と全く同じ考えの文章が載っていて [joelonsoftware.com] 溜飲が下がったけれど。
# 自社製のひどいフレームワークを使わされているので AC
Re:フレームワークは嫌いです (スコア:0)
古き良き「ライブラリ」とか「サブルーチン集」が重宝され広く使われてきたのは、それを使うコンテキストの制約が少ない、つまり使いたい時に使いたいように使えるからだと思います。他のものと組み合わせたり、自分のデータ構造に合わせて呼び出したり。
フレームワークなんて、魂まで売り渡さないと使えないようなものと心中するのは勘弁という感じです。
Re:フレームワークは嫌いです (スコア:0)
逆にフレームワークが無いと肉体を売り渡しますけどね。
つまりコーディングの絶対量とか、あるいは各種寄せ集めライブラリのすり合わせとかで、コスト(時間とか)が大量に食われる。しんどい思いをする。
つまりどっちを採るかという究極の選択です。
で、それはさておくとして、
>古き良き「ライブラリ」とか「サブルーチン集」が重宝され広く使われてきたのは
古典的言語であればあるほど、フレームワークが「構築しにくい」、ライブラリ「しか」作れない、
なんてな場面が多いと思います。
たとえばRailsのActiveRecord。
カラムの存在を宣言するというライブラリなら多くの言語でも作れるでしょうけど、
宣言を不要にし、しかもソース自動生成も使わずにすむ、なんてのは
Rubyの(リフレクション系の)機能が充実してるからで。
Re:フレームワークは嫌いです (スコア:0)
>すり合わせとかで、コスト(時間とか)が大量に食われる。しんどい思いをする。
なんでも最初は寄せ集めから始まるものじゃないの?そういうものを統廃合した
結果がフレームワークなんじゃないかと思うけど。
それが嫌って「オールインワンのパッケージがなきゃヤダ」って言ってるだけ?
>古典的言語であればあるほど、フレームワークが「構築しにくい」、ライブラリ「しか」作れない、
>なんてな場面が多いと思います。
>たとえばRailsのActiveRecord。
>カラムの存在を宣言するというライブラリなら多