アカウント名:
パスワード:
Gnome標準にするってのはわからなくもないわけですよ。Gnome周りのコンポーネントに依存してるアプリが多いのも事実だしね。ただこの さまざまな条件を検討した結果 [debian.org]ってのは、一体なんなんです?
tasksel task qualityからしておかしいよね。まあ100歩譲って、GnomeのXfceが+1なのは許すよ。だけどkdeが0ってのは何なの? mateやcinnamonに至っては-1って何なんです?そんなに優位な差がどこにあるの? どう見ても50歩100歩にしか見えんのだけど。
accessibilityも何を評価してんだか分からんよね。xfceやlxdeを差し置いて、kdeは-1ですもんね。kdeがlxde以下の評価とかびび
> だけどkdeが0ってのは何なの?
KDEはC++が(主要な)開発言語だから。C++はちゃんと勉強しないと罠が多い言語でOSSのプロジェクトで使うには不向きだと思われる。
Cでやると標準ライブラリで可変長バッファをサポートしないわ、ランタイムに生のポインタを渡しまくるわ、例外処理機構がないので無数のIF文が増殖するわでセキリティと堅牢性の問題が出やすい。
ユーザーランドでC言語を使うのは時間と労力を浪費してる。
それはC++に対する反論なのか?多分、CとC++の両方だろうけど。
> Cでやると標準ライブラリで可変長バッファをサポートしないわ、realloc()は可変長バッファとは言わないの?まぁ、標準ライブラリは貧弱だから、GTK+で作る時はベースになってるglibを使うし、滅茶苦茶便利だよ。一度glibのリファレンスを見てみるといいよ。
> ランタイムに生のポインタを渡しまくるわ、生のポインタを渡すこと自体はなんの問題もない。問題は解放済みのポインタを使っちゃう事だけど、それは開発中に簡単に検出出来るよ。
> 例外処理機構がないので無数のIF文が増殖するわで例外機構は必須じゃないよ。コンシューマーゲームってC++で作られるのがほとんどだけど、ほぼ100%例外処理は使われてないけど特に問題ないよ。
> セキリティと堅牢性の問題が出やすい。これは確かに問題が出やすいけど、やっぱりチェックする方法はある。
他にもメモリリークの検出とかも出来るし、徹底的にチェックしようと思えばむしろスクリプト言語より徹底的にチェック出来る。まぁ、そういう技法はあまり知られてないのかな?
OSSのプロジェクトに絡んでいる人はC++をちゃんと学んでいる人が少ないと言いたいのかな?WebkitとかGeckoとかMySQLとか怖くて使えないね。
つうか、そもそもtasksel task qualityはtaskselのメンテナがしっかり仕事をしているかを評価したものに過ぎず、開発環境について評価したものではない。それなのに理由が「KDEはC++が(主要な)開発言語だから」って論理が飛躍しすぎ。
> OSSのプロジェクトに絡んでいる人はC++をちゃんと学んでいる人が少ないと言いたいのかな?WebkitとかGeckoとかMySQLとか怖くて使えないね。OSSプロジェクト全体で見ると実際少ないと思うよ。特にソースはないけど…(ほとんどのプロジェクトはC言語な事がソースとも言える)その3つのプロジェクトははっきり言って少数のフルタイム開発者が主要な部分を開発してるから、問題が無いと思われる。
> つうか、そもそもtasksel task qualityはtaskselのメンテナがしっかり仕事をしているかを評価したものに過ぎず、開発環境について評価したものではない。そこまでは把握できてなかった。それだと確かに開発環境とは関係ないと思う。
> ほとんどのプロジェクトはC言語な事がソースとも言える
ダウト。プロジェクト、っていうか、ライブラリ系は移植性の問題があるからC言語が圧倒的に多い。だから、普通の開発者はCで書けるならちょっとくらい不便でも(利用者のために)Cで書こうとする。しかし、ある程度複雑になってくるとそうも言ってられないから、製品はC++で、ってパターンが多い。プロジェクトから「ライブラリのみのプロジェクト」を除いて集計すると、C++の圧勝じゃないかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
検討結果が作為的すぎる (スコア:5, 参考になる)
Gnome標準にするってのはわからなくもないわけですよ。
Gnome周りのコンポーネントに依存してるアプリが多いのも事実だしね。
ただこの さまざまな条件を検討した結果 [debian.org]ってのは、一体なんなんです?
tasksel task qualityからしておかしいよね。
まあ100歩譲って、GnomeのXfceが+1なのは許すよ。
だけどkdeが0ってのは何なの? mateやcinnamonに至っては-1って何なんです?
そんなに優位な差がどこにあるの? どう見ても50歩100歩にしか見えんのだけど。
accessibilityも何を評価してんだか分からんよね。
xfceやlxdeを差し置いて、kdeは-1ですもんね。
kdeがlxde以下の評価とかびび
Re:検討結果が作為的すぎる (スコア:2)
> だけどkdeが0ってのは何なの?
KDEはC++が(主要な)開発言語だから。
C++はちゃんと勉強しないと罠が多い言語でOSSのプロジェクトで使うには不向きだと思われる。
Re: (スコア:0)
Cでやると標準ライブラリで可変長バッファをサポートしないわ、
ランタイムに生のポインタを渡しまくるわ、
例外処理機構がないので無数のIF文が増殖するわで
セキリティと堅牢性の問題が出やすい。
ユーザーランドでC言語を使うのは時間と労力を浪費してる。
Re:検討結果が作為的すぎる (スコア:2)
それはC++に対する反論なのか?多分、CとC++の両方だろうけど。
> Cでやると標準ライブラリで可変長バッファをサポートしないわ、
realloc()は可変長バッファとは言わないの?
まぁ、標準ライブラリは貧弱だから、GTK+で作る時はベースになってるglibを使うし、滅茶苦茶便利だよ。
一度glibのリファレンスを見てみるといいよ。
> ランタイムに生のポインタを渡しまくるわ、
生のポインタを渡すこと自体はなんの問題もない。
問題は解放済みのポインタを使っちゃう事だけど、それは開発中に簡単に検出出来るよ。
> 例外処理機構がないので無数のIF文が増殖するわで
例外機構は必須じゃないよ。
コンシューマーゲームってC++で作られるのがほとんどだけど、ほぼ100%例外処理は使われてないけど特に問題ないよ。
> セキリティと堅牢性の問題が出やすい。
これは確かに問題が出やすいけど、やっぱりチェックする方法はある。
他にもメモリリークの検出とかも出来るし、徹底的にチェックしようと思えばむしろスクリプト言語より
徹底的にチェック出来る。
まぁ、そういう技法はあまり知られてないのかな?
Re: (スコア:0)
OSSのプロジェクトに絡んでいる人はC++をちゃんと学んでいる人が少ないと言いたいのかな?WebkitとかGeckoとかMySQLとか怖くて使えないね。
つうか、そもそもtasksel task qualityはtaskselのメンテナがしっかり仕事をしているかを評価したものに過ぎず、開発環境について評価したものではない。それなのに理由が「KDEはC++が(主要な)開発言語だから」って論理が飛躍しすぎ。
Re:検討結果が作為的すぎる (スコア:2)
> OSSのプロジェクトに絡んでいる人はC++をちゃんと学んでいる人が少ないと言いたいのかな?WebkitとかGeckoとかMySQLとか怖くて使えないね。
OSSプロジェクト全体で見ると実際少ないと思うよ。特にソースはないけど…(ほとんどのプロジェクトはC言語な事がソースとも言える)
その3つのプロジェクトははっきり言って少数のフルタイム開発者が主要な部分を開発してるから、問題が無いと思われる。
> つうか、そもそもtasksel task qualityはtaskselのメンテナがしっかり仕事をしているかを評価したものに過ぎず、開発環境について評価したものではない。
そこまでは把握できてなかった。それだと確かに開発環境とは関係ないと思う。
Re: (スコア:0)
> ほとんどのプロジェクトはC言語な事がソースとも言える
ダウト。
プロジェクト、っていうか、ライブラリ系は移植性の問題があるからC言語が圧倒的に多い。だから、普通の開発者はCで書けるならちょっとくらい不便でも(利用者のために)Cで書こうとする。しかし、ある程度複雑になってくるとそうも言ってられないから、製品はC++で、ってパターンが多い。プロジェクトから「ライブラリのみのプロジェクト」を除いて集計すると、C++の圧勝じゃないかな。