08/05/12 17:54:56
それ言語じゃなくてfontじゃｗ
370:デフォルトの名無しさん
08/05/12 18:01:28
>>369
シェイクスピア言語の向こうを張るためには、連綿くらいしないと。
371:デフォルトの名無しさん
08/05/12 18:04:08
シラフでは決して通らないコンパイラとかね。
372:デフォルトの名無しさん
08/05/12 18:07:23
美は乱調にあり。ですか。
373:デフォルトの名無しさん
08/05/13 15:40:07
2ch風(実は帝国陸軍風)に。
美ﾊ乱調ﾆあり。
これを、Prologをアセンブラとして、
美ﾊ乱調ﾆあり。 -> 美(乱調).
に落とす。なんていうのはどうですか。
奥行きがありそうだと思いませんか。
374:デフォルトの名無しさん
08/05/14 07:03:30
意味判らんが、エンコードに失敗してる
375:デフォルトの名無しさん
08/05/14 07:34:31
>>374
おちゅーしゃ ってEUCの半角エンコードしないのかな。
376:デフォルトの名無しさん
08/05/14 07:38:51
美(乱調).
乱調(美).
あり(美,乱調).
いろいろあるね。こういうの奥行きがあるっていうw
377:デフォルトの名無しさん
08/05/14 09:51:45
>>376
Prologもそんな風に積み上げていくと、着物の文様ようで
美しいじゃないか。
378:デフォルトの名無しさん
08/05/14 09:52:30
文様のようで ね
379:デフォルトの名無しさん
08/05/14 10:16:29
「李太白憶奮遊詩巻」のようなものはさすがに難しいが、
最終的にはプログラムも「墨跡」のようなものになって
行くのではないか。
380:デフォルトの名無しさん
08/05/14 12:59:15
>>379
3D-Visulan っていうのがある。私は使えないが。積み木を重ねて、
グラフィック制御を定義する。ちょっと可能性を感じる。
墨跡ということになると、量子プログラム言語などというキャチフレーズが
付きそうだが、50年くらい遅れてる。
381:デフォルトの名無しさん
08/05/15 03:34:11
そりゃ、単にアナログプログラミングだ。
382:デフォルトの名無しさん
08/05/16 18:13:12
まあ兎に角、シェイクスピアには触発される何かがあることは確か。
美しいとは思わないけれど。
383:デフォルトの名無しさん
08/05/20 20:36:41
間違いなくRuby
384:デフォルトの名無しさん
08/05/20 20:58:44
>>383
無限ループ
>>333,335-336,343,345,349-350,383
385:デフォルトの名無しさん
08/05/20 22:07:06
C#
386:デフォルトの名無しさん
08/05/20 22:49:28
美しさに拘るならやっぱ色々言語を使ってみて
最終的には俺言語を自作する所までやるのがいいのかもしれないね
387:デフォルトの名無しさん
08/05/20 22:54:55
最も美しい美人は誰か？ と問うに等しい。
388:デフォルトの名無しさん
08/05/20 23:49:44
私も僣越ながら「究極的に美しい言語を作ってやるぜ！」と野望を抱いていましたが、
PrologやBrainfuckのことを知って「この美しさは超えられない！」と諦めました…。
389:デフォルトの名無しさん
08/05/21 07:44:01
>>388
これって究極の宣言型と手続型言語なんだね。それなら、
手続型部門: Brainfuck
宣言型部門: Prolog
OOP部門: Smalltalk
審査員特別賞: Shakesphere
でどんなもんだろう。
390:デフォルトの名無しさん
08/05/21 08:26:05
Brainfuckが手続型部門というのはどうなんだろ…
それにパズル部門？とするならWhitespace の方が「美しい」と思う。
あと、関数型のHaskellもはずせない。
391:デフォルトの名無しさん
08/05/21 08:35:42
>>390
Brain* は確かに少し無理があるか・・。
OOを取り入れるとどうしてもゴツくなってしまって
見た目の美しさは失われるから、公平に評価し難い。
これは別にOOP部門を設けたい。
Haskell 美しいかなぁww
392:デフォルトの名無しさん
08/05/22 09:54:17
Grassも美しい
393:デフォルトの名無しさん
08/05/24 04:22:45
>>389
>宣言型部門: Prolog
ﾌﾟ
394:デフォルトの名無しさん
08/05/25 11:46:27
理屈を付ければ通る、的な言語はいやだね。
関数型にもあるけど。
395:デフォルトの名無しさん
08/05/25 12:06:44
理屈馬鹿の言語、効率馬鹿の言語、省略馬鹿の言語、矯正馬鹿の言語とある中で、
やっぱりRubyのバランスの良さは飛び抜けてるね。圧倒的に美しい。
既存の様々なコードもさることながら、アンチのレベルの低さもまた、逆説的にその証明になってる。
他の言語はアンチの言い分にもそれなりに「見るべきところ」があるわけだけど、
Rubyのアンチは勘違いからくる言いがかりと人格批判だけ。欠点がまともに指摘されることが殆ど無い。
勿論この世に完璧な言語など無いが、それでもRubyの欠点を「正しく」挙げるのはそれほどに難しい。
これはすごいこと。現状、神の言語に最も近いのがRubyだ。
396:デフォルトの名無しさん
08/05/25 13:51:14
なんだろう…これが既にアンチに見えなくも無い俺は病気なのか
397:デフォルトの名無しさん
08/05/25 15:46:19
神の言語に最も近いのがRubyだ。
神の言語に最も近いのがRubyだ。
神の言語に最も近いのがRubyだ。
神の言語に最も近いのがRubyだ。
神の言語に最も近いのがRubyだ。
398:デフォルトの名無しさん
08/05/25 16:17:07
やっぱA言語(APL)だろw
予約語の少なさは他の言語も
見習うべきだ。
399:
08/05/25 16:17:47
Rubyの英語版のWikiにruby作った人の写真があるけど不細工だな。
ていうか外人ってわざと日本人の不細工に写ってる写真使う気がする。サッカー選手とかでも感じる。
400:デフォルトの名無しさん
08/05/25 16:25:09
被害妄想乙
401:デフォルトの名無しさん
08/05/25 16:40:29
>>399
神を馬鹿にするな！
402:デフォルトの名無しさん
08/05/25 16:47:24
やっぱIoだろw
予約語がないところは他の言語も
見習うべきだ。
403:デフォルトの名無しさん
08/05/25 16:56:46
予約語無いと最適化の邪魔になりそうだからバンバン予約語作ってくれたほうが嬉しい
404:デフォルトの名無しさん
08/05/25 18:25:45
FORTRANにも予約語はなかったな。
405:デフォルトの名無しさん
08/05/25 19:37:01
>>403
普通予約後が少ない場合は演算子なり記号に
置き換わるだけだから別に最適化の役にはたたんだろ…。
予約語が多いと使えるシンボル名が減ってウザス。
COBOLのPICとPICTUREとかまったく同じ意味なのに予約語とかアホかと
406:デフォルトの名無しさん
08/05/27 13:14:13
なでしこ
407:デフォルトの名無しさん
08/05/28 17:26:33
他の事を書こうとしたが>>406で納得してしまった
408:デフォルトの名無しさん
08/05/28 19:51:22
ラムダ計算
409:デフォルトの名無しさん
08/05/29 00:13:12
>>408
そういう名前の言語があるの？
410:デフォルトの名無しさん
08/05/29 09:26:26
これ以上分解できない最小の単位というのは美しい。
よってマシン語が美しい
411:デフォルトの名無しさん
08/05/29 10:10:31
これ以上分解できない最小の単位というのは美しい。
よってCPUロジックが美しい
冗談はさておき、ペンティアム系の、86系に増築しまくった歪なマシン語がとても美しいとは思えない。
412:デフォルトの名無しさん
08/05/29 15:51:03
増設された年代別に分けて見るよろし
413:デフォルトの名無しさん
08/05/29 16:36:59
>>411
>よってCPUロジックが美しい
つ[論理ゲート]
414:デフォルトの名無しさん
08/06/02 01:09:20
>>411
そこで、Cellですよ。
415:デフォルトの名無しさん
08/06/04 10:15:37
簡潔なものを美しいとするグループと、
複雑でも筋の通ったものを美しいとするグループがあるらしい。
416:デフォルトの名無しさん
08/07/21 15:20:31
混沌に美しさを感じるアナーキストはどうすればいいですか
417:デフォルトの名無しさん
08/07/21 19:02:50
>>416
>>367 以下ではだめですか。
418:デフォルトの名無しさん
08/07/22 00:01:39
Malbolgeがあるじゃないか
419:デフォルトの名無しさん
08/08/24 04:37:17
どうやっても言語に高度な機能を載せていったら結局C++みたいになる
しかないと思うが。
Class obj;
obj.Func();
オブジェクト作ってオブジェクトを操作するのってこれ以上簡潔な
記述方法ももうないわけで。最近の言語は大体みんなこうでしょ。
ヒープに作る言語は
Class obj = new Class;
obj.Func();
とかだけど、書くのめんどうだし速度も遅いしそういうJavaの欠点を
C#はまたC++みたいにスタック生成もできるとかに修正してるよね。
テンプレートを付けると
Class<int> obj;
obj.Func();
これも最近の言語はどれも同じだし、関数も
Func(Class obj);
だけど、これに変更不可とか値渡し参照渡しを機能として付けると
Func(const Class& obj);
Func(readonly Class obj by ref);
とかにするしかないわけで、Javaとかconstなしとか機能削減すれば
もちろんより簡単に書けるわけだけど、当然その分性能が悪くなる。
んで、CとかC++の読みづらいソースとかはライブラリとかに依存する
部分がほとんどな気がするよ。LPCTSTRとか自社マクロが大量に定義され
ちゃっててCreateWindowなんて引数が大量でそらで書くのはほぼ無理みたいな。
上の方にも書いてあったけど、今どきは言語の機能/文法なんかほぼどれも似たり
よったりで大差なくってそんな重要なことじゃなくってさ、それよりOSが提供する
機能が簡単に使えたり、その他アプリケーション作るために必要な大量にある
ライブラリ機能とかがどれだけ豊富で(Win32とか.NETとかCPANとか)、いかに
簡単に使えるかとかが重要だと思うんだが。
420:デフォルトの名無しさん
08/08/24 06:21:43
LispやPrologはどうなんだい?
機能と美しさの関係をどう考えているのかな。
20世紀の歴史をもう一度見直した方がいいんじゃないか。
421:デフォルトの名無しさん
08/08/24 07:10:12
機能と美しさねぇ。ソフトウェアを作る上で必要な概念ってあるじゃない？
プロセスとかスレッドとかファイルとかXMLとかウィンドウとかDBとか
いろんなパーツがさ。こういったのをうまく抽象化できて生成削除が
うまく扱えて、それぞれをうまく繋げることができて、総合的には
容易にアプリケーションを構築できて、新しい概念や変更が発生した場合にも
うまく繋ぎかえることが可能なものが上手というか美しいのかなとか思ってる
程度だけど。
foreachとかlambdaとか高階関数とかも言語ごとにいろいろあるけどそれほど
本質的な話でもないかなと。あるともちろんいろいろと便利だとは思うんだけど、
それよりも現実的にはUnicodeはきちんと扱えるんですか？とかの方が重要だったり。
歴史を見直すって具体的にはどう見直してなにを見出したいんだ？
おおざっぱには20世紀はC++/Javaみたいな大衆向け現実指向言語がlispなり
prologなりを圧倒した感じがしてるけど。
RubyなりPythonなりは動的機能とかがあるけどC++/Java/C#と概念にあんまり
違いを感じないんだが。
422:デフォルトの名無しさん
08/08/24 07:29:00
機能を徹底的に追求すれば、自ずと美しさがそこにあるという確信だけど。
それを追求しきれずに終わったのが20世紀だという意味。
ここでいう機能は「無駄を省く」という概念を含んでいて、その点で
あなたの挙げた言語群は機能的な美さへ持っていない。
C#はC++よりまし、というような言い方はできるが。
423:デフォルトの名無しさん
08/08/24 07:44:43
うーん、その機能を追求すると結局C++みたいな方向にしかならん気がするん
だよね。細かいとこは修正できるかもしれんけどさ。
プロセスを作りたいと。
Process p;
p.Create("hoge.exe");
ウィンドウを作りたいと。
Window w;
w.Show();
これ以上簡単に表現できる必要もさしてないわけで。
そしてこのへんの表現方法は言語よりもライブラリの設計が担ってるわけで。
ただまあオブジェクト指向以外の方向だとまた違うかもしれないけど。
でもオブジェクトみたいに状態を持たせずに例えばウィンドウとかを管理
するのって難しくないかな？
424:デフォルトの名無しさん
08/08/27 07:10:43
C++は言語自体よりもMSのぐちゃぐちゃなライブラリ(Win32/MFC/ATL/COM・・)が
だめぽだと思う。
文字列を表す型が_bstr_t/CComBSTR/CString/char*/wchar*/std:string/
std::wstring/OLECHAR*/BSTR・・
ボンクラどもがライブラリを設計するとどんな言語でもだめになる。
これからの言語は言語設計もだけど、それ以上にいかに使いやすい質と量が
そろったライブラリを提供できるかが重要だと思う。
425:デフォルトの名無しさん
08/08/28 08:03:04
要するにライブラリに登録されてる手続きとか関数を
縦に並べれば、抽象化された表現になり美しいといいたいんだね。
426:デフォルトの名無しさん
08/08/28 08:12:56
そしてC#が生まれた
427:デフォルトの名無しさん
08/08/28 08:39:26
バッチファイルが一番美しいってことになるね。
428:デフォルトの名無しさん
08/08/28 09:57:23
そういう意味では一つの概念には一つのやり方のPythonは美しいね
429:デフォルトの名無しさん
08/08/28 10:02:02
>>428
どういうこと? 少し詳しく説明してください。
430:デフォルトの名無しさん
08/08/28 20:26:41
>>428
最近はひとつのことでもいくつかの書き方が出来るようになったから、そうでもないけどね。
431:429
08/08/28 20:37:17
Pythonのコンセプトからいって、ライブラリの中身は誰が書いても
あまり変わらず書けるということはわかるけど、それを呼び出す側は
どうなるというのかな。
432:デフォルトの名無しさん
08/08/30 23:36:11
昔のモジュール型言語は見た目は悪いけどプログラムを読むのは楽だった
関数のネストが１，２個だったからね
オブジェクト指向は確かに見た目は綺麗に見えるけどただのパズルだよ
全体を既に把握してる場合は抽象化されたクラスは見やすいが
把握してない人間がソースをトレースしようとすると何重にもネストされた
関数郡が実行順位も不明確な状態で分散されてるごみの塊
433:デフォルトの名無しさん
08/08/31 13:44:47
>>432
何が何を呼んでいるか、
気にしないようにしよう（気にしなくても問題無いようにしよう）と、
潮流が変わったんだよ。
気にするのに疲れちゃったからね。
434:デフォルトの名無しさん
08/08/31 19:13:15
最も美しいプログラミング言語か
やはり、C++しか無いだろう
「華麗にして醜悪」「壮麗にして貧弱」
そんな相反する要素を持っているのはC++以外に無いしな
435:デフォルトの名無しさん
08/08/31 19:27:37
そっから華麗と壮麗をさっ引くと俺の知ってる C++ になるぜ。
436:デフォルトの名無しさん
08/09/02 19:15:37
華麗さと壮麗さは使用者のスキルに依存します
437:デフォルトの名無しさん
08/09/02 19:32:22
という事は純粋に言語自体が華麗で壮麗という訳じゃないんだね。
まあ C++ はそんな所だろうな。
438:デフォルトの名無しさん
08/09/02 20:36:40
芸術ってのは、やはり書き手の技能に依存するんじゃないだろうか。
弘法筆を選ばず
439:デフォルトの名無しさん
08/09/02 20:39:57
プログラム無関係だが、絵の上手い人はチョーク一本でも上手いわけだし。
こんな風に
URLﾘﾝｸ(kokuban.in)
440:デフォルトの名無しさん
08/09/02 21:22:15
チョークは芸術じゃないからね
441:デフォルトの名無しさん
08/09/03 23:49:28
じゃあ何なら芸術？
442:デフォルトの名無しさん
08/09/04 05:51:11
道具が芸術になることはないだろう。
443:デフォルトの名無しさん
08/09/06 22:35:27
forthだな
444:デフォルトの名無しさん
08/09/06 22:43:22
>>442
では美しいプログラミング言語は道具ではない(道具としては役に立たない)のかな？
445:デフォルトの名無しさん
08/09/06 23:05:10
forth はゲームみたいで良いね
446:デフォルトの名無しさん
08/09/07 10:24:18
>>444
話の流れが理解できない人は、無理して参加しなくてもいいよ。
447:デフォルトの名無しさん
08/09/07 12:35:13
C++ は美しい、という話の流れだと思ってたが・・
448:デフォルトの名無しさん
08/09/07 12:39:58
美は乱調にあり。
449:デフォルトの名無しさん
08/09/07 23:10:29
美しさという言葉が最も似合わない言語なら Java かな
450:デフォルトの名無しさん
08/09/07 23:48:24
機能美なら当て嵌まる
451:デフォルトの名無しさん
08/09/13 08:15:57
プログラミングしりとり
ｽﾚﾘﾝｸ(575板)l50
452:デフォルトの名無しさん
08/09/19 20:36:11
>>245
OOPの枠内で考えるからライブラリに目がいくのではないか？
453:452
08/09/19 20:37:51
なかったことにしてくれ
454:デフォルトの名無しさん
08/10/03 10:51:06
音楽だと不協和音が逆に美しかったりするだろ。
醜さの中にも美しさは見出せると思うんだ
455:デフォルトの名無しさん
08/10/05 10:48:41
真幸乙
456:デフォルトの名無しさん
08/11/28 16:06:31
テキストエディタの着色機能がでかなり変わると思う
457:デフォルトの名無しさん
08/11/28 16:36:46
Whitespaceだろう。
URLﾘﾝｸ(ja.wikipedia.org)
458:デフォルトの名無しさん
08/11/28 16:56:32
すでに>>5から既出・頻出なんだがな。
459:デフォルトの名無しさん
08/11/28 17:19:14
リストアップするスレじゃなくて自分の意見を書くスレだから、
別にその言語を推す何人目になっても構わないんじゃないかと。
460:デフォルトの名無しさん
08/11/29 00:28:55
Haskellってことでいい？
461:デフォルトの名無しさん
08/11/29 23:23:04
いいよ
462:デフォルトの名無しさん
08/12/01 10:05:16
重っ苦しいな。
463:デフォルトの名無しさん
09/01/20 20:45:00
96117515
80402966
28237893
29335028
49310357
07361287
0132343
464:デフォルトの名無しさん
09/02/02 03:41:47
javaで完全にクラスの呼び出しのみで出来たプログラムは綺麗に見えるけどな．
他人がそのソースを一目で理解するのは難しいが
465:デフォルトの名無しさん
09/02/03 22:39:52
>>464
所詮、その程度のプログラム
美しくはないな
466:デフォルトの名無しさん
09/02/10 14:50:27
Haskellにしても、OCaml,Ruby,Python,Java,C#などみんな。
Prologならappend一つで済むものを汚い!汚い!
467:デフォルトの名無しさん
09/04/01 23:25:06
inc
dec
set
clr
halt
jz [飛び先]
jnz [飛び先]
の7個の命令だけで出来た言語
チューリングマシン語を分解したようなやつ。
468:デフォルトの名無しさん
09/04/02 02:47:52
>>467
アセンブラ？ニモニック？
469:デフォルトの名無しさん
09/04/02 09:34:49
>>467
jz あれば jnz いらなくないか?
470:デフォルトの名無しさん
09/04/02 23:39:56
>>469
チューリング完全の必要最低限という意味なら不要。
対称性の為に入れた。
jnzを入れるか入れないかに対して大してこだわりはない。
471:デフォルトの名無しさん
09/04/03 02:05:01
>>467
ピュアリスプなら以下のオペレータで可能です
car cdr eq cons quote atom cond(if)
472:デフォルトの名無しさん
09/04/03 23:02:02
こだわりのない言語は美しいとは言えない
473:デフォルトの名無しさん
09/04/04 15:35:50
いいね（微笑
474:デフォルトの名無しさん
09/04/07 00:31:42
ねーよｗ
475:デフォルトの名無しさん
09/04/18 14:02:05
美しさではＨａｓｋｅｌｌが一番だと思ってます。
数学的な美しさを一番素直に表現できる言語かと。
ＩＯモナド使うと他の言語と変わらなくなってしまうけど・・・
個人的にはパターンマッチとガードさえあればif,caseも要らないと思ってしまいます。
言語仕様から排除して問題ないんじゃないかとすら思えて・・・
476:デフォルトの名無しさん
09/04/19 00:50:53
んな事言ったらdo構文こそいらない。
477:デフォルトの名無しさん
09/04/19 09:19:14
＞＞476
私もそれは思いますが、あれは必要悪かと･･･
478:デフォルトの名無しさん
09/04/20 18:13:48
>>477
美しさを評価しているのに必要悪ってなんですか。
479:デフォルトの名無しさん
09/04/20 22:15:11
>>478
何と言いましょうか。純粋関数型言語が手続き型言語と同じ順番に依存した処理をするために手続き型言語をシュミレーションする仕組み(モナド)の構文糖衣なんですよ。
純粋な関数型言語らしい書き方はとても美しいのに、手続き型をシュミレーションしないといけない場面(入出力・代入)がどうしても必要なばっかりに出来た一点のシミ。
Haskellの達人たちはそのシミを必要最小限に抑えられると聞きます。
でも、そういう欠点で言えば他の言語に比べて一番(仕様的に)不満の少ない言語だと感じています。
例えば、Smalltalkはオブジェクト指向言語では最高だと思いますが、メソッドは全てpublic。フィールドは全てprivete。変更不可と言うのが不満です。
Rubyはその点の不満は無いですが、Smalltalkと違い、if文等(+,-,*,/)の制御構文はオブジェクトではありません。
Haskellはもちろん、if文(正確にはif式)すらも関数で、+,-,*,/も関数です。モジュールなどでアクセス制御も不満な点はありません。
何より、アルゴリズムをもっとも素直に表現できる言語であるところが最大の魅力です。
480:デフォルトの名無しさん
09/04/20 22:47:52
qsort [] = []
qsort (x:xs) = qsort [a|a<-xs,a<=x]
++ [x] ++
qsort [a|a<-xs,a>x]
今更ですが、長文すみませんでしたm(__)m
クイックソートのコード載せて帰ります。
481:デフォルトの名無しさん
09/04/21 00:17:28
要するに全てをHaskellで書けば良いというわけだな？
482:デフォルトの名無しさん
09/04/21 01:21:27
ええと、私もまだ勉強中の身ですが、モナドもHaskellの文法ですので正確に言えば入出力や代入を必要としない処理(少なくともあまり必要としない処理)だととても美しいです。
IOモナドが無いと実行結果がばらばらで出力されてしまいます。(原理的にそうらしいです)
実際にはIOモナド使わないと結果が見れないのでばらばらで出力された所を見た事無いですが･･･
せめて、IOモナドとかを直接見ないですむ仕組みで(個人的にはRAD環境とか何かしらのラッパーとか）Window(X-System含む)アプリとか出力（や状態を保持する処理)の権化みたいなアプリを書ける仕組みがあれば完璧です。
483:デフォルトの名無しさん
09/04/21 01:30:54
何か、長文になる癖でもあるみたいです＾＾；
またまた済みません･･･
今後、なるべく短くなるように頑張ります。
484:デフォルトの名無しさん
09/04/21 03:49:26
よし、君が作るんだ！
485:デフォルトの名無しさん
09/04/21 07:27:51
私じゃ全然実力不足ですよぅ＾＾；
486:デフォルトの名無しさん
09/04/21 10:43:18
ruby の if とかは文じゃなくて式だよ
487:デフォルトの名無しさん
09/04/21 11:28:07
きたねえ言語だな
488:デフォルトの名無しさん
09/04/21 17:03:12
なんでもかんでも式ってのは一様性の観点からみて美しいだろｊｋ
489:デフォルトの名無しさん
09/04/21 20:02:12
>>486
あ、そう言えばどこかで聞いたような･･･
済みません間違いでしたね＾＾；
でも･･･何が不満だったっけ?
と、思い出してみたらRubyは(当たり前だけど)Rubyを動かす環境はオブジェクトじゃなかったのが不満だったんでしたっけ・・・
SmalltalkのOS(仮想OSであるSmalltalk）もオブジェクトで、分からないことはオブジェクトに聞け!!って環境は中々得難い体験でした＾＾
490:デフォルトの名無しさん
09/04/21 20:20:10
>>489
>SmalltalkのOS(仮想OSであるSmalltalk）もオブジェクトで、
>分からないことはオブジェクトに聞け!!って環境は中々得難い体験でした＾＾
Smalltalkは抽象度が高過ぎて、自分にはもどかしかった
汚い物を汚い物として直接触れないのも不便です
491:デフォルトの名無しさん
09/04/21 20:58:06
ええと、まあ・・・分かります。
私も何だかんだとDelphiやVC#メインですし＾＾；
でも、ここは｢美しい（ｒｙ
ある意味、抽象度を高めるのがプログラミング言語の歴史な訳ですし＾＾；
それを言ったらHaskellはSmalltalkよりさらに抽象度高いですよ?
492:デフォルトの名無しさん
09/04/21 21:40:04
ならLispの方が抽象度高いんじゃないの？
更に言えばWhitespaceやBrainfuckの方が・・・・
493:デフォルトの名無しさん
09/04/21 22:57:13
LispのS式って万能のデータ構造とか聞きますし、そうなのかも知れませんね＾＾
残念ながら、私はLisp挫折しているのでまだ分かりませんが･･･
来月辺り、littleSchemerを買って再チャレンジの予定です＾＾
ただ、私が思うに一般の人がプログラミング言語の美しさを理解できる限界がHaskellなんじゃないかと思っています。
数学の表記をほぼそのままコードに落とせますし。
私の想像ですが、Lisp系はさらにその上の抽象度で、一般の人より上の見方が出来る人じゃないと美しさを感じられないのではないかと想像しています。
WhitespaceやBrainfuckは・・・まだ入門すらしていないのですが、ラムダ計算をそのまま書ける言語っぽい雰囲気を感じますね･･･
どこかに良い入門サイトがあれば教えて欲しいです＾＾
494:デフォルトの名無しさん
09/04/21 23:01:59
>>491
抽象と書いたのは、やたらとモデル化したり階層化したがる事を言いたかったんだ。
Haskellはハードウェアの実装から遠いという意味では抽象的ですが、プログラムの
作り方は割りとダイレクトな言語だと思います。
495:デフォルトの名無しさん
09/04/21 23:02:47
Brainfuckはこの板に専用スレがあるからそこからVIPのWikiに行くといい。
λ計算なら寧ろ、grassじゃないかな。それも専用スレがある。
496:デフォルトの名無しさん
09/04/21 23:27:53
…と＾＾が多い文章は全く美しくない
497:デフォルトの名無しさん
09/04/22 11:54:22
つーか、Lisp程度で挫折するヤツが偉そうに限界とか語るなよ。
498:デフォルトの名無しさん
09/04/22 19:48:28
>>495
Brainfuckスレ見てきました。
限りなくチューリング機械に近い言語ですね。
これはこれで凄いです。
幾何学模様で確かに芸術的な美しさがありますね。
>>494
>やたらとモデル化したり階層化したがる事を
ああ、納得です。
家系図みたいに連綿と受け継ぐ傾向はありそうですね。
>>496
まだ書き込み始めて数日なので、ルールとか良く知らないのですが、…や＾＾は書かない方が良いのでしょうか?
一応、書かないように気をつけてみます。
>>497
アマチュアの日曜プログラマーの戯言ですので、あまり気にしないでください。
単純な関数程度ならLispでも書けますけど、プログラミング言語を知らない人が見ても理解できそうな書き方はHaskellの書き方だと感じたもので。
499:デフォルトの名無しさん
09/04/22 20:03:23
死ね
500:デフォルトの名無しさん
09/04/22 20:30:53
あなたらしさが出ているので…や＾＾は書いたほうがいいと思う
501:デフォルトの名無しさん
09/04/22 22:49:53
むしろ…と＾＾だけの言語を作ったほうが良いと思う
502:デフォルトの名無しさん
09/04/22 23:13:10
散々くだをまいといて「日曜プログラマです」とか恥ずかしくないのかね
503:デフォルトの名無しさん
09/04/22 23:17:27
>>498
それでPrologはどう評価するの？
504:デフォルトの名無しさん
09/04/22 23:50:44
>>503
“一般”の人には理解できないから駄目な言語ってんだろ。たぶん。
前提が間違っているととんでもない結論に至るな。
505:デフォルトの名無しさん
09/04/23 00:18:30
A ・・・ Axum ★
B ・・・ B言語
C ・・・ C/C++/C#
D ・・・ D言語
E ・・・ Erlang ★
F ・・・ F# ★
実際の世界は並列に動いている。
世の中をモデル化するときに並列という概念がプログラミング言語に備わっていれば
美しくプログラムをかけるんじゃないかと。。。並列指向の★に期待。
506:デフォルトの名無しさん
09/04/23 01:13:03
アルファベット順というのは無意味だったので、パラダイムで整理するとこんな感じか。
構造化 ・・・ BASIC
オブジェクト ・・・ C++
関数型 ・・・ F#
並列 ・・・ Axum
だんだん下にいくほど美しくプログラムが書けるようになるのかな。
507:デフォルトの名無しさん
09/04/23 01:36:38
マイクロソフト以外だとこんな感じか。
構造化 ・・・ C/Perl
オブジェクト ・・・ C++/Java/Python/Ruby
関数型 ・・・ Ocaml/Haskel/Lisp/Scheme/Scala
並列 ・・・ Erlang
508:デフォルトの名無しさん
09/04/23 02:00:35
原点回帰 シェルスクリプト
■ソフトウェア・プロダクト・オブ・ザ・イヤー(R)2008
ユニケージ開発手法および同開発コマンドセット
URLﾘﾝｸ(www.ipa.go.jp)
■ユニケージ開発手法
USP(Ｕｎｉｖｅｒｓａｌ Ｓｈｅｌｌ Ｐｒｏｇｒａｍｍｉｎｇ)研究所は、
Ｌｉｎｕｘの基本思想である「小さな道具」（コマンド）を組み合わせて「問題を解決する」（シェルスクリプト）手法の研究・普及を行っています。
この手法（ユニケージ開発手法）は、Java、Oracleなどを用いた従来の「手引き型」開発手法と一線を画し、
★圧倒的な開発生産性
★圧倒的な柔軟性
を特徴としています。
URLﾘﾝｸ(www.usp-lab.com)
509:デフォルトの名無しさん
09/04/23 02:03:11
Lispはマルチパラダイム言語。
510:デフォルトの名無しさん
09/04/23 02:06:33
C++もね。
511:デフォルトの名無しさん
09/04/23 05:40:09
>>504
君が知らないだけだろ。なんで>>503のタイミングで持ち出したか
理解できていないようだから。
512:デフォルトの名無しさん
09/04/23 06:01:19
きみはプログラミング言語より日本語の勉強をしたほうがいいな
513:デフォルトの名無しさん
09/04/23 11:03:26
>>512
なるほど。>>504をよく読んでいなかった。ごめんなさい。
514:デフォルトの名無しさん
09/04/23 12:39:32
既出ならごめん
ニモニック
515:デフォルトの名無しさん
09/04/23 20:10:25
ちょっとわき道にそれるが、
>>508とも関連するが、
システムを作るときにDSLを作ることはよくある。
その際、システムに最適化されたDSLが作れたとき美しいと感じるときがある。
ある販売管理システムが
START
A 100 100
B 0 0
C
END
とかけてしまったら美しいと感じないだろうか。
システム作りでの美しさとはそのような抽象化でもありえるのでは。
まあ、このスレはその抽象化を行うのに美しく作業できる言語は？とうのが主題ではあるけれど。
516:デフォルトの名無しさん
09/04/23 20:38:05
>>499
これは･･･私に言っているのでしょうが何を不満に思ったのか書いていただかないと改善しようが･･･
あ、一応、私らしさが伝わるそうなので戻しますね?
書き方に不満があったら投票でもしましょうか＾＾；
Lisp知りもしないくせにとか言われると耳が痛いですが＾＾；
強力ではあると思いますが直感的ではないなぁ、と。
まだまだLispに数学的な美しさを見出すには修行不足のようです＾＾；
>>502
くだを巻いていた気はないのですが、気に障ったのなら謝ります。
自分を誇張表現するより、ありのままの自分で美しい言語とは?を話したいので正直に自分のレベルを明かしました＾＾；
>>503
ごめんなさいm(__)m
Prologは私の感性との相性が悪いみたいでどうも美しいとは感じていませんm(__)m
理由になっていないと言われるでしょうけど、変数が大文字で始まらなければならないのが、どうしても受け入れられません。
一階述語理論自体には興味はあるのですが、どうも変数が大文字で始まる言語だけは受け付ける事が出来ないようです。（なので、Erlangも同様な理由で受け付けられません＾＾；）
Javaにでも脳を侵されてしまっているな･･･とは感じているんですけど、駄目なんです＞＜
それでも論理型言語の何が魅力なのかちゃんと知りたいと思い、関数論理型言語Curryなるものに注目しています。
まだ、英語のチュートリアルを落としてざっと読んでもHaskellっぽくしか見えなくて、論理型言語の特徴を見分けるに至っていませんが、時間があるときにじっくり読んで勉強するつもりで居ます。
517:デフォルトの名無しさん
09/04/23 20:42:43
Javaばかりを悪者にしてはいけませんでしたね＾＾；
でも、今まで変数はずっと小文字で始めていたのでどうしてもそこを曲げられるのに抵抗を感じてしまいます＾＾；
518:デフォルトの名無しさん
09/04/23 20:47:44
日曜プログラマだから参加してはいけない！とは思わないけれど、
ある程度修練を積まないと見えない美しさって言うのは、
例えば、、、数学にだってあったわけじゃない？
だから、日曜プログラマでは見えてこない部分も有るってのに長文かよ、
みたいに思う人はいて当然かな。と思うよ。
だから俺はいつもROMってる。
519:デフォルトの名無しさん
09/04/23 21:04:49
近年稀にみるウザキャラ。
同年代の人間と会話する訓練でもしたほうがいい。
やっててこれなら周りもおかしいか、
おまえのおかしさを憐れまれているだけだ。
520:デフォルトの名無しさん
09/04/23 23:08:02
理系の学部とか院とかにたまにいるタイプ
521:デフォルトの名無しさん
09/04/24 00:08:43
What a wonderful world!!!!
522:デフォルトの名無しさん
09/04/24 00:26:27
Yet another decent diary!!!
523:デフォルトの名無しさん
09/04/24 07:28:39
>>518
ええ、高卒の私では見えない世界が一杯あると思います＾＾
家が貧乏でなければ大学に行きたかったですね･･･
なるべく短くなるように努力してみます。
>>519
私がウザイと思われているのは理解しました。
そんな些細な事よりも美しいプログラミング言語とは?についてお話して頂きたいです。
私と話したくないのであれば、私のコメントは無視して他の方とお話すれば良いのです。
524:デフォルトの名無しさん
09/04/24 08:54:07
>>523
俺はなんとも思わないけど
自分自身を主張する奴は2chでは嫌がられる。
コテが嫌われるのと同様に。
こういうスレならなおさら意見や考えを主張すればよいのであって、
自分自身を主張する必要はない。
反論するのは筋違いだと思うよ。
PCだけじゃなく携帯から見てる人もいるから、NGすればいいなんて言うのはナシね
525:デフォルトの名無しさん
09/04/24 08:55:34
毎度上げてるしね
526:デフォルトの名無しさん
09/04/24 09:15:08
つい最近まで、マ板の底も底、もうすぐ最下位というところにいたスレなんだから、
たくさん書き込んでもらえるだけでありがたいけどね。
527:デフォルトの名無しさん
09/04/24 09:19:57
ム板だったw
528:デフォルトの名無しさん
09/04/24 10:24:08
動くプログラムは全て美しい
これ言った人、もういないんだよな。
529:デフォルトの名無しさん
09/04/24 15:11:45
つーか、「Haskellに一票」と書けば済む話をなぜだらだらと長文で
他の言語にまでケチを付けて。周りをむかつかせて。馬鹿なの？死ぬの？
530:デフォルトの名無しさん
09/04/24 15:12:21
>>529
531:デフォルトの名無しさん
09/04/24 18:04:54
つーか、「perlに一票」と書けば済む話をなぜだらだらと長文で
他の言語にまでケチを付けて。周りをむかつかせて。馬鹿なの？死ぬの？
532:デフォルトの名無しさん
09/04/24 20:19:59
最強がHaskellで実用性はRuby
533:デフォルトの名無しさん
09/04/24 20:26:19
私の思う美しい。
1.その言語の背景になっているモデルや指向をどれだけ自然に表せるか?
2.記述の簡潔さ。読みやすさ。(思考とコードとの間の齟齬が少ない)
3.上記を保ったまま堅牢性を求めるプログラミングにも耐え得るか?
こんな感じで、Haskellに一票です＾＾
まだ、自己主張してますかね･･･
534:デフォルトの名無しさん
09/04/24 20:50:30
私は GHC
Haskellコンパイラではないよ。
535:デフォルトの名無しさん
09/04/24 21:03:50
あの国家規模でコケたやつか。そのGHCは現代の環境でも並列処理を活かせるの？
536:デフォルトの名無しさん
09/04/24 21:13:20
あ、私も言語としてのGHC気になります＾＾
PCでもコンパイラ使えますか?
良い入門ページもあれば教えて欲しいです＾＾
537:デフォルトの名無しさん
09/04/24 21:58:54
ハット記号を NG 登録で快適
538:デフォルトの名無しさん
09/04/24 22:01:18
わざわざ人の嫌がることをやる人間がプログラミング言語の美しさを語って、
誰がそんな奴の話を聞いてくれると思っているんだろう？
539:デフォルトの名無しさん
09/04/24 22:08:11
そこまで嫌がられていたのなら、もう消えます･･･
お騒がせして済みませんでしたm(__)m
540:デフォルトの名無しさん
09/04/24 22:22:00
>>535
並列処理自体がこれからですからね。 PSI II がないと
検証もままならないという状態は困ったものです。
541:デフォルトの名無しさん
09/04/24 22:50:05
>>523
ｲｲﾊﾅｼﾀﾞﾅｰ 頑張ろうな。
542:デフォルトの名無しさん
09/04/24 22:52:15
つーか、「Schemeに一票」と書けば済む話をなぜだらだらと長文で
他の言語にまでケチを付けて。周りをむかつかせて。馬鹿なの？死ぬの？
543:デフォルトの名無しさん
09/04/24 23:12:14
しつこいよ
544:デフォルトの名無しさん
09/04/25 12:25:41
>>539
少し目立つとケナすのが2chの文化です。
あまり気にする事はないです。
しばらく発言せずにあちこちのスレを覗く事をおすすめします。
これを2ch風に言い表すと以下の様になります。
「半年ROMってろ」
545:デフォルトの名無しさん
09/04/25 12:41:11
Scheme に一票．
546:デフォルトの名無しさん
09/04/26 00:21:17
Z80のニーモニック。
547:デフォルトの名無しさん
09/04/26 00:43:05
ニーモニックの読みやすさならそうだが直交性なら8080だな
てか6809はどうよ？
きれいにまとまってると思うぞ
548:デフォルトの名無しさん
09/04/26 07:38:08
>>547
もっと具体的に教えて。
抽象化してシステム記述言語がアセンブラっぽくなる可能性もあるわけで
参考のために知っておきたい。
549:デフォルトの名無しさん
09/04/26 08:09:03
80系はレジスタが目的別なので、一般的には汚いと言われるね。
6809は16bitを睨んだ為に若干直行性に掛けるが、68000になると寧ろ綺麗な作りだ。
550:デフォルトの名無しさん
09/04/26 08:50:20
>>549
直交性っていうのはどういうこと？似た命令がないってこと？
551:デフォルトの名無しさん
09/04/26 09:06:04
お前らコーディングの汚さを言語のせいにする前に
自分のプログラミングのスキルを磨け ボケ！
552:デフォルトの名無しさん
09/04/26 10:27:10
>>550
任意の演算に対して任意のアドレッシングモードが使える事を
直交性が高いって言う
add reg
add imm
ってな感じの, アキュームレータ決めうち命令の場合, 直交性はない
add reg, reg
add reg, mem
add mem, reg
てな感じの, 命令は直交性が高いと言う
一番直交性が高い命令体型を持っていたのは, おそらく VAX
その物まねの V60 あたりも直交性は高かった.
68k はデータレジスタとアドレスレジスタが別扱いだったので
VAX や V60 に比べると直交性は低い
553:デフォルトの名無しさん
09/04/26 10:36:56
>>552
なるほど。thnx
たしかに直交性が高いプログラミングの自由度があがって柔軟性がでるよね。
同じことをやる場合、直交性が低い方が見た目的には短いプログラムになるのかな。
自由度でいうと直交性が高いほうがいいけど、コードが短くなるなら
きめうちっていうのはある意味システムの抽象化が行われてるってことで場合によっては
美しい（短くてシンプル）なプログラムがかけそうな気がする。。。
554:デフォルトの名無しさん
09/04/26 10:42:26
Aが最強だろ
555:デフォルトの名無しさん
09/04/26 11:11:53
>>553
直交性が高い方が、おおむねコードは短くなる
前の例だと, 直交性低い場合こんな感じ
(index アドレッシングないと仮定)
load (r0), acc
add index
mov acc, r0
load (r0), acc
add r1
store acc, (r0)
高いとこんな感じ
add r0, index
add (r0), r1
556:デフォルトの名無しさん
09/04/26 14:56:43
Pascalですね
557:デフォルトの名無しさん
09/04/26 21:17:51
$記法を導入したという点で、並みいる関数型言語の中でも
Haskellは、より美しいといえると思う。
print (map last (a b (c d)))
↓
print $ map last $ a b $ c d
こんな置き換えが可能。
LISP系みたいに括弧だらけにならない。
558:デフォルトの名無しさん
09/04/26 23:29:21
$がきもちわるい
そんな記法ならLISPでもできるし
559:デフォルトの名無しさん
09/04/26 23:49:48
LiSPなんて旧時代のゴミだろwHaskellの美しさの足元におよばない
あらゆる意味でHaskellのほうが優れている
560:デフォルトの名無しさん
09/04/27 00:04:54
そういう変態構文のオナニーショーはLISPer個々でよくやってる事だよ
$記法とやらが読みやすいとはとても思えないし
561:デフォルトの名無しさん
09/04/27 00:16:16
みやすさって概念だったら表形式がみやすいのでは？
いっそのことExcelみたな表でプログラミングするっていうのはどう？表っていうのはリストの特殊形態であるわけだし。
562:デフォルトの名無しさん
09/04/27 02:02:58
($) がいつから記法になったの。ただの関数でしょ。
563:デフォルトの名無しさん
09/04/27 12:54:34
なんで過去の人工知能の研究者にリスパーが多かったんですか？エロい人教えて
あスレ違いか
564:デフォルトの名無しさん
09/04/27 13:10:26
LISPって他人が書いたコードを理解するのが極端に難しくない？
これは俺のアタマが手続き脳だから単に理解できないだけかもしれないけど。
565:デフォルトの名無しさん
09/04/27 13:38:54
>>561
Excelの表を「数式を置けるプログラミング・フィールド（ソースコード置き場）」とみなせば
かなり美しいプログラミング環境のような気もします。
プログラミング「言語」と呼ぶのは難しいでしょうか？
566:デフォルトの名無しさん
09/04/27 13:43:09
>>565
プログラミング言語かどうかは兎も角、環境としてはありだと思う。
実際、私のプロジェクトではそういうケースも多いし。
# アルゴリズムの検証をシート関数で行ない、それを元にC/C++で実装する。
そもそも、保存ファイル形式がXMLなんだしね。
567:デフォルトの名無しさん
09/04/27 13:47:28
>>565
表計算はもちろんプログラム言語だよ。
568:デフォルトの名無しさん
09/04/28 09:40:47
コーディングしないことが最も美しいのでは？
569:デフォルトの名無しさん
09/04/28 12:39:41
ニモニックかわいいよニモニック
570:デフォルトの名無しさん
09/04/28 14:44:14
Delphi prism - Delphiのグリーンスパンの第10法則に従った進化形ｗ
571:デフォルトの名無しさん
09/04/28 22:01:17
delphiというかpascalはピリオドの付け方がよく判らなくて嫌い
572:デフォルトの名無しさん
09/04/30 02:05:11
やっぱりHaskell lisp Smalltalk辺りかな。
例えば、Smalltalkなら、分岐制御、式ブロック、クラスが全てが
オブジェクト表現され、継承やクラス定義は全てメッセージングで表現される。
全てオブジェクトとメッセージ。こういう完結された仕様はやっぱり美しく感じる。
逆に、同じオブジェクト指向を謳うJavaの中途半端さと言ったら醜悪に尽きる。
あそこまで。バランスを崩すなら速度に特化したC++の方がまだ潔い。
Haskell lispは上の方で語られているから詳細は省くが、やっぱり美しい一貫性をもつ。
573:デフォルトの名無しさん
09/04/30 02:26:13
Haskell lispってなんだ。Haskell, Lispってことか？
574:ちんこ ◆GbXlaaQNk.
09/04/30 07:16:47
美しいのはPythonだけど、
使ってるのはJavaです。
結局、可読性が高くなるかどうかなんて、
実装者の能力次第です。
575:デフォルトの名無しさん
09/04/30 07:31:10
>>574
その言語を熟知している人にとっての可読性ではそうだが、
その言語を全然知らない人間にとっての可読性は言語仕様によるのではないか。
576:ちんこ ◆GbXlaaQNk.
09/04/30 07:36:12
可読性を上げる要因として、
主要はものは、
凝集度、結合度、明示的なネーミング
の３つである。
これらは言語とは全く関係ない。
凝集度が著しく低いコード、
不必要な結合性を生んでるコード、
意味分からん変数やメソッドがたくさんあるコード、
これらはどれも可読性が低い。
Cでも可読性の高いコードは書けるし、
Pythonでもゴミのようなコードは書ける。
言語への習熟度は、主要な言語においてはそれほど関係ない。
577:デフォルトの名無しさん
09/04/30 10:36:39
ToStringより、toStringがいいし、to_sが一番いい。
言語とその文化がもつ冗長性は美しさにかかわる。
578:デフォルトの名無しさん
09/04/30 11:06:36
>>577
sって何ですか、という疑問は？
579:デフォルトの名無しさん
09/04/30 11:13:55
to_i, to_f, to_aと並べて見せて、類推してもらう。
580:デフォルトの名無しさん
09/04/30 11:25:09
なんだかんだ言っても俺が見て一目で内容がわかる言語が美しいと言うことだろうな。
そんな言語はないけどね
581:デフォルトの名無しさん
09/04/30 11:27:52
どの言語も、汚いと思うのは意外と無いよね。
独自の文化には意外と慣れるから。
C#の命名も苦にならなくなる。
けど、phpとperlだけは馴染めなかった覚えが。
自分が使う期間が短かったのもあるけど。
582:デフォルトの名無しさん
09/04/30 14:56:42
>>580
Prolog
583:ちんこ ◆GbXlaaQNk.
09/04/30 16:50:51
>>577
それは小さな問題だよ。
結局は、可読性に対するきちんとした知識と実装力を持っているかどうか。
可読性という意味からいえば、toStringの方が高いといえる。
to_sではsが何を意味しているのか分からない。
もちろんRuby出身なおれは分かるけどね。
例えば、
おれに言わせれば、
ｽﾚﾘﾝｸ(tech板:567番)
のコード、これ書いたやつは死ぬべきだと思うんだけど、
なんでだか分かる？
このコード読んで吐き気を覚えないやつは
プログラミングをすべきじゃないよ。
584:デフォルトの名無しさん
09/04/30 17:02:18
おまいは名前のわりにしっかりしてるなｗ
> このコード読んで吐き気を覚えないやつは
すまんが、吐き気を覚えない。
java.util.Scanner使ったこと無いから、
それに関する部分は良く分からんし。
585:デフォルトの名無しさん
09/04/30 17:17:11
>>583
俺も吐き気を覚えない。
可読性はプログラミング言語の美しさとは関係ないと書いている（>>576）ので
これは「最も美しいプログラミング言語」とは関係ない話？
586:デフォルトの名無しさん
09/04/30 17:36:14
美しいものに吐き気を覚えることもあり得るのでこの話はスレ違い
587:ちんこ ◆GbXlaaQNk.
09/04/30 18:57:52
Scannerがどうとか言ってるんじゃないよ。
おれも使ったことないし、推測でscanfみたいなことかなと思ってるだけ。
おれはこのコードを見て、鳥肌がたち、書いた人間に殺意を覚えた。
おれがプログラムを書くものが読むことを必須とすると考えている本は、
Code Complete（上）
リファクタリング
実装パターン
の３冊だ。
他にもいい本は色々あるが、
とりあえずこの３冊を読まなければダメだ。
特にCode Completeは必須中の必須。
これが分からなくて、何を実装するというのだろうか。
可読性の低いコードは環境汚染に等しい。
無意識に可読性の低いコードを書く人間は、害悪。
おれは美しいコードを書くことについて強い興味を持っている。
そのおれが言う。
もっとも美しい言語はPythonだ、と。
そしてJavaプラットフォーム上で動くJythonを中心にこれからの世界は動き始めるだろう、と。
588:デフォルトの名無しさん
09/04/30 19:03:23
大仰な前フリはいいからｗ
ｽﾚﾘﾝｸ(tech板:567番)
の問題点を簡潔に示しておくんなまし。
> 鳥肌がたち、書いた人間に殺意を覚えた。
吐き気につづき、鳥肌、殺意とくれば、
興味深々になってしまって仕方ない。
ちなみに、俺が吐き気するコードは、
if (isRunning == true) と無用で余計なことをするものとか、
int flgっていう変数をヒョイと作って以下でグデグデ使うもの。
そんなもんかなぁ。
589:デフォルトの名無しさん
09/04/30 19:04:28
×吐き気する
○吐き気を催す
590:ちんこ ◆GbXlaaQNk.
09/04/30 19:13:36
と、言っても、
実装上そうしなければいけないのかも知れないということはある。
パっと見、形がおかしいということで吐き気を催しただけであることを断って、
その上でコードの気持ち悪さを指摘する。
それは、順番がおかしいことだ。
Scanner stdIn = new Scanner(System.in);
System.out.println("xとyを加減乗除します。");
System.out.print("xの値:");
int x = stdIn.nextInt();
この4行のうち、2,3行の段階ではstdlnという変数は必要ない。
4行目でやっと必要になるのだから、1行目を3,4行目の間に移すべきだ。
変数stdlnのライフタイムが不必要に長い。
これを見た時、おれは2行目のどこにstdlnが使われてるのか真剣になって探した。
当然あるべきだからだ。
変数のライフタイムが不必要に長くなることで可読性は落ちる。
結果としてバグが増える。
可読性の落ちる原因は、ある時点のコードを理解する上で、
脳のワーキングメモリに保存しておくべき情報が増えてしまうからだ。
上から下までさーっと読んで、
全部理解出来るコードじゃないとおかしい。
日本のソフトウェア業界のレベルが低いのは、
ちゃんとしたソフトウェアの教育を受けた人がいないからだ。
591:ちんこ ◆GbXlaaQNk.
09/04/30 19:19:40
>>588
flagを立ててそれを使うというのは、
可読性を落とすという要因から禁止されている。
何かの本に書いてあったから、おれの読んだ本を何年かかけて全部嫁、このクソ虫が。
また、flagというのであればbooleanにして欲しいし、
booleanの変数名には肯定的な名前をつけるというのもルールだ。
flagと言われても、何のことだか分からない。flgなんて論外だ。"a"を省略する意味が分からない。
勉強のために色々コードを読んできた。
どれもひどいものばかりだ。どいつもこいつも狂ってる。
おれが注目するのはすでに述べたとおり、
凝集度、結合度、明示的なネーミングの３つだ。
きちんと１つの仕事をする明示的な名前のついた小さなメソッドに分けることによって、
文を読むがごとく読めるようになってないコードはすべて吐き気がする。
おれがかなり好きなコードがある。
JUNGというソフトウェアのコードだ。
参考にするといい。
これを書いた人はかなり出来る。
592:デフォルトの名無しさん
09/04/30 19:19:57
そ、そんだけ？
593:デフォルトの名無しさん
09/04/30 19:21:00
このスレは、美しいプログラミング「言語」について書くスレです。
>>590 は「美しいプログラミング」について語っているので、
すれ違いだと思います。
594:デフォルトの名無しさん
09/04/30 19:29:11
ポール・グレアムが書いた文書（の翻訳）を読むと、
「LISP最高！Schemeって美しい！」と思うんですが、
いざ使ってみると、「なにこのカッコの多さ！ありえない！」
と思うんですよね（笑）
595:ちんこ ◆GbXlaaQNk.
09/04/30 19:37:40
美しいプログラミングが分からない人間が、
プログラミング言語の美しさの何を語ろうというのだ。
何も判断基準がないじゃないか。
そこにあるのは、感性だけだ。
ただ美しいと思った、それだけ。
プログラミング言語は芸術ではない。
美しいものには美しいだけの理由がある。
そういう、なぜ美しいかということが分かった上で、
美しさについて語りたまえ、このクソ虫どもが。
もし分からないのであれば、
おれのようなスーパーハカーのいうことを聞いて
Pythonを使ってればいいんだよ。
596:デフォルトの名無しさん
09/04/30 19:38:22
でもまぁ、確かにJavaは美しくないとは思った。
597:デフォルトの名無しさん
09/04/30 19:39:53
Scanner stdIn = new Scanner(System.in);
System.out.println("xとyを加減乗除します。");
System.out.print("xの値:");
int x = stdIn.nextInt();
これが、
System.out.println("xとyを加減乗除します。");
System.out.print("xの値:");
Scanner stdIn = new Scanner(System.in);
int x = stdIn.nextInt();
こうなったら吐き気収まりますか＞＜
598:ちんこ ◆GbXlaaQNk.
09/04/30 19:41:21
>>596
なぜだ。
なぜ、Javaが美しくないと考えたのか。
それが問題だ。
残念ながら、おれはJavaは最高に美しくはないものの、
それなりに美しく、かつ非常に生産性の高い言語だということで、
とてもお気に入りなんだ。
美しくなくはない、吐き気がするのはC++だ。
C++よりはCの方が美しい。
C++は言語仕様がどうとかいうより、
仕様の設計者はバカなのではないかと思うようなところがある。
599:デフォルトの名無しさん
09/04/30 19:44:02
>>598
具体的に、吐き気がするところは?
俺はクラス定義の中にメンバー関数の定義を書くと
それだけでインライン化するところは、馬鹿じゃないかと思った。
インライン化したければ「inline」と書けばいいのに。
600:ちんこ ◆GbXlaaQNk.
09/04/30 19:47:38
ごめん、実はC++はあまり知らない。
601:デフォルトの名無しさん
09/04/30 19:49:18
>>599
理由は違うが同意。inlineなんてのはコンパイラに対するヒントでしかないんだから存在意義自体がないと思う。
インラインかしたくない事情があれば、それを指定するようにすればいいんだ。
602:デフォルトの名無しさん
09/04/30 20:07:34
俺は変態的なもののほうが美しく感じる。
C++ サイコー Lisp マンセー チンコシネー
まじめに書くと、なんとか指向とか関数型なんとかなどとのたまう言語は醜くく感じる。
そうしたければそのように書くこともできる、というのは大事だと思う。
でも、そのスタイルを強制されるのはまっぴらゴメン。
で、必然的にハイブリッドなものに美しさを感じるようになる。
いかにブレンドするか、その美しさこそが真の美しさ。
603:ちんこ ◆GbXlaaQNk.
09/04/30 20:28:23
もうさ、
プログラミング言語はJavaで統一しようぜ。
全員Javaと最悪、Jython, JRuby, GroovyなどのJava実装スクリプトね。
Cを撲滅しようぜ。
Javaは実行速度だって、C++よりずいぶん速いんだ。
604:デフォルトの名無しさん
09/04/30 20:31:37
＞Javaは実行速度だって、C++よりずいぶん速いんだ。
なんだ、妄想癖の人だったのか。
605:ちんこ ◆GbXlaaQNk.
09/04/30 20:38:50
いや、事実だけど・・・。
今のJavaはまじで速い。
Javaが遅かったというのは過去の話。
今はCと変わらないレベルの速度が出る。
606:デフォルトの名無しさん
09/04/30 20:39:17
【レス抽出】
対象スレ：最も美しいプログラミング言語は？
キーワード：D言語
抽出レス数：1
607:デフォルトの名無しさん
09/04/30 20:40:14
現行、言語の性能はコンパイラ屋の質に依存してるぞ。
意外かも知れんが、Linux上ではJavaとCは同等、C++が一番早い。
the computer language benchmark gameのサイトでスコアが見れる。
608:デフォルトの名無しさん
09/04/30 20:40:57
>>606
おもしろではあるが、美しくはないだろ。
!()だかの使い方が未だにわからんｗ
609:ちんこ ◆GbXlaaQNk.
09/04/30 20:46:07
単純なプログラムではJavaは不利かも知れない。
だが、プログラムが複雑になるほど、Javaの最適化技術が生きてくるよ。
Javaは可読性の高いコードに対してもっともよい最適化を施す仕組みになってる。
610:デフォルトの名無しさん
09/04/30 20:55:09
はい、はい、はい。
わかったから、もう帰れ＞ちんこ
611:ちんこ ◆GbXlaaQNk.
09/04/30 20:57:21
帰ります。
ただ、これからはみなさんも可読性というものに高い意識を持って欲しいです。
いや、持ちなさい、持ちやがれ。
可読性の低いコードを書く人は死ぬべきです。
プログラマというのは超のつく知能職だということを知るべきです。
612:デフォルトの名無しさん
09/04/30 21:06:16
C++だって速いからというだけで使われているという考えもどうかと思う。
一応オブジェクト指向も可能でありながら、Cとの互換性のために
OSのAPIやCのライブラリを使え、アセンブリ言語との連携が容易で、大抵のスクリプト言語をホストできる。
D言語とか出てきてはいるんだけど、C++を置き換えるまでには至っていないし……。
613:デフォルトの名無しさん
09/04/30 21:08:49
てかC言語とC++ってもう互換性無いよね？
614:ちんこ ◆GbXlaaQNk.
09/04/30 21:10:47
現代のプログラムにおいては、
実行速度は関係ないから、
とにかく開発の容易性を重視すべき。
半導体技術の向上は目覚ましい。
だから、ソフトウェアの世界には、
古い時代のハードでやっていた人と、
新しい時代のハードから始めた人（おれとか）の
２つが入り交じってしまっている。
それが害悪なんだ。
若い人は積極的に正しいプログラムの書き方を学んで、
古い人たちを追い出すべきなんだ。
615:デフォルトの名無しさん
09/04/30 21:14:12
> 実行速度は関係ないから、
> とにかく開発の容易性を重視すべき。
はい、これで Java 消えた。
616:デフォルトの名無しさん
09/04/30 21:20:26
さすがに>>615は情弱というか低脳を感じざるを得ない
617:ちんこ ◆GbXlaaQNk.
09/04/30 21:23:33
Java以上に開発が容易な言語があったら教えてください。
おれは知りません。
Javaにはたくさんの道具があります。
Pythonにはそれがありません。
Eclipse+Javaに開発速度で勝つことは不可能ですし、
Javaならば、美しいプログラムを書けるだけの言語仕様を備えています。
例えば、おれがC++が嫌いな一つの理由は、
コンストラクタチェーンが出来ないことです。
コンストラクタからコンストラクタを呼び出せなければチェーン出来ません。
保守性が著しく低くなります。
618:デフォルトの名無しさん
09/04/30 21:27:59
つ Ruby
619:デフォルトの名無しさん
09/04/30 21:28:41
つ Ruby on Rails
620:デフォルトの名無しさん
09/04/30 21:34:50
Web屋かよ、カスが
621:デフォルトの名無しさん
09/04/30 21:35:31
Twitterにも見捨てられた糞環境、それがRoR。
622:デフォルトの名無しさん
09/04/30 21:38:54
Ruby に仕事を取られたからといって、そう僻むなｗ
623:ちんこ ◆GbXlaaQNk.
09/04/30 21:38:57
確かにRubyは美しい。
いや、美しさだけで言ったらRubyがマックスかも知れない。
だけど、RubyにはPythonに対して圧倒的に劣る点がある。
それは、コミュニティが小さいという点だ。
また、GoogleがPythonを採用してるなどの状況もあり、
Rubyへ優秀な人材が流れにくくなっている。
よって、RubyのライブラリはPythonに比べるとだいぶしょぼい。
スクリプトの標準がPythonになりつつあるというのもあって、もうこの差は埋まらないだろう。
Rubyはホビーランゲージとして生きていくことになる。
ただ、もし、もし、RubyがPythonと同じくendがいらない設計だったら・・・
そしたら話は変わっていたかも知れない。
Rubyのエンドラダーは害悪、可読性を言語仕様レベルで落とす原因になっている。
624:デフォルトの名無しさん
09/04/30 21:39:57
Rubyの字面は美しいって感じじゃないな。
あまりにも趣味的に過ぎる。
まあそれでもC++の醜悪さには及ぶべくもないが。
C++はパフォーマンスの要求されるところで使われて入るが
マルチコア環境での開発効率があまりにも悪すぎるので
関数型言語の台頭が予測されてるな。
625:デフォルトの名無しさん
09/04/30 21:41:58
>>623
> 確かにRubyは美しい。
> いや、美しさだけで言ったらRubyがマックスかも知れない。
> だけど、RubyにはPythonに対して圧倒的に劣る点がある。
> それは、コミュニティが小さいという点だ。
いいかげん、スレタイ読めや。
626:デフォルトの名無しさん
09/04/30 21:43:53
>>605
Javaでは配列にアクセスするごとにインデックスがはみ出していないかチェックする。
最適化しても、それを取り除くことはできないんじゃない?
C++では両端だけチェックして他は省くように書けるし、
コンパイラによっては、データ並列な部分を自動的にベクトル化してくれる。
(OpenMPを使って指示する必要がある部分もあるけど)
だから、信号処理や行列の計算など、速度が必要なタイプの処理の速度では、
JavaよりC++の方が一般的に言って上じゃないかな。
(私はJavaがメインだけど、嫌々C++を使いまくる場面がまだまだあるよ)
>>617
C++ 0xではコンストラクタチェーンができるようになる予定。
楽しみですな。
URLﾘﾝｸ(ja.wikipedia.org)
627:デフォルトの名無しさん
09/04/30 21:45:08
RoRなんて使ってるとこなんてホントにあるの？
どこの底辺？
628:デフォルトの名無しさん
09/04/30 21:45:50
がっはっは。
> ただ、もし、もし、RubyがPythonと同じくendがいらない設計だったら・・・
> そしたら話は変わっていたかも知れない。
end がなければ google が Ruby を採用し、優秀な人材も集まり、
しょぼいライブラリも目の醒めるようなライブラリとして生まれていた、と。
んな、あほな。
629:デフォルトの名無しさん
09/04/30 21:47:42
さすがに>>627には情弱というか低脳を感じざるを得ない
630:デフォルトの名無しさん
09/04/30 21:50:21
反応が既に終わってるな、まともに答えられんのか
631:デフォルトの名無しさん
09/04/30 21:52:40
URLﾘﾝｸ(www.tiobe.com)
PERLもどきならではの汚さを持つRubyの人気はもう落ちてます。
632:626
09/04/30 21:53:50
配列の処理を中心に見ると、美しいと思う言語はSaCかな。
SaCでは配列は全て値渡しで、プリミティブ値はランク0の配列として扱われる。
ランク数不明の配列を引数に取る関数を定義すれば、
プリミティブ値でも任意のランク数の配列でも、一つの関数で処理できる。
概念的には値渡しだけど、内部ではポインタ渡しにした上、
データフロー解析を使って処理は最小限にしてくれる。
ベンチマークではFORTRANよりも速度が出ているくらい速い。
(ちなみにコンパイラが出力するのはCのコード)
研究用の言語なので常用は厳しいし、足りないものも多いけど、
メインストリームの言語に長所が取り込まれればいいと思っている言語だ。
URLﾘﾝｸ(www.sac-home.org)
633:デフォルトの名無しさん
09/04/30 21:56:25
>>631
Java の人気の下がり具合のほうが大きいね。
634:ちんこ ◆GbXlaaQNk.
09/04/30 21:56:54
>>628
それはない。
だが、おれはRubyを好んでいたかも分からん。
いや、やっぱりPythonかな。
Pythonコミュニティには高い可読性を追求する気概がある。
可読性を無視するクズプログラマには用はない。
でもやっぱりRubyもいいよね。
Rubyはインスタンス変数の書き方がいいわ。
Pythonは少しうんこなところがある。
selfがくどかったりね。
あれはC言語でのオブジェクト指向の書き方なんだよ。古い。
>>626
C++の設計者が、
C++が保守性、可読性について言語仕様レベルで問題があることに気づいていた。
それだけで余は満足じゃ。
635:ちんこ ◆GbXlaaQNk.
09/04/30 22:01:03
>>631
どこが？
Python VS Rubyに関しては
もう逆転出来ないくらいの差がついてしまったよな。
Matz涙目www
636:デフォルトの名無しさん
09/04/30 22:08:04
>>635
英語は読めなくても、下のグラフが何を意味しているかぐらいはわかるだろう。。。
しかし、
> Matz涙目www
なんか、発言にギャッップを感じる。
637:デフォルトの名無しさん
09/04/30 22:10:51
>>636
常識のある人だと，長い目で見た場合 Java は下降気味，
Ruby は上昇気味という傾向を読み取るだろうね．
妄想系の人にこのグラフが一体どのように見えるかまではわからんがw
638:デフォルトの名無しさん
09/04/30 22:13:12
何でRubyヲタがJavaを目の敵にしてるのか知らんが、実際使われてないだろ
はてなとかやってる人？ｗ
639:デフォルトの名無しさん
09/04/30 22:16:15
だーれも Java を目の敵してませんが。
被害妄想系にはそう見えるかも知れませんねｗ
そうか、Ruby に仕事を取られたカワイソウな奴は
そんなに危機意識を持ってるのか。
640:デフォルトの名無しさん
09/04/30 22:18:32
> Ruby に仕事を取られた
という妄想をRubyヲタが好むのは何でだろうね
641:デフォルトの名無しさん
09/04/30 22:19:29
>>640
そんなことはない！と涙目になりながら必死で否定するやつがいるからじゃない？
642:デフォルトの名無しさん
09/04/30 22:20:39
P系言語とよろしくやってるだけで、Web屋以外の人は見向きもせんでしょ
643:ちんこ ◆GbXlaaQNk.
09/04/30 22:22:52
Pythonのやばいところは、
いちいちself.valueで指定しなきゃいけないところ。
これは可読性を落とすね。
でも、インデントによる論理改行と、
あとはキーワード引数で楽々借金返済出来る。
PythonとRubyのいいとこどりをした言語があったらいいんだけどね。
Rubyのmixinなんかは美しい。
Pythonはmixinをとって、多重継承を捨てるべきだと思う。
Pythonは大体いいけど、時々悪い。
Rubyはかなりいい言語なんだけど、コミュニティが貧弱すぎる。
GoogleはPythonだけど、ThoughtWorksはRubyだ。
おれはGoogleとThoughWorksどっちにでも入れるとしたらThoughtWorksを選ぶ。
644:デフォルトの名無しさん
09/04/30 22:26:18
ところで今日一番恥かしい発言をした>>631はどこに行ったんだろう
645:デフォルトの名無しさん
09/04/30 22:28:06
Rubyが凄い勢いで飽きられてるソースとしては十分だな
646:デフォルトの名無しさん
09/04/30 22:36:03
いや、別に Ruby を擁護する気はさらさらないが、どう考えても
> Rubyが凄い勢いで飽きられてるソースとしては十分だな
は >>631 のリンク先から読み取れないな
647:デフォルトの名無しさん
09/04/30 22:54:20
>>626
普段C++を使うけど、さすがにJavaもそこまで間抜けなわけがないと思うぞ。
範囲チェックを必要最低限に押さえることはJavaの最適化の序の口だろ。
648:デフォルトの名無しさん
09/04/30 22:59:40
>>643
手続き型の言語しかわからない人には
GoogleのMapReduceは何をやっているか
理解するのは難しいでしょう。
Code Completeもいいけど、
プログラムの作り方や
プログラム言語の優劣について論じるならば
SICPあたりも読むべき。
649:デフォルトの名無しさん
09/04/30 23:10:20
ぶっちゃけ、審美眼とうものは恣意的なものであるので、
○○は美しい、 というあらゆる命題は真理を述べることはできない。
○○は可読性が高い、という命題も同様である。
というわけでお前ら乙としか言いようがないわｗ
650:デフォルトの名無しさん
09/05/01 02:30:53
アセンブラやってるとすべての言語の意味がイメージできるので、
自分が美しいと思う言語を選ぶと、ずばりJava。EJBを除く。
651:ちんこ ◆GbXlaaQNk.
09/05/01 08:16:48
>>648
SICP読んだ人は美しいコードが書けるんですか？
立ち読みしたけど、とてもそんな感じはしなかった。
逆に、あれを読んだら汚いコードを書くようになってしまう気すらした。
事実、情報系の人間のコードを読んだことがあるが、腹抱えて笑うほどだった。
暗号みたいなコード書いて、自分は頭がいいんだと主張しているようだった。
おれはそんな世界には用がないんだ。
おれは正しいソフトウェアをアジャイルに構築することに興味がある。
そのためには急がば回れなんだよ、もっとも美しい設計、高い可読性の保ち方を知らない人間はゴミみたいなソフトウェアしか作れない。
したがって、生きてる意味がない。
おれは日本でもっとも可読性にストイックな男だ。
652:デフォルトの名無しさん
09/05/01 09:00:16
＞おれは日本でもっとも可読性にストイックな男だ。
なんだ、妄想癖の人だったのか。
653:ちんこ ◆GbXlaaQNk.
09/05/01 09:03:17
じゃあ、おれより可読性にストイックな人間を教えてくれ。
アポイントメントとって会いにいく。
654:デフォルトの名無しさん
09/05/01 09:10:34
>>653
可読性にそこまで拘るなら、
転職して、実行速度なんか気にしなくてもよい環境で、
Prologプログラミングの修練を勧めます。
これ本気。
655:ちんこ ◆GbXlaaQNk.
09/05/01 09:24:19
>>654
当方学生でつ。
656:654
09/05/01 09:28:31
>>655
いっしょにやろうじゃないか。
657:ちんこ ◆GbXlaaQNk.
09/05/01 09:31:44
どういう進路にするか迷ってるんでつ。
研究職でいくか、プログラマとして突っ切るか。
おれはプログラミングが好きだし、得意だけど、
日本のプログラマは地位が低すぎる。
年収１０００万はないと嫌だ。
658:デフォルトの名無しさん
09/05/01 09:34:08
可読性にこだわってる割にはちょっとな。
590でその４行が おまいのいう順番になったときは、
プログラムとして違う動作になる。
事の大小はともかく、入力があった場合にのみ表示が出るという動作を
たったこんな小さなプログラムから読めないやつに可読性なんていう資格は無い。
ちゃんと動くことの方が数倍重要だ。
659:ちんこ ◆GbXlaaQNk.
09/05/01 09:40:00
あ、そうなの・・・？
知らんけど。
660:ちんこ ◆GbXlaaQNk.
09/05/01 09:45:50
まず、
入力があった場合にのみ表示が出る、
なんて仕様が狂ってるし、
大体、このプログラムおかしいもん。
日本のソフトウェア業界っていうのは、こういうコードが蔓延してるんだろ。
おれは単純に凝集度の観点から可読性が低いといっただけで、
こんなのそもそもまともなプログラムじゃない。
動作を確認するまでもないコード。
見たその時点で、気持ち悪いという感情を得た、それだけだ。
もちろん、入力を施す為の記述もない、という意味も含めてね。
661:デフォルトの名無しさん
09/05/01 10:53:13
>>651
SICPを読んだら、より美しいコードが書ける。
なぜならば、手続きの抽象化について学ぶことができるから。
Javaが採用しているオブジェクト指向はデータの抽象化を推進する。
もし手続きの抽象化について学べば、それをJavaでも応用できるよ。
綺麗なStrategyパターンを書くとかね。
662:デフォルトの名無しさん
09/05/01 11:04:31
「ケント・ベックの Smalltalk ベストプラクティス・パターン」
これを読むと、ケント・ベックは可読性にストイックな男としては
世界でも上位に入るのではないかと思う。
可読性にこだわった先達として、>>660はこれも読むといいよ。
663:デフォルトの名無しさん
09/05/01 11:04:51
>>590の言語が何かは知らないけれど
Scanner stdIn = new Scanner(System.in);
これは、入力オブジェクトの宣言なのだから、処理とは分けて記述しなければならないのでは?
処理の最中に、これがある方が気持ち悪いのですが...
664:デフォルトの名無しさん
09/05/01 11:10:17
>>660
とりあえず、君の書いたソースを読みたいな
665:デフォルトの名無しさん
09/05/01 11:19:25
>>664
こういう展開でソースを出して見せた奴、みたことないｗ
可読性という話で、十数行のサンプルプログラムみたいなのに大げさに噛み付く姿からして、
彼が取り組んだことのあるプログラムの大きさと複雑さの程度が見て取れる。
666:デフォルトの名無しさん
09/05/01 11:23:46
多面的に物事を見れてないしね
667:デフォルトの名無しさん
09/05/01 13:47:46
>>665
出したところで、
ふーん、俺には可読性が高いようには思われない
と言い出す人が現れて終了
668:デフォルトの名無しさん
09/05/01 15:44:13
このコテはソースの美しさを語る前に自分の日本語をどうにかした方がいいと思う
669:デフォルトの名無しさん
09/05/01 16:11:41
件のコードが書かれた文脈（書き捨てのサンプル）を考えると
>>660 はアホとしか思えん
いくらソースの可読性が高かろうが、文脈を読み取れないやつが
読むんじゃなあｗ
670:デフォルトの名無しさん
09/05/01 17:11:30
>>605,634
C++もLLVMなんかのVMで動くし。ネイティブに最適化された
バイナリよりも早い。当然、JVMより遥に早い訳だが。
言語の話をしてる時に環境の話を出すなよ。不毛だ。
>selfがくどかったりね。
>あれはC言語でのオブジェクト指向の書き方なんだよ。古い。
あんまり、オブジェクト指向しらんだろ？マルチディスパッチとか
Smalltalk学んでこいよ。
著名人の間で美しいと言われるのはLispだが、
基本的に統一性のある文法の言語が美しいとされるね。
Rubyの話も度々出るが、改行が不自由でメソッド呼び出しに
糖衣構文があるってのは汚いな。概念上はSmalltalkに似て
綺麗なんだけどな。あと、最近人気が下降気味らしいな。
(書籍販売数・プロジェクト数・他 が縮小してるらしい)
Objective-Cなんかは、C言語に埋め込みできるオブジェクト
指向言語だと考えれば綺麗だと考える著名人も少なくないだろうね。
671:ちんこ ◆GbXlaaQNk.
09/05/01 18:59:36
お前ら、ずいぶんと偉そうだな。
日本のソフトウェアエンジニアなんて、高卒とか文系とかばかりだろ。
相手にならんよw
日本人が書いたコードで美しいコードを見たことがない。
もしオープンソースでそういうものがあるのなら教えてくれ。
情報学科卒でSICPなどは当然読んでるだろうと思われる人間のコードも読んだことがあるが、
カス同然だった。
よってSICPなど意味ない。
672:デフォルトの名無しさん
09/05/01 19:18:03
>>671
そっすね。
673:ちんこ ◆GbXlaaQNk.
09/05/01 19:20:44
ところでだけど、
Python3.0とPython2.6だったら、
どっちを使うべき？
対して差、ないよね？
Python3.0ってこれから広く使われる予定あるの？
互換性切ってるし、美しくなったといっても、使われるかどうかは別な気がする。
674:デフォルトの名無しさん
09/05/01 19:33:43
＞ ちんこ
そこまで自惚れられる根拠は何かね？
675:デフォルトの名無しさん
09/05/01 20:26:36
> ちんこ
マーチン・ファウラーが評価している「fluent interface（流れるようなインターフェイス）は
デメテルの法則を破っているからCode Complete的にはNGだと思うんだけど、
ちんことしては、これはOKなの？NGなの？
676:ちんこ ◆GbXlaaQNk.
09/05/01 20:36:49
絶対にNG
他にも、おれはインターフェイスの設計として、
メソッドの引数を単純データ結合に保たないような設計
（
これは、
場合によっては引数オブジェクトの導入リファクタリングによって改善されるが、
最初は絶対に、結合度を低く保つべき
）
や、
メソッドチェイニングを前提とした設計、
とりわけ、可変オブジェクトを返す設計を嫌う。
Immutableなオブジェクトを生成して返すのであればそれは許されないこともない。
Mutableなオブジェクトを返すのはかなりやばい。
このFluent Interfaceというのは返したオブジェクトが可変になっているから、相当悪い。
これをおれが悪いと思う理由は、
おれがテスト駆動とリファクタリングを前提にプログラムを書くようにしているからであり、
経験的に、結合度をとにかく低く保った方がリファクタリングがしやすいからだ。
確かに、メソッドチェイニングを回避するために、委譲メソッドを作るのは手間だが、
IDEを前提とした場合、そこまでの手間でもないし、
何より結合度を低く保つことのメリットの方が断然大きいと感じている。
677:ちんこ ◆GbXlaaQNk.
09/05/01 20:43:23
マーチンはたまにおかしなことをいう。
ケントベックのいうことはほとんどの場合信じられる
（
例えば、おれは美しい設計のために
常にstaticファクトリを使うべきだと思っていたが、
ケントは、ただの生成の為にstaticファクトリを作るのは愚であると、
実装パターンにおいて説いている。
確かにそうだと思ったので、それ以降、おれは無駄なstaticファクトリを作ることをやめた
）。
あと、Code Completeに書いてあることもほぼ１００％信じられる。
マーチンのリファクタリングもほとんどは信じられるが、
おれは、仲介人の導入メソッドだったか、名前は忘れたが、
委譲するのが大変だからやめる、と言った主旨のリファクタリングは訂正して消去して欲しいと思った。
マーチンは尊敬出来るソフトウェア開発者だが、彼とおれとの間には少しだけ設計に対して意見の相違がある。
678:675
09/05/01 21:00:22
>>676
ありがとう。
流れるようなインターフェイスは読みやすいので、
読みやすさとどっちを優先するか聞きたかった。
俺もクラス間の結合度を低く保つように心がけているけど、
メソッドが7つを超えたら別のクラスに分けて、
元のクラスに分けたクラスのオブジェクトを返すファクトリメソッドを作ってる。
679:ちんこ ◆GbXlaaQNk.
09/05/01 21:03:31
メソッドの数は関係ない。
仮にメソッドの数が増えたらクラスを分離して、
そのクラスに処理を委譲するようにしろ。
実装コードが増えすぎるのが問題なので、あって、
インターフェイスの数が増えることが問題なのではない。
これを勘違いしてるやつが多すぎる。
そして、
元のクラスにわけたクラスのファクトリを作るという設計も意味不明だ。
君はちゃんとオブジェクト指向を学んでいない。
よって死ね。
680:デフォルトの名無しさん
09/05/01 22:34:40
「俺は、ビックマグナムだ!!!」
と思っていられるうちは自惚れる事もできるさ
まあ、大抵の場合、銭湯に行って己の矮小さに気付くわけだがなwww
681:デフォルトの名無しさん
09/05/02 00:49:24
だから、ソースは？
682:デフォルトの名無しさん
09/05/02 01:13:54
自演乙
683:デフォルトの名無しさん
09/05/02 01:43:55
よしいまからHaskerubyつくる
684:デフォルトの名無しさん
09/05/02 03:56:41
夜郎自大とはまさにこのことだ
685:デフォルトの名無しさん
09/05/02 16:00:30
「プログラム言語ツクール」とかあったら、
みんなで作って見せ合えるのにね。
文法をBNFで書けば言語ができるようなの。
ライブラリは.NETのを使えばいいね。
…単に.NET用のyacc/lexを使えばいいのか？
っていうか、最も美しい言語はBNFか？
686:デフォルトの名無しさん
09/05/02 16:32:42
>>685
ようこそ♪
ｽﾚﾘﾝｸ(tech板)
yaccやbisonは使いにくいので、個人的にはCaperがお薦め。
BNFを書くと、構文解析機と、解析後に呼びだす
(意味解析用の) 関数が一通り定義されたインターフェースを
生成してくれる。
(言語はC++, C#, Java, D, JavaScriptに対応)
後はそのインターフェースを、構文に対応する
処理をするよう実装すれば、自分の言語ができてしまうよ。
687:デフォルトの名無しさん
09/05/02 16:39:28
>>685
システムトレードの話かとおもった
688:デフォルトの名無しさん
09/05/02 16:44:34
言語の美しさが構文の美しさに還元されると思ってる人がいるけど・・・
そもそも、仕様が美しければ実装はどうでもいい的なことを最初に言い出したのは
いったい誰なんだろう
689:デフォルトの名無しさん
09/05/02 16:47:20
Lispでいいじゃん
690:デフォルトの名無しさん
09/05/02 16:47:55
実装なければ言語がないのも同じ。
ひとつでも実装あって動けばその言語はある。
実装あればその動作は関係ないだろう。
691:デフォルトの名無しさん
09/05/02 16:54:17
>>685
既存の言語を使いこなせないと新しい言語を作れないから、
既存の言語が使いにくいと思う人達は
新しい言語を作るところまでいきつかない。
そういう人達こそ言語に革新をもたらすかもしれないのにね。
誰でも簡単に動く言語を使えるツクールがあれば、
言語の開発が促進されるかもね。
面白いアイデアだと思う。
字句解析と構文解析は定義ファイルから自動生成できるとして、
難しいのは意味解析の自動生成かな。
自動生成できなくてもツクール内に動作を用意しておいて選択する
方法もあるけど、典型的な機能以外は実装できなくなってしまう。
692:デフォルトの名無しさん
09/05/02 16:56:27
>>688
仕様が最適化を難しくすることもあるから、
個人的には言語の仕様と実装はセットで考えるべきだと思う。
>>689
Schemeをいじってみたけど、if-then-elseなどの
普通の関数とは動作 (評価の順序) が違う機能も
同じS式で統一してあるのが嫌だった。
意味が違うものは構文も別にするべきだと思う。
Haskellのように全て最外簡約ならいいんだけど。
>>690
使える道具を探す立場ではそうなのだけど、
仕様を示すだけでも、言語を作りたい人達の参考になるよ。
(私も含めて)
693:デフォルトの名無しさん
09/05/02 18:02:35
なんだかんだCOBOLが一番読みやすい。
694:デフォルトの名無しさん
09/05/02 18:19:30
ちがう。こういう事。
If you give someone Fortran, he has Fortran.
If you give someone Lisp, he has any language he pleases.
---Guy L. Steele Jr.
695:デフォルトの名無しさん
09/05/03 05:06:44
そんなあなたにSmalltalk。予約語なんてなし。分岐も繰り返しもただただメッセージングあるのみ。
696:デフォルトの名無しさん
09/05/03 07:00:01
>>686
汎用の言語と範囲限定の言語（いわゆるDSL)の2種類あると思うよ。
汎用の言語は、既存の言語をこえるものはでてこないし、Lispでいいじゃんで終わってしまったりすると思う。
面白いのは範囲限定の言語で、
～のような目的のシステムを書くために、○○のような言語を作ってみました。
っていうアイデアをもちよるのは面白いかもしれない。
美しさのひとつにシンプルさってあると思ってて、ある程度自由度をもったシステムがいかに簡潔かけたかというのがポイントの一つになり得ると思う。
697:デフォルトの名無しさん
09/05/03 07:54:00
>>696
システムの簡潔さはどうやって評価するの？
たとえば、DSLを利用するためのライブラリをリンクしなければならないとしたら、
そのライブラリを必要としないシステムよりも複雑になったと言うこともできるけど。
698:デフォルトの名無しさん
09/05/03 13:19:34
Objective-Cはなんかゾクゾクくる。
Javaさんざんやって、
Smalltalkやそのコミュニティにはなんかしらんが畏敬の念を抱きつつ、
C++行ってモヤモヤして、
Rubyをやってウハウハしてると。
699:デフォルトの名無しさん
09/05/03 16:35:35
Objective-C最高。
700:デフォルトの名無しさん
09/05/03 21:32:00
>>697
そういう評価もそれはそれでありなのでは。いろいろ評価方法はあっていいと思う。目的によって違うのでしょうから。
将来同じような目的にであったとき、そういえばこういう局面でこういう言語を使えば効率よくなるって話があったなっていう引き出しをたくさん
用意しておくのもいいのでは。
701:デフォルトの名無しさん
09/05/03 23:41:05
>>692
Schemeのifは「文」なんですよね。
特別扱いのようです。
Haskellは最外簡約で、
smalltalkはブロック（lambdaと同じ）で
無理なくクリアしているのが美しいと思います。
702:デフォルトの名無しさん
09/05/03 23:45:02
こんなのやってたんだ。。。
言語開発合宿
・2泊3日の期間内に、オレ言語の仕様とその処理系を作るというイベントです
URLﾘﾝｸ(wiki.fdiary.net)
703:デフォルトの名無しさん
09/05/04 17:27:23
>>696, >>697, >>700
「言語の」複雑さを評価する指標なら、
ASTのノード数なんてどうだろう。
同じ処理を少ないノード数で記述できたら
その言語は簡潔ということにならないかな?
704:デフォルトの名無しさん
09/05/04 19:06:02
>>703
それ全然意味ない！lambda 一発になるwW
最終的には、なにがしかの形式意味を、いかに簡潔に書きうるかだろ？
705:デフォルトの名無しさん
09/05/05 00:05:28
>>704
> lambda 一発になるwW
lambdaを使って書いた無名関数の定義が含むノード数も
評価するわけだから、それなりに妥当なんじゃない?
無名関数を使う側が1ノードになるのは、コード自体の簡潔さに対応する。
> 最終的には、なにがしかの形式意味を、いかに簡潔に書きうるかだろ？
簡潔であることを「どう評価 (数値化) するか」の話をしているんでしょ。
>>704は>>694かな?
706:705
09/05/05 00:16:53
>>703-704
問題になるのは無名関数ではなく、マクロかな、と思う。
707:デフォルトの名無しさん
09/05/05 02:22:14
>>705 ASTでは構文の持つ意味まで説明できないって言ってるんじゃないの?
708:デフォルトの名無しさん
09/05/05 03:37:30
>>702
自分で言語を開発したい/してる人って、案外いそうですね。
この板にはそういうスレが無いので、
もしこのスレにそういう人がいたら、
様子を聞かせて (読ませて) もらえると面白いと思います。
>>707
>>703の「同じ処理を少ないノード数で記述できたら」が
>>704の「なにがしかの形式意味を、いかに簡潔に書きうるか」
に対応していると見ると「処理」は「形式意味」に対応しますね。
そうだとすると、>>703は
「処理 == 形式意味」が「同じ」場合、
つまり「構文の持つ意味」を統一済みの場合についての話なので、
構文の持つ意味を説明する必要は無いのでは。
思うに、
>>707が真だとすると、>>704は既に存在するコードを対象に、
同じ量のコードがどれだけの量の形式意味に還元されるか、
という話をしているのでは。
それに対し、>>703と>>705はおそらく、
決まった課題を与えて (あらかじめ形式意味を統一して)
それをどれだけの量のコードで表現できるか、
という話をしていると思います。
709:デフォルトの名無しさん
09/05/05 19:17:58
最も美しいプログラミング言語は賛否両論あるだろうが、
最も汚いプログラミング言語の一つがC++であることに異論がある人は
少ないだろう。
710:デフォルトの名無しさん
09/05/05 20:13:38
つ COBOL
711:デフォルトの名無しさん
09/05/05 20:46:42
つ Objective-C
712:ちんこ ◆GbXlaaQNk.
09/05/05 21:34:31
もっとも美しい言語はPythonです。
ほんと、この言語で仕事ができるところに就職したい。
やっぱベンチャーを作るべきなのかな？かな？
713:デフォルトの名無しさん
09/05/05 22:12:05
>>712
ベンチャー作るのに賛成!
Pythonに反対!
714:ちんこ ◆GbXlaaQNk.
09/05/05 22:50:49
Pythonはもっとも美しい言語だろjk
これ以上に美しい言語があったら教えてくれ。
おれは知らない。
715:デフォルトの名無しさん
09/05/05 22:53:32
ぱいそんはどのあたりがうとぅくしぃのかおせーてくれ
716:デフォルトの名無しさん
09/05/05 23:01:21
>>712
宣言的とは見えない点。
オブジェクト指向である点。
インデント構文を必要とした点。
リストの内包表記は評価するけど。
717:デフォルトの名無しさん
09/05/05 23:02:25
>>715 だったね。>>712というより。
718:デフォルトの名無しさん
09/05/05 23:17:08
検索してみた。意味あるかはわからん。COBOLがずば抜けて高い。
C++ 言語 の検索結果 約 2,600,000 件
C++ 言語 美しい の検索結果 約 66,800 件
→2.57%
COBOL 言語 の検索結果 約 138,000 件
COBOL 言語 美しい の検索結果 約 39,000 件
→28.3%
Java 言語 の検索結果 約 424,000 件
Java 言語 美しい の検索結果 約 39,800 件
→9.39%
C# 言語 の検索結果 約 1,900,000 件
C# 言語 美しい の検索結果 約 34,700 件
→1.83%
Ruby 言語 の検索結果 約 3,040,000 件
Ruby 言語 美しい の検索結果 約 110,000 件
→3.6%
Smalltalk 言語 の検索結果 約 171,000 件
Smalltalk 言語 美しい の検索結果 約 8,550 件
→5%
Squeak 言語 の検索結果 約 83,100 件
Squeak 言語 美しい の検索結果 約 6,700 件
→8.06%
Python 言語 の検索結果 約 2,830,000 件
Python 言語 美しい の検索結果 約 58,400 件
→2.06%
Perl 言語 の検索結果 約 2,540,000 件
Perl 言語 美しい の検索結果 約 173,000 件
→6.81%
BASIC 言語 の検索結果 約 309,000 件
BASIC 言語 美しい の検索結果 約 15,700 件
→5.08%
719:デフォルトの名無しさん
09/05/05 23:23:28
追加。。。やっててただ疲れるだけな気がしてきたｗ
Objective-C 言語 の検索結果 約 266,000 件
Objective-C 言語 美しい の検索結果 約 9,880 件
→3.71%
Tcl 言語 の検索結果 約 113,000 件
Tcl 言語 美しい の検索結果 約 2,430 件
→2.15%
FORTRAN 言語 の検索結果 約 204,000 件
FORTRAN 言語 美しい の検索結果 約 31,900 件
→15.6%
720:デフォルトの名無しさん
09/05/05 23:36:07
>>718-719
乙。
COBOLはアンチが多い一方で、魅力を語るのをなかなか見かけない。
でも、一時代を築いた言語だし、何か美しさがあるんじゃないかな。
(>>693あたり、語ってくれないかな)
721:デフォルトの名無しさん
09/05/05 23:43:03
>>719
FORTRAN訂正。。。やっぱCOBOLか。ほかはだいたい同じ感じだな。
FORTRAN 言語 の検索結果 約 204,000 件
FORTRAN 言語 美しい の検索結果 約 5,180 件
→2.53%
722:デフォルトの名無しさん
09/05/06 00:18:56
LISP 言語 の検索結果 約 494,000 件
LISP 言語 美しい の検索結果 約 36,400 件
→7.36%
Scheme 言語 の検索結果 約 1,480,000 件
Scheme 言語 美しい の検索結果 約 35,000 件
→2.36%
Haskell 言語 の検索結果 約 326,000 件
Haskell 言語 美しい の検索結果 約 13,000 件
→3.98%
Delphi 言語 の検索結果 約 480,000 件
Delphi 言語 美しい の検索結果 約 7,070 件
→1.47%
FORTH 言語 の検索結果 約 291,000 件
FORTH 言語 美しい の検索結果 約 26,000 件
→8.93%
Erlang 言語 の検索結果 約 254,000 件
Erlang 言語 美しい の検索結果 約 19,500 件
→7.67%
723:デフォルトの名無しさん
09/05/06 00:31:22
>>709
激しく同意。
そして俺はC++をさらに拡張しようとしている連中の思考が理解できない。
もう既にぐっちゃんぐっちゃんの闇なべの残飯みたいな状態なんだから、
さらに何個か残り物ぶち込んでも分かんないだろ？みたいな感じなのだろうか。
そしてそんな物をいったい誰が食うというのだろうか。
724:デフォルトの名無しさん
09/05/06 01:04:53
お前や俺が食うんだよ！ ヒッヒッヒ
725:デフォルトの名無しさん
09/05/06 06:05:56
>>723
闇鍋から嫌いな物を除いて好きなものだけにすると、
あら不思議、至高のお鍋になるんだよ。
726:デフォルトの名無しさん
09/05/06 06:51:21
>>708
おれがこの合宿に参加して、
この中のどれかのテーマの言語を開発するとする。
そして、そのテーマの命題＋美しい言語に仕上げることを目標とする。
そのとき、Lispのような言語にするだろうか。
いざ、そうなったときにはシンプルな命令体系にして、BASIC風なスクリプトにするんじゃないかなと思う。
つまり、美しい＝覚えることが最小限の言語（文法が最小）
となるような気がする。
727:デフォルトの名無しさん
09/05/06 07:01:34
>>726
そういう意味では Guarded Horn Clauses のような言語が
一番美しいのではないか。
728:デフォルトの名無しさん
09/05/06 10:01:05
>>727
平行プログラミング言語がもっともシンプルというのも考えてみれば不思議だね。
729:デフォルトの名無しさん
09/05/06 11:17:06
>>726
> シンプルな命令体系にして、BASIC風なスクリプト
HSP?
730:デフォルトの名無しさん
09/05/06 12:01:19
>>727
Guarded Horn Clauses（KL1）について調べてみた。
これは美しいね。
しかし、これの仕様と実行環境を作るのに570億円もかかっているとは…。
これといい、Σプロジェクトといい、官主導のものって無駄に金を食ってる気がする。
731:デフォルトの名無しさん
09/05/06 12:30:41
気がする？
今さら何を・・・。
732:デフォルトの名無しさん
09/05/06 13:03:30
Σプロジェクトなんて２億円を使ったあげく
結局OSはUNIXが一番いいという結論を出しただけのプロジェクトだもんな。
官僚ってアホばっかりだな
733:デフォルトの名無しさん
09/05/06 13:16:11
>>727,729
KL1は、論理や並行処理の部分を抽象化してあって、HSPはある範囲ないのGUIアプリのためにカスタマイズされているよね。
空想の話だが、
>>702のような合宿があって、そこの審査員を依頼されたとしよう。
担当は作成された言語を「美しさ」という点から評価するとする。
この場合、どういう評価観点が考えられるかな。例えば
・目的に対し最適化された命令体系・文法になっている
・目的に対して最適のパラダイムまで抽象化が行われている（構造化、オブジェクト、関数型、論理型、並行）
・ライブラリ、、、
などかな。
734:デフォルトの名無しさん
09/05/06 17:19:01
CはうつくC
なっつっ亭
735:デフォルトの名無しさん
09/05/06 19:08:13
駄洒落は寒いが、Cが美しいことは真理。
736:デフォルトの名無しさん
09/05/06 23:22:02
Pythonは'Python'という名前以外は美しい
737:デフォルトの名無しさん
09/05/07 01:24:01
>>736
あなたなら、なんと名付けるの?
738:デフォルトの名無しさん
09/05/07 01:54:56
oppai
739:デフォルトの名無しさん
09/05/07 02:13:14
HSPって昔の8bitマシンのBASICみたいだね。
美しいかどうかは議論の余地があるけど、とっつきやすく、初心者でもプログラミングしやすいと思う。
740:デフォルトの名無しさん
09/05/07 04:13:26
>>739
>とっつきやすく、初心者でもプログラミングしやすいと思う。
それって「美しい」の必要条件になり得ると思うんだけどなぁ。
741:デフォルトの名無しさん
09/05/07 06:51:23
高度なアートは素人には分からないというのもあるのでは
742:デフォルトの名無しさん
09/05/07 07:33:11
2
E=mc
743:デフォルトの名無しさん
09/05/07 10:29:42
逐次的に書けてシンプル
動作がスタック操作のみでシンプル
関数に副作用がなくてシンプル
すべてがリストでシンプル
すべてがオブジェクトへのメッセージ送信でシンプル
すべてがホーン節のみでシンプル
744:ちんこ ◆GbXlaaQNk.
09/05/07 18:33:22
とりあえず、今インターンとやらで、WinAPIを触ってる。
ひどい・・・。
C++もちょっと勉強したけど、
ひどい・・・。
Javaのありがたみが分かったのと同時に、
Pythonとかゆとり用言語だな、と感じた。
745:デフォルトの名無しさん
09/05/07 19:19:07
ハードウェアを触ればもっとひどいと思うよ。
そして、プリインストールされているOSのありがたみが分かる
または、ゆとり用OSだなと感じる。
746:デフォルトの名無しさん
09/05/07 19:31:19
haskellとかprologこそ真のゆとり言語だよ
747:ちんこ ◆GbXlaaQNk.
09/05/07 19:35:12
>>745
ハードからのシグナルをコールバック関数で受けるというプログラムを書いている。
なんか、オブザーバパターンってレベルじゃなくて、
依存の方向が逆な気がするんだよね・・・。
美しいプログラムしか知らないおれにとっては地獄も同然だぜ。
>>746
それらに実用性はないだろ。
Pythonには高い実用性がある、それに書いててwktkする何かがある。
748:デフォルトの名無しさん
09/05/07 20:12:43
>>746
'70年代のSmalltalk（＝暫定ダイナブック環境）はさながら、ゆとりＯＳか。
749:デフォルトの名無しさん
09/05/07 20:17:56
>>747 ハードからのシグナルをコールバック関数で受ける
(with-signal-handler (signal)
(case signal
(rx-ready (...))
(tx-ready (...))))
なにか問題でも?
750:デフォルトの名無しさん
09/05/08 00:04:17
>>747
Pythonはメタオブジェクトがらみになるととたんに美しさを失うからなぁ…。俺は嫌い。
751:デフォルトの名無しさん
09/05/08 00:26:52
インパクトという点ではLISPが一番びっくりした
この衝撃はあと50年は続くだろう
752:デフォルトの名無しさん
09/05/08 00:51:59
Prologのユニフィケーションほどの衝撃はなかったなぁ。
構文木がファーストクラスてだけじゃんと。
753:デフォルトの名無しさん
09/05/08 01:57:51
えー、やっぱFORTHじゃねーの？
「この世にコンピュータ言語は二種類ある。それはFORTHとそれ以外だ。」
まさにこの言葉がぴったりだと思ったよ。
754:デフォルトの名無しさん
09/05/08 05:11:45
>>738
第一回LLVM勉強会での主催者さんの資料に、
そういう名前が自作処理系の名前の候補として出てくるよ (笑
ユーモアのある、魅力的な人だったな。
>>ちんこ
URLﾘﾝｸ(blog.livedoor.jp)
C++の「醜さ」には、設計ミスとしか思えないような部分と、
意図的にやっている部分がある。
JavaやPythonとは違った「美しさ」に気付くと、
君のようにこだわりがある人は、案外気に入るかもよ。