【Perl,PHP】LLバトル ..
2:デフォルトの名無しさん
09/02/15 03:18:58
■LLとは？
軽量プログラミング言語（Lightweight Language,LL）とは、取り回しに優れ、
コードの作成や修正が容易と見なされるプログラミング言語のことを指す。
ここでいう「軽さ」はプログラマの負担の軽重を指し、
実行速度に優れているという意味ではない。
現在の水準では
・インタプリタ
・動的型
・正規表現
・関数オブジェクト
などを利用できるものがLLと呼ばれることが多い。（Wikipediaより）
■過去スレ
【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】
ｽﾚﾘﾝｸ(tech板)
【Perl,PHP】LLバトルロワイヤル２【Ruby,Python】 （DAT落ち？）
ｽﾚﾘﾝｸ(tech板)
【Perl,PHP】ＬＬバトルロワイヤル【Ruby,Python】
ｽﾚﾘﾝｸ(tech板)
3:デフォルトの名無しさん
09/02/15 10:53:12
LL、LL、みんなLLを議論し続けろ...
激しく...もっと激しく...
Ruby信者とPython信者でつぶしあって...PerlとPHPは非難の的にして...
LLの定義が決まるまで無駄な議論をし続けろ...
いづれはム板中のプログラマーも参加させてやる...善人顔したSE達もだ...
ム板中のスレというスレすべてでLLの議論をしてやる...
C言語使いもCOBOLerも皆、Matzの様に一人よがらせて、閉じ括弧の化わりにendをぶちこむのさ...
ム板の次はこのＰＣ等のカテゴリ、全てを巻き込んでやる...
ただ気まぐれで立てられただけの見ず知らずのクソスレを、いきなりLLでバトロワ議論にさせてやる...
例えそれがこのスレッドはアイちゃんがどうのだろうと...ム板のphpスレであろうと...
インデント議論スレであろうと...スレタイがC言語なのに>>1がC#の話題だろうと...
クラック依頼fusianasanトラップスレであろうと...毎回マルチポストしかない宿題スレだろうと...単発質問就職相談スレ(ゲームプログラマーになりたい)だろうと...
全スレ残らず、LLはバズワードでしょ？とレスして、定義の議論をループさせてやる...
LL、LL、LL、
どいつもこいつもLL議論させてやる...
毎日10:00出社の5:00帰宅で嫁が口利いてくれない、デスマ明けでも議論をさせてやる...
和製英語と、ソースはwikipediaのみ、ム板なのにwebの話題にまみれながら、レスが減ったら自演で言語信者同士を衝突させ、
議論に負けそうになったら作者の人格攻撃をさせる...
そして永遠続けさせてやる...LLバトルロワイヤルを...
LLだ...LL、LL、LL、LL、LL、LL、
LL、LL、LL、LL、LL、LL、LL、
LL、LL、LL、LL、LL、LL、LL、
4:デフォルトの名無しさん
09/02/15 13:55:53
LL! LL! LL! どいつもこいつもLL! なぜだ! なぜやつを認めてこの俺を認めねえんだ
5:デフォルトの名無しさん
09/02/15 13:58:16
前スレまとめ
LLって口にするのが恥ずかしいので、従来通りの"スクリプト"ということで
6:デフォルトの名無しさん
09/02/15 14:00:03
タイプが楽なんだよな
7:デフォルトの名無しさん
09/02/15 14:04:46
>>5
好きにすればいい。何事も強制や決めつけが一番よくない
ってわけでLLでもいいよ
8:デフォルトの名無しさん
09/02/15 14:20:49
言語自体の性能、実効速度、動作環境、正規表現、安全性。
それと、言語を取り巻く環境、利用できるライブラリ、IDE、フレームワーク、、、etc
前スレから自演している厨は、以上をまとめてこい
9:デフォルトの名無しさん
09/02/15 14:23:52
えむえむっ
って知ってか？ケメコのじゃないぜ。
10:デフォルトの名無しさん
09/02/15 14:41:50
派遣 「じゃあ次のプロジェクトはLLで開発ということですね？」
上司 「LL？って、えっと、なんだったっけ？スクリプト全般のことだっけ？」
派遣 「いやもっと新しいイメージの開発が楽な言語というか・・」
上司 「ん？結局開発言語はなにになるんだっけ？」
派遣 「まあPerlとかPythonとかですかねぇ」
上司 「あぁPerlは俺が学生のころからあったからよく知ってるけど、なんか新しいバージョンってことだっけ？」
派遣 「んーっとまあPerlは昔からのものなんですがもっとなんかモダンというか・・」
上司 「よくわかんないけどまあ今回はPerlスクリプトで開発ってことね？」
派遣 「はあ・・まあ・・。（いやなんかこう古いPerlじゃなくってもっと今風のイメージなんだけどなあ）」
上司 「了解。（いちいち流行りの単語使いたがるんだよな・・スクリプトって言えばわかるのにメンドクセー奴だな）」
11:デフォルトの名無しさん
09/02/15 14:42:42
>>8
言語自体の性能ｗ
言語自体の安全性ｗ
あんたが得意な言語について、一つお手本を見せてくれ
12:デフォルトの名無しさん
09/02/15 14:43:04
>>10
リアルｗｗｗ
13:デフォルトの名無しさん
09/02/15 14:49:41
>>10
× 派遣 「いやもっと新しいイメージの開発が楽な言語というか・・」
○ 派遣 「そうですそうです。（以下空気に応じて） もうちょっと広い範囲でLightweight Languageと言ってますが、PerlやPythonみたいなものが中心です。」
これでいいじゃん。
14:デフォルトの名無しさん
09/02/15 15:21:26
前スレの終盤で
"LL"という言葉に以外にも信者が多いことがわかったな。
15:デフォルトの名無しさん
09/02/15 15:37:02
誰かさんが勝手にバズワードだなんだと騒いでただけだろ
一単語に信者がいるとか頭おかしいとしか
16:デフォルトの名無しさん
09/02/15 15:45:46
しかしMLやHaskellからPerlまで一緒くたにする分類なんて
何か意味があるとは思えないんだが……
17:デフォルトの名無しさん
09/02/15 15:53:41
近代的な高水準言語を指す単語がちょうど無いんだと思う
高水準言語ってだけだと、あくまで相対的に高水準という意味になる
Cとかも場合によっては高水準扱いになってしまうことを考えると、
まああまり良くないわな
18:デフォルトの名無しさん
09/02/15 15:57:01
なんとなくだけど、大規模開発と小規模開発の違いのような気がしてきた。
19:デフォルトの名無しさん
09/02/15 15:58:12
>>17
近代的とかモダンとかって主観じゃないの？
Perlより新しいJavaやC#はLLなのか、そうじゃないのか
20:デフォルトの名無しさん
09/02/15 16:24:23
別にテクニカルタームでもないただの便利な言葉なんだし、掘り下げたって
PCとPDAと携帯端末の厳密な分類、みたいな一般人にとってはどうでもいい
不毛な論争にしかならないんだから、こだわりすぎる方がどうかしてる。
このスレでLLが「恥ずかしい」って言ってるのは一人だけだろ。
そいつはきっと「ノートパソコン」も「メールマガジン」も全て「恥ずかしい」に違いない。
日常生活が不便そうで同情するわ。
21:デフォルトの名無しさん
09/02/15 16:32:55
>>16
関数型もLLに含まれんの？ソースは？
22:デフォルトの名無しさん
09/02/15 16:39:36
>>21
前スレにあった
URLﾘﾝｸ(d.hatena.ne.jp)
23:デフォルトの名無しさん
09/02/15 16:42:08
>>20
HaskellとPerlを同一のタームでくくることが
具体的にどういう文脈で「便利な言葉」なのか正直さっぱり分からん
>>10の派遣がHaskellやErlangで並列処理とかSchemeで継続サーバとか考えてて
上司はPerlとPHPでドカタ仕事とか考えてるかもしれない
全部LLなんだろ？馬鹿馬鹿しい
24:デフォルトの名無しさん
09/02/15 16:42:18
>>20
定義厨ってのはどの板にもいるよ。
九州ラーメンの定義なんてどーでもいいわ。
25:デフォルトの名無しさん
09/02/15 16:42:34
信者というより、いままでブログとかで得意気にLLとか使ってしまってた人が必死なだけだと思う。
26:デフォルトの名無しさん
09/02/15 17:22:26
Python3の教本が出たね
27:デフォルトの名無しさん
09/02/15 17:28:31
>>25 アンチ必死だな
28:デフォルトの名無しさん
09/02/15 19:13:33
エル エル エルはリップのエル
29:デフォルトの名無しさん
09/02/15 20:58:54
開発が楽（Laku）な言語（Language）ってことでいいだろ。
日本生まれの定義らしいからちょうどいい。
30:デフォルトの名無しさん
09/02/15 21:04:02
プログラムの重さについて賛否両論みたいだから、この際新しい基準を作れば。。。？
無難なのは仕様書の印刷重量＝言語の重さ（単位：g）、かな。
31:デフォルトの名無しさん
09/02/15 21:24:31
JavaのEJBなんかは、もう見たまんま「（いろんな意味で）重量級だなぁ〜」って思う。
32:デフォルトの名無しさん
09/02/15 21:30:37
>>29
なんだ要するにVBか
33:デフォルトの名無しさん
09/02/15 22:50:01
LLがMatzをはじめとする一部の連中の
でっちあげだったと知って必死な厨房達乙
34:デフォルトの名無しさん
09/02/15 23:05:17
LLって、難しいロジックをサックリ実装できて試すことのできる言語だって思うだけど。
VBやHSPは、サックリ作れても、難しいロジックの実装は困難でしょ？
35:デフォルトの名無しさん
09/02/15 23:12:54
>>34
Cの最長不倒関数とか、人間の可能性には限りがない。
VBだろうがHSPだろうが、BrainF*ckででも書く奴は書く。
36:デフォルトの名無しさん
09/02/15 23:14:39
単なる政治性でしょ
SunがJavaを広めるときにC++叩いてたのと全く同じ
どういうグループが入っていてどういうグループが排除されてるかを
考えてみればよい
37:デフォルトの名無しさん
09/02/15 23:17:19
いや俺もLLって職場ではちょっとこっぱずかしくって言えない。
大部分の人にへ？って言われると思うし。
Rubyはともかく、外人が作ったものになんで日本人が名前付けんの？って気はする。
38:デフォルトの名無しさん
09/02/15 23:26:03
>>35
同じことするのにさ、例えば、
迷路を解くプログラムを書けとかいう問題を、
Cでリスト構造から作り出すのと、
それを初めから備えている言語を使うのと、
どっちが楽だと思う？
39:デフォルトの名無しさん
09/02/15 23:27:27
今のVBはLinqとか使えるからLLだＮＥ
40:デフォルトの名無しさん
09/02/15 23:31:49
昔はVariant、.NETになってもObjectがあるから動的片付けだYO
41:デフォルトの名無しさん
09/02/15 23:33:04
つまりどうみてもVBです本当にありがとうございました
ってことでいいのかNA
42:デフォルトの名無しさん
09/02/15 23:35:30
vbって言語自体が、最初から備えるデータ構造って何？
汎用ポインタみたいなのしかないの？
43:デフォルトの名無しさん
09/02/15 23:37:34
.NETの奴は構文がみょうちきりんなC#みたいなもんだと思うYO
それ以前もべつに全部VARIANTというわけじゃなくて
整数だの文字列だのといった組み込み型や構造体やクラスぐらい使えたYO
44:デフォルトの名無しさん
09/02/16 00:20:25
>>38
いまどきどの言語でもリストなんてライブラリがあるし
45:デフォルトの名無しさん
09/02/16 00:23:25
>>38
C++はLLだネ☆
STLとか使えるし
匂いだっていいし
46:デフォルトの名無しさん
09/02/16 00:35:11
foreachやラムダ式がないのはいただけないと思う。
47:デフォルトの名無しさん
09/02/16 00:50:29
なにいってんの?ラムダってC++が採用してからパクった言語多いじゃんw
48:デフォルトの名無しさん
09/02/16 00:56:38
リストくらいネイティブで扱えば良いじゃないって最近は思うなぁ
大昔から存在する古典的なデータ構造なんだし
49:デフォルトの名無しさん
09/02/16 00:57:53
>>46
うｎ
代数データ型もパターンマッチも遅延評価も使えない言語はうんこだよね
たとえばPerlとか
LL？何それ
50:デフォルトの名無しさん
09/02/16 00:58:58
>リストくらいネイティヴで
CPUの勉強でもしてくれ。
51:デフォルトの名無しさん
09/02/16 01:01:22
>50
いや、C言語みたいなCPUやメモリに近い言語ならそれでも良いけどさ…
ある程度の高級言語になってくると気になる。
52:デフォルトの名無しさん
09/02/16 01:02:15
多分「組み込み」と言いたかったのではないだろうかと想像
でもPerlもPythonもリストなんか組み込みで持ってないよ
あれは動的配列
53:デフォルトの名無しさん
09/02/16 01:03:40
ライブラリは言語自体が備えるデータ構造じゃねーだろ
54:デフォルトの名無しさん
09/02/16 01:04:20
>>52
ってことはデータを動的に追加しまくると重くなったりするの？
55:デフォルトの名無しさん
09/02/16 01:04:38
まあ、データ構造そのものではなくて、
データ構造を意識しないで済む型がゴールだよな
リスト、スタック、ツリーetc言ってる時点で古い
56:デフォルトの名無しさん
09/02/16 01:04:54
>>54
あたりまえだけどinsertionがO(N)でインデクスアクセスがO(1)
57:デフォルトの名無しさん
09/02/16 01:05:30
>>55
アルゴリズムのオーダーも意識できない奴はプログラマをやめたほうがいい
どんな言語だろうとそれは同じ
58:デフォルトの名無しさん
09/02/16 01:06:59
>>53
言語仕様をコンパクトにしてライブラリで高度な機能を提供する。
これが正しいプログラミング言語。
もちろんスクリプト言語やら動的言語はこの限りではない。
59:デフォルトの名無しさん
09/02/16 01:07:13
>>55
古い、ではなく（脳内処理が）重い、っていうとLightweightの概念に少し近づく？
60:デフォルトの名無しさん
09/02/16 01:08:33
>>57
その考えが古いよ。
少なくともここで語られているようなスクリプト言語の進化の方向性と
君の考えは異なっているようだ。
61:デフォルトの名無しさん
09/02/16 01:12:23
>>57
アルゴリズム本の良書おしえて
62:デフォルトの名無しさん
09/02/16 01:12:27
>>60
は？
効率がどうでもいいなら連想配列は単なるassociative listとして
実装してもいいわけでハッシュとか要らない
メモリ効率がどうでもいいんならgeneratorとか実装する必要は無い
むしろドン亀スクリプト言語で悪いアルゴリズムを選ぶと、C/C++では
バレなかったかもしれないがモロに影響が出るわけだが
なんか勘違いしてんじゃねーの？
63:デフォルトの名無しさん
09/02/16 01:15:09
>>62
最近アルゴリズムの勉強し始めたのか?
スクリプト言語はアルゴリズムが具体的になんであるべきかは規定していないものが多い。
変数の使われ方から最適なアルゴリズムをコンパイラが選択できるのがベスト。
人間からアルゴリズム時間を見積もる必要がある用途ではそもそも
ここで語られているような言語は向いてない。
64:デフォルトの名無しさん
09/02/16 01:19:49
>>63
> スクリプト言語はアルゴリズムが具体的になんであるべきかは
> 規定していないものが多い。
は？例えばPerlの配列が動的配列でハッシュがハッシュテーブルであることは
Perlプログラマならみんな知ってるし理解していなければならないことだろ
65:デフォルトの名無しさん
09/02/16 01:20:15
>>62
ちょっと冷静になった方がいいかも。
> 効率がどうでもいいなら連想配列は単なるassociative listとして
> 実装してもいいわけでハッシュとか要らない
これは、言語の内部実装じゃないの？
むしろあんたの主張と逆に、アルゴリズムなんか考えなくてもいいようになってる例じゃないか？
> メモリ効率がどうでもいいんならgeneratorとか実装する必要は無い
ただ単に言語の使い勝手の問題として捉えると、これは極論過ぎるだろｗ
簡単な事を簡単にできるのが大事なことで、選択肢として複雑な事ができるのは悪いことでも
不必要なことでもないだろ。ってなんか書いてて恥ずかしくなってきた。
66:デフォルトの名無しさん
09/02/16 01:23:08
>>65
その通りで、言語側の組み込みないしライブラリのデータ構造だが、
それについて何も知らなければ効率の良いコードは書けないということ。
「アルゴリズムなんか知らなくても／考えなくてもいい」というのは全くの誤りだ。
67:デフォルトの名無しさん
09/02/16 01:23:28
>>61
珠玉のプログラミング か プログラミングの宝箱
68:デフォルトの名無しさん
09/02/16 01:27:11
例えばハッシュテーブルなのに順序性を保障してほしいとかいうどこぞの言語みたいな
馬鹿げた話はアルゴリズムとデータ構造への根本的無知から生じる
69:デフォルトの名無しさん
09/02/16 01:30:48
本に書いてあるデータ構造やアルゴリズムは、基本であって、きわめてプリミティブなもの。
組み込みの抽象データ型なんてのはどうにでも実装できるし、
最近のスクリプト言語では、万人がよくつかう使い方でいかに効率よく処理できるかを
考えて色々組み合わせて実装されている罠。だからあえてリストですとかハッシュですなんていわない。
70:デフォルトの名無しさん
09/02/16 01:31:02
>>68
だから、その時どっち（実行効率？ コーディングの簡略・利便？）をとるかってことで
まったく別の路線があるだろｗ
そこんところはわかって書いてるんだよな？
71:デフォルトの名無しさん
09/02/16 01:34:03
>>70
ん？「ハッシュ」という名前ならハッシュテーブルだろ？
実際には赤黒木なのにハッシュという名前をつけているのならそれは名前が悪い
抽象化したいのなら単にディクショナリとでも呼んでおくべきだ
が、集合が順序付けされているかどうかは、例えばキーを列挙するときに
ソートが必要かどうか、という「実質」に関わってくるのだから、
その内実を知らなくていいということには全くならない
72:デフォルトの名無しさん
09/02/16 01:37:03
>>68
RubyのHashの話だったら、そう変な要求でもない
追加順にリンクをつないでやるだけだから、ハッシュ操作自体のオーダーに変化はない
SortedMapっていうか、赤黒木やB木みたいな整列済みツリーにしろってのは無茶だがｗ
73:デフォルトの名無しさん
09/02/16 01:37:07
ここまで思いこみの激しいやつが正しく組み込み型の処理時間を計算出来るとは思えないな。
応用ができないやつ。
74:デフォルトの名無しさん
09/02/16 01:38:29
まさか、言語設計や実装をやっているプログラマが何も考えずに
組み込み型を赤黒木やらハッシュやらそのまんまべっちょり実装してるとおもってないよなw
75:６１
09/02/16 01:39:59
>>67
トンクス。お金がたまったら珠玉のプログラミング買おぅ
それまで、キッシュイーターでいいや。
76:デフォルトの名無しさん
09/02/16 01:42:08
>>73
> 正しく組み込み型の処理時間を計算出来る
誰もそんなこと言ってねーっつーの極論に走る奴だなｗ
例えば
if x in foo
がリニアサーチかディクショナリルックアップかぐらい意識しとけって話だよ
>>55は極論過ぎる
例えば集合の性質によって、列挙するコードが変わるという例は挙げたよな？
77:デフォルトの名無しさん
09/02/16 01:47:56
だからゴールっていっとりますがな。
Cプログラムがどんなアセンブリコードに変換されるか考えて、
命令実行時間も出力されたアセンブリ命令から計算できる、
それができないやつはプログラマじゃない。
君が言っているのはそういうこと。
78:６１
09/02/16 01:49:00
本物のプログラマって大変だな
79:デフォルトの名無しさん
09/02/16 01:50:00
古いというのはそういうことだ。
組み込み型がスクリプト言語で気持ち悪いとおもうプログラマは殆どいないだろ。
それと同じだよ。
80:デフォルトの名無しさん
09/02/16 01:53:00
>>77
いやそこまで言ってねえよ、勝手に決め付けるなｗ
ゴールも何も、効率をあえて度外視するとしても、重複の有無だの順序性だの、
機能／使用のレベルで違うものを同一視しようがないだろ
データ構造を全く考えなくても良いという話には絶対にならない
81:デフォルトの名無しさん
09/02/16 02:04:11
例えだよ。
ハードが高速化したのの大部分はソフト開発の生産性向上についやされているのよ。
そもそもスクリプト言語ってのは、ハード性能に甘えて、実行効率よりも生産性やプログラミングの敷居の低さを
狙った方向性から出てきたモノなわけで。少しは想像力をはたらかせてくれよとw
82:デフォルトの名無しさん
09/02/16 02:13:48
>>81
今度は「例え」で逃げるのかよ
ハードがちょろっと進歩しようがO(1)とNPの違いはそれこそどうにもならんだろが
数独パズルでも総当りで解いてろって話だ
83:デフォルトの名無しさん
09/02/16 02:16:30
ごめんごめん組み込みね。
>76
線形探索と辞書のこと？
確かにリストと連想配列の違いは意識した方が良いかも知れないけど…
最初に言いたかったのは、リストやそれに相当するものの生成に関して。
組み込み構文とまでは言わないけど、JavaScriptぐらいには書けて欲しいよ。
（変数名 = new Array(要素,要素,要素...); で書ける）
あとは、リストやそれに相当するものに対するforeach、map、filter(select)
辺りもせめて標準添付のライブラリで持ってて欲しいなぁ、と思う。
84:デフォルトの名無しさん
09/02/16 02:19:26
>>83
その選択（forarch, map, filter..)がものすごく恣意的かもしれないことに
気づいてる？
>>49みたいな人もいるかもしれないよ
85:デフォルトの名無しさん
09/02/16 02:22:53
理解力のないやつだなあ。そのうち知識がついてくれば普通にわかることだからいいのだが。
データ構造/アルゴリズムの基礎を知っていればスクリプト言語の組み込み型の使い方を理解するのに
助けになる。とでも書いておけばいいのに、>>57は視野が狭いとしかいいようがない。
残念ながらアルゴリズムを意識しなくてもスクリプト言語は十分使えるものだ。
86:デフォルトの名無しさん
09/02/16 02:28:34
いや、アルゴリズムだのデータ構造だのは古いとかいう意味不明なレッテル張りを
している電波に突っ込んだだけだが
87:デフォルトの名無しさん
09/02/16 02:33:35
>アルゴリズムだのデータ構造だのは古い
そんなの誰も言ってないって。勘違い大杉。全てのレスに勘違いが入ってるよ、君。
アルゴリズムやデータ構造を意識しなくても一般に使える型に近づけることが
(人間の脳力を最小限にするという意味で)ゴールなの。
現時点の処理系の妥協点が、()だったり[]だったり{}だったりするわけよw
動的コンパイルで分析・最適化できることはハード性能の向上とともに広がっている。
スクリプト言語やその処理系はそれに乗っかって成り立っているもの。
今はわりに合わないと思われることも将来はできるようになる可能性があります。
88:デフォルトの名無しさん
09/02/16 02:36:03
> 今はわりに合わないと思われることも将来はできるようになる可能性があります。
いやだからハード性能で替わるのは定数項であってオーダーは同じだろ
算数もできないのか？
89:デフォルトの名無しさん
09/02/16 02:39:53
ハード性能があがると、コンパイル時に分析できるものが異なる。
JITやらVMなんてハード性能がある程度なきゃそもそも成り立たないモノ。
当然今時のスクリプト言語もね。
90:デフォルトの名無しさん
09/02/16 02:43:52
最近だと配列とリストの違い意識しないのって割と普通なの？
91:デフォルトの名無しさん
09/02/16 02:45:34
いやだから、ハード性能が上がってコンパイル時に分析できるものが増えても
リニアサーチはO(n)だし、バブルソートはO(n^2)だろ
本質的な計算を自分で行わないない／計算量が少ないプログラムなら確かに
どうでもいいだろうし、実際にそういうプログラムは多い
が、そのようなものが全く不要という状態にはならない
だから「プログラマなら」と言ったんだ
手遊びでちょろっとオモチャを書いてる人の話をしていたんじゃないんだぞ
92:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/02/16 02:47:59
>>90
そんなわけねえ
94:デフォルトの名無しさん
09/02/16 02:48:12
>>91
ハードが速くなり、コンパイラ進歩すれば、
もっと適切なデータ構造やアルゴリズムを実行時に選択できるようになります。
95:デフォルトの名無しさん
09/02/16 02:50:18
>>94
ああ、「ボブ、あのプログラム書いといてくれ」とメールすれば済むみたいな奴な
理解したよ、何を言っているかを
96:デフォルトの名無しさん
09/02/16 02:51:25
つか、わざわざスクリプト言語使ってるのに必要もないところで無理に
実行速度なんて考えないよ。遅かったらそのとき考えればいい。
その必要なところに労力をかけて、他は要領よくこなす加減がプロです。
97:デフォルトの名無しさん
09/02/16 05:05:54
> もっと適切なデータ構造やアルゴリズムを実行時に選択できるようになります。
そのアルゴリズムの計算量を教えてくれ。
98:デフォルトの名無しさん
09/02/16 05:32:28
まあ確かに最近はその辺の名前適当だよね。JavaとかC#のArrayListって
配列なのかリストなのかわけわかんねーって思うし。リストはLinkedListか・・うーん。
もともとVectorだったのに同期化ないバージョンはArrayListですとか、ジェネリクス
バージョンはList<T>ですとか、これは概念としてのリスト構造でありアルゴリズムは
配列ですとか、概念とアルゴリズムの名前がかぶっててなんかもうカオスw
でも実態は、どの言語でも使うのは配列・マップ(辞書)でほとんどだし、双方向リストは
途中挿入が頻繁な場合にくらいしか使わないし、あとは各言語のリファレンス見て
ふむふむって感じかなあ。
> もっと適切なデータ構造やアルゴリズムを実行時に選択できるようになります。
インターフェースが同じならできる場合もあるよね。たとえばソートとかは実装が
なにかはあんまり外に出てこないよね。クイックソートかヒープソートかとかは。
例えばマイクロソフトのSTLは、数が少ないとインサーションソートして、数が
多いとクイックソートに切り替えるみたいな内部的に選択している実装。
でもデータ構造の双方向リストと配列とかは、リストはインデックスアクセスは構造的に
作れなくてインターフェースが変わるから、やっぱ別の系統にするしかないと思う。
さらにマップとハッシュマップはインターフェースが同じにできてもイテレータの取得結果が
変わるからこれも別にするしかないよね。
99:デフォルトの名無しさん
09/02/16 13:20:08
遅かったらそのとき考えればいいっていうのは、アルゴリズム（とデータ構造）の知識があるから講じれる手段でしょ
全く勉強してないけど適当にあれこれやってたら速くなったっていうならそれはそれで結構なことかもしれないけど
普通は考えても何も浮かんでこないと思うよ
100:デフォルトの名無しさん
09/02/16 14:03:49
>>96
無視していいかどうかを判断して無視するのがプロ
スクリプトならアルゴリズムのオーダーなど気にせずともよいとか言ってるお前は
DBも常にCOBOL風に全件スキャンするド素人
101:デフォルトの名無しさん
09/02/16 14:20:22
COBOLは全件スキャンは全件スキャンとして書かなきゃならない
PERFORM VARYING 〜 END-PERFORM だっけ？
大概のLLでやってることはそうじゃない
例えばリストの中から条件に当てはまるものを抽出して、という処理
（Pythonのfilterとかリスト内包表記のif、Rubyのselect、Perlだと…grepだっけ？）
だとしても、実際の処理は実装・ライブラリにお任せします、ってのがスクリプトじゃない？
まぁ、どの言語も似たような実装になるのは目に見えてるけどさ
…で、内部処理を見るのがプロで見ないのが素人だとしても
それがボトルネックで無いなら、プロでも可読性を選ぶだろ
102:デフォルトの名無しさん
09/02/16 15:16:02
>>101
誰も常に効率を優先させて最適化しろなんて言ってないんだが
むしろ早すぎる最適化は悪で、そんなことは昔からの常識だ
「スクリプトなんだから効率やアルゴリズムやデータ構造なんか
気にする必要は無い」というのがナンセンスだという話
「スクリプトかどうか」は、「効率云々を気にすべきかどうか」とは独立の
無関係な問題だ
「スクリプト〜」を過度に強調する奴は、ボトルネックがCPUなのかIOなのか
ネットワークなのかプログラマの脳みそなのか、
本当にプログラミング言語による実行効率の違いなのか、
アルゴリズム自体に改善の余地がないのかも
判断できていない証拠だ
スクリプトなら、ウン100万件のデータが入っているDBから一件データを
抜きたいときに、いつもテーブルスキャンを行うのだろうか？
そんなことは馬鹿げていて、それはスクリプトかどうかとは関係ない
103:デフォルトの名無しさん
09/02/16 19:29:27
>>92
趣旨はわかるが、それでもオレなら
馬鹿説を主張したい。
ループ内で関数呼び出しを追加したら、
最適化は難しくなる。
コンパイラの賢さや機嫌を考えながら
コードを書くのは嫌だ。
104:デフォルトの名無しさん
09/02/16 19:35:50
スクリプトってアルゴリズムを抽象化して
誰でも同じ書き方ができて、そんで平均値（ってかそれなりの速さ）
出せるって事を狙ってるんじゃねえの。
速いことに越したこたねえけど、もっとこう、本質的な部分（目的）に力を注ごうぜ
っていうスタンス。
105:デフォルトの名無しさん
09/02/16 19:36:06
>>92
この最適化って、コンパイラの組み込み関数使う時だけ効く最適化なのかな？
106:デフォルトの名無しさん
09/02/16 19:39:13
遅かったら考えればいいって考えの人には二種類いるんだよ
1. アルゴリズムを学習する気がないけどコンプレックスはある人
2. 必要なアルゴリズムは十分に理解しているが、経験的にいってほとんどの
プログラムは最適化によって十分速くなると考える人
”アセンブラ言語を学習するべきか”とか”関数型言語を学習するべきか”なんて話題を振ると意味も無く
攻撃的になる人いるじゃん。
107:デフォルトの名無しさん
09/02/16 21:39:29
勘違いの馬鹿が多すぎ。
アルゴリズム否定なんて誰もしてないだろ。
ちゃんと意図よめよ、理解力のないクズさん。
108:デフォルトの名無しさん
09/02/16 21:41:51
どうせここ数年で一般的なデータ構造やアルゴリズムを学習した初心者が騒いでるだけなんだろうけど、
他人の知識や能力をあまくみすぎですよ。
109:デフォルトの名無しさん
09/02/16 21:45:04
>>107
とりあえずアンカーつけたら？
文章に内容がないからこのレスの意図はわからん。
>>100とか>>102とか、必死になってる人かも知れんが、そうだとしてこれらのレスも、
プログラムやるんなら最低限、内部実装を意識して書く能力が無いと糞！認められん！
っていうなんとも言えない主張しか伝わらんので、このスレで頑張ってレスしてる意図は
あんまり汲めない。悪いけど。
110:デフォルトの名無しさん
09/02/16 21:46:14
>>109
立場としたら逆の方か。まあどっちにしろ、アンカーつけてわかりやすくしてくれ。
なんかごっちゃごちゃになってる
111:デフォルトの名無しさん
09/02/16 21:53:22
>>92が典型的な例でしょ。
コンパイルの質があがれば、事前に時間のかかる処理を排除できる。
アルゴリズムやデータ構造も応用しだいで組み合わせてつかえば弱点を補完して使うこともできる。
その辺の理解がないやつが特に1人いて暴れていたっだけの話だ。
112:デフォルトの名無しさん
09/02/16 22:23:45
現状アルゴリズムやデータ構造を意識しなくてもいいかどうかと、将来的にはそうなるかどうかって話が混ざり合っててカオス
113:デフォルトの名無しさん
09/02/16 22:24:56
例えば一番単純な例として、配列をn要素ずつ連結リストにm格納すれば、
連結リストと配列の中間的な探索速度を得られる。
理解できますかな?(わらい
ハッシュテーブルもリストで連結したり、ツリーにしたりとかよくやるんだよ。
特にスクリプト言語のように動的コンパイルで、あらゆるユーザがどんな使い方をするかわからないような
組み込み型は、頭の良い言語設計者や処理系の設計者が一般的なケースを研究したりして、
条件によってアルゴリズムを選択したりとか色々と工夫しています。
114:デフォルトの名無しさん
09/02/16 22:25:40
探索・挿入速度
115:デフォルトの名無しさん
09/02/16 22:38:41
>>113
でっていう
116:デフォルトの名無しさん
09/02/16 22:54:00
10m離れた位置での殴り合いみたい。
見てる分には面白いが。
117:デフォルトの名無しさん
09/02/16 23:00:44
見えない敵と戦う人たち
118:デフォルトの名無しさん
09/02/16 23:04:21
>>113
いや主張の意図をやっと理解した
ほんとごめん
「処理系が最適化してくれるからアルゴリズムとか関係ねー」
「総当たりのアホみたいな探索コードを書いても最適化すれば
小人さんが頭の良いコードに書き換えてくれます」
とかいう主張だと思ってずーっと意味不明だったんだけどな
いきなり無説明で「スタックだのキューだのは古い」とか言われても
主張の意図がわかんなかったよ
119:デフォルトの名無しさん
09/02/16 23:04:27
>>116
あるいは、相手の手からボールが離れた瞬間に全力でその軌道から離れて、
「どこ投げてんだ下手糞！」
ってなじりあう負のキャッチボールみたいな。
120:デフォルトの名無しさん
09/02/16 23:07:11
>>118イイ奴だな
121:デフォルトの名無しさん
09/02/16 23:40:55
>>55 != >>133
の悪寒
122:デフォルトの名無しさん
09/02/16 23:41:25
>>105
ループ不変命令のループ外移動は、よく知られた最適化の一つ
ある程度賢い最適化コンパイラならやってくれるはず
123:デフォルトの名無しさん
09/02/17 00:43:49
まとめると
・LLでは処理の裏側のアルゴリズムまで書き込むようなマイクロマネージメント的なコードは書かない
・もっと抽象的なレイヤで書き、使われ方などからアルゴリズム選択などを処理系に裏で丸投げするのがLL
・LLはクソコードを適正化しないが、詳細をスルーできるので普通のコードの作成での脳力削減になる
でおけ？
124:デフォルトの名無しさん
09/02/17 01:12:38
ごめん、もうなにを罵り合ってんのかよくわからないし、つまんないから3行まとめして、次行ってくれるか？
125:デフォルトの名無しさん
09/02/17 01:12:52
ポールグレアムのエッセイで、似たようなことが述べられている
テーマは100年後の言語だが、
計算機資源の無駄遣いもある程度許されるという点では、LLの環境は近い
URLﾘﾝｸ(practical-scheme.net)
126:デフォルトの名無しさん
09/02/17 01:39:26
クラスも継承も仮想関数もテンプレートも例外も名前空間も1960年代の言語にあったし、
なんつーか進歩ねーよな。まあ所詮コンピュータ動かすための文脈的設定ファイルだから
もうやることもねーんだろうけど。コンピュータ言語って数千種類くらいあるんだったっけな。
あとは、ぱくりだらけの俺流に実装しましたみたいなオレオレ糞言語が湧いてくるだけだな。
127:デフォルトの名無しさん
09/02/17 01:42:35
>>126
上から目線と下層階級の臭いが
良い感じにブレンドされたレスだな。
128:デフォルトの名無しさん
09/02/17 02:02:51
人間の脳力を取り扱うのは、もはや計算機科学ではなく、
既に医学や心理学の担当だったりして
手続き型の言語は、もう概念だけ全部まとめてしまって、後の言語のデザインは、
心理学者とラット（プログラマ）に任せちゃえばいいじゃないか？
129:デフォルトの名無しさん
09/02/17 02:06:08
計算機科学が人間の脳力を取り扱ってた時代なんてあったっけ？
130:デフォルトの名無しさん
09/02/17 02:15:41
生産性と読み替えれば、
ソフトウェア工学で扱ってる話題に持ってけるんでは
131:デフォルトの名無しさん
09/02/17 02:15:51
>>126
falseと0を比較するためだけに演算子を追加するという
誰もが想像しなかった進化をした言語があるじゃないかwww
132:デフォルトの名無しさん
09/02/17 05:06:08
>131
どれ？
133:デフォルトの名無しさん
09/02/17 06:40:40
SQLのことだろうか
134:デフォルトの名無しさん
09/02/17 07:44:15
>>127
脊髄にびりびりきちゃった？
135:デフォルトの名無しさん
09/02/17 10:41:51
何を持ってLLと定義するかの議論が欠落してるために堂々巡りかつ水掛け論の様相を呈しているような気がする。
136:デフォルトの名無しさん
09/02/17 11:28:32
外人的には俺らの開発したスクリプト言語に、LLとか名前付けられても・・ばかなの？って
感じなんだろうな。まあ日本のごく一部の人が勝手に言ってるだけだからそもそも知らないだろうけど。
137:デフォルトの名無しさん
09/02/17 11:40:28
心配しなくてもはやってない
138:デフォルトの名無しさん
09/02/17 12:16:28
流行ってないものに、そうそう書籍が出るかよバーカ
139:デフォルトの名無しさん
09/02/17 12:50:32
書籍？何言ってんだこいつ
140:デフォルトの名無しさん
09/02/17 13:50:58
LLなんとかってタイトルの書籍が幾つも並んだ棚を
脳内書店で見たことがあるんだろうな
141:デフォルトの名無しさん
09/02/17 13:55:33
ああ、そっちの方か。”LL"のことね
142:デフォルトの名無しさん
09/02/17 20:40:04
"LL"は今のところRubyだけでいいよ。
国産だし、言葉も国産。Matzだしw
外国の人がつくった数多くの既になじみの言語に"LL"とか今更名前つけてみたところで
これから世界的に流行る見込みなし。
143:デフォルトの名無しさん
09/02/17 20:40:59
ここで華麗にDan Kogai登場
144:デフォルトの名無しさん
09/02/17 21:04:07
LLってLightWeight Languageの略ですよね。
でもLLと呼ばれる言語は総じて、むしろ重い…。
何でLLなんて呼ぶんだろ？と思ったんですが
もしかしてLightなのはプログラマの書くコードの量ですか？
145:デフォルトの名無しさん
09/02/17 22:52:25
本来のスクリプト言語の比較・検討スレと内容がずれるし荒れるだけだから、
スレタイからLLとかはずすべきだろうな。
次スレ立てる奴のセンスに期待
146:デフォルトの名無しさん
09/02/17 23:05:50
パートスレでスレタイ変えたら分かりづらいし、変える必要なんてないだろ
それに、”LL”なんて呼称に粘着しているのは、
FOTRANか、COBOLプログラマで、LLを必要としないだろう人たちだし。
147:デフォルトの名無しさん
09/02/17 23:19:17
スクリプト系言語って書くと長い
略称自体が軽量ｗ で、短く書けるLLで良いかなと思ってる
何か厳密な議論をしたいなら、もっとふさわしい単語を持ち出さなきゃとは思うけど
148:デフォルトの名無しさん
09/02/17 23:26:15
>FOTRANか、COBOLプログラマで、LLを必要としないだろう人たちだし。
LL脳ってすごいね。
149:デフォルトの名無しさん
09/02/17 23:26:47
この世はLLすら使えない時代遅れの馬鹿ばかりとな。
150:デフォルトの名無しさん
09/02/17 23:29:00
LLを使っていると最先端のプログラマって感じがするよなw
C++以前のプログラマにはLLの生産性の素晴らしさ理解できないであろう。
151:デフォルトの名無しさん
09/02/17 23:30:16
>>148
後ろに脳つければいいってもんではない。
その「LL脳」は「LL」より痛い。
152:デフォルトの名無しさん
09/02/17 23:31:00
実はC++などが満足に使えなかった奴の逃げみ(ry
153:デフォルトの名無しさん
09/02/17 23:31:41
LL脳さっそく必死だなwww
154:デフォルトの名無しさん
09/02/17 23:44:32
>Groovyとは ...
>Python,Ruby,Smalltalk等の多くの機能がインスパイヤされ、
>Java開発者がJavaのような構文で使用可能にしたJavaプラットホーム用の アジャイルダイナミック言語 です。
アジャイルダイナミック言語か。
155:デフォルトの名無しさん
09/02/17 23:46:02
> アジャイルダイナミック
厨ｶｺｲｲ
156:デフォルトの名無しさん
09/02/17 23:47:28
C++を満足に使えるプログラマなんて、そんなにいない
157:デフォルトの名無しさん
09/02/18 00:52:33
Rubyコミュニティの連中だけだろ。
LLなんつって胸張ってるのはｗ
158:デフォルトの名無しさん
09/02/18 00:54:57
Larryもきてるんだがな
LLなんたらつーイベントに
159:デフォルトの名無しさん
09/02/18 00:59:30
来ればアニメのDVDBOXあげるよって言われたんじゃね
160:デフォルトの名無しさん
09/02/18 01:09:14
ここのLLという用語談義はアンチが気持ち悪すぎる
日本人が作るモノやること全て嫌いならさっさとアメリカにでも移住すればいいのに
161:デフォルトの名無しさん
09/02/18 01:44:57
>>160
> 日本人が作るモノやること全て嫌いならさっさとアメリカにでも移住すればいいのに
その通りだな。そんな奴は日本を出て行ったほうがいい。
ただ問題は、誰も「日本人が作るモノやること全て嫌い」なんてことは言っていなくて、
あえて言うなら「馬鹿な日本人が作るモノやること全て嫌い」という立場に立っていて、
この場にいない「日本人が作るモノやること全て嫌いな奴」を無意味に語ってふんぞり返るお前は
まさにその「馬鹿な日本人」に含まれるってことだ。
162:デフォルトの名無しさん
09/02/18 02:49:05
この人は馬鹿って言葉で昔ひどく傷ついたりしたんだろうか
163:デフォルトの名無しさん
09/02/18 02:57:55
馬鹿な発想だな。
164:デフォルトの名無しさん
09/02/18 09:57:34
現実問題として、最も普及しているLLは
PHP・Javascript・Actionscriptだろう。
結局、用途限定なのがいいということだね。
そして全部Web関連。
で、それで出来ないことはJavaでやると。
RubyとPythonは何でもできるけど、
上記３つに比べると普及していないといえる。
アイデアなんだけど、RubyとPythonは
思い切ってWebを捨てたらどうかと思う。
で、C/C++のヘルプ的な言語になればいいと思う。
165:デフォルトの名無しさん
09/02/18 09:59:07
例えばC言語だとめんどくさくて
C++だと難解すぎることを
C言語＋Rubyでやれば
簡単に出来るようにするとかさ。
166:デフォルトの名無しさん
09/02/18 10:17:41
ごめん、俺スクリプトは好きだけど、LL、LL言ってる奴は正直ちょっとキモイ。
あと自称アルファーなんとかとかのWebプログラマーとかは、電波だなあと感じるけど。
俺の周りの奴もそんな感じに思ってるし、それくらいの感覚が普通じゃね？
167:デフォルトの名無しさん
09/02/18 10:29:07
おまえら、熱いよな。俺なんてFlashやれって言われたからActionScript、ツール作れって
言われたからC++、サーバやれって言われたからPHPって感じで必要に迫られてやってるだけで、
言語とかに全然こだわりないんだが。結局なにかしかやらないできないとかが焦燥感なんだろうな。
168:デフォルトの名無しさん
09/02/18 12:11:17
>>167
何が言いたいのかよくわからんが、例えばお前が仕事でたった１種類の言語しか触れなかったとするじゃん。
んで、なんか知らんがこき使われて、一日18時間ほどそればーーっかりいじってると。２年くらい。
そんで毎度毎度のことで飽きてきたりすると、よその言語ではどうなってるのかとか気になったりするべ。
もしそれが５年くらいになったら、そりゃ他の言語を全く触ってない知らないっていう焦燥感も出てくるわな。
そう言う意味？
169:デフォルトの名無しさん
09/02/18 13:05:32
>>164
ActionScriptってJavaScriptの方言なんじゃない？
>>167
>ツール作れって言われたからC++
たぶんだけど、自分用のツールを作るか、日常の諸処雑多なことをするのには便利だよ
そんなものもC++で書いた方が早いってなら別だけど
Winユーザしかいない悪寒
170:デフォルトの名無しさん
09/02/18 13:32:04
>>169
横レスだけど、ASはバージョンによって違う。
AS2はほぼjavascriptと一緒。
AS3はちょっとJAVAっぽくなった。型付けが厳しく求められたり、、、
そしてMSの陰謀によってECMA標準から外れてしまった。
171:デフォルトの名無しさん
09/02/18 14:17:34
>>164
おまえの世界がWebしかないんだろ。
だいたい、C++自体はマルチパラダイムで処理系もライブラリも
ブクブクと膨れ上がっているのに、そのヘルプ的な役割を果たすとか意味が分からない。
品質よりも速度を重視するためのものなんだってば。
172:デフォルトの名無しさん
09/02/18 14:35:11
> RubyとPythonは
> 思い切ってWebを捨てたらどうかと思う。
そもそも汎用言語にWebを捨てたらって何を指すのか分からん。
PHPが急激に伸びたのもなんちゃってPGレベルでも食っていける市場を開拓したからだろ。
173:デフォルトの名無しさん
09/02/18 15:03:12
PHPはWeb特化だな
RubyはPerlと同じくテキスト処理が得意分野じゃね
イテレータとかがちょっと豪華になってるけど分野は被ると思う
Pythonは良くも悪くも汎用スクリプトって感じるが
LinuxだとちょっとしたGUIツールがPython製だったりすることが割とある
174:デフォルトの名無しさん
09/02/18 15:34:27
>>173
このレス見るの何度目だろうｗ
175:デフォルトの名無しさん
09/02/18 16:43:56
LLの印象。
perlは元々がテキスト処理向けだったのに、pythonやrubyみたく、
グルー言語の方向を目指してご乱心。毎日触っていたら、ものの数秒で痒いところに手が届く。
pythonは、テキスト処理は弱い気もするけど可読性は良い。
rubyだと、いい感じにテキスト処理も糊としても使える。オブジェクト指向の度合いが強い。
実行速度やユーザ数、ユーザの質、ドキュメントの量では、上２つに劣っている。
Groovyは、今後ともJVMでしか動かない。
JavaScript。方言が一杯。
PHP。馬鹿でも、ご飯が食べられる。
Haskel。とても頭の良い人たちが、かしこいことするのに向いている。
土方には門前払いだし、知る必要がなければ、知ってどうにもならない。
最強の定義:＝>ご飯が食べられる(日本)
PHP>Perl>>Ruby>>>>>>Python>>>>>>>>>>>>>Haskel
176:デフォルトの名無しさん
09/02/18 18:23:03
Haskellは無限リストが扱いやすいかな
「1〜無限大の中で、条件にあてはまる数のn番目は？」なんてことをそのまま書ける
ちょっと触った限り、使い道はそれしか思いつかなかったけど
まあ特化言語と考えたら悪くないんじゃない？
177:デフォルトの名無しさん
09/02/18 18:41:33
特に歴史認識がひどい。
178:デフォルトの名無しさん
09/02/18 18:55:04
>日本人が作るモノやること全て嫌いならさっさとアメリカにでも移住すればいいのに
これがLL脳の恐怖というやつか…。
誰もそんなこと言ってないのに、そこまで拡大解釈、極端な思想に走れるんだ。
179:デフォルトの名無しさん
09/02/18 19:01:18
今更"LL"なんていう日本でしか通用しない用語を蔓延させようとしている連中の方が
よっぽど日本のためにならないし、日本的なものが嫌いだと思うが。
Lightweight Languageなんていわずに、すなおに日本語らしい語呂で広めりゃいいのに、
そこまでして英語圏の文化にしっぽふって、猿まねしながらあこがれているのかと。
180:デフォルトの名無しさん
09/02/18 19:05:11
>>175
最後の行、馬鹿が手を出しそうな度合いでそのまま通用するぞw
181:デフォルトの名無しさん
09/02/18 19:14:43
>>167のいってることは正論だよな。
ソフト開発のプロが、たかが言語ごときでぐたぐたいってる。
そりゃそいつの能力だか脳力がやばいだけだ。
回路設計屋のおれですら、スクリプト言語だけで5種類以上はやれるのだから。
面倒なハードのデバッグにもなかなか使えるのよ。
182:デフォルトの名無しさん
09/02/18 19:44:43
>>180
馬鹿って、自分にとって必要ないことを学習する人のこと
>>181
休暇中のボンクラ学生だとは考えないの？
183:デフォルトの名無しさん
09/02/18 19:47:45
学生なら未来があるからまだマシだ。プロだったらむしろやばい。
おれも暇な学生のときにコンパイラの設計とかの本読んだりしてたおかげで、
マッハで言語が頭にはいるようになったわけだからな。HDLとかでもコード書くわけだし。
184:デフォルトの名無しさん
09/02/18 20:05:14
マッパで言語が頭にはいるだと…
185:デフォルトの名無しさん
09/02/18 20:40:33
>>179
簡易言語？
186:デフォルトの名無しさん
09/02/18 20:50:12
「軽量」っていうとまたファビョる人が多いからな・・・
187:デフォルトの名無しさん
09/02/18 20:51:05
>>183
手続き型なら、どれも基本的な部分は同じじゃない？
関数型や論理型も同じように理解できるならすごいけど
>>185
軽量言語じゃ？
日本がどうとか、ホント、どうでもいいよ。
188:デフォルトの名無しさん
09/02/18 20:51:53
まあ、「軽量」はなあ。
なにが軽量なのか一聴して混乱するし。
189:デフォルトの名無しさん
09/02/18 20:58:51
未来永劫日本以外で仕事をしない人はあまり気にならないのかもな。
190:デフォルトの名無しさん
09/02/18 21:03:52
RubyもPythonもスクリプトの中じゃファットな部類だと思うけどな。
191:デフォルトの名無しさん
09/02/18 21:07:25
高位言語
192:デフォルトの名無しさん
09/02/18 21:07:45
もうお手軽言語でいいよ
英語で Convenient Languages ？
ダサいかも
しかしここで新しい呼び方を決めたとして、結局世間ではLLが使われ続けるわけだがなｗ
matzやdan kogaiが使い続ける以上、たぶん
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5327日前に更新/221 KB
担当:undef