- 1 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 03:18:33 ]
- 最強のＬＬ＝軽量プログラム言語は、どれよ？
エントリーは、
Perl、PHP、Python、Ruby、JavaScript・・・
さあ、死ぬまで語りやがれ！！！
- 12 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 14:43:04 ]
- >>10
リアルｗｗｗ
- 13 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 14:49:41 ]
- >>10
× 派遣 「いやもっと新しいイメージの開発が楽な言語というか・・」
○ 派遣 「そうですそうです。（以下空気に応じて） もうちょっと広い範囲でLightweight Languageと言ってますが、PerlやPythonみたいなものが中心です。」
これでいいじゃん。
- 14 名前：デフォルトの名無しさん [2009/02/15(日) 15:21:26 ]
- 前スレの終盤で
"LL"という言葉に以外にも信者が多いことがわかったな。
- 15 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 15:37:02 ]
- 誰かさんが勝手にバズワードだなんだと騒いでただけだろ
一単語に信者がいるとか頭おかしいとしか
- 16 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 15:45:46 ]
- しかしMLやHaskellからPerlまで一緒くたにする分類なんて
何か意味があるとは思えないんだが……
- 17 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 15:53:41 ]
- 近代的な高水準言語を指す単語がちょうど無いんだと思う
高水準言語ってだけだと、あくまで相対的に高水準という意味になる
Cとかも場合によっては高水準扱いになってしまうことを考えると、
まああまり良くないわな
- 18 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 15:57:01 ]
- なんとなくだけど、大規模開発と小規模開発の違いのような気がしてきた。
- 19 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 15:58:12 ]
- >>17
近代的とかモダンとかって主観じゃないの？
Perlより新しいJavaやC#はLLなのか、そうじゃないのか
- 20 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 16:24:23 ]
- 別にテクニカルタームでもないただの便利な言葉なんだし、掘り下げたって
PCとPDAと携帯端末の厳密な分類、みたいな一般人にとってはどうでもいい
不毛な論争にしかならないんだから、こだわりすぎる方がどうかしてる。
このスレでLLが「恥ずかしい」って言ってるのは一人だけだろ。
そいつはきっと「ノートパソコン」も「メールマガジン」も全て「恥ずかしい」に違いない。
日常生活が不便そうで同情するわ。
- 21 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 16:32:55 ]
- >>16
関数型もLLに含まれんの？ソースは？
- 22 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 16:39:36 ]
- >>21
前スレにあった
ttp://d.hatena.ne.jp/minekoa/20090122/1232634141
- 23 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 16:42:08 ]
- >>20
HaskellとPerlを同一のタームでくくることが
具体的にどういう文脈で「便利な言葉」なのか正直さっぱり分からん
>>10の派遣がHaskellやErlangで並列処理とかSchemeで継続サーバとか考えてて
上司はPerlとPHPでドカタ仕事とか考えてるかもしれない
全部LLなんだろ？馬鹿馬鹿しい
- 24 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 16:42:18 ]
- >>20
定義厨ってのはどの板にもいるよ。
九州ラーメンの定義なんてどーでもいいわ。
- 25 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 16:42:34 ]
- 信者というより、いままでブログとかで得意気にLLとか使ってしまってた人が必死なだけだと思う。
- 26 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 17:22:26 ]
- Python3の教本が出たね
- 27 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 17:28:31 ]
- >>25 アンチ必死だな
- 28 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 19:13:33 ]
- エル エル エルはリップのエル
- 29 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 20:58:54 ]
- 開発が楽（Laku）な言語（Language）ってことでいいだろ。
日本生まれの定義らしいからちょうどいい。
- 30 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 21:04:02 ]
- プログラムの重さについて賛否両論みたいだから、この際新しい基準を作れば。。。？
無難なのは仕様書の印刷重量＝言語の重さ（単位：g）、かな。
- 31 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 21:24:31 ]
- JavaのEJBなんかは、もう見たまんま「（いろんな意味で）重量級だなぁ〜」って思う。
- 32 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 21:30:37 ]
- >>29
なんだ要するにVBか
- 33 名前：デフォルトの名無しさん [2009/02/15(日) 22:50:01 ]
- LLがMatzをはじめとする一部の連中の
でっちあげだったと知って必死な厨房達乙
- 34 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:05:17 ]
- LLって、難しいロジックをサックリ実装できて試すことのできる言語だって思うだけど。
VBやHSPは、サックリ作れても、難しいロジックの実装は困難でしょ？
- 35 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:12:54 ]
- >>34
Cの最長不倒関数とか、人間の可能性には限りがない。
VBだろうがHSPだろうが、BrainF*ckででも書く奴は書く。
- 36 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:14:39 ]
- 単なる政治性でしょ
SunがJavaを広めるときにC++叩いてたのと全く同じ
どういうグループが入っていてどういうグループが排除されてるかを
考えてみればよい
- 37 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:17:19 ]
- いや俺もLLって職場ではちょっとこっぱずかしくって言えない。
大部分の人にへ？って言われると思うし。
Rubyはともかく、外人が作ったものになんで日本人が名前付けんの？って気はする。
- 38 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:26:03 ]
- >>35
同じことするのにさ、例えば、
迷路を解くプログラムを書けとかいう問題を、
Cでリスト構造から作り出すのと、
それを初めから備えている言語を使うのと、
どっちが楽だと思う？
- 39 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:27:27 ]
- 今のVBはLinqとか使えるからLLだＮＥ
- 40 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:31:49 ]
- 昔はVariant、.NETになってもObjectがあるから動的片付けだYO
- 41 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:33:04 ]
- つまりどうみてもVBです本当にありがとうございました
ってことでいいのかNA
- 42 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:35:30 ]
- vbって言語自体が、最初から備えるデータ構造って何？
汎用ポインタみたいなのしかないの？
- 43 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:37:34 ]
- .NETの奴は構文がみょうちきりんなC#みたいなもんだと思うYO
それ以前もべつに全部VARIANTというわけじゃなくて
整数だの文字列だのといった組み込み型や構造体やクラスぐらい使えたYO
- 44 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 00:20:25 ]
- >>38
いまどきどの言語でもリストなんてライブラリがあるし
- 45 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 00:23:25 ]
- >>38
C++はLLだネ☆
STLとか使えるし
匂いだっていいし
- 46 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 00:35:11 ]
- foreachやラムダ式がないのはいただけないと思う。
- 47 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 00:50:29 ]
- なにいってんの?ラムダってC++が採用してからパクった言語多いじゃんw
- 48 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 00:56:38 ]
- リストくらいネイティブで扱えば良いじゃないって最近は思うなぁ
大昔から存在する古典的なデータ構造なんだし
- 49 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 00:57:53 ]
- >>46
うｎ
代数データ型もパターンマッチも遅延評価も使えない言語はうんこだよね
たとえばPerlとか
LL？何それ
- 50 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 00:58:58 ]
- >リストくらいネイティヴで
CPUの勉強でもしてくれ。
- 51 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:01:22 ]
- >50
いや、C言語みたいなCPUやメモリに近い言語ならそれでも良いけどさ…
ある程度の高級言語になってくると気になる。
- 52 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:02:15 ]
- 多分「組み込み」と言いたかったのではないだろうかと想像
でもPerlもPythonもリストなんか組み込みで持ってないよ
あれは動的配列
- 53 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:03:40 ]
- ライブラリは言語自体が備えるデータ構造じゃねーだろ
- 54 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:04:20 ]
- >>52
ってことはデータを動的に追加しまくると重くなったりするの？
- 55 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:04:38 ]
- まあ、データ構造そのものではなくて、
データ構造を意識しないで済む型がゴールだよな
リスト、スタック、ツリーetc言ってる時点で古い
- 56 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:04:54 ]
- >>54
あたりまえだけどinsertionがO(N)でインデクスアクセスがO(1)
- 57 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:05:30 ]
- >>55
アルゴリズムのオーダーも意識できない奴はプログラマをやめたほうがいい
どんな言語だろうとそれは同じ
- 58 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:06:59 ]
- >>53
言語仕様をコンパクトにしてライブラリで高度な機能を提供する。
これが正しいプログラミング言語。
もちろんスクリプト言語やら動的言語はこの限りではない。
- 59 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:07:13 ]
- >>55
古い、ではなく（脳内処理が）重い、っていうとLightweightの概念に少し近づく？
- 60 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:08:33 ]
- >>57
その考えが古いよ。
少なくともここで語られているようなスクリプト言語の進化の方向性と
君の考えは異なっているようだ。
- 61 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:12:23 ]
- >>57
アルゴリズム本の良書おしえて
- 62 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:12:27 ]
- >>60
は？
効率がどうでもいいなら連想配列は単なるassociative listとして
実装してもいいわけでハッシュとか要らない
メモリ効率がどうでもいいんならgeneratorとか実装する必要は無い
むしろドン亀スクリプト言語で悪いアルゴリズムを選ぶと、C/C++では
バレなかったかもしれないがモロに影響が出るわけだが
なんか勘違いしてんじゃねーの？
- 63 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:15:09 ]
- >>62
最近アルゴリズムの勉強し始めたのか?
スクリプト言語はアルゴリズムが具体的になんであるべきかは規定していないものが多い。
変数の使われ方から最適なアルゴリズムをコンパイラが選択できるのがベスト。
人間からアルゴリズム時間を見積もる必要がある用途ではそもそも
ここで語られているような言語は向いてない。
- 64 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:19:49 ]
- >>63
> スクリプト言語はアルゴリズムが具体的になんであるべきかは
> 規定していないものが多い。
は？例えばPerlの配列が動的配列でハッシュがハッシュテーブルであることは
Perlプログラマならみんな知ってるし理解していなければならないことだろ
- 65 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:20:15 ]
- >>62
ちょっと冷静になった方がいいかも。
> 効率がどうでもいいなら連想配列は単なるassociative listとして
> 実装してもいいわけでハッシュとか要らない
これは、言語の内部実装じゃないの？
むしろあんたの主張と逆に、アルゴリズムなんか考えなくてもいいようになってる例じゃないか？
> メモリ効率がどうでもいいんならgeneratorとか実装する必要は無い
ただ単に言語の使い勝手の問題として捉えると、これは極論過ぎるだろｗ
簡単な事を簡単にできるのが大事なことで、選択肢として複雑な事ができるのは悪いことでも
不必要なことでもないだろ。ってなんか書いてて恥ずかしくなってきた。
- 66 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:23:08 ]
- >>65
その通りで、言語側の組み込みないしライブラリのデータ構造だが、
それについて何も知らなければ効率の良いコードは書けないということ。
「アルゴリズムなんか知らなくても／考えなくてもいい」というのは全くの誤りだ。
- 67 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:23:28 ]
- >>61
珠玉のプログラミング か プログラミングの宝箱
- 68 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:27:11 ]
- 例えばハッシュテーブルなのに順序性を保障してほしいとかいうどこぞの言語みたいな
馬鹿げた話はアルゴリズムとデータ構造への根本的無知から生じる
- 69 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:30:48 ]
- 本に書いてあるデータ構造やアルゴリズムは、基本であって、きわめてプリミティブなもの。
組み込みの抽象データ型なんてのはどうにでも実装できるし、
最近のスクリプト言語では、万人がよくつかう使い方でいかに効率よく処理できるかを
考えて色々組み合わせて実装されている罠。だからあえてリストですとかハッシュですなんていわない。
- 70 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:31:02 ]
- >>68
だから、その時どっち（実行効率？ コーディングの簡略・利便？）をとるかってことで
まったく別の路線があるだろｗ
そこんところはわかって書いてるんだよな？
- 71 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:34:03 ]
- >>70
ん？「ハッシュ」という名前ならハッシュテーブルだろ？
実際には赤黒木なのにハッシュという名前をつけているのならそれは名前が悪い
抽象化したいのなら単にディクショナリとでも呼んでおくべきだ
が、集合が順序付けされているかどうかは、例えばキーを列挙するときに
ソートが必要かどうか、という「実質」に関わってくるのだから、
その内実を知らなくていいということには全くならない
- 72 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:37:03 ]
- >>68
RubyのHashの話だったら、そう変な要求でもない
追加順にリンクをつないでやるだけだから、ハッシュ操作自体のオーダーに変化はない
SortedMapっていうか、赤黒木やB木みたいな整列済みツリーにしろってのは無茶だがｗ
- 73 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:37:07 ]
- ここまで思いこみの激しいやつが正しく組み込み型の処理時間を計算出来るとは思えないな。
応用ができないやつ。
- 74 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:38:29 ]
- まさか、言語設計や実装をやっているプログラマが何も考えずに
組み込み型を赤黒木やらハッシュやらそのまんまべっちょり実装してるとおもってないよなw
- 75 名前：６１ mailto:sage [2009/02/16(月) 01:39:59 ]
- >>67
トンクス。お金がたまったら珠玉のプログラミング買おぅ
それまで、キッシュイーターでいいや。
- 76 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:42:08 ]
- >>73
> 正しく組み込み型の処理時間を計算出来る
誰もそんなこと言ってねーっつーの極論に走る奴だなｗ
例えば
if x in foo
がリニアサーチかディクショナリルックアップかぐらい意識しとけって話だよ
>>55は極論過ぎる
例えば集合の性質によって、列挙するコードが変わるという例は挙げたよな？
- 77 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:47:56 ]
- だからゴールっていっとりますがな。
Cプログラムがどんなアセンブリコードに変換されるか考えて、
命令実行時間も出力されたアセンブリ命令から計算できる、
それができないやつはプログラマじゃない。
君が言っているのはそういうこと。
- 78 名前：６１ mailto:sage [2009/02/16(月) 01:49:00 ]
- 本物のプログラマって大変だな
- 79 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:50:00 ]
- 古いというのはそういうことだ。
組み込み型がスクリプト言語で気持ち悪いとおもうプログラマは殆どいないだろ。
それと同じだよ。
- 80 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:53:00 ]
- >>77
いやそこまで言ってねえよ、勝手に決め付けるなｗ
ゴールも何も、効率をあえて度外視するとしても、重複の有無だの順序性だの、
機能／使用のレベルで違うものを同一視しようがないだろ
データ構造を全く考えなくても良いという話には絶対にならない
- 81 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:04:11 ]
- 例えだよ。
ハードが高速化したのの大部分はソフト開発の生産性向上についやされているのよ。
そもそもスクリプト言語ってのは、ハード性能に甘えて、実行効率よりも生産性やプログラミングの敷居の低さを
狙った方向性から出てきたモノなわけで。少しは想像力をはたらかせてくれよとw
- 82 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:13:48 ]
- >>81
今度は「例え」で逃げるのかよ
ハードがちょろっと進歩しようがO(1)とNPの違いはそれこそどうにもならんだろが
数独パズルでも総当りで解いてろって話だ
- 83 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:16:30 ]
- ごめんごめん組み込みね。
>76
線形探索と辞書のこと？
確かにリストと連想配列の違いは意識した方が良いかも知れないけど…
最初に言いたかったのは、リストやそれに相当するものの生成に関して。
組み込み構文とまでは言わないけど、JavaScriptぐらいには書けて欲しいよ。
（変数名 = new Array(要素,要素,要素...); で書ける）
あとは、リストやそれに相当するものに対するforeach、map、filter(select)
辺りもせめて標準添付のライブラリで持ってて欲しいなぁ、と思う。
- 84 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:19:26 ]
- >>83
その選択（forarch, map, filter..)がものすごく恣意的かもしれないことに
気づいてる？
>>49みたいな人もいるかもしれないよ
- 85 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:22:53 ]
- 理解力のないやつだなあ。そのうち知識がついてくれば普通にわかることだからいいのだが。
データ構造/アルゴリズムの基礎を知っていればスクリプト言語の組み込み型の使い方を理解するのに
助けになる。とでも書いておけばいいのに、>>57は視野が狭いとしかいいようがない。
残念ながらアルゴリズムを意識しなくてもスクリプト言語は十分使えるものだ。
- 86 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:28:34 ]
- いや、アルゴリズムだのデータ構造だのは古いとかいう意味不明なレッテル張りを
している電波に突っ込んだだけだが
- 87 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:33:35 ]
- >アルゴリズムだのデータ構造だのは古い
そんなの誰も言ってないって。勘違い大杉。全てのレスに勘違いが入ってるよ、君。
アルゴリズムやデータ構造を意識しなくても一般に使える型に近づけることが
(人間の脳力を最小限にするという意味で)ゴールなの。
現時点の処理系の妥協点が、()だったり[]だったり{}だったりするわけよw
動的コンパイルで分析・最適化できることはハード性能の向上とともに広がっている。
スクリプト言語やその処理系はそれに乗っかって成り立っているもの。
今はわりに合わないと思われることも将来はできるようになる可能性があります。
- 88 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:36:03 ]
- > 今はわりに合わないと思われることも将来はできるようになる可能性があります。
いやだからハード性能で替わるのは定数項であってオーダーは同じだろ
算数もできないのか？
- 89 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:39:53 ]
- ハード性能があがると、コンパイル時に分析できるものが異なる。
JITやらVMなんてハード性能がある程度なきゃそもそも成り立たないモノ。
当然今時のスクリプト言語もね。
- 90 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:43:52 ]
- 最近だと配列とリストの違い意識しないのって割と普通なの？
- 91 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:45:34 ]
- いやだから、ハード性能が上がってコンパイル時に分析できるものが増えても
リニアサーチはO(n)だし、バブルソートはO(n^2)だろ
本質的な計算を自分で行わないない／計算量が少ないプログラムなら確かに
どうでもいいだろうし、実際にそういうプログラムは多い
が、そのようなものが全く不要という状態にはならない
だから「プログラマなら」と言ったんだ
手遊びでちょろっとオモチャを書いてる人の話をしていたんじゃないんだぞ
- 92 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:46:50 ]
- int func1 (char * buf1, char * buf2) {
int sum = 0;
for ( size_t i = 0 ; i < strlen(buf1) ; i++ ) {
for ( size_t j = 0 ; j < strlen(buf2) ; j++ ) {
sum += buf2[j];
}
}
return sum;
}
関係ないけど、別スレで上のC言語のコードでstrlen()をfor(...)内に入れるやつは馬鹿だという奴がいて、
結局、最新のコンパイラでコンパイルすると、strlen()は1度だけ評価されてあとは変数になって
しまうで実行時間は殆どかわらないというのがあったな。コンパイラの進歩はあなどれないよ。
- 93 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:47:59 ]
- >>90
そんなわけねえ
- 94 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:48:12 ]
- >>91
ハードが速くなり、コンパイラ進歩すれば、
もっと適切なデータ構造やアルゴリズムを実行時に選択できるようになります。
- 95 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:50:18 ]
- >>94
ああ、「ボブ、あのプログラム書いといてくれ」とメールすれば済むみたいな奴な
理解したよ、何を言っているかを
- 96 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 02:51:25 ]
- つか、わざわざスクリプト言語使ってるのに必要もないところで無理に
実行速度なんて考えないよ。遅かったらそのとき考えればいい。
その必要なところに労力をかけて、他は要領よくこなす加減がプロです。
- 97 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 05:05:54 ]
- > もっと適切なデータ構造やアルゴリズムを実行時に選択できるようになります。
そのアルゴリズムの計算量を教えてくれ。
- 98 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 05:32:28 ]
- まあ確かに最近はその辺の名前適当だよね。JavaとかC#のArrayListって
配列なのかリストなのかわけわかんねーって思うし。リストはLinkedListか・・うーん。
もともとVectorだったのに同期化ないバージョンはArrayListですとか、ジェネリクス
バージョンはList<T>ですとか、これは概念としてのリスト構造でありアルゴリズムは
配列ですとか、概念とアルゴリズムの名前がかぶっててなんかもうカオスw
でも実態は、どの言語でも使うのは配列・マップ(辞書)でほとんどだし、双方向リストは
途中挿入が頻繁な場合にくらいしか使わないし、あとは各言語のリファレンス見て
ふむふむって感じかなあ。
> もっと適切なデータ構造やアルゴリズムを実行時に選択できるようになります。
インターフェースが同じならできる場合もあるよね。たとえばソートとかは実装が
なにかはあんまり外に出てこないよね。クイックソートかヒープソートかとかは。
例えばマイクロソフトのSTLは、数が少ないとインサーションソートして、数が
多いとクイックソートに切り替えるみたいな内部的に選択している実装。
でもデータ構造の双方向リストと配列とかは、リストはインデックスアクセスは構造的に
作れなくてインターフェースが変わるから、やっぱ別の系統にするしかないと思う。
さらにマップとハッシュマップはインターフェースが同じにできてもイテレータの取得結果が
変わるからこれも別にするしかないよね。
- 99 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 13:20:08 ]
- 遅かったらそのとき考えればいいっていうのは、アルゴリズム（とデータ構造）の知識があるから講じれる手段でしょ
全く勉強してないけど適当にあれこれやってたら速くなったっていうならそれはそれで結構なことかもしれないけど
普通は考えても何も浮かんでこないと思うよ
- 100 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 14:03:49 ]
- >>96
無視していいかどうかを判断して無視するのがプロ
スクリプトならアルゴリズムのオーダーなど気にせずともよいとか言ってるお前は
DBも常にCOBOL風に全件スキャンするド素人
- 101 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 14:20:22 ]
- COBOLは全件スキャンは全件スキャンとして書かなきゃならない
PERFORM VARYING 〜 END-PERFORM だっけ？
大概のLLでやってることはそうじゃない
例えばリストの中から条件に当てはまるものを抽出して、という処理
（Pythonのfilterとかリスト内包表記のif、Rubyのselect、Perlだと…grepだっけ？）
だとしても、実際の処理は実装・ライブラリにお任せします、ってのがスクリプトじゃない？
まぁ、どの言語も似たような実装になるのは目に見えてるけどさ
…で、内部処理を見るのがプロで見ないのが素人だとしても
それがボトルネックで無いなら、プロでも可読性を選ぶだろ
- 102 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 15:16:02 ]
- >>101
誰も常に効率を優先させて最適化しろなんて言ってないんだが
むしろ早すぎる最適化は悪で、そんなことは昔からの常識だ
「スクリプトなんだから効率やアルゴリズムやデータ構造なんか
気にする必要は無い」というのがナンセンスだという話
「スクリプトかどうか」は、「効率云々を気にすべきかどうか」とは独立の
無関係な問題だ
「スクリプト〜」を過度に強調する奴は、ボトルネックがCPUなのかIOなのか
ネットワークなのかプログラマの脳みそなのか、
本当にプログラミング言語による実行効率の違いなのか、
アルゴリズム自体に改善の余地がないのかも
判断できていない証拠だ
スクリプトなら、ウン100万件のデータが入っているDBから一件データを
抜きたいときに、いつもテーブルスキャンを行うのだろうか？
そんなことは馬鹿げていて、それはスクリプトかどうかとは関係ない
- 103 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 19:29:27 ]
- >>92
趣旨はわかるが、それでもオレなら
馬鹿説を主張したい。
ループ内で関数呼び出しを追加したら、
最適化は難しくなる。
コンパイラの賢さや機嫌を考えながら
コードを書くのは嫌だ。
- 104 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 19:35:50 ]
- スクリプトってアルゴリズムを抽象化して
誰でも同じ書き方ができて、そんで平均値（ってかそれなりの速さ）
出せるって事を狙ってるんじゃねえの。
速いことに越したこたねえけど、もっとこう、本質的な部分（目的）に力を注ごうぜ
っていうスタンス。
- 105 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 19:36:06 ]
- >>92
この最適化って、コンパイラの組み込み関数使う時だけ効く最適化なのかな？
- 106 名前：デフォルトの名無しさん [2009/02/16(月) 19:39:13 ]
- 遅かったら考えればいいって考えの人には二種類いるんだよ
1. アルゴリズムを学習する気がないけどコンプレックスはある人
2. 必要なアルゴリズムは十分に理解しているが、経験的にいってほとんどの
プログラムは最適化によって十分速くなると考える人
”アセンブラ言語を学習するべきか”とか”関数型言語を学習するべきか”なんて話題を振ると意味も無く
攻撃的になる人いるじゃん。
- 107 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 21:39:29 ]
- 勘違いの馬鹿が多すぎ。
アルゴリズム否定なんて誰もしてないだろ。
ちゃんと意図よめよ、理解力のないクズさん。
- 108 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 21:41:51 ]
- どうせここ数年で一般的なデータ構造やアルゴリズムを学習した初心者が騒いでるだけなんだろうけど、
他人の知識や能力をあまくみすぎですよ。
- 109 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 21:45:04 ]
- >>107
とりあえずアンカーつけたら？
文章に内容がないからこのレスの意図はわからん。
>>100とか>>102とか、必死になってる人かも知れんが、そうだとしてこれらのレスも、
プログラムやるんなら最低限、内部実装を意識して書く能力が無いと糞！認められん！
っていうなんとも言えない主張しか伝わらんので、このスレで頑張ってレスしてる意図は
あんまり汲めない。悪いけど。
- 110 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 21:46:14 ]
- >>109
立場としたら逆の方か。まあどっちにしろ、アンカーつけてわかりやすくしてくれ。
なんかごっちゃごちゃになってる
- 111 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 21:53:22 ]
- >>92が典型的な例でしょ。
コンパイルの質があがれば、事前に時間のかかる処理を排除できる。
アルゴリズムやデータ構造も応用しだいで組み合わせてつかえば弱点を補完して使うこともできる。
その辺の理解がないやつが特に1人いて暴れていたっだけの話だ。
- 112 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:23:45 ]
- 現状アルゴリズムやデータ構造を意識しなくてもいいかどうかと、将来的にはそうなるかどうかって話が混ざり合っててカオス
|
 |
