アカウント名:
パスワード:
> パフォーマンスを重視すると、 > ある程度汚く読みにくくなるのは、 > 仕方がないと思われますが。
これって昔から言われることですが, 本当にこれが当てはまるケースって今ではごく稀になっているのではないかと. おそらくは
程度か, その類似の場合だけで, 多くの場合はむしろコンパイラが最適化しやすいように明瞭なプログラムの流れにした方が良いでしょう. それに手による最適化が必要な局面って, プログラム全体の高々数%未満ですから, 最適化を理由に汚いコードを書く人は, 単にきれいなコードを書くスキルが無いと思った方が良いでしょう. 経験的には, スキルの有る人が汚いコードを書かざるを得ない場合には, なぜそのようになったかがコメントに明記されているので, 十分に分かりやすくなっています.
で, いわゆる自称VBプログラマが問題になるのは, 実際のプログラミングに入る前段階での実装設計能力に欠けているからです. これは言語環境にはほとんど依存しませんから, RAD技法で対応可能な規模を超える物件では, どれだけプログラマが増えようと保種困難なクズプログラムが増えるだけで, 保守を前提としない使い捨てプログラムにしか適応不可能です.
本質的にはそこまで考えなくともよい、というのが private たる 所以なんですけどね。 Java の限界でしょうか。
いわゆる職人の出番は無い、悲しい時代です。
なのでコンパイラのバグを考慮しながら書くのが 日常茶飯事だという話を聞いたような聞かないような……
私の知っているVBプログラマって、たいていは VB“しかできない”プログラマ だったりするので、彼らに限って言えば無理っすね。
たとえば「キャッシュ」なんてものはフローの美しさ、読みやすさを考えれば存在しない方がいいわけです。 それでもパフォーマンスを得るためにわざわざそういった機構を実装し、内容を一致させるためにその内部でややこしい配慮をしているわけで。
あくまでバランスの問題とは思いますが、そういう必要悪的な部分をうまくパッケージ化することで、プログラムをきれ いに整えていくことは可能だと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
どの言語でも (スコア:3, 参考になる)
ある程度汚く読みにくくなるのは、
仕方がないと思われますが。
うちの仕事ものんびりした仕事は少ないので、
とりあえず動くものということだと、
金余分に貰ってそれをOSとDBにつぎ込んで
VBできる人を集めて、ASPで作っちゃいます。
Javaの「使える」エンジニアは常に不足気味ですから、
なかなか現場の要求に迅速に対応できないんですよね。
SunとJava陣営はそこんとこなんとかしないとね。
.netによって、これまでの大量のVBプログラマが
VB.Net経由でC#に徐々に慣れてくれれば、
あとでJavaに移植しやすくなるので
ありがたいと思うんですけど。
Re:どの言語でも (スコア:5, 参考になる)
> パフォーマンスを重視すると、
> ある程度汚く読みにくくなるのは、
> 仕方がないと思われますが。
これって昔から言われることですが, 本当にこれが当てはまるケースって今ではごく稀になっているのではないかと. おそらくは
程度か, その類似の場合だけで, 多くの場合はむしろコンパイラが最適化しやすいように明瞭なプログラムの流れにした方が良いでしょう. それに手による最適化が必要な局面って, プログラム全体の高々数%未満ですから, 最適化を理由に汚いコードを書く人は, 単にきれいなコードを書くスキルが無いと思った方が良いでしょう. 経験的には, スキルの有る人が汚いコードを書かざるを得ない場合には, なぜそのようになったかがコメントに明記されているので, 十分に分かりやすくなっています.
で, いわゆる自称VBプログラマが問題になるのは, 実際のプログラミングに入る前段階での実装設計能力に欠けているからです. これは言語環境にはほとんど依存しませんから, RAD技法で対応可能な規模を超える物件では, どれだけプログラマが増えようと保種困難なクズプログラムが増えるだけで, 保守を前提としない使い捨てプログラムにしか適応不可能です.
Re:どの言語でも (スコア:2, 興味深い)
ソフトウェアの開発も十二分に大きな市場ですから、優秀な人材を探したり育成したりすることに投資するよりも、優秀とはいえない人材をいかに活用するかへ金が流れるようになるのでしょう。
とくにWeb系に関しては、開発スパンがweek単位~長くて1年ですから、満足な設計すらもままならないことになり、プログラマにその辺のしわ寄せがやってくるケースが多々あるのではないでしょうか。
それに加えて、サーバサイドアプリケーションの場合は成果物を配布しませんから、設計や仕様変更に関して柔軟に対応できる分、コードのクォリティが必然的に低下していきます。
ある意味で、顧客満足度を高めるために、コードが犠牲になっているとも言えますが・・・
Re:どの言語でも (スコア:1)
>仕様変更に関して柔軟に対応できる分、コードのクォリティが必然的に低下していきます。
これは、逆じゃないですか?
設計や仕様変更に関して柔軟に対応する必要があるのなら、読みやすく、
メンテナンスしやすいコードほど、修正が短時間で行えるのだから、
コードのクオリティを高める必要が出てくるのでは?
使い捨てのプログラムなら(つまり、再利用や保守の必要が無いなら)、コードの
クオリティは低くて構わないのかもしれませんが。
Re:どの言語でも (スコア:2, 参考になる)
> 設計や仕様変更に関して柔軟に対応する必要があるのなら、読みやすく、
> メンテナンスしやすいコードほど、修正が短時間で行えるのだから、
> コードのクオリティを高める必要が出てくるのでは?
柔軟に対応する必要があるというよりは、
柔軟に対応を迫られる、
という表現が近いのでしょうね。
で、修正を短時間で行えるのは理想なのですが、設計と実装も短時間で行わなければなりませんから・・・なかなか理想的には行きません。
先日も、あるJava信仰者のSEの人が保守性を主張しまくって、大変な目にあいました。
保守性に固執しすぎてコーディングのアップが遅れると、テストのスケジュールを圧迫し、それによって成果物のクォリティが低下するという悲惨な結果を招く場合もあります。
大切なのはバランスだと思いますが、それがなかなか難しいんですよね。
Re:どの言語でも (スコア:1)
> 設計や仕様変更に関して柔軟に対応できる分、コードのクォリティが必然的に低下していきます。
ではなく、
> 設計や仕様変更に関して柔軟に対応させられる為、コードのクオリティが必然的に低下していく。
ということでよろしいでしょうか。それなら納得です。
----
<オフトピック>
> 大切なのはバランスだと思いますが、それがなかなか難しいんですよね。
ああ、もう、本当その通りですよね。御託ばっかり並べても、上手くやる奴は上手く
やるし、上手く出来ない奴は出来ない。で、何が違うのかというと、バランス感覚
というものを知っているか、ということなんやろなー、とよく思います。とは言え、
うまくバランスを取るのは難しい。要領よくやりたいもんですけどねー。
</オフトピック>
Re:どの言語でも (スコア:1)
そういう人と一緒に仕事がしたいっっっっ。
#そんなこと言う前に自分がそういう人になる事が先決>俺
Re:どの言語でも (スコア:1)
そうかな?コンパイラによる最適化が効くような、
抽象度の低い層の話だけでもないだろう。
外部には公開していない、
オブジェクト内部でだけ保持しているような中間状態を利用して
高速化を行うことって多いんでないかな。特に OOP だと。
もちろん、そういう書き方をすると「公開用インターフェース」と
「内部向けインターフェース」の2つが混在するから、
「公開用インターフェース」のみに絞った場合に比べて
読みにくくなる。
後半の部分については同意。
# mishimaは本田透先生を熱烈に応援しています
Re:どの言語でも (スコア:1)
(って言うか、ちょっとしたのならやっちゃうし。
public:はキレイキレイに書くんだけどなぁ。
愚痴
コメントレスなソースとか時々見かけたりして
ソース見ただけで判るからコメント要らないなんて言ってる人とは
一緒に仕事したくありません(タダの愚痴だよ (/_;)
Re:どの言語でも (スコア:0)
Java 文化の場合、
・クラス名、メソッド名、メンバ変数名は省略せずに書く
・1ファイル1クラス
・(特にシステムパッケージ以外の) import はクラス単位で書く
Re:どの言語でも (スコア:1)
private をおろそかにすると、MT-safe なものはとても書けないはずなんですが。逆に言えば、private をそうとしか考えてないということは、使い方を間違っているとしか言えないような。
Re:どの言語でも (スコア:1)
で、privateが外部から破壊できる状況ってのは、publicなインターフェースからのアクセスに限られません?
Re:どの言語でも (スコア:1)
クラスがMTセーフをうたってないのに、privateはMTセーフであるべきってのは違う話じゃなかろうかと
#単純に参照の出し入れをするだけのセッタとゲッタがあれば private であっても public とかわんねぇじゃんって話の延長ですね
Re:どの言語でも (スコア:1)
たとえば、あるクラスAがあるとして、そのクラスAのprivateなメンバについての情報をソースを参照せずに知る方法はあるでしょうか?(シリアライズの情報を見れば知れる場合も多いけど)通常はわかりませんよね。
その状態でクラスAを利用する人はクラスAがMTセーフかどうかを意識することはあっても、privateなメンバがMTセーフかどうかを意識することはできませんよね。
だから、privateなメンバがMTセーフかどうかを意識しないといけないのはクラスAのpublicなインターフェースの実装者であって、クラスAのユーザではありませんよね。
だから、ユーザはprivateに対してはMTセーフかどうかを考慮はできないし、する必要もないと考えているのですが。
あと、クラスがMTセーフをうたってないといのはドキュメントの話です。MTセーフだと明記されていないクラスはMTセーフでないか、MTセーフかどうかを考慮していないと考えてます。ドキュメントで明記されていなくてもMTセーフなクラスは複数あるかもしれませんが、そのクラスがMTセーフであることはドキュメントに明記されていない以上、約束されたことではなく、次のバージョンでは変わっているかもしれませんし。
外部からMTセーフか否かを知るすべがないのは確かに私も言語の欠陥であると思っています。Javadocの要素でもいいから実装者が外部にMTセーフか否かを公開する方法が欲しいですね(コンパイラでチェックするところまでは求めないけど)。
Re:どの言語でも (スコア:1, 興味深い)
悲しいかな私の廻りでは時代は変わり、今や「使い捨てプログラム」を作る時代になってしまいました。
使い捨てなプログラムになってしまうのではなく、初めから使い捨てにするつもりのプログラムなのです。take0m さんの書いてらっしゃるような、Web 系の開発スパンの短いものはほとんどがそういうものです。
いわゆる職人の出番は無い、悲しい時代です。
Re:どの言語でも (スコア:2, おもしろおかしい)
一瞬、「使い捨てプログラマ」って読んでしまいそうになった(笑)。
いや、笑い事じゃないな…。
Re:どの言語でも (スコア:1)
やってて虚しいのは確かですがね。
Re:どの言語でも (スコア:1)
大体 5 分ぐらいで「ちゃちゃ」っと書き上げて、
20 分ぐらい実行して、処理後のデータを見ることが多いですね。
その空いている時間は、調べものや息抜きタイムです。
> いわゆる職人の出番は無い、悲しい時代です。
こんな時代だからこそ、職人の時代です。
Re:どの言語でも (スコア:1)
この前もコンパイラの最適化では追いつかなくて ループ内のポインタ演算をアセンブラで最適化したり、
割り込み処理ルーチンでコンパイラがレジスタ退避などに使っていた部分を 処理内容にあわせて削ったりしました。
このためにグローバル変数を専用に作ったりして、ある程度美しくないソースになってしまいました。
この仕事では、全体の30%くらいはこのような状況でした。
というわけで、今でも状況によってはコンパイラに頼れない場面もかなりあります。
#んで愚痴になるんですが、
#その仕事で使うC処理系がかなり腐ってまして、
#単純二重ループを入れるだけでコンパイルが通らなくなる…
#結局ループを別関数に逃がさないといけないのでそのオーバーヘッド分遅くなる…
#それにCPUの「仕様」で特定の命令でダミーの信号が出てしまい、それを回避するためにインラインアセンブラの嵐
#しかもインラインアセンブラを使うとバグなのかAUTO変数がたまに化ける…
#それの回避にスタティック変数を大量に使わざるを得ない…
#美しいソースがどうこう言えるような状態では無い(;-;)
#バージョンアップは無いのかっ!
Re:どの言語でも (スコア:1)
最終的に幸せになるのでは?…とか、一瞬思ってしまいました。
まぁそう簡単にもいかないでしょうけどね。ご愁傷様ですm(__)m
ところでそういうコンパイラって、もしや売り物なのですか?
なんかとてもじゃないが売り物水準じゃないDQNな物に思えるのですが。
Re:どの言語でも (スコア:1)
そこの社内でも使って居るものなんですけど、何で修正されないのか不思議です。
VCでも (スコア:1)
最適化をONにすると余計な命令の並べ替えをしてくれて動作しませんでした。
「暗黙のオペランド」を使用する命令(maskmovqとか)を使うときは注意してね。
#VisualStudio.NET では直ってるんだろうな。たぶん。
うじゃうじゃ
Re:どの言語でも (スコア:1)
しかるべき量の工数を割いてコンパイラを修正してしまったがために,バグを考慮しながら書かれた過去のコードを再コンパイルすると,正しいコードをはかなくなってしまったりしたら,いやーんな感じ。
# バグも仕様と言うが如し。
Re:どの言語でも (スコア:1)
これらの情報が無いので判断ができませんが、
チューニングでスペック叩き出すより、
アルゴリズムやデータ構造を変えた方が良くないですか ?
30% が特殊なコーディングなら
60% 以上は性能が上がってないと割りに合わないかなと。
ま、
やっている事がどんだけ複雑か知らないで言っていますが。
Re:どの言語でも (スコア:1)
ハードウェアが要求する仕様を満たすためのものです。
そのためチューニングにより性能は0(動作しない)から1(動作する)へと
無限大%(?)向上しています。
ちなみにアルゴリズムがどうこう言うレベルのものではなく
単にバッファにデータを送るだけのものだったりします。
そのタイミングの条件が厳しいのがチューニングをする理由です。
ハードウェアのスペックがぎりぎりなのは、少量ですが数が出るので
部品代と部品点数を削るのが理由です。
Re:どの言語でも (スコア:1)
そういう0%から100%にするための修正(だよね)は、
「チューニング」とは、あんまり呼ばないのでは?
Re:どの言語でも (スコア:1)
ハードウェアのタイミング要件を満たすために、ソフトウェアをチューニングして間に合わせる、ってのはありますね。
こういうのは、ハードとソフトを組み合わせた製品として見れば「チューニング」じゃないんでしょうが、ソフト部分のみ取り出して見れば、「チューニング」以外の何ものでもないでしょう。
Re:どの言語でも (スコア:1)
> 直接アセンブラを使ってディレイスロット等を入れる場合
delay slot を手で埋めて最適化というのは、ちょっと古い気がします。
命令スケジューラを完備した最適化コンパイラの場合、コンパイラに埋めさせた方が高速だと思います。
p.s.
delay slot に似たような話だと、プレディケイト命令があります。
プレディケイト命令は使い所が難しくて静的なコンパイラだけでは痛し痒しなコードを出力しますが、
(C言語の)処理系によっては、条件分岐を 3項演算子で書くと積極的にプレディケイト命令を使ってくれてハッピーな場合があります。
特に EPIC の Itanium になると同時実行される命令スロットを埋めるために、
プレディケイト命令を積極的に使う必要がありますから、高速化のために
コーディングスタイルの変更を求められるかもしれません。
p.p.s.
コンパイラが最適化しやすいコードって、プログラマにとって明瞭な流れになるかなぁ?
例えば「A と B の 2 つの処理を定数回繰り返す返すループ。ただし、cond1 が成立する場合には初回の A 処理を省略する」というルーチンの場合、どれが読みやすいですか?
# コンパイラが最適化しやすいのは例 3。
● 例1
if( cond1 )
goto label;
for( i=0 ; i<N ; i++ ){
// A
lable:
// B
}
● 例2
if( !cond1 ){
// A
}
// B
for( i=1 ; i<N ; i++){
// A -> B
}
● 例3
if( cond1 ){
// B
for( i=1 ; i<N ; i++){
// A -> B
}
} else {
for( i=0 ; i<N ; i++ ){
// A → B
}
}
● 例4
tmp = cond1;
for( i=0 ; i<N ; i++ ){
if( tmp )
tmp = 0;
else{
// A
}
// B
}
コンタミは発見の母
訂正 (スコア:1)
● 例1
i=0;
if( cond1 )
goto label;
for( ; i<N ; i++ ){
// A
lable:
// B
}
コンタミは発見の母
Re:どの言語でも (スコア:1)
i=0;
if( cond1 ){
// B
i++;
}
for( ; i<N ; i++ ){
// A -> B
}
はどうでしょう?例2よりはちょっぴりましになるかも。
保守性を考えると例1が好きですね。
同じ処理を複数箇所に書くと、片方だけ修正して気づかないことがよくあるので。
うじゃうじゃ
Re:どの言語でも (スコア:1)
> 同じ処理を複数箇所に書くと、片方だけ修正して気づかないことがよくあるので。
ですね。私も普通に書くときは例1のように書くと思います。
goto はスパゲッティーコードの素と言われますが、使い方によってはプログラムを読みやすくしてくれます。
p.s.
例1は goto の代わりに switch を使うこともできます。
コンタミは発見の母
Re:どの言語でも (スコア:1)
switch (!cond) {
case 0: for (i=0; i<N; i++) {
// A
default:
// B
}
}
# 先生! 合ってますか?
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
Re:どの言語でも (スコア:1)
i=0;
switch (cond) {
case 0: for (; i<N; i++) {
// A
default:
// B
}
}
ですね。
# 薀蓄をたれると Duff's device といいます。
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
Re:どの言語でも (スコア:1)
でも、この手の怪しい記述のコードは薀蓄を語る時か、コンパイラ
のデバッグをするときにしか使いませんよね。
実際のプログラムでこういうコーディングをする人がいて、
その人の書いたコードをデバッグすることになったら嫌だろうなぁ。
コンタミは発見の母
Re:どの言語でも (スコア:1)
例3が例2より最適化しやすい理由がわかりません。よろしかったら教えてください。
# 個人的には私なら2を選ぶだろうなと思います。
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
Re:どの言語でも (スコア:1)
このままではほとんどの最適化手法が使えないので、最適化コンパイラはコードを複製して例3 に近い形に変形します。
# irreducible loop が多段に入ると、びっくりするほど大きなオブジェクトコードが生成される
# ことがあります。
例3 はループ本体をコピーしているため、例2 よりループを周る回数を判断しやすいです。ループ系の最適化が効き易くなります。
コンタミは発見の母
Re:どの言語でも (スコア:1)
この説明は嘘ですね。例2、3ともループの回数を判断できますから。
ただ、ループに入る前の変数の状態の曖昧さ 例3 の方が少ないので、最適化は効き易いです。
A が S++、B が空だとすると、以下のように最適化される可能性があります。
● 例2
if(!cond1){
S++;
}
S += N-1;
● 例3
if(cond1){
S += N-1;
} else {
S += N;
}
# 例のコードの外側にさらにループがある場合には、例2 の方が有利かもしれません。
コンタミは発見の母
Re:どの言語でも (スコア:1)
> この説明は嘘ですね。例2、3ともループの回数を判断できますから。
ああ、そうでしたか。Nがcondに依存する変数のつもりで書かれたのかと思いました。
> ただ、ループに入る前の変数の状態の曖昧さ 例3 の方が少ないので、最適化は効き易いです。
なるほど、そのとおりですね。ご説明ありがとうございました。
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
Re:どの言語でも (スコア:1)
>VB.Net経由でC#に徐々に慣れてくれれば、
私の知っているVBプログラマって、たいていは
VB“しかできない”プログラマ
だったりするので、彼らに限って言えば無理っすね。
Re:どの言語でも (スコア:3, すばらしい洞察)
私の知っているVBプログラマって、大抵はVBもできないプログラマだったりします。
で、そいつらの書いたコードと思しきものをメンテすることになる罠。
Re:どの言語でも (スコア:1)
Re:どの言語でも (スコア:1)
そもそも Basic ですらない VB.
しかも、どういうわけか依存性が強く、
他の言語に移(らない|れない)人が多い気がします。
オブジェクト指向っぽい言語ですが、
「っぽい」所がコードらしき文字の羅列を
作らせるのではないでしょうか。
罪を憎んで人を憎まず。
Re:どの言語でも (スコア:1)
あくまで一般論ですね。
ゲーム作ってるとMMXで扱いやすいようにデータ構造を変更したり、
PS2ではキャッシュを意識したコードを書いたりしました。
もっとよくある例では、クイックソートが読みやすいコードなのかと問いたい。
うじゃうじゃ
Re:どの言語でも (スコア:1)
考えています。なぜなら、読みやすいプログラムなのかどうかは、ルーチン
の複雑さよりも、機能が整理されて書かれているかどうかに掛かっている
からです。
仰られているクイックソートの例で言えば、読みやすいプログラムを作るのに、
クイックソートの処理自体は汚いコードでも構わない。ただし、クイックソート
の機能を関数としてまとめ、その関数のインタフェイスは整理しておく必要が
あります。それと、関数の動作の定義、引数の値の制限、戻り値の定義を書いて
おくべきです。そうすれば、関数の中身が読みにくいコードであろうと、関数の
動作は明らかなので、プログラムは読みやすいです。
関数化のオーバーヘッドが気になるのなら、関数化はできないケースもあるかも
しれませんが、その場合でも、必要なパラメータは何で、結果はどこにあるとい
うことを明らかにしておけば、やはり読みやすいプログラムは作れると思います。
読みにくいプログラムとは、読んだ人が、何をやっているのか理解できないプロ
グラムのことでしょうから。
例えば (スコア:1)
確かに全体の見通しはよくなるでしょうけど、例えば、関数化した内部にバグがあって他の人が直さなきゃいけないとか、仕様変更に対応しなければならない、とかいう場合はどうなりますでしょうか?
Re:例えば (スコア:1)
威力が発揮されます。
関数の内部にバグがある場合は、関数のインタフェースを定義しておくことにより、
・関数の中に問題があるのか、外に問題があるのかの切り分けがしやすい。
・機能の定義が明確である為、プログラム作成者以外にも、プログラムの動作が理解しやすい。
・関数の中の修正が、関数の外の部分に影響を与えないことが保証されるので、修正のために見るべきコードの量が減る。
・コードの修正量が、どんなに多くとも、関数の全書き直しで済む。
・修正後のテストは、インタフェースの入出力をチェックするだけでよい。
等のメリットがあります。
また、仕様変更の際には、インタフェースを定義しておくことによって、
・設計の変更を、関数(機能)のインタフェースのレベルで論じることができる。
・実際にコードを修正する人にとっては、インタフェースに合致した関数を書けばよいので、作業の目標が明確である。
等のメリットがあります。
デメリットとしては、インタフェースをきっちり前もって考えるのは難しいし、修正ごとに
いちいちインタフェースを定義しなおすのはめんどくさい、というのはあるかも
しれませんが、保守する側にとってはインタフェースの定義があると、大変楽です。
Re:どの言語でも (スコア:1)
>考えています。
一般論として、原則的には同意してます。
ただそれだけでは十分なパフォーマンスが得られないために読みやすさを犠牲にする必要がある場合もあり、すべてに当てはめることはできないことを指摘しているまでです。
ほんの数個の低レベルルーチンが処理時間の半分以上を費やしている場合もあります。
呼び出し回数を減らしてもまだ不十分であれば、そのルーチンを美しくなくても速度のみを優先したものに書き換えたりします。
たとえば「キャッシュ」なんてものはフローの美しさ、読みやすさを考えれば存在しない方がいいわけです。
それでもパフォーマンスを得るためにわざわざそういった機構を実装し、内容を一致させるためにその内部でややこしい配慮をしているわけで。
ブラックボックスの中身を気にせずに十分なパフォーマンスが得られれば、それに越したことはないんですけどね。
うじゃうじゃ
Re:どの言語でも (スコア:1)
あくまでバランスの問題とは思いますが、そういう必要悪的な部分をうまくパッケージ化することで、プログラムをきれいに整えていくことは可能だと思います。例えばキャッシュの例では、そのキャッシュに関わる部分を1つのオブジェクトや関数にして、統一的な API にしておけば、あとからそれをいじる人は、中の実装はともかく(キャッシュだろうが直接アクセスだろうが)、ここはデータにアクセスする部分である、と認識できればよいわけです。 C++ の inline や LISP の macro を使えば、パッケージングによる呼び出しオーバヘッドも極力避けられますし。
Re:どの言語でも (スコア:1)
でもそれは単に見えなくしただけで、美しくない部分を隠しているだけのことです。
基本的には読みやすいプログラムの方がパフォーマンス的にも優れていることの方が多いし、そうであって欲しいと思います。
でも、すべての場合にそれが当てはまるというような「信仰」を持つのは間違いであると言いたいのです。
うじゃうじゃ
Re:どの言語でも (スコア:1)
データ構造にメドをつけて、
マージソートを利用した方が高速です。
し、条件によってはもっと高速なソートがあります。
「データ + アルゴリズム = プログラム」
プログラムはアルゴリズムだけでなく、データ構造も重要です。