アカウント名:
パスワード:
プログラミングRubyのRubyベタボメっぷりにRubyを使い始めて早10数年、使えば使う程にRubyって駄目だなと痛感するRubyを学習し始めた頃は誰でもRubyは素晴しいと思うのだが、数年も使えばそのどうしようもない互換性のなさにウンザリするしかも互換性が無くなることをマズいと思っていない集団がRubyを制作しているのでどうしようもない1.4時代のコードが1.6になった途端に互換性がなくなり動かなくなることはあったが、1.6→1.8ではそれが顕著になり、1.9など何のエラーも出さずに前のコードが動く方が珍しいほどそれどころか1.9に行かずREEが海外ではデファクトになりつ
なぜこれほど事実誤認だらけのコメントに "すばらしい洞察" がついているのかわかりません。モデレータの人は、自分で正しいかどうか判断できない内容ならば、せめてモデレーションせずに放置しておいて欲しいものです。
> Rubyを学習し始めた頃は誰でもRubyは素晴しいと思うのだが、数年も使えばそのどうしようもない互換性のなさにウンザリする> しかも互換性が無くなることをマズいと思っていない集団がRubyを制作しているのでどうしようもないこれはポリシーの問題です。Rubyは後方互換性を犠牲にすることで、優れたAPIや洗練されたコードを提供することを選択してい
長々と書いてあるけど、結局元コメと同じことを言ってるだけですよね。 長期的にしっかりとメンテナンスを考慮するなら、仕様がコロコロ変わる Ruby をビジネスで使うとかあり得ない、と。
個人的には、質がある程度担保できない人数のプロジェクトになったりするような場合でも、ちょっと採用したくないな、という感じはありますが。
> 長期的にしっかりとメンテナンスを考慮するなら、仕様がコロコロ変わる Ruby をビジネスで使うとかあり得ない、と。
"長期的にしっかりとメンテナンス" というのが何を指しているか曖昧ですが、前述の "勝手にRubyのメジャーバージョンアップをされる可能性があり、野良ビルドも許されず、環境の変化によるメンテナンスの工数も割けない場合" に該当するのならその通りだと思います。まあ、その条件だとRuby以外にもダメ出しされる言語が多そうではありますが。
自分でRubyの実行環境を監理できたり、メジャーバージョンアップの際にメンテナンスができたり、そもそもあまり長期に使用しない用途ならビジネスでも十分に使えますし、実際に使われています。案件毎の条件によって向いている言語を使えば良いだけでしょう。
「勝手に Ruby のメジャーバージョンアップをされる可能性があり、野良ビルドも許されず」というのは開発者視点ですよね。 運用視点から見ると、前者は OS の更新やハードウェア故障等に伴う機器入れ替えによるバージョン変更などのパターンが考えられますね。また、別例としては「専用サーバーを用意できないのでこれで動かしてください」なんていうのもあり得ますか。そういった場合に 1.8.6 と 1.8.7 の壁のようなものはちょっと困りますね。 後者は Ruby を動かすシステムにそれだけのコストをかける価値があるかどうか次第でしょうが、基本的には論外ではないでしょうか。
メンテナンス作業を属人化/特殊化したり、メジャーバージョンアップのたびにメンテナンスコストが発生したりするのは基本的に避けたいですし、ビジネスではできるだけ避けたいところですね。 長期に使用しない用途 (使い捨てのものとか) ならそれこそなんでもいいと思いますが。
開発者視点からは、動作環境 (言語のバージョンを含む) を最初に合意してから開発に入るというのが一般的だと思います。その場合、異なるバージョンで不具合が出たケースはサポート対象外としても問題ないと思います (さすがにセキュリティパッチを当てたら動かなくなった、くらいは対応する必要があると思いますが) 。これはRuby以外の言語でも同様ですね。
運用者視点からは、特にビジネスで使う場合、動作させるソフトウェアの動作環境に合わせて環境を組むのが一般的だと思うのですが、Ruby1.8.6用のソフトウェアをRuby1.8.7で動かさなければいけなくて困るという
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
Rubyはオワコン (スコア:1, すばらしい洞察)
プログラミングRubyのRubyベタボメっぷりにRubyを使い始めて早10数年、使えば使う程にRubyって駄目だなと痛感する
Rubyを学習し始めた頃は誰でもRubyは素晴しいと思うのだが、数年も使えばそのどうしようもない互換性のなさにウンザリする
しかも互換性が無くなることをマズいと思っていない集団がRubyを制作しているのでどうしようもない
1.4時代のコードが1.6になった途端に互換性がなくなり動かなくなることはあったが、1.6→1.8ではそれが顕著になり、1.9など何のエラーも出さずに前のコードが動く方が珍しいほど
それどころか1.9に行かずREEが海外ではデファクトになりつ
Re: (スコア:0, 参考になる)
なぜこれほど事実誤認だらけのコメントに "すばらしい洞察" がついているのかわかりません。
モデレータの人は、自分で正しいかどうか判断できない内容ならば、せめてモデレーションせずに放置しておいて欲しいものです。
> Rubyを学習し始めた頃は誰でもRubyは素晴しいと思うのだが、数年も使えばそのどうしようもない互換性のなさにウンザリする
> しかも互換性が無くなることをマズいと思っていない集団がRubyを制作しているのでどうしようもない
これはポリシーの問題です。
Rubyは後方互換性を犠牲にすることで、優れたAPIや洗練されたコードを提供することを選択してい
Re: (スコア:1)
長々と書いてあるけど、結局元コメと同じことを言ってるだけですよね。
長期的にしっかりとメンテナンスを考慮するなら、仕様がコロコロ変わる Ruby をビジネスで使うとかあり得ない、と。
個人的には、質がある程度担保できない人数のプロジェクトになったりするような場合でも、ちょっと採用したくないな、という感じはありますが。
Re:Rubyはオワコン (スコア:0)
> 長期的にしっかりとメンテナンスを考慮するなら、仕様がコロコロ変わる Ruby をビジネスで使うとかあり得ない、と。
"長期的にしっかりとメンテナンス" というのが何を指しているか曖昧ですが、前述の "勝手にRubyのメジャーバージョンアップをされる可能性があり、野良ビルドも許されず、環境の変化によるメンテナンスの工数も割けない場合" に該当するのならその通りだと思います。まあ、その条件だとRuby以外にもダメ出しされる言語が多そうではありますが。
自分でRubyの実行環境を監理できたり、メジャーバージョンアップの際にメンテナンスができたり、そもそもあまり長期に使用しない用途ならビジネスでも十分に使えますし、実際に使われています。案件毎の条件によって向いている言語を使えば良いだけでしょう。
Re:Rubyはオワコン (スコア:1)
「勝手に Ruby のメジャーバージョンアップをされる可能性があり、野良ビルドも許されず」というのは開発者視点ですよね。
運用視点から見ると、前者は OS の更新やハードウェア故障等に伴う機器入れ替えによるバージョン変更などのパターンが考えられますね。また、別例としては「専用サーバーを用意できないのでこれで動かしてください」なんていうのもあり得ますか。そういった場合に 1.8.6 と 1.8.7 の壁のようなものはちょっと困りますね。
後者は Ruby を動かすシステムにそれだけのコストをかける価値があるかどうか次第でしょうが、基本的には論外ではないでしょうか。
メンテナンス作業を属人化/特殊化したり、メジャーバージョンアップのたびにメンテナンスコストが発生したりするのは基本的に避けたいですし、ビジネスではできるだけ避けたいところですね。
長期に使用しない用途 (使い捨てのものとか) ならそれこそなんでもいいと思いますが。
Re: (スコア:0)
開発者視点からは、動作環境 (言語のバージョンを含む) を最初に合意してから開発に入るというのが一般的だと思います。その場合、異なるバージョンで不具合が出たケースはサポート対象外としても問題ないと思います (さすがにセキュリティパッチを当てたら動かなくなった、くらいは対応する必要があると思いますが) 。これはRuby以外の言語でも同様ですね。
運用者視点からは、特にビジネスで使う場合、動作させるソフトウェアの動作環境に合わせて環境を組むのが一般的だと思うのですが、Ruby1.8.6用のソフトウェアをRuby1.8.7で動かさなければいけなくて困るという