Javaで書かれたソースコードの大部分は冗長? 116
ストーリー by hylom
なんとも難しい 部門より
なんとも難しい 部門より
insiderman 曰く、
本家SlashdotでYour Java Code Is Mostly Fluff、New Research Finds(あなたのJavaコードの大半は無駄なもの、新たな研究で判明)なる記事が出ている。元ネタはITworld。
さらにその元ネタの論文を見ないとなかなか意味が把握しにくいのだが、自然言語による文章解析をプログラムコードにも適用したところ、そのような結果が得られたという話のようだ。
自然言語で書かれた文章は、その一部の単語がなくなったとしても意味を把握できることが多い。このように文中でなくなっても意味が変わらない単語を「chaff」(もみ殻)と呼び、逆にその単語がなくなると意味が分からなくなる/意味が変わってしまう単語は「wheat」(小麦)と呼ぶという。自然言語でこのような「chaff」と「wheat」を抽出する手法をプログラミング言語にも応用してJavaソースコードを分析したところ、「wheat」に相当する部分はソースコードの約5%程度で、残りの95%はなくなっても意味が変わらない「chaff」に相当する、という話だそうだ。
実際、ソースコードの多くが冗長であると言われても確かにそうなのだが、自然言語処理の話をプログラミング言語に適用するのはやや乱暴な気はする。そういった冗長な部分こそ自動生成できないケースも多いわけで、プログラマの作業の大半は不毛だと言われても納得してしまうが。
これは何との比較? (スコア:3, すばらしい洞察)
複数のプログラミング言語を比較した結果Javaがそうだった、ならJavaには冗長になるような特徴があるということでちょっと興味深いけど、
自然言語とプログラミング言語(その代表としてJava)を比較した結果プログラミング言語は冗長という話だと、
まあプログラミング言語って自然言語とは違うから…としか言えない気がする。
(論文チラ見したけど、プログラミング言語別の比較表とかはなさそうな雰囲気。後者?)
Re: (スコア:0)
自動生成されたアクセサとか、そういう無駄なものが多いということでないの。
言語に用意されてないから。
だったら、 (スコア:2, すばらしい洞察)
その5%で、元の100%のプログラムと同じ機能を持つものを作ってみてほしい。
それをして、初めて「95%は冗長だった」と言えるんじゃないの?
Re:だったら、 (スコア:1)
lisperかhaskellerに頼めば。
Re:だったら、 (スコア:1)
Computer Langauge Benchmarks Gameというサイトに行けば、コードの長さも評価に入れた言語対抗ベンチマークがありますよ。
これはJava vs Dartの例。
http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=java&... [debian.org]
Re: (スコア:0)
最適化して機械語にして圧縮をかけたら、それぐらいにならないかな。
Re:だったら、 (スコア:1)
メッセージ性とか全く関係ない言葉遊びだと思われ。
んー、この論文て、関数名やら変数名やら2度目に出てきたら冗長といってるんだよね?
その理論でいくと、機械語で同じ番地を同じインデックス修飾で参照したら冗長ということになりそうだけど。
コンパイルしたところで理論的には冗長度は変わらないはず。
人間はそれほど複雑な構文を扱わない(扱えない)ので冗長性が低いメッセージを扱うことが多くて、
取扱説明書とっいた類の文書はやっぱり冗長性高いという分析結果になるだろう。
プログラムなんて、取扱説明書の束みたいなもんだから、そりゃ冗長性高いだろ。
5%でした、と言われても、じゃぁ他はいくつなの?としか言いようがないよ。
insidermanクオリティ (スコア:2, 興味深い)
> 自然言語による文章解析をプログラムコードにも適用したところ、
違います
自然言語に冗長性があるように、プログラムにも冗長性があるのではないかと考え、形式的な方法によりJavaプログラムの冗長性を計算した
という話です
(アルゴリズムもちゃんと書かれています)
自然言語の話はせいぜいヒントになっているだけです
パリティビットは冗長なビット (スコア:1)
パリティビットは冗長だから削除しましょうとか言いたいの?
冗長性がないと、スペルミス一つ検出できなくなるよ。
いわゆるマシン語に比べてプログラミング言語の良さは、冗長性があること。
Re:パリティビットは冗長なビット (スコア:1)
そりゃそうだ。
けど、無制限にパリティビット付け足す、って話にもならないよね。
どのくらいのバランスがいいか、って話になるんじゃない?
Re: (スコア:0)
参考までに (スコア:1)
いわゆる hello world を解析してみた結果が知りたいな。
どのくらい冗長と判定されるのか。
クラス名のこと? (スコア:0)
なら納得だが
Re:クラス名のこと? (スコア:1)
コメントを書かない代わりに、クラス名や変数名、メソッド名を冗長にしてるんです。
・・・っていう手法が出てくんないかなぁ。
Re:クラス名のこと? (スコア:1)
>コメントを書かない代わりに、クラス名や変数名、メソッド名を冗長にしてるんです。
Clean Codeとか、結構その手法を推奨している書籍はある気がします(なおこれもJavaの本)。
最も、提唱者はだいたい英語圏の人で、英語ネイティブではない日本人がそれを猿真似すると、多くの場合悲惨な目にあいますが・・・。
# 動詞と形容詞と動名詞の区別も付かない開発者たちにその手法を適用した結果、意味も分からずコメントもなくなったソースを前にして。
Re: (スコア:0)
そうなんだよね。
英語はある程度読めるけど英文はたいしてかけない民族であることを前提にしないで
というか現場という現実も顧みずになんのアレンジもなく理想のまま適用するとひどい目になる。
まさになんとかの一つ覚え。(でもやりたいから推し進めたくなるんだよね)
アンクルボブは好きだけど、あれはそのまま適用できないよね。
Re:クラス名のこと? (スコア:2)
だったら、クラス名とか関数名を日本語にすれば?
言語仕様上は問題ないはずだよね。
Mind だとかみたいな関数名をつけていれば日本人には読めるようなのが作れるかも。
Re:クラス名のこと? (スコア:1)
それで御社は英語を社内公用語に。
Re: (スコア:0)
色々な場所に同じ内容を書かなきゃいけないところもねw
とりわけ関数型系の言語を使った後だと組んでいても冗長だなと感じることもままあり
Re: (スコア:0)
パブリックやらプライベートやら一々言葉が多い
Re:クラス名のこと? (スコア:1)
VBのように宣言に使う予約語が多い言語だとさらに冗長度が高まりますね。
Re: (スコア:0)
インデントのタブとか無駄だよね?
とかそういう話かもしれない。
5%って (スコア:0)
まさか識別子のうち辞書に載ってるもののユニーク数を数えてるだけだったりしないよな?
Re:5%って (スコア:2, 参考になる)
それにかなり近いです。
プログラミング言語の文脈等はほとんど考慮されていません。
1. 関数定義をトークン分け。
2. トークン列を抽象トークン列に変換。
3. 抽象トークン列からトークンの順序構造を取り除いて、抽象語彙集合を作る。
4. それぞれの関数定義の抽象語彙集合の部分集合のうち、全ての関数定義で部分抽象語彙集合が異なっていて、最も大きさが小さくなる様に取る(最小部分中小語彙集合)。
5. 抽象語彙集合と最小部分中小語彙集合の大きさの比が冗長度を表していると考えられる。
Re:5%って (スコア:1)
> プログラミング言語の文脈等はほとんど考慮されていません。
考慮されていないというより、考慮しなくて良いほうが、
構文解析も言語仕様もシンプルになるので、意識的に文脈に依存しない文法を採用しているのだと思います。
趣味レベルの知識ですが、大抵のプログラミング言語は、LR法 [wikipedia.org]をベースとした構文解析を使っており、Javaも基本的にはそうだと考えています。
LR法は、文脈自由文法 [wikipedia.org]に属する方式です。
情報工学の世界では、文脈自由文法と文脈依存文法 [wikipedia.org]とかがあります。
パーザーを作るにあたって、識別子が前後関係に依存する場合、
先読みや 2-pass の解析が必要になったりするなど、バリデーションを含めた実装と言語仕様が
複雑になる傾向があります。処理が複雑になると、構文解析の速度も遅くなります。
そのため、文脈依存文法は避けられる傾向があります。
また、言語仕様としても、文脈によって記法が違うと学習コストも高くなるので、
シンプルな文法を追求して、覚えやすくどの文脈でも同じルールに……とすると自然に
文脈自由文法(LR法ベース)になっていくのだと思います。
Re: (スコア:0)
まずはやってみました、ってことでいうと、なかなか面白い試みだと思いますし、
最終的には プログラミング言語だって、
背景知識を持った文脈解釈器に、クエリ言語で命令するぐらいのものになるはずで、
例えば
「この前のアレの中で一番いい評判だったの100個出して平均も出しといて。出来上がったら教えて」
てな具合に自然言語に近いものになるはずだから、
今はイマイチでも いずれいい指標になるかも、ですね。
Re:5%って (スコア:1)
解釈器に過度な期待をしなければ、今でも
select foo,avg(foo) from bar order by reputation desc limit 100
くらいのことは普通にできる。
Re: (スコア:0)
int number = 1192;のintは自然言語的には不要でしょう。
誰が見ても1192が整数であることは明白なのでわざわざ説明する必要はない。
Re: (スコア:0)
プログラミング言語でも言語によっては不要だし。(静的型付けでないとか型推論があるとか)
Re:5%って (スコア:1)
実際には、1185年に頼朝が全国に守護・地頭の設置(事実上徴税・司法権を得た)のと、1192年に征夷大将軍に任命された(正式に朝廷の統帥権から独立した兵権を確立した)と両方を教わります。
「鎌倉幕府の成立年」というのをはっきりとは示さない形です。
え?素晴らしいんじゃないの? (スコア:0)
オブジェクト指向っていうのは、つまるところコードを意味と機能に分割するプログラミング手法だ。
機能を括りだして下位に置くようにプログラムを作って、意味を浮き出せる。
95%に意味がなかったということは、コードの5%にまで抽象化が完成しているということでは。
素晴らしいと思うねどな。
#かなり雑談です。
プログラム言語って自然言語だっけ? (スコア:0)
言語によっては文法は通常の英語と異なる。
どうせならコメント文の冗長性を調べたほうが面白い。
Re: (スコア:0)
どうせ調べるならApple Scriptとかにしておけばいいのに。あれは英語の文法ほぼそのままで書けると言ってもいいので、少なくともJavaを自然言語解析するよりかはもっともらしい結果が得られるはず。
# そもそも自然言語とは、全く似ても似つかないプログラミング・スクリプト言語を自然言語解析しようと思うことがアレゲだ、とは言っちゃだめ。
Re:プログラム言語って自然言語だっけ? (スコア:1)
> Apple Scriptとかにしておけばいいのに。あれは英語の文法ほぼそのままで書ける
COBOLが仲間になりたそうにこちらを見ている
Re: (スコア:0)
【演習】 どちらが冗長なコメントか。
(1) ++i; // iを1増やす。
(2) ++i; // ここで転送元だけを進めて上位バイトへ。
Re:プログラム言語って自然言語だっけ? (スコア:1)
そりゃ長い方に決まってんだろ。(2)と。
Javaはタイプ量が多い (スコア:0)
他人の書いたソースコードを読むのがかったるいのがJava
この20年間Java自身も改良されてるけど根本的に治らないから無理
Re: (スコア:0)
10年前に書いた自分のコードですら読むのがかったるいです。
Re: (スコア:0)
10日前に書いた自分のコードを読むのもかったるいです。
Re: (スコア:0)
メモリ解放書かなくて良いCみたいな使われかたしてる問題もあるかと。。
main以外禁止とか、コピペとか。
オブジェクト指向、Javadocでのドキュメント一元化を全力否定した使い方の多さときたらね。。
何がwheatで何がchaffか (スコア:0)
どれが冗長なものなのか論文眺めてもよくわからない... 一応後の方の表でValiable IdentifierとかType IdentifierとかOperator,literal等に分類して集計されてるんですがそれもどっちに所属するかが全然わかりません。
なんか議論しにくいですなあ。だれか分類たのんます。
同じ内容が短く書けるなら (スコア:0)
単語レベルでいらないものってそうそうないと思いますから、キーワードの構成文字数なんかが指標としてよいかと。
たとえば...
* rustはキーワードを短くしてコードを短くする工夫が随所に見られます。functionをfnにしてみたり。
* VBの FUNCTION ~ END FUNCTION を見ると、Cならfunctionすら使わず{}でわずか2文字、返り値がvoidならsubもこなすと考えると短い。
* JavaScriptのファイルを圧縮するYUI Compressorは不要スペース文字をつぶして変数名をaとかbにしてしまうことで文字数を徹底的に削り、可読性を犠牲にコンパクトにしています。言語仕様ではないけれど一つの極端な例として頭の片隅に。ハンガリアン記法なんかと好対照です。
Re: (スコア:0)
> ハンガリアン記法なんかと好対照です。
ハンガリアン記法は変数名をコンパクトにするために編み出されたものなんだが?
仕様変更・拡張を予見してあえて冗長に書いておく (スコア:0, 興味深い)
ってのは普通によくあることだよね。
職業プログラマでない学者さんには理解できないかもだけど。
「メンテハッチを全廃すれば大幅にコストダウンできますよ!」と言ってるのと同じくらい愚にもつかない研究。
Re:仕様変更・拡張を予見してあえて冗長に書いておく (スコア:2, おもしろおかしい)
むしろ職業プログラマなら将来の再利用や拡張への備えはだいたい無駄になるということを学習していそうなものだが。
せっかく論文へのリンクがあるんだからさ (スコア:1)
イントロと結果くらい目を通せばいいのに。
冗長だからダメだとか、冗長性を削れなんて言ってないですよ。そもそも一番最初に「自然言語は冗長だから頑健だよね」みたいなことを言ってるし。
・自然言語のchaff/wheatの分類法をプログラミング言語にも試してみたらおもしろいんじゃね? → なんかそれらしい結果が出たよ。
・これだけ冗長性があるなら、IDEの補完機能とかもっとうまく出来る可能性があるよね。本質的な部分だけ書いたら残りががばっと補完されるとか。
・新しい言語をデザインする時に何らかの指標としても使えるかもね
とか、そういう話です。
別に読みたくなければ読まなくてもいいんだけど、その場合「学者さんには理解できないかもだけど」とか「愚にもつかない研究」とか言わない方がいいんじゃないかなあ。
読んだ上での批判なら「この手法では将来の仕様変更・拡張を予見して冗長になっている部分が検出できない」と判断した理由を書いてくれると良い議論になると思う。
Re: (スコア:0)
Re: (スコア:0)
どうせ10年経ったって使わねえよ
Re: (スコア:0)
ただのゴミ。
予定されていれば、少しは価値あるが、
大抵は、外れるし、担当変われば、意味不明のコード。
引き継いだ時にばっさり消したいけど、中身が不明だと簡単に消す事も出来ずに、、、。
あ、開発が一旦、終了すると、既存部分の変更はウルサイから、
仕様変更/拡張は、結局、新規にコードを起こすし。
難読化には少しは価値有るかも。
昨日も難読既存コードで苦労させられた。
Re: (スコア:0)
そんな貴方に送る言葉がある
"You ain't gonna need it"
新人上がりや三流職業プログラマには理解できないかもだけど。
やるとしても「予見」ではなく冗長であることを求められる「仕様」の場合だな
求められていないことをやって無駄に資源を消費するのは愚かな職業プログラマ