最も美しいプログラミング言語は？

1 ：デフォルトの名無しさん：2006/07/19(水) 23:51:56

最も美しいプログラミング言語は何か語りませう。

最も美しくプログラムを書ける言語はなにか？ということです。

言語名と理由を書いてください。

2 ：デフォルトの名無しさん：2006/07/19(水) 23:56:28

美しいの定義を書け。

3 ：デフォルトの名無しさん：2006/07/19(水) 23:59:48

魔神語

4 ：デフォルトの名無しさん：2006/07/20(木) 00:00:24

Brai(ry

5 ：デフォルトの名無しさん：2006/07/20(木) 00:21:45

Whitespace

6 ：デフォルトの名無しさん：2006/07/20(木) 00:24:04

Whitespace
誰が書いても美しいソースになる。

コメントを書かない限りは。

7 ：デフォルトの名無しさん：2006/07/20(木) 00:26:01

brainf*ck

>>4
自信もてよ

8 ：デフォルトの名無しさん：2006/07/20(木) 01:22:23

HASKELL!

9 ：デフォルトの名無しさん：2006/07/20(木) 01:26:27

What's faster than C++,
more concise than Perl,
more regular than Python,
more flexible than Ruby,
more typeful than C#,
more robust than Java,
and has absolutely nothing in common with PHP?

It's Haskell!

10 ：デフォルトの名無しさん：2006/07/20(木) 01:34:33

>>9
But Lisp is more "beautiful" than Haskel!

11 ：デフォルトの名無しさん：2006/07/20(木) 01:41:56

Lisp族の1つとしてSchemeを初めて触ったときには衝撃的だったね。

俺の中に今まであったコンピュータは数値を扱うと言う概念が覆された。
数値だけでなく文字列も何もかもアトムとして平等にセルに収まり、
分け隔てなく扱ってしまうことは驚きだった。

というわけでLisp族に1票。

逆に最も美しくないプログラミング言語としては、よい意味でC++に1票。その理念は好きだよ。

12 ：デフォルトの名無しさん：2006/07/20(木) 02:16:38

あっというまに見た目の話じゃなくなったのは、予想通り

13 ：デフォルトの名無しさん：2006/07/20(木) 02:46:59

>>11
CommonLispさわってがっかりなんだぜ？
Lispが綺麗なんじゃない、Schemeが綺麗なんだ

14 ：デフォルトの名無しさん：2006/07/20(木) 04:46:13

>>11
>数値だけでなく文字列も何もかもアトムとして平等にセルに収まり、
>分け隔てなく扱ってしまうことは驚きだった。
そんな機能いまならいろんな言語あるだろ。
LispオタクがLispを真に評価しているのはそこではない。

15 ：デフォルトの名無しさん：2006/07/20(木) 04:59:24

Lispって人工知能とかに使われてるって良く聞きますが、人工知能がショボいのはその言語のせいじゃないんですかね？

16 ：デフォルトの名無しさん：2006/07/20(木) 11:42:38

人工知能屋ってのは、一つの言語にとどまって研究を続けたりしない。
ナニをやるかにあわせて、言語を選んだり、作ったりする。一時の彼らの
手段としてLispが選ばれていたというだけだよ。

17 ：デフォルトの名無しさん：2006/07/20(木) 19:26:42

人工知能屋って言っても最近は膨大なデータから学習とかだろうしなあ
わかりきった話だがLispの出番じゃない希ガス

18 ：デフォルトの名無しさん：2006/07/21(金) 00:04:26

スクリプト系ではpython(見た目だけだけど)。ちなみに今勉強中
尤もインデントによるブロックはpythonのオリジナルじゃないらしいけどね
一番汚いのは……シェルスクリプトかなw

19 ：デフォルトの名無しさん：2006/07/21(金) 00:38:29

((lambda(scheme)(scheme scheme))(lambda(scheme)(scheme scheme)))

20 ：♥　殿舎男萌え萌え系？謎 ◆ej9/UehK8Y ：2006/07/21(金) 01:17:39

あえてphp

21 ：デフォルトの名無しさん：2006/07/21(金) 01:23:11

少し前まで C# 2.0が最も美しいを思っていた。

でもプログラミング言語は外見じゃない！中身だ！
最近はそんな風に思えて来ました。

22 ：デフォルトの名無しさん：2006/07/21(金) 01:26:05

見た目の美しさと読みやすさは両立するんだろうか？

23 ：デフォルトの名無しさん：2006/07/21(金) 01:31:10

ルールが少ないのがもっとも美しい。

24 ：♥　殿舎男秋葉系? ◆ej9/UehK8Y ：2006/07/21(金) 01:45:11

ルールが少ないと同じプログラムでも
プログラマーによって大きくソースが変わりそう

25 ：デフォルトの名無しさん：2006/07/21(金) 02:38:29

Pythonは記号含有率が低くて見た目的に好きだ

26 ：デフォルトの名無しさん：2006/07/21(金) 02:50:16

リスプはきたならしい

27 ：デフォルトの名無しさん：2006/07/21(金) 03:20:20

リテラル表記の種類が多ければ多い程好き
でも Lisp はリテラルを自分で作れるからなぁ...

28 ：デフォルトの名無しさん：2006/07/21(金) 06:38:07

とりあえずscheme(または最小lisp)でしょ。
データ構造がそのままプログラムになる。美しい。
ラムダ計算。美しい。
数十年間現役。美しい。
簡単なものならば、誰でも処理系が作れる。美しい。

ある意味でSmalltalkあたりも美しい。

「プログラマーに総てを委ねる」潔さって意味ではC言語も美しい。最も醜悪な言語でもあるが。

29 ：デフォルトの名無しさん：2006/07/21(金) 10:06:38

審美眼が狂ってるヤツの見本でした

30 ：デフォルトの名無しさん：2006/07/21(金) 10:09:42

美しいアーキテクチャは、それだけでは何も産まない

31 ：デフォルトの名無しさん：2006/07/21(金) 11:08:10

使用者が馬鹿な場合はな

32 ：デフォルトの名無しさん：2006/07/21(金) 14:12:10

MLって合理的だな。

33 ：デフォルトの名無しさん：2006/07/21(金) 14:16:24

電気信号

34 ：デフォルトの名無しさん：2006/07/21(金) 14:31:47

美しいって、主観だから
いみないよね。

35 ：デフォルトの名無しさん：2006/07/21(金) 17:43:21

美しく書ける言語でも命名のセンスが無い俺が書く
プログラムは非常に醜い。　　　orz

36 ：デフォルトの名無しさん：2006/07/21(金) 17:54:36

ループが多ければ多いほど醜い

37 ：デフォルトの名無しさん：2006/07/21(金) 18:21:28

じゃあ再帰ばかり多用で

38 ：デフォルトの名無しさん：2006/07/21(金) 21:02:49

スタックオーバーフローを引き起こす可能性のある再帰は
見た目だけ美しい。

39 ：デフォルトの名無しさん：2006/07/21(金) 22:34:39

プログラムの美しさをテーマにするといろいろな意見があって面白いですね。
そもそも美しさってなんだっていう議論も興味深い。いろいろな意見をぶつけあって、お互い尊重して、そんな感じでこのスレッドを楽しみましょう。

40 ：デフォルトの名無しさん：2006/07/22(土) 01:45:34

Pascal

なんだかんだいって見やすい

41 ：デフォルトの名無しさん：2006/07/22(土) 05:07:45

Whitespace だけはガチ

42 ：デフォルトの名無しさん：2006/07/22(土) 07:54:31

Whitespaceのソース、美しいとは思わんな

43 ：デフォルトの名無しさん：2006/07/22(土) 19:26:35

最も完結なスクリプト
↓
「明日までにアレやっといてね。」

44 ：デフォルトの名無しさん：2006/07/22(土) 23:35:56

return "㍉" ;

45 ：デフォルトの名無しさん：2006/07/23(日) 16:16:18

まあこの世で最も美しいのは俺だけどな

46 ：デフォルトの名無しさん：2006/07/23(日) 23:18:22

ユダ乙

47 ：デフォルトの名無しさん：2006/07/24(月) 12:39:04

C#はきれいだと思う

frameworkは糞だがw

48 ：デフォルトの名無しさん：2006/07/24(月) 13:59:02

System F

49 ：デフォルトの名無しさん：2006/07/24(月) 23:08:22

C にオブジェクト指向を足しただけのような言語が欲しいな。

50 ：デフォルトの名無しさん：2006/07/24(月) 23:18:33

>>49
つ[ObjectiveC]

51 ：デフォルトの名無しさん：2006/07/25(火) 02:50:01

>>49
Objective-C

52 ：デフォルトの名無しさん：2006/07/25(火) 02:53:44

ファミリーベーシック

53 ：デフォルトの名無しさん：2006/07/26(水) 23:47:48

しかし、Objective-CはCとは別物という罠

54 ：デフォルトの名無しさん：2006/07/26(水) 23:57:08

だって別の欲しいんだろ？

55 ：デフォルトの名無しさん：2006/07/27(木) 00:24:33

Cにtemplateを足しただけのような言語が欲しいな。

56 ：デフォルトの名無しさん：2006/07/27(木) 00:52:11

>>49
GuidelinesC++

57 ：デフォルトの名無しさん：2006/07/27(木) 11:12:03

なんかどんどんマニアックなのが出てきそうだな

58 ：デフォルトの名無しさん：2006/07/27(木) 16:10:56

Objective-C++

59 ：デフォルトの名無しさん：2006/07/27(木) 21:00:44

>>55
C++でOOPしないと心に決めてかかればいいだろ。

60 ：デフォルトの名無しさん：2006/07/27(木) 22:39:08

THINK-C

61 ：デフォルトの名無しさん：2006/07/27(木) 23:22:22

だれかC--つくって

62 ：デフォルトの名無しさん：2006/07/28(金) 01:55:01

まぁ、既にあるわけだが。

http://www.cminusminus.org/index.html

C++ みたいにコンパイル速度劇遅じゃなく、
Objective-C みたいに実行速度劇遅じゃない、
OCaml みたいに見た目が小汚くなく、
C をちょっと便利にしたような言語が欲しい。
出来れば REPL 付きで。

63 ：♥　殿舎男秋葉系? ◆ej9/UehK8Y ：2006/07/28(金) 08:10:25

アセンブラ

64 ：デフォルトの名無しさん：2006/07/29(土) 02:48:59

そういやＦ言語ってどうなったんだろうか

65 ：デフォルトの名無しさん：2006/07/29(土) 17:59:27

織田信長

完全に名前勝ち

66 ：デフォルトの名無しさん：2006/07/30(日) 00:22:01

アンラムダは？

67 ：デフォルトの名無しさん：2006/07/30(日) 01:26:34

BrainfuckYOU!

68 ：デフォルトの名無しさん：2006/07/30(日) 02:07:29

いっこうに1.0にならない言語->nasm

69 ：デフォルトの名無しさん：2006/07/30(日) 16:33:23

Brainfsck（なぜか読めない）とかWhitespace
あとShakesphereもアリかな

だがここはあえてBASIC

70 ：デフォルトの名無しさん：2006/07/30(日) 20:07:34

ttp://www.dangermouse.net/esoteric/chef_fib.html
まるでわからない

71 ：デフォルトの名無しさん：2006/07/30(日) 20:22:32

>>70
これはなかなか面白いな

72 ：デフォルトの名無しさん：2006/07/30(日) 20:53:50

ttp://www.dangermouse.net/esoteric/piet/samples.html
こいつも上手に組めば美しくなるはず
美しくするためだけに労力を費やす必要がありそうだが

73 ：デフォルトの名無しさん：2006/07/30(日) 23:03:13

C++は自然言語より複雑なのでは
と思う今日この頃

74 ：デフォルトの名無しさん：2006/07/31(月) 00:21:08

>>73
C++は無限に増殖を続ける自然言語だよ。
ただでさえチューリング完全なテンプレートが仕様にある上に、
そのテンプレートを利用したライブラリが標準として仕様になっているのだから
これはもう無限に仕様の拡大を将来に約束してしまったようなものだ。

75 ：デフォルトの名無しさん：2006/07/31(月) 07:58:57

↑アホ

コンパイル時にプログラムできる機構ぐらいで
「無限に増殖を続ける自然言語」って、バカじゃねーの。

76 ：デフォルトの名無しさん：2006/07/31(月) 08:07:50

まぁ、ここまで全力で釣られてくれたら
age厨も本望だろうよ。

77 ：デフォルトの名無しさん：2006/07/31(月) 21:35:40

お前等の釣りや冗談すら理解できない俺ガイル

78 ：デフォルトの名無しさん：2006/08/01(火) 02:27:18

となると話の流れ的にもっとも美しい言語は
「ライフゲーム」ということでよろしいか？

79 ：デフォルトの名無しさん：2006/08/01(火) 05:39:39

C# for API2

80 ：♥　殿舎男秋葉系? ◆ej9/UehK8Y ：2006/09/02(土) 11:26:00

機械語

81 ：デフォルトの名無しさん：2006/09/04(月) 08:29:37

ソースコードの見た目はpythonかなぁ

82 ：デフォルトの名無しさん：2006/09/05(火) 03:46:41

ついに1000体突破かよ
アイロボットみたいだな
株ロボもいつか夢を見るようになるのかなぁ

83 ：デフォルトの名無しさん：2006/09/05(火) 03:53:38

regex

84 ：デフォルトの名無しさん：2006/09/05(火) 04:05:07

COBOL
触ればわかる美しさ

85 ：デフォルトの名無しさん：2006/09/05(火) 04:15:32

ttp://www.shiro.dreamhost.com/scheme/trans/hundred-j.html

>生物種と同様に、言語も枝分かれや行き止まりが
>そこらじゅうにある進化の系統樹を形成する。
>既にその一部は現在でも観て取れる。 Cobolは、
>かつてあれだけ流行ったのに、知能ある子孫を
>残してはいないようだ。それは進化の行き止まり、
>ネアンデルタール言語なんだ。

86 ：デフォルトの名無しさん：2006/11/01(水) 20:44:34

とりあえず、無限とかいう言葉を平気でいえるやつは
プログラマとしてはどうかと思う

87 ：デフォルトの名無しさん：2006/11/02(木) 04:28:08

for(;;) {
// 無限ループ
...
}

88 ：デフォルトの名無しさん：2006/11/04(土) 13:35:11

double.PositiveInfinity

89 ：デフォルトの名無しさん：2006/11/20(月) 07:08:47

意外にjavascriptって言語としては綺麗じゃね？

90 ：デフォルトの名無しさん：2006/11/20(月) 07:14:38

関わってる面子見れば全然意外じゃない

91 ：デフォルトの名無しさん：2006/11/20(月) 20:40:37

>89
lisp の物マネ言語だからな。
当たり前。

92 ：デフォルトの名無しさん：2006/11/20(月) 20:41:58

>>91
リスプが美しいと思うのなら魔道に堕ちてる気がするが
そのへんは大丈夫だよね・・・

93 ：デフォルトの名無しさん：2006/11/20(月) 21:13:44

>>90
Guy Steele しか知らないけど、他にも有名な人が多いの?

94 ：デフォルトの名無しさん：2006/11/20(月) 21:43:45

またLISPERの起源説か。

95 ：デフォルトの名無しさん：2006/11/21(火) 09:20:38

全ての言語はlispが起源ニダ

96 ：デフォルトの名無しさん：2006/11/21(火) 12:19:38

APLの美しさ、そして禍々しさ・・・
なめてもらっては困るな

97 ：デフォルトの名無しさん：2006/11/21(火) 12:25:51

言語ではなく書く人次第

98 ：デフォルトの名無しさん：2006/11/21(火) 21:17:57

じゃあ、最も美しいプログラマは誰？

99 ：デフォルトの名無しさん：2006/11/21(火) 21:23:31

>>98
わたくしザマス

100 ：デフォルトの名無しさん：2006/11/22(水) 00:50:49

OOPになって、言語の重要性は低下しているなぁ。クラスライブラリこそ命。

101 ：デフォルトの名無しさん：2006/11/22(水) 01:11:42

>>100
ライブラリが命になるように、
言語仕様をコンパクトにまとめる事こそ
一番重要だと思う。

102 ：デフォルトの名無しさん：2006/11/22(水) 09:20:01

俺としてはやはりN-88BASICを推したい。goto文を駆使し、あらゆるところにジャンプする様は美しい。DATA文の後の16進数の並びは何物にも変え難い。pokeで手当たり次第にメモリに読み込む様を見ると死にたくなるほどの絶頂を感じる

103 ：デフォルトの名無しさん：2006/11/22(水) 09:42:05

brainfuckを忘れてもらっては困る

104 ：デフォルトの名無しさん：2006/11/22(水) 12:57:21

モールス信号の二番煎じにすぎぬわ！！

105 ：デフォルトの名無しさん：2006/11/23(木) 01:48:56

Lispのマクロより美しいものがあるだろうか？

106 ：デフォルトの名無しさん：2006/11/23(木) 01:54:18

あれより「強い」ものなら無いかもしれないが

107 ：デフォルトの名無しさん：2006/11/23(木) 02:17:30

なでしかまたはひまわら

108 ：デフォルトの名無しさん：2006/11/23(木) 12:40:10

109 ：デフォルトの名無しさん：2006/11/23(木) 15:36:52

Lispは使った事がないから分らないけど
書いてて気持ちいいのはpythonだね

110 ：デフォルトの名無しさん：2006/11/23(木) 16:23:59

(if (is? Lisp (beautiful language)) (= you magician) (= you (of one people)))

111 ：デフォルトの名無しさん：2006/11/23(木) 16:36:28

スクリプト系は全般的にシンメトリーじゃないからキモチワルイ

112 ：デフォルトの名無しさん：2006/11/23(木) 17:14:24

お前IronPythonスレにもいたな

113 ：デフォルトの名無しさん：2006/11/23(木) 17:16:39

それはお前だろ

114 ：デフォルトの名無しさん：2006/11/23(木) 18:44:04

言語がシンメトリーってどういう事だ?
直行性が低いとか、そういう意味で言ってる?

115 ：デフォルトの名無しさん：2006/11/23(木) 19:12:50

VB.NETが最高だと思います。

116 ：デフォルトの名無しさん：2006/11/23(木) 21:48:32

左右対称じゃないとビル爆破する建築家も居るくらいだからな

117 ：デフォルトの名無しさん：2006/11/23(木) 22:42:18

西洋人の美的感覚は対称性に支配されすぎてる

118 ：デフォルトの名無しさん：2006/11/23(木) 23:55:48

>>116
とりあえず赤い線切っとけ

119 ：デフォルトの名無しさん：2006/12/01(金) 22:02:21

>>118
白い線と黒い線しかない場合はどうしたらいいですか？

120 ：デフォルトの名無しさん：2006/12/01(金) 22:36:28

>>119
パンティだと考えれば自ずと答えは出るだろう

121 ：デフォルトの名無しさん：2007/01/19(金) 11:23:48

>>118
ラッキーカラーだからなw

122 ：デフォルトの名無しさん：2007/01/22(月) 19:29:27

歳がばれる

123 ：デフォルトの名無しさん：2007/02/08(木) 18:09:51

OOは全部失格です。

124 ：デフォルトの名無しさん：2007/03/21(水) 16:55:59

MS-BASIC、C、アセンブリャー（Z80、MC68000）、C++、Java、Perl、JavaScriptとやってきたゲーム系。

んで、エロい人がみんな関数型言語やっとけ言ってて怖いんだけど、どれくらいやればええのん。
入門サイト一通り見た限りではﾌｰﾝとしか思わなかったのだが。
何か新しい知見やカルチャーショックがあるでもなかったし。

もっと踏み込まないとダメなのか？
でも、別にやることがないから、踏み込もうにも踏み込む場所がないのだが。

125 ：デフォルトの名無しさん：2007/03/21(水) 17:08:07

>>124
ゲームの一つでも作ってみたら?

126 ：デフォルトの名無しさん：2007/03/21(水) 17:47:03

>>124
関数型言語って何やったの？あんたの経験した言語から見たら型のパターンマッチや
カリー化、末尾再帰の最適化と新しいことだらけだと思うけど。

127 ：デフォルトの名無しさん：2007/03/21(水) 19:07:57

末尾再帰最適化は、あくまで「関数型に合わせた」仕様でしょ。
普通にループすりゃいいのに。

128 ：デフォルトの名無しさん：2007/03/21(水) 19:10:22

型のパターンマッチってポリモルフィズ無となにがちがうのん？

129 ：デフォルトの名無しさん：2007/03/21(水) 21:56:02

カリー化はともかく、その他の2つはそんなに重要でもないと思う。
型のパターンマッチはC++のテンプレートの特殊化・部分特殊化だって似たような感じだったと思うし、
末尾再帰の最適化は手続き型言語でも一応（コンパイラの中の人担当だが）出てくる。
それよりも副作用の無さを挙げるべきだと俺は思う。

130 ：デフォルトの名無しさん：2007/03/21(水) 22:26:35

C++ は参照透明な言語であるという話を思い出した

131 ：デフォルトの名無しさん：2007/03/24(土) 05:04:13

過去レス読まずにｶｷｺ
美しいの定義が非常に難しいけど個人的にはC#が今のところもっとも美しいと思う

C++はポインタがうるさくて美しくない
JavaはCOBOLチックな過剰なコードを要求する汚さが合って美しくない
perlは変数の表現が美しくない
VBもCOBOLチックな過剰なコードを要求するし、勝手にソース加工しやがるから美しくない

132 ：デフォルトの名無しさん：2007/03/24(土) 08:47:24

＞C++はポインタがうるさくて美しくない
それはポインタを使うから。C++なら明示的なポインタは(必ずしも)言語仕様的には必要としない。

＞JavaはCOBOLチックな過剰なコードを要求する汚さが合って美しくない
美しさの根拠として汚さを持ち出すのは意味が無い。

＞perlは変数の表現が美しくない
同意。

＞VBもCOBOLチックな過剰なコードを要求するし、勝手にソース加工しやがるから美しくない
ソースを加工するのは言語仕様か? 処理系が糞なだけだろ。

133 ：デフォルトの名無しさん：2007/03/24(土) 23:56:37

C#は言語は美しいが・・・
.Net Frameworkはライブラリがヘボイ。
ビジュアルコンポーネントがヘボイ。
ソース付いてないから勉強にならん。

134 ：デフォルトの名無しさん：2007/03/25(日) 00:29:30

プログラマの心情としてシンプルなものが美しいという点に異論はなかろう。
もっとも文法のルールが少ないものが一番美しい言語。

135 ：デフォルトの名無しさん：2007/03/25(日) 01:17:45

文法のルールが少ないからといって美しいとは限らないから却下。

136 ：デフォルトの名無しさん：2007/03/25(日) 02:36:40

文法のルールが少ない、というのは
書き方の自由度が多いのか少ないのか、どっちだろう

137 ：デフォルトの名無しさん：2007/03/25(日) 13:14:46

>>134
そうかな

138 ：デフォルトの名無しさん：2007/03/25(日) 13:29:25

>>133
全部ではないがShared Source CLIである程度のソースは公開されている。

139 ：デフォルトの名無しさん：2007/03/25(日) 18:19:05

>>134
つまりBrain F(以下略

140 ：デフォルトの名無しさん：2007/03/25(日) 19:06:23

>>139
おいおい、8命令も存在する言語なんてシンプルじゃないだろ
つまりHQ9+が(以下略

141 ：デフォルトの名無しさん：2007/03/26(月) 22:20:53

あれれ、OOは全部失格と書いておいてのだが復活しているな・・・。まあ、
たまに覗いて文句をいう筋合いでもないが。

142 ：デフォルトの名無しさん：2007/03/27(火) 06:45:21

日本語でおｋ

143 ：デフォルトの名無しさん：2007/05/05(土) 18:05:46

Ook!も美しい言語なのかな。
Ook.とOok!とOok?だけしかないし。

144 ：デフォルトの名無しさん：2007/05/05(土) 18:10:46

JAVaを中心に世界が回っているって本当ですか？

145 ：デフォルトの名無しさん：2007/05/05(土) 18:15:55

正確に言えば、コアを中心に地球が回ります。

146 ：デフォルトの名無しさん：2007/05/05(土) 18:26:54

>>144
すみません。私は無知なため知りません。

147 ：デフォルトの名無しさん：2007/05/05(土) 20:48:14

lispが一番美しい

148 ：デフォルトの名無しさん：2007/05/05(土) 21:29:38

Haskell, Lisp, C

149 ：デフォルトの名無しさん：2007/05/06(日) 00:09:20

>>133
アレは、配布している.NETランタイムとは実装だぞ。

150 ：デフォルトの名無しさん：2007/05/06(日) 07:26:17

JAVA:106
C++:91
C言語:61
PHP:28
C#:25
VBA:24
VB.NET:26
JavaScript:22
Perl:13
ASP.NET:12
JSP:12
アセンブラ：9
VB6:8
ActionScript:1
Ruby:1

松下エクセルスタッフ
http://tech.excelstaff.jp/index.php

151 ：デフォルトの名無しさん：2007/05/06(日) 12:23:12

>>150
汚いもの貼るなよ

152 ：デフォルトの名無しさん：2007/05/06(日) 13:21:35

Turing 機械は 1 命令だけど美しいかなぁ。数学やるのには楽だけど。
あと、構文が 3 つしかないのは Smalltalk?

6809 のアセンブラとか美しかった気がする。

153 ：デフォルトの名無しさん：2007/05/06(日) 16:03:50

>>152
Prologはひとつ? 　それとも
':-'/1 と ':-'/2 と '?-'/1 の3通りかな

154 ：デフォルトの名無しさん：2007/05/07(月) 01:31:10

Brainfuckに一票
+++++++++[>++++++++>+++++++++++>+++++<<<-]>.>++.++
+++++..+++.>-.------------.<++++++++.--------.+++.
------.--------.>+.

155 ：デフォルトの名無しさん：2007/05/08(火) 05:56:11

>>153
a.
b.
c:-a,b.
これを美しいというか、ということですね。

156 ：デフォルトの名無しさん：2007/05/08(火) 13:14:03

>>155
再帰の表現は、LispよりPrologの方が美しいよ．

157 ：デフォルトの名無しさん：2007/05/08(火) 13:44:07

r.
r:-r.

158 ：デフォルトの名無しさん：2007/05/08(火) 15:37:59

>>156
それなら、最も美しい言語の候補に挙げない理由は?

159 ：デフォルトの名無しさん：2007/05/08(火) 15:43:11

挙げる義務が無いから。

160 ：デフォルトの名無しさん：2007/05/08(火) 17:06:33

>>158
確かにこのスレではPrologは一度も出てこない。私があげない理由は、
1) 論理は超時間的な筈なのに、Prologとなると実行速度が遅いためか、
導出(反駁)が、動力車が働いているような実時間的な印象になってしまう。
ラファエロの絵にミケランジェロが描き加えているような感じ。
2) 双方向性が完全に確保できていれば、断じて第一席に推すが、実際には
20-30%のコードしかこのように働かない。いささか中途半端。
3) 視覚的な美にいまひとつ。徹底して不均整、左右非対称。
4) 反対に「美は乱調にあり」をよしとすれば、今度は二次元の木構造が
見えすぎて、乱れがなさ過ぎる。もうちょっとハイパーなところがあってもよい。

161 ：160：2007/05/08(火) 18:30:27

どんな言語でも推薦しない理由なら切りなく挙げられる。
ネタにしかならなかったね。

162 ：デフォルトの名無しさん：2007/05/08(火) 22:53:34

素朴な疑問:
boost って, なんであんな不毛な努力してるんですか?
言語設計からやり直した方が良さげに見えるんですけど...

163 ：デフォルトの名無しさん：2007/05/08(火) 22:59:41

>>162
その疑問に対する回答じゃないが、boost の全てが統合失調症じみてるわけじゃないぞ。
標準化に間に合わなかっただけで、普通に共通部品(ライブラリ)として相応しいものもある。

164 ：デフォルトの名無しさん：2007/05/08(火) 23:21:44

>>163
> 普通に共通部品(ライブラリ)として相応しいものもある。

bind とか fanction とか fanctor とか lambda とか....
あの枠組みでやるには苦しいなぁ... ...
言語仕様少しつつけば何とかなるんでねぇの???

と, 思っただけなんで, 深く考えての発言じゃないっす.

165 ：デフォルトの名無しさん：2007/05/08(火) 23:49:07

美しいかどうか微妙だけど、ちょっとかわいい。
The Cat Programming Language
ttp://www.cat-language.com/

166 ：デフォルトの名無しさん：2007/05/09(水) 18:20:36

C++が美しくないって言ってる椰子は何を理由としてるんだ
複雑で難解なため？
要素を詰め込みすぎて統一性に欠けるため？
重箱の隅を突くようなルールが多すぎるため？

そういう理屈からいくと日本語あたりは
自然言語の中で相当美しくない部類に入るな

俺の美意識からするとC++は最も美しい言語の一つ

167 ：デフォルトの名無しさん：2007/05/09(水) 18:34:08

なぜか LL(1) 文法　の言語が美しく感じられる。
高級ではないが美しい

168 ：デフォルトの名無しさん：2007/05/09(水) 18:36:12

>>166
> そういう理屈からいくと日本語あたりは
> 自然言語の中で相当美しくない部類に入るな

それがどうかしましたか？

169 ：デフォルトの名無しさん：2007/05/09(水) 19:53:39

>>164
bindとfunctionは、次期規格C++0xで標準入り確定と見てよい。もうTR1に入っている。
lambdaは、言語仕様の改良も含め色々提案が出ているようだが、決定打がない模様。

ところで俺は、今まで広く使われてなお輝きを失っておらず、
ファンがいる、使っているところがあるというところにC++の美しさを感じる。

170 ：デフォルトの名無しさん：2007/05/09(水) 20:21:17

>>166
日本語は文法が整然としていて綺麗な言語ですが。。。

171 ：デフォルトの名無しさん：2007/05/09(水) 20:26:56

日本語の美しい点は、何より速読性に優れている事だな。
斜め読みがこんな簡単な表現法は無いぞ
漢字ばかりの国やアルファベットだけの国の人はかわいそす

172 ：デフォルトの名無しさん：2007/05/09(水) 20:28:09

>>166
それでどこが美しいのですか?

173 ：166：2007/05/09(水) 20:36:35

>>170
例えば「黒い瞳の大きな女の子」
たったこれだけの言葉に何通りの解釈が可能か？
これは日本語の文法が如何に曖昧であるかの証明
意思疎通不可能にすら思える方言多数
漢字、平仮名、片仮名など文字があまりに多い
これらを考えると整然とした言語とは到底いえない

だが、だからこそ豊かな文章表現が可能な美しい言語だと思う
ルールが少ないとか、ここでよく挙がっているような（プログラム言語の）美しさ
の基準からすると日本語は美しくないということになりかねん

俺の言いたいのはそういうことだ
文章力不足でｽﾏｿ

174 ：デフォルトの名無しさん：2007/05/09(水) 21:04:04

COBOLに一票。
ただし正書法フルスペックで書くこと。
一切の省略を無くせば、これ以上の言語はShakesphereくらいだろう。

175 ：デフォルトの名無しさん：2007/05/09(水) 21:39:46

>>173
文章力不足でｽﾏｿ
全くだな

ところで
日本語が美しかろうと美しくなかろうと、どうでもいいじゃん。
そんで、何語なら美しいって言うんだい？

ここは自然言語のスレッドじゃないはずだが、、、

176 ：173：2007/05/09(水) 21:47:06

>>175
>そんで、何語なら美しいって言うんだい？
C++だって言ってんだろｶｽ
あれほど何でも書ける自由な言語は他にない

揚げ足とるくらいならせめて読んでから言え>>175

177 ：デフォルトの名無しさん：2007/05/09(水) 23:15:25

ひまわり

178 ：デフォルトの名無しさん：2007/05/09(水) 23:41:03

>>176
手続的な意味で、出現順を変えたらまったく違った意味になってしまうのではないか?
「あれほど自由」とはとても思えないが・・

179 ：デフォルトの名無しさん：2007/05/09(水) 23:44:57

>>178
それはお前が遅延評価処理を書けないってだけの話。

180 ：デフォルトの名無しさん：2007/05/09(水) 23:51:21

>>176
>あれほど何でも書ける自由な言語は他にない
>
>揚げ足とるくらいならせめて読んでから言え>>175

断定するくらいならせめてその証拠となる具体例を出してから言え>>176

181 ：デフォルトの名無しさん：2007/05/09(水) 23:54:02

わかるけど、そこで解釈させるであろう並列的なコードは
もはやC++であるとは言えない。

182 ：デフォルトの名無しさん：2007/05/09(水) 23:58:50

>>181
確かに。 C++ で、Lisp コンパイラ(インタプリタ)でも書いて、
ほらLispでできることは全部C++でできるよ！って言うようなもんかｗ

183 ：デフォルトの名無しさん：2007/05/09(水) 23:59:10

アセンブリは美しい

184 ：デフォルトの名無しさん：2007/05/10(木) 00:19:57

>>181
>もはやC++であるとは言えない。
は？言語の標準に完全に則してるのにC++でないってどういうことだ

>>182
意味不明。例えにすらなってない。
考えもせずに他人の尻馬に乗るのは頭悪く見えるぞ？

185 ：デフォルトの名無しさん：2007/05/10(木) 00:25:51

言語よりも俺様の方が美しい

186 ：デフォルトの名無しさん：2007/05/10(木) 00:44:18

いっそのこと、プログラム言語 Most Beautiful でも作れや・・・

187 ：デフォルトの名無しさん：2007/05/10(木) 01:00:10

「レベル４以上のスパゲッティプログラム３体を生贄に、
２４番目のプログラミング言語「Alcai son na MON」を召喚！」

「な、なに！美しさ４０００だと！？」

188 ：デフォルトの名無しさん：2007/05/10(木) 01:02:48

>>184
尻馬っていうなよ、自演なんだから。

189 ：デフォルトの名無しさん：2007/05/10(木) 01:55:18

>>176
> C++だって言ってんだろｶｽ
> あれほど何でも書ける自由な言語は他にない

それ以上のことがlisp系の言語で出来るてるんだが…
つか、ほとんどLisp系言語の後追いじゃん、C++って

つぎは、continuationのfirst citizen化ですか？

190 ：デフォルトの名無しさん：2007/05/10(木) 02:15:16

>>189
> それ以上のことがlisp系の言語で出来るてるんだが…
具体例をあげてくれ
> ほとんどLisp系言語の後追いじゃん、C++って
は、どこが？だから言うなら具体例をあげろよ

C++で関数型プログラミングは可能だが
Lisp系で手続き型やOOって可能なの？
論理型プログラミングは？ジェネリック指向は？

191 ：178：2007/05/10(木) 07:32:23

上田和紀氏設計の並列論理型言語 GHC の言語仕様を
思いおこしての書き込みなんだが。

192 ：デフォルトの名無しさん：2007/05/10(木) 07:52:05

>>190
>具体例をあげてくれ

continuationのfirst citizen化じゃね？ｗ

>Lisp系で手続き型やOOって可能なの？

余裕で可能
というか、OOを一番最初にやったのはLisp(ｗ

>論理型プログラミングは？ジェネリック指向は？

これも可能
ジェネリックという意味じゃLispが究極ｗ

193 ：デフォルトの名無しさん：2007/05/10(木) 08:38:35

>>192
> というか、OOを一番最初にやったのはLisp(ｗ

つsmalltalk

194 ：デフォルトの名無しさん：2007/05/10(木) 09:19:11

>>190はLispが関数型言語だと思ってる人なんじゃね？

195 ：デフォルトの名無しさん：2007/05/10(木) 09:30:22

C++もLispも「マルチパラダイム言語」ってやつの代表格だな。

196 ：デフォルトの名無しさん：2007/05/10(木) 10:09:39

Lispは遅くね？　

現実的な選択はC++と思う．

197 ：デフォルトの名無しさん：2007/05/10(木) 10:13:47

C++は #include　が美しくない
最近の言語のモジュール化の仕組みの方が美しい

198 ：デフォルトの名無しさん：2007/05/10(木) 10:58:31

むかしスポーツメーカーのコピーに
速いものは必ず美しい
っていうのがあったけれど、プログラム言語の世界で
自由なものは必ず美しい
っていうのはどんなものだろうね。みんなの感想をききたい。

199 ：デフォルトの名無しさん：2007/05/10(木) 11:10:32

美に指標はいらない。　各自が満足すればいいんだよ

200 ：デフォルトの名無しさん：2007/05/10(木) 11:32:13

>>193
SmalltalkよりもCommonLispのCLOSのほうが公式な言語としては
早かったはず

201 ：デフォルトの名無しさん：2007/05/10(木) 11:54:43

「公式」ってのがよくわからんが、公式じゃなくてもいいのなら
CLOSよりSmalltlakのほうが早いしSimulaのほうがもっと早いだろ
あとLISPならCLOSよりFlavorsの方が早いぞ
LISPが最初というのも、Flavorsが最初に多重継承とMix-inをやったってのと
勘違いしてないか？

202 ：デフォルトの名無しさん：2007/05/10(木) 11:57:39

美しさで言うなら、Lispの括弧は汚い。

203 ：デフォルトの名無しさん：2007/05/10(木) 12:59:19

MACLISP にもOOのモジュールがあった。私が使ってみたのは1980年以降で
いつ頃組み込みまれのかはわからない。MACLISPは1970年代前半から開発
されていたはずだけれど、OOの追加時期はずっと遅いのではないかと思う。

204 ：デフォルトの名無しさん：2007/05/11(金) 17:47:36

OOは汚い。

205 ：デフォルトの名無しさん：2007/05/12(土) 05:30:50

OOはウンコしたあと手を洗わないらしいからね。

206 ：デフォルトの名無しさん：2007/05/12(土) 09:28:12

コンストラクタとクラス名が同じＯＯ言語なんて学ばせちゃいけねーよ

207 ：デフォルトの名無しさん：2007/05/12(土) 11:01:39

> ＯＯ
全角ｗｗｗ頭悪そうｗｗｗ

# 全角って何ですか?

208 ：デフォルトの名無しさん：2007/05/12(土) 11:56:04

標準化されたのはCLOSの方が早いね。

209 ：デフォルトの名無しさん：2007/05/13(日) 16:37:42

CLOSというのは1990年代の中頃に開発されたと思い込んでいました。
そんなに古い言語なのですか。

210 ：デフォルトの名無しさん：2007/05/13(日) 20:04:28

ヒント：SmallTalkが標準化されたのは何年？

211 ：デフォルトの名無しさん：2007/05/13(日) 20:44:23

CLOSが開発されたのは1980年代

212 ：デフォルトの名無しさん：2007/05/13(日) 20:55:53

これからはサーバーもクライアントも全部Pythonで統一するらしいよ。

Python以外の言語は、なくされ、つくられないらしい。

213 ：デフォルトの名無しさん：2007/05/13(日) 23:01:06

>>210
その疑問に対する正しい答えは「SmallTalk などという物が標準化された事はありません」だね。
冗談はさておき、ANSI Smalltalk より ANSI Common Lisp のが時期はだいぶ早かったと思う。

214 ：デフォルトの名無しさん：2007/05/26(土) 21:25:09

Whitespaceがもっとも美しい。

215 ：デフォルトの名無しさん：2007/07/19(木) 19:15:42

俺たちが最も美しい言語を作っちゃえばいいんだ

216 ：デフォルトの名無しさん：2007/07/19(木) 19:30:42

可読性と、読んでて面白いという点で一番はなんといっても

Shakespeare Programming Language
だろ。

217 ：デフォルトの名無しさん：2007/07/19(木) 19:39:30

C++だな。
あまりにも静的。

218 ：デフォルトの名無しさん：2007/07/19(木) 20:21:43

そいつはもう静的というより、コンパイル時と実行時の2度
動的になる瞬間があるといったほうがいいと思う。

それ以上のLispなども同じ。

219 ：デフォルトの名無しさん：2007/07/19(木) 21:34:42

オブジェクト指向言語は対象外です

220 ：デフォルトの名無しさん：2007/07/23(月) 22:53:31

どういう感じのが美しいのか
お前ら勝手に言語を脳内で創作してHello,worldを理想系で書いてください
もちろん応用が利く形でなければ

221 ：デフォルトの名無しさん：2007/07/23(月) 22:58:23

Hello,world

222 ：デフォルトの名無しさん：2007/07/24(火) 00:16:15

頼むッ！
標準出力にこれからオレが伝える11文字を書いてくれ！
その10文字は 'Hello,world' だッ！
頼んだぜッ！！

223 ：デフォルトの名無しさん：2007/07/24(火) 00:28:27

あーん? 聞こえんなぁ。

224 ：デフォルトの名無しさん：2007/07/24(火) 06:54:29

Hello, worldを出力しろ

225 ：デフォルトの名無しさん：2007/07/24(火) 08:43:01

'Hello,world' が美しくないのが問題だね。どちらかというと滑稽。

226 ：デフォルトの名無しさん：2007/07/24(火) 10:33:50

test(いつもの)

227 ：デフォルトの名無しさん：2007/07/24(火) 11:57:34

逆に言えば、たかが Hello, world と表示させるのに長々とおまじないが必要な言語は醜いな、

Java とかｗ

228 ：デフォルトの名無しさん：2007/07/24(火) 12:33:33

cout << "Hello, world";

229 ：デフォルトの名無しさん：2007/07/24(火) 13:01:36

内容としては間違ってないと思うから書いておく

1995年　5月23日　Java言語発表　
1995年　某日　日本映画初CG作品「学校の怪談」でプログラムが世に認められる
1995年　11月23日　Windows95が発売　爆発的ブームになる

現在に至る

今のオープンフェイスOSが存在するのは、Java+CGの影響に著しく関与する

230 ：デフォルトの名無しさん：2007/07/24(火) 13:51:08

C や Java のような命令型言語っていつまで使われるんでしょうね

231 ：デフォルトの名無しさん：2007/07/24(火) 14:31:35

えっ、全部宣言型になるということ?

232 ：デフォルトの名無しさん：2007/07/24(火) 14:37:48

そうか、宣言型の対は手続き型だった。

233 ：デフォルトの名無しさん：2007/07/24(火) 22:26:53

確かに最近のC++はどんどん宣言型っぽくなってるな。

ネタレスすると、命令じゃなく嘆願型になると大胆予想。
preare句やexcuse句から始まるコードになる。

234 ：デフォルトの名無しさん：2007/07/24(火) 22:27:46

lとr間違えた… orz

235 ：デフォルトの名無しさん：2007/07/24(火) 22:39:39

C++ が宣言型っぽく見えるためには、どんな修行を積めばいいですか？

236 ：デフォルトの名無しさん：2007/07/24(火) 23:00:33

>>235
まずは宣言型の言語を全て忘却する所からだな
その後、C++ こそが宣言が他言語であるとひたすら刷り込む

237 ：デフォルトの名無しさん：2007/07/24(火) 23:05:39

>>235
l と r を間違える。

238 ：デフォルトの名無しさん：2007/07/25(水) 01:43:48

ひまわり

239 ：デフォルトの名無しさん：2007/07/25(水) 01:48:43

くのいちＴＶ
http://www.freewebs.com/activetv/?X2/?YTV=kayukayutamaking+Ninja+Girl

240 ：デフォルトの名無しさん：2007/07/25(水) 02:16:07

この手のスレでschemeが話題にならないのはどうしたことか。
別のスレでこんな事議論してるが、
http://pc11.2ch.net/test/read.cgi/tech/1185010023/55-
やはりschemeの美しさは異常

241 ：デフォルトの名無しさん：2007/07/25(水) 03:45:42

ま、こんな感じの定義になるのかな

S＝プログラムの仕様の適当な有限集合
d＝言語仕様の「長さ」（e.g. formal semantics の長さ）
c(s)＝「仕様　s∈S　を満たす最小のプログラム長」
A, B＝適当な定数

美しさ＝A*d + B*min c(S)　（小さい方が美しい）

242 ：デフォルトの名無しさん：2007/07/25(水) 03:46:00

Wikipediaの宣言型言語の右側に、プログラム言語一覧がある。
RPGが命令型に分類されているのだが、あれは、デシジョンテーブルに
記述することによって実行を制御してるから宣言型ではないかな。

243 ：デフォルトの名無しさん：2007/07/25(水) 03:48:17

ちがうか、こうか

×美しさ＝A*d + B*min c(S)　（小さい方が美しい）
○美しさ＝A*d + B*max c(S)　（小さい方が美しい）

244 ：デフォルトの名無しさん：2007/07/26(木) 11:54:23

writeline( 何か小粋な文句 );

245 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 15:25:52

OOPになって、言語の重要性は低下しているなぁ。クラスライブラリこそ命。

246 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 15:32:26

プログラミング言語からすると、日本語は美しくないよなぁ

247 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 16:08:35

>>245
OOPになって、言語の美しさは低下しているなぁ。辞書引きこそ命。

248 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 16:52:14

OOPL だって辞書引きしてるけど?

249 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 17:06:11

可読性の無い言語は全部クソ

ごめんなさいごめんなさいごめんなさい

250 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 17:07:30

C++ に謝れ

251 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 17:47:05

OOPL の失敗から学ぶことは多かった、そういう意味でだけ OO は評価できる

252 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 17:50:57

パラレルワールドから来た人か?
殆ど全ての言語がオブジェクト指向化されたこの時代に…

253 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 17:58:35

もともと OO なんて Lisp でウインドウシステムを作るために開発された
アドホックなコーディングテクニック（loops, flavors, ...) に過ぎないんだがね
理論的に言えば単なる subtyping

254 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 18:04:31

>>252
美しさという観点からはOOを取り込んだ言語はやはり失格!

255 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 18:18:19

>>254
Smalltalk は美しいぞ。Lisp 並みに文法のルールが少ない。

256 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 18:20:15

Lisp から見れば OO なんて単なるライブラリ拡張だからどーでもいい
いまだにオブジェクト指向（８０年代の香りプンプン）が、とか言ってる人もいるんだねｗ

ま、そういう素人さんはスルーするとして、

Lisp は確かに一つの候補ではあるが最も美しいかというと同意は出来ない。
OO 程度ライブラリで実現出来る（実際俺のいた某Ｔ大では演習問題だったｗ）
というグルーの強力さは類を見ない。

何となく漠然としているが、まず最低限の要求事項として strongly-typed language
であることが上げられる。（まあタイプシステムに理論的にも汚い subtyping (= OO) を導入するかは悩むが）

その上で、言語仕様が簡潔であり（従って Haskell は NG）かつ Lisp 並みの
強力なグルーを有していることが上げられる。

257 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 18:31:58

８０年代以前から来た人ｷﾀｰ

258 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 18:34:15

OO 除外という点は同意

259 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 18:36:42

すげえ、このひと自分に同意してるわ…

260 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 19:16:14

C++ に謝れ

261 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 19:40:31

>>256
なんだかよくわからないが、
strong-typed language が美しいという確信は
どこからでてくるのかな。

262 ：デフォルトの名無しさん：2007/07/29(日) 21:37:06

>>261
美しいという曖昧な感覚に確信も糞もなかろう＞Ruby厨

263 ：デフォルトの名無しさん：2007/07/29(日) 21:40:03

Malbolgeって無名なの？

264 ：デフォルトの名無しさん：2007/07/29(日) 21:49:39

黄金比をみたしてない言語はダメだな

265 ：デフォルトの名無しさん：2007/07/29(日) 22:19:04

1/f揺らぎを満たしてない言語はダメだな

266 ：デフォルトの名無しさん：2007/07/29(日) 23:23:42 0

ttp://gazo07.chbox.jp/announcer/src/1185613645761.jpg

267 ：デフォルトの名無しさん：2007/07/29(日) 23:34:59 0

誰？

268 ：デフォルトの名無しさん：2007/07/29(日) 23:56:54 0

>>256
すげえ自信満々だが、９０年代の香りプンプンだな
前世紀からの書き込みですか？

269 ：デフォルトの名無しさん：2007/07/30(月) 00:14:13

ruby厨涙目で反論…すら出来ずｗ

270 ：デフォルトの名無しさん：2007/07/30(月) 00:22:04

>>268
90年代をバカにすんな

271 ：デフォルトの名無しさん：2007/07/30(月) 00:25:03

２１世紀になってからは糞言語しか生まれていない件

272 ：デフォルトの名無しさん：2007/07/30(月) 00:25:59

>>270
９０年代で頭の中が止まったままなら、そういう扱いをされても仕方があるまい

273 ：デフォルトの名無しさん：2007/07/30(月) 00:45:43

GTKについて語るスレはありますか？

274 ：デフォルトの名無しさん：2007/07/30(月) 01:08:56

お前ら>>256の笑い所を間違えてるぞ。
結局どの言語が最も美しいのか、これだけ饒舌で「わかってる俺」をアピールしておきながら、
実際には「意見をまったく言っていない」のがポイントなんだよ。気付いてやれよ、力作なんだから！

275 ：デフォルトの名無しさん：2007/07/30(月) 01:10:03

大漁じゃない

276 ：デフォルトの名無しさん：2007/07/30(月) 01:17:10

>>274
具体的な話をしてしまうと突っ込まれるからじゃないか

277 ：デフォルトの名無しさん：2007/07/31(火) 08:40:37

lispの「それをlispは既に持っていた」は確に強力だけどな。
この頃はC++がそうなりつつあるのが興味深い（それをテンプレートは既に持っていた）
C++はこの先どうなってしまうんだ？
ていうか何指向なのよあの言語

278 ：デフォルトの名無しさん：2007/07/31(火) 08:46:13

あと俺的にはunlambdaが美しいよ。

279 ：デフォルトの名無しさん：2007/07/31(火) 10:52:00

C++のboostは言語界のお笑い

280 ：デフォルトの名無しさん：2007/07/31(火) 12:21:52

>>277
何指向でもかかってきなさい状態

281 ：デフォルトの名無しさん：2007/07/31(火) 12:43:20

>>277
・Cとの互換性はできる限り保つぞ！
・いかなる分野・プラットフォームでも使えるものにするぞ！
・いかなるプログラミングパラダイムも押さえるぞ！
の三本柱を、一言でどう表すべきだろな。

282 ：デフォルトの名無しさん：2007/07/31(火) 12:53:15

よくばり

283 ：デフォルトの名無しさん：2007/07/31(火) 20:42:02

つかCでも大規模開発だとマクロだらけで実質別の言語だよなー。

284 ：デフォルトの名無しさん：2007/08/01(水) 01:58:09

Ｃ＋＋＝砂上の楼閣

285 ：デフォルトの名無しさん：2007/08/01(水) 12:22:27

まあ別にC++は、美しさを狙った言語ではないし。

286 ：デフォルトの名無しさん：2007/08/01(水) 20:45:10

C++は、人間に理解される事を狙った言語でもないね。

287 ：デフォルトの名無しさん：2007/08/01(水) 23:18:44

人間を馬鹿に置き換えれば、まぁその通り。

288 ：デフォルトの名無しさん：2007/08/01(水) 23:42:50

そこを置き換えるのは無粋だな

289 ：デフォルトの名無しさん：2007/08/02(木) 00:46:41

Ｃ＋＋＝最も醜悪な言語、でおｋ？

290 ：デフォルトの名無しさん：2007/08/02(木) 00:53:54

Lispより読める

291 ：デフォルトの名無しさん：2007/08/02(木) 01:14:31

プログラムの意図を掴むのは割と簡単だけど、何であんなに汚いんだろうね。

292 ：デフォルトの名無しさん：2007/08/02(木) 01:16:40

PerlもFREEDAMに書いてあると読めない

293 ：デフォルトの名無しさん：2007/08/02(木) 08:52:58

日本語でおｋ

294 ：デフォルトの名無しさん：2007/08/02(木) 23:19:55

Ｃ＋＋の汚さ、泥臭さ、低脳さが、
学の無い一般的プログラマ（一般大衆）に受けが良かったんだろうな

295 ：デフォルトの名無しさん：2007/08/02(木) 23:23:05

そりゃそうだ。
美しさよりも現実に使い物になるかが重要なんだから。
それをわかっていて、そういう道を選んだのがC++。

296 ：デフォルトの名無しさん：2007/08/02(木) 23:24:15

2行目はもちろん、294の言う学の無い一般的プログラマは、ということね。

297 ：デフォルトの名無しさん：2007/08/03(金) 08:17:37

C++のコンパイラ作れって言われたら泣く

298 ：デフォルトの名無しさん：2007/08/03(金) 08:45:13

コンパイラに適した言語って何だろう？
C++？

299 ：デフォルトの名無しさん：2007/08/03(金) 09:13:50

COBOL

300 ：デフォルトの名無しさん：2007/08/03(金) 09:41:53

>>298
コンパイラを書くのに適した言語ってこと?
ターゲットの言語にもよるけど、C++ はむしろ向いていないよ。

301 ：デフォルトの名無しさん：2007/08/03(金) 10:26:23

>>298
LISPに決まってんだろヴォケ

302 ：デフォルトの名無しさん：2007/08/04(土) 22:23:18

Ｃ＋＋＝最も滑稽な言語、でおｋ？

303 ：デフォルトの名無しさん：2007/08/19(日) 15:24:01

コンパイラに適した言語ねぇ……
Pascal とか思い浮かぶけど美しくは無いねぇ。

言語仕様がコンパクトの方がいいとか言うと万能チューリング機械とかが入っちゃうから嫌だなぁ。

構文規則の割に書きたいことがすらすら短く書けるのがいいかな？

304 ：デフォルトの名無しさん：2007/08/19(日) 15:32:51

>構文規則の割に書きたいことがすらすら短く書ける

Smalltalk はグッド

305 ：デフォルトの名無しさん：2007/08/20(月) 15:39:20

Smalltalk Prolog などが浮かぶけれど、
どちらも、美しいとは言い難いな。
関数型よりまし、という程度。

306 ：デフォルトの名無しさん：2007/08/20(月) 15:52:58

Prolog はシンプルだけど楷書(正書)しかない感じ。
行書も草書もたまには篆、隷も欲しい。
Smalltalk だとメッセージの宛先なんて、文脈上
たいていの場合省略できるはず。もっと自由に。

307 ：デフォルトの名無しさん：2007/08/20(月) 16:03:10

コンパイラはOCamlとかHaskellあたりの
代数的データ型とパターンマッチのある言語が書きやすいと思う

308 ：305：2007/08/20(月) 16:11:03

ゴメンこれコンパイラの話じゃない。ただ美しさについて。
Prologはコンパイラ作るのが難しい言語かもしれない。

309 ：デフォルトの名無しさん：2007/08/20(月) 22:53:44

Smalltalk の「メッセージ」って、関数呼び出しのシンタックスシュガーだからねえ
見た目で釣られる馬鹿には受けがいい言語らしいけどｗ

310 ：デフォルトの名無しさん：2007/08/21(火) 00:42:10

とか言う奴でSmalltalkをまともに読み書きできる輩を見たことがない。

311 ：デフォルトの名無しさん：2007/08/21(火) 01:16:45

>>309
>関数呼び出しのシンタックスシュガー

シンタックスシュガーの意味をちゃんと理解してないだろ。
単なる制御構文に還元されるメッセージ呼び出しもあるから、
「関数呼び出し」にわざわざ限定する意味も無いし。

丸出しだな…

312 ：デフォルトの名無しさん：2007/08/21(火) 08:50:30

見た目も重要な要素だと思うが。

Smalltalkのキーワードメッセージが読みやすくて好きなんだけど、
あれが他の言語に採用されないのはどうしてだろう？

313 ：デフォルトの名無しさん：2007/08/21(火) 09:29:55

そういや大学の時、「C 言語は汚い。ソースコードのどこにでも {} が書ける」
とかいうネタで酒飲んだことある。
このセリフを言った人の美的感覚は構文規則にソースコードの美化を保つ仕組がない
のが嫌だったんだろうね。
でも意味を変えずに特定の記号をいくらでも配置できる言語なんて
ほとんどの言語がそうなんじゃないだろうか？

314 ：デフォルトの名無しさん：2007/08/21(火) 10:16:34

SELECT (DEPTNO,DNAME,LOC) FROM DEPT; でエラーになるのはおかしい、
というネタで珈琲飲んだことならある。

315 ：デフォルトの名無しさん：2007/08/21(火) 10:16:53

今頃はPythonあたりを称えてるのかな。

316 ：デフォルトの名無しさん：2007/08/21(火) 10:44:47

Prolog はホーン節というのだそうで、
頭部にひとつの項しか記述ができない。
p1,p2,p3 :- q1,q2. のような定義はできない。それで条件節はどうしても
頭部 :- 本体の本体側が重くなる。ここが美しくない。
そのこと以外、構文規則や表記法などはもっともすっきりした言語の
ひとつだと思う。

317 ：デフォルトの名無しさん：2007/08/21(火) 10:56:24

>>313
fortranやcobolに慣れ親しんだ人なのかね。

318 ：デフォルトの名無しさん：2007/08/21(火) 15:28:12

>>312
正確には、あれを採用した言語がメジャーになれないのはどうしてだろう？…か。
採用した言語はいくつかあるから。
マイナーメジャーなところでは SELF とか Objective-C とか。
その答えも、きっと単に C 言語に似ていないから…かとも。

あと、それこそ見た目に惑わされて recevier doSomething: arg1 with: arg2 が、
recevier.doSomething:with:(arg1, arg2) あるいは、
doSomething:with:(receiver, arg1, arg2) に過ぎないと言うことに
意外と気づく人が少ない…ということとか。コロンを関数名に入れられる
言語が少ないために、この読み替えに馴染めない…とか。

いろいろあるけど、結局は Smalltalk がメジャーになれなかったから…でＦＡ？

319 ：デフォルトの名無しさん：2007/08/21(火) 22:06:53

Smalltalk なんて、CLOS から見たら小学生の○○ゴッコにしか見えないな
所詮、頭の悪い人が設計した糞言語

320 ：デフォルトの名無しさん：2007/08/21(火) 22:34:56

# Dan IngallsやAdele Goldbergをバカに出来るということは、そりゃもう滅茶苦茶に
# 賢いんだろうなあ。

あの分かち書きが流行らんのは、入れ子になると読みづらいってのもあると思う。

hoge doSomething: (fuga doSomething2: page
　　　　　　　　　　　　　with: piyo)
　　　with: foo.

に比べると、

hoge.doSomething(fuga.doSomething2(page, piyo), foo)

のほうが通りが良いと言うか何と言うか。

321 ：デフォルトの名無しさん：2007/08/21(火) 22:45:09

Smalltalk の理論的な innovation って全く無いよね

322 ：デフォルトの名無しさん：2007/08/22(水) 01:24:20

cは少なくともPerlよりはキレイ

323 ：デフォルトの名無しさん：2007/08/22(水) 07:56:28

言語もマスターしていない批判坊ｗｗｗ

324 ：デフォルトの名無しさん：2007/08/22(水) 08:16:24

>>316
Prologは反駁が美しいか、という根本問題がある。それと、
論理変数のリンクがストリームとして意識されるところに
特徴があり、このストリームが赤、青、黄、と色付けされた
配管のように見えてくる。この印象は美しさとはほど遠い。

325 ：デフォルトの名無しさん：2007/08/22(水) 19:18:46

思うんだけどさ、ビット演算子に数限られてる記号を割くのってもったいなくね？

昔と違ってビット演算の割合って減ってるわけでしょ

今はそのオブジェクトにメソッドがあるかどうか、が重要なだけで、
つうか型チェックが必至てビット演算くらいじゃね？

326 ：デフォルトの名無しさん：2007/08/22(水) 19:39:35

記号を割くのがもったいないということに関してだけなら、
BASICは昔からアルファベットを使ってきたよ。ほかにもそんな言語いくらでもあるだろうし。
AND, OR, NOT, XOR
VBにはIMP, EQVまであるけど、これはどこのBASICも持っているものなのかな？

327 ：デフォルトの名無しさん：2007/08/22(水) 21:08:45

.AND., .OR., .XOR.
.NOT., .EQV., .NEQV.
.EQ., .NE., .LT., .LE., .GT., .GE.

328 ：デフォルトの名無しさん：2007/08/23(木) 04:48:23

>>326
少なくともN88にはあった

329 ：デフォルトの名無しさん：2007/08/23(木) 08:52:55

>>326
SP-5030では「AND, OR, NOT」が中間コードに定義されていた。

330 ：デフォルトの名無しさん：2007/10/19(金) 06:25:58

GHC(KL1)

331 ：デフォルトの名無しさん：2007/10/19(金) 10:20:03

ﾌﾟ

332 ：デフォルトの名無しさん：2008/04/21(月) 23:25:36

P系言語の美しさ寸評。

Pascal
　case文がブサイク。それ以外は美しい。

Python
　ブロックのコロンがブサイク。それ以外は美しい。

PHP
　<?php ～ ?> がブサイク。それ以外は並。

Prolog
　角括弧の多用がちょっと見苦しいが、これは仕方ないだろう。
　まあまあ美しい。

Perl
　何から何まで全部ブサイク。美しい所なんか皆無。

PL/I
　知らん。

333 ：デフォルトの名無しさん：2008/04/21(月) 23:31:31

Rubyしかあり得ない。
人類が皆Rubyを使えば世界に平和が訪れ
神から祝福されることだろう

334 ：デフォルトの名無しさん：2008/04/21(月) 23:38:14

なら、要らないや

335 ：デフォルトの名無しさん：2008/04/21(月) 23:42:59

Rubyが「美しい」とは思えない…

336 ：デフォルトの名無しさん：2008/04/22(火) 00:57:30

Ruby のデザインは素人臭くて使う気がしない

337 ：デフォルトの名無しさん：2008/04/22(火) 04:30:28

高速なネイティブコードを吐くコンパイラと
SLIME並みの開発環境があればScheme最強

338 ：デフォルトの名無しさん：2008/04/22(火) 06:28:47

>>337
「速いものは必ず美しい」、ですか。

339 ：デフォルトの名無しさん：2008/04/22(火) 07:42:02

そんな言葉初めて聴いたけど Scheme は俺も良いと思う
まあ俺は常用しないけど

340 ：デフォルトの名無しさん：2008/04/22(火) 07:56:37

スキーウェアのデサントが使ってたコピーですね。

341 ：デフォルトの名無しさん：2008/04/22(火) 08:23:10

>>338
美しいが、遅いから最強とは言えない。>>337を満たせば文句なし、って意味かと。

342 ：デフォルトの名無しさん：2008/04/22(火) 08:38:06

>>337
LISP(系)の言語は丸くしっとり囲まれて美しいですね。
手続き型の諸言語は迷走しないための枠が必要ですから、
どうしてもゴツくなるようです。
クラス別にして、別枠で競った方がよさそうですね。

343 ：デフォルトの名無しさん：2008/04/22(火) 08:49:41

全てがendで終わるRubyこそ美しさの賜物である

344 ：デフォルトの名無しさん：2008/04/22(火) 08:58:07

COBOLは EXIT PROGRAM. かな

345 ：デフォルトの名無しさん：2008/04/22(火) 12:15:28

>>343
endが邪魔
Pythonの美しさを見たまえ

346 ：デフォルトの名無しさん：2008/04/22(火) 16:22:13

美しさと実用性は反比例するのか？？？

347 ：デフォルトの名無しさん：2008/04/22(火) 16:41:16

反比例とまでは言えないけど一致はしないな…。

348 ：デフォルトの名無しさん：2008/04/22(火) 18:05:53

言語を美しくするためにはコストがかかる。そのコストが
往々として速度の遅さにくる。
Prologなどは極めて簡潔な構文を得る代償として、どんな些細な
処理でも4本のスタックの push pop を繰り返す。

349 ：デフォルトの名無しさん：2008/04/29(火) 00:13:53

>>345
endだけあってbeginが無いのはアンバランスに見えるな。
beginとendの対は崩してはいけない。

Pythonはbegin～endも{～}も無いから美しい。
Rubyみたいに片方だけ有るってのはものすごくブサイクに見える。

350 ：デフォルトの名無しさん：2008/04/29(火) 00:50:15

あぁ、そうか
俺がRubyで書く時に感じていた不安感はそれだったのか…

351 ：デフォルトの名無しさん：2008/04/29(火) 00:57:41

美しい方は良くわからんが
もっともバッチイ言語の一つに c++0x が名乗りを上げたことは確だ

352 ：デフォルトの名無しさん：2008/04/29(火) 01:05:29

もっともバッチィ言語はDOSのバッチィファイルだろ
駄洒落だと思ったら大間違いだぞ。
本当にバッチィぞ。

353 ：デフォルトの名無しさん：2008/04/29(火) 13:13:44

endがあるのがいいとか悪いとか
対になってるのがいいとか悪いとか
そんなくだらないことはどうでもいい

354 ：デフォルトの名無しさん：2008/04/29(火) 13:31:23

do endって{}と違ってviの%で飛ばないから嫌い。

355 ：デフォルトの名無しさん：2008/04/29(火) 14:26:19

>>352
出来上がったコードの問題だったらちゃうよ
新しくなる予定の C++0x の lambda の仕様を見てみれば？
ASTレベルでバッチィいんだが…

356 ：デフォルトの名無しさん：2008/04/29(火) 23:38:26

>>353
くだらない事にこだわるのが「美」ではないだろうか？

357 ：デフォルトの名無しさん：2008/04/30(水) 00:22:34

いや、そこに本質的な意味があってこそ美しい

358 ：デフォルトの名無しさん：2008/04/30(水) 15:07:39

アセンブリが美しい
初めて勉強した時には感動した
まさに最低で最高って感じ

359 ：デフォルトの名無しさん：2008/04/30(水) 19:00:00

>>357
禿堂。独りよがりの美意識なんてプログラミング言語にゃ不要

360 ：デフォルトの名無しさん：2008/04/30(水) 19:10:27

>>359
記法に本質的意味を求めるのもなかなか難しいと思うな。

361 ：デフォルトの名無しさん：2008/04/30(水) 19:14:35

記法ではなく、規則に美しさがあるんだろう

362 ：デフォルトの名無しさん：2008/05/01(木) 14:28:29

「無料で学べるプログラミングツール」bookでケンサ子

363 ：デフォルトの名無しさん：2008/05/02(金) 02:28:09

シェイクスピア言語が一番美しい。

--終了--

364 ：デフォルトの名無しさん：2008/05/03(土) 12:05:47

>>363
この言語を日常的に使っている人がこう書き込んだのだとすると、
うーーん、と感心するところですが、実際のところはどうなんで
しょうね。

365 ：デフォルトの名無しさん：2008/05/03(土) 22:08:03

シェイクスピア言語のプロは文系なのか理系なのか

366 ：デフォルトの名無しさん：2008/05/09(金) 09:08:45

プログラム言語ではありませんが、近年流行の「お品書き」ね。
あれ、美しいと思いますか。

367 ：デフォルトの名無しさん：2008/05/12(月) 11:13:24

>>366
もしかして、黄山谷の草書みたいなプログラム言語を
夢見てたりしない?

368 ：デフォルトの名無しさん：2008/05/12(月) 13:01:05

いいねぇ。作ろうよw

369 ：デフォルトの名無しさん：2008/05/12(月) 17:54:56

それ言語じゃなくてfontじゃｗ

370 ：デフォルトの名無しさん：2008/05/12(月) 18:01:28

>>369
シェイクスピア言語の向こうを張るためには、連綿くらいしないと。

371 ：デフォルトの名無しさん：2008/05/12(月) 18:04:08

シラフでは決して通らないコンパイラとかね。

372 ：デフォルトの名無しさん：2008/05/12(月) 18:07:23

美は乱調にあり。ですか。

373 ：デフォルトの名無しさん：2008/05/13(火) 15:40:07

2ch風(実は帝国陸軍風)に。

美ﾊ乱調ﾆあり。

これを、Prologをアセンブラとして、
美ﾊ乱調ﾆあり。 -> 美(乱調).
に落とす。なんていうのはどうですか。
奥行きがありそうだと思いませんか。

374 ：デフォルトの名無しさん：2008/05/14(水) 07:03:30

意味判らんが、エンコードに失敗してる

375 ：デフォルトの名無しさん：2008/05/14(水) 07:34:31

>>374
おちゅーしゃ　ってEUCの半角エンコードしないのかな。

376 ：デフォルトの名無しさん：2008/05/14(水) 07:38:51

美(乱調).
乱調(美).
あり(美,乱調).
いろいろあるね。こういうの奥行きがあるっていうw

377 ：デフォルトの名無しさん：2008/05/14(水) 09:51:45

>>376
Prologもそんな風に積み上げていくと、着物の文様ようで
美しいじゃないか。

378 ：デフォルトの名無しさん：2008/05/14(水) 09:52:30

文様のようでね

379 ：デフォルトの名無しさん：2008/05/14(水) 10:16:29

「李太白憶奮遊詩巻」のようなものはさすがに難しいが、
最終的にはプログラムも「墨跡」のようなものになって
行くのではないか。

380 ：デフォルトの名無しさん：2008/05/14(水) 12:59:15

>>379
3D-Visulan　っていうのがある。私は使えないが。積み木を重ねて、
グラフィック制御を定義する。ちょっと可能性を感じる。
墨跡ということになると、量子プログラム言語などというキャチフレーズが
付きそうだが、50年くらい遅れてる。

381 ：デフォルトの名無しさん：2008/05/15(木) 03:34:11

そりゃ、単にアナログプログラミングだ。

382 ：デフォルトの名無しさん：2008/05/16(金) 18:13:12

まあ兎に角、シェイクスピアには触発される何かがあることは確か。
美しいとは思わないけれど。

383 ：デフォルトの名無しさん：2008/05/20(火) 20:36:41

間違いなくRuby

384 ：デフォルトの名無しさん：2008/05/20(火) 20:58:44

>>383
無限ループ
>>333,335-336,343,345,349-350,383

385 ：デフォルトの名無しさん：2008/05/20(火) 22:07:06

386 ：デフォルトの名無しさん：2008/05/20(火) 22:49:28

美しさに拘るならやっぱ色々言語を使ってみて
最終的には俺言語を自作する所までやるのがいいのかもしれないね

387 ：デフォルトの名無しさん：2008/05/20(火) 22:54:55

最も美しい美人は誰か？　　と問うに等しい。

388 ：デフォルトの名無しさん：2008/05/20(火) 23:49:44

私も僣越ながら「究極的に美しい言語を作ってやるぜ！」と野望を抱いていましたが、
PrologやBrainfuckのことを知って「この美しさは超えられない！」と諦めました…。

389 ：デフォルトの名無しさん：2008/05/21(水) 07:44:01

>>388
これって究極の宣言型と手続型言語なんだね。それなら、
手続型部門: Brainfuck
宣言型部門: Prolog
OOP部門: Smalltalk
審査員特別賞: Shakesphere
でどんなもんだろう。

390 ：デフォルトの名無しさん：2008/05/21(水) 08:26:05

Brainfuckが手続型部門というのはどうなんだろ…

それにパズル部門？とするならWhitespace の方が「美しい」と思う。

あと、関数型のHaskellもはずせない。

391 ：デフォルトの名無しさん：2008/05/21(水) 08:35:42

>>390
Brain* は確かに少し無理があるか・・。
OOを取り入れるとどうしてもゴツくなってしまって
見た目の美しさは失われるから、公平に評価し難い。
これは別にOOP部門を設けたい。
Haskell 美しいかなぁww

392 ：デフォルトの名無しさん：2008/05/22(木) 09:54:17

Grassも美しい

393 ：デフォルトの名無しさん：2008/05/24(土) 04:22:45

>>389

>宣言型部門: Prolog

ﾌﾟ

394 ：デフォルトの名無しさん：2008/05/25(日) 11:46:27

理屈を付ければ通る、的な言語はいやだね。
関数型にもあるけど。

395 ：デフォルトの名無しさん：2008/05/25(日) 12:06:44

理屈馬鹿の言語、効率馬鹿の言語、省略馬鹿の言語、矯正馬鹿の言語とある中で、
やっぱりRubyのバランスの良さは飛び抜けてるね。圧倒的に美しい。
既存の様々なコードもさることながら、アンチのレベルの低さもまた、逆説的にその証明になってる。
他の言語はアンチの言い分にもそれなりに「見るべきところ」があるわけだけど、
Rubyのアンチは勘違いからくる言いがかりと人格批判だけ。欠点がまともに指摘されることが殆ど無い。
勿論この世に完璧な言語など無いが、それでもRubyの欠点を「正しく」挙げるのはそれほどに難しい。
これはすごいこと。現状、神の言語に最も近いのがRubyだ。

396 ：デフォルトの名無しさん：2008/05/25(日) 13:51:14

なんだろう…これが既にアンチに見えなくも無い俺は病気なのか

397 ：デフォルトの名無しさん：2008/05/25(日) 15:46:19

神の言語に最も近いのがRubyだ。
神の言語に最も近いのがRubyだ。
神の言語に最も近いのがRubyだ。
神の言語に最も近いのがRubyだ。
神の言語に最も近いのがRubyだ。

398 ：デフォルトの名無しさん：2008/05/25(日) 16:17:07

やっぱA言語(APL)だろw
予約語の少なさは他の言語も
見習うべきだ。

399 ：　：2008/05/25(日) 16:17:47

Rubyの英語版のWikiにruby作った人の写真があるけど不細工だな。
ていうか外人ってわざと日本人の不細工に写ってる写真使う気がする。サッカー選手とかでも感じる。

400 ：デフォルトの名無しさん：2008/05/25(日) 16:25:09

被害妄想乙

401 ：デフォルトの名無しさん：2008/05/25(日) 16:40:29

>>399
神を馬鹿にするな！

402 ：デフォルトの名無しさん：2008/05/25(日) 16:47:24

やっぱIoだろw
予約語がないところは他の言語も
見習うべきだ。

403 ：デフォルトの名無しさん：2008/05/25(日) 16:56:46

予約語無いと最適化の邪魔になりそうだからバンバン予約語作ってくれたほうが嬉しい

404 ：デフォルトの名無しさん：2008/05/25(日) 18:25:45

FORTRANにも予約語はなかったな。

405 ：デフォルトの名無しさん：2008/05/25(日) 19:37:01

>>403
普通予約後が少ない場合は演算子なり記号に
置き換わるだけだから別に最適化の役にはたたんだろ…。
予約語が多いと使えるシンボル名が減ってウザス。

COBOLのPICとPICTUREとかまったく同じ意味なのに予約語とかアホかと

406 ：デフォルトの名無しさん：2008/05/27(火) 13:14:13

なでしこ

407 ：デフォルトの名無しさん：2008/05/28(水) 17:26:33

他の事を書こうとしたが>>406で納得してしまった

408 ：デフォルトの名無しさん：2008/05/28(水) 19:51:22

ラムダ計算

409 ：デフォルトの名無しさん：2008/05/29(木) 00:13:12

>>408
そういう名前の言語があるの？

410 ：デフォルトの名無しさん：2008/05/29(木) 09:26:26

これ以上分解できない最小の単位というのは美しい。
よってマシン語が美しい

411 ：デフォルトの名無しさん：2008/05/29(木) 10:10:31

これ以上分解できない最小の単位というのは美しい。
よってCPUロジックが美しい
冗談はさておき、ペンティアム系の、86系に増築しまくった歪なマシン語がとても美しいとは思えない。

412 ：デフォルトの名無しさん：2008/05/29(木) 15:51:03

増設された年代別に分けて見るよろし

413 ：デフォルトの名無しさん：2008/05/29(木) 16:36:59

>>411
>よってCPUロジックが美しい
つ[論理ゲート]

414 ：デフォルトの名無しさん：2008/06/02(月) 01:09:20

>>411
そこで、Cellですよ。

415 ：デフォルトの名無しさん：2008/06/04(水) 10:15:37

簡潔なものを美しいとするグループと、
複雑でも筋の通ったものを美しいとするグループがあるらしい。

416 ：デフォルトの名無しさん：2008/07/21(月) 15:20:31

混沌に美しさを感じるアナーキストはどうすればいいですか

417 ：デフォルトの名無しさん：2008/07/21(月) 19:02:50

>>416
>>367 以下ではだめですか。

418 ：デフォルトの名無しさん：2008/07/22(火) 00:01:39

Malbolgeがあるじゃないか

419 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/08/24(日) 06:21:43

LispやPrologはどうなんだい?
機能と美しさの関係をどう考えているのかな。
20世紀の歴史をもう一度見直した方がいいんじゃないか。

421 ：デフォルトの名無しさん：2008/08/24(日) 07:10:12

機能と美しさねぇ。ソフトウェアを作る上で必要な概念ってあるじゃない？
プロセスとかスレッドとかファイルとかXMLとかウィンドウとかDBとか
いろんなパーツがさ。こういったのをうまく抽象化できて生成削除が
うまく扱えて、それぞれをうまく繋げることができて、総合的には
容易にアプリケーションを構築できて、新しい概念や変更が発生した場合にも
うまく繋ぎかえることが可能なものが上手というか美しいのかなとか思ってる
程度だけど。

foreachとかlambdaとか高階関数とかも言語ごとにいろいろあるけどそれほど
本質的な話でもないかなと。あるともちろんいろいろと便利だとは思うんだけど、
それよりも現実的にはUnicodeはきちんと扱えるんですか？とかの方が重要だったり。

歴史を見直すって具体的にはどう見直してなにを見出したいんだ？
おおざっぱには20世紀はC++/Javaみたいな大衆向け現実指向言語がlispなり
prologなりを圧倒した感じがしてるけど。
RubyなりPythonなりは動的機能とかがあるけどC++/Java/C#と概念にあんまり
違いを感じないんだが。

422 ：デフォルトの名無しさん：2008/08/24(日) 07:29:00

機能を徹底的に追求すれば、自ずと美しさがそこにあるという確信だけど。
それを追求しきれずに終わったのが20世紀だという意味。
ここでいう機能は「無駄を省く」という概念を含んでいて、その点で
あなたの挙げた言語群は機能的な美さへ持っていない。
C#はC++よりまし、というような言い方はできるが。

423 ：デフォルトの名無しさん：2008/08/24(日) 07:44:43

うーん、その機能を追求すると結局C++みたいな方向にしかならん気がするん
だよね。細かいとこは修正できるかもしれんけどさ。
プロセスを作りたいと。
Process p;
p.Create("hoge.exe");
ウィンドウを作りたいと。
Window w;
w.Show();
これ以上簡単に表現できる必要もさしてないわけで。
そしてこのへんの表現方法は言語よりもライブラリの設計が担ってるわけで。

ただまあオブジェクト指向以外の方向だとまた違うかもしれないけど。
でもオブジェクトみたいに状態を持たせずに例えばウィンドウとかを管理
するのって難しくないかな？

424 ：デフォルトの名無しさん：2008/08/27(水) 07:10:43

C++は言語自体よりもMSのぐちゃぐちゃなライブラリ(Win32/MFC/ATL/COM・・)が
だめぽだと思う。
文字列を表す型が_bstr_t/CComBSTR/CString/char*/wchar*/std:string/
std::wstring/OLECHAR*/BSTR・・
ボンクラどもがライブラリを設計するとどんな言語でもだめになる。
これからの言語は言語設計もだけど、それ以上にいかに使いやすい質と量が
そろったライブラリを提供できるかが重要だと思う。

425 ：デフォルトの名無しさん：2008/08/28(木) 08:03:04

要するにライブラリに登録されてる手続きとか関数を
縦に並べれば、抽象化された表現になり美しいといいたいんだね。

426 ：デフォルトの名無しさん：2008/08/28(木) 08:12:56

そしてC#が生まれた

427 ：デフォルトの名無しさん：2008/08/28(木) 08:39:26

バッチファイルが一番美しいってことになるね。

428 ：デフォルトの名無しさん：2008/08/28(木) 09:57:23

そういう意味では一つの概念には一つのやり方のPythonは美しいね

429 ：デフォルトの名無しさん：2008/08/28(木) 10:02:02

>>428
どういうこと? 少し詳しく説明してください。

430 ：デフォルトの名無しさん：2008/08/28(木) 20:26:41

>>428
最近はひとつのことでもいくつかの書き方が出来るようになったから、そうでもないけどね。

431 ：429：2008/08/28(木) 20:37:17

Pythonのコンセプトからいって、ライブラリの中身は誰が書いても
あまり変わらず書けるということはわかるけど、それを呼び出す側は
どうなるというのかな。

432 ：デフォルトの名無しさん：2008/08/30(土) 23:36:11

昔のモジュール型言語は見た目は悪いけどプログラムを読むのは楽だった
関数のネストが１，２個だったからね
オブジェクト指向は確かに見た目は綺麗に見えるけどただのパズルだよ
全体を既に把握してる場合は抽象化されたクラスは見やすいが
把握してない人間がソースをトレースしようとすると何重にもネストされた
関数郡が実行順位も不明確な状態で分散されてるごみの塊

433 ：デフォルトの名無しさん：2008/08/31(日) 13:44:47

>>432
何が何を呼んでいるか、
気にしないようにしよう（気にしなくても問題無いようにしよう）と、
潮流が変わったんだよ。
気にするのに疲れちゃったからね。

434 ：デフォルトの名無しさん：2008/08/31(日) 19:13:15

最も美しいプログラミング言語か
やはり、C++しか無いだろう
「華麗にして醜悪」「壮麗にして貧弱」
そんな相反する要素を持っているのはC++以外に無いしな

435 ：デフォルトの名無しさん：2008/08/31(日) 19:27:37

そっから華麗と壮麗をさっ引くと俺の知ってる C++ になるぜ。

436 ：デフォルトの名無しさん：2008/09/02(火) 19:15:37

華麗さと壮麗さは使用者のスキルに依存します

437 ：デフォルトの名無しさん：2008/09/02(火) 19:32:22

という事は純粋に言語自体が華麗で壮麗という訳じゃないんだね。
まあ C++ はそんな所だろうな。

438 ：デフォルトの名無しさん：2008/09/02(火) 20:36:40

芸術ってのは、やはり書き手の技能に依存するんじゃないだろうか。
弘法筆を選ばず

439 ：デフォルトの名無しさん：2008/09/02(火) 20:39:57

プログラム無関係だが、絵の上手い人はチョーク一本でも上手いわけだし。
こんな風に
ttp://kokuban.in/view/1217480299

440 ：デフォルトの名無しさん：2008/09/02(火) 21:22:15

チョークは芸術じゃないからね

441 ：デフォルトの名無しさん：2008/09/03(水) 23:49:28

じゃあ何なら芸術？

442 ：デフォルトの名無しさん：2008/09/04(木) 05:51:11

道具が芸術になることはないだろう。

443 ：デフォルトの名無しさん：2008/09/06(土) 22:35:27

forthだな

444 ：デフォルトの名無しさん：2008/09/06(土) 22:43:22

>>442
では美しいプログラミング言語は道具ではない(道具としては役に立たない)のかな？

445 ：デフォルトの名無しさん：2008/09/06(土) 23:05:10

forth はゲームみたいで良いね

446 ：デフォルトの名無しさん：2008/09/07(日) 10:24:18

>>444
話の流れが理解できない人は、無理して参加しなくてもいいよ。

447 ：デフォルトの名無しさん：2008/09/07(日) 12:35:13

C++ は美しい、という話の流れだと思ってたが・・

448 ：デフォルトの名無しさん：2008/09/07(日) 12:39:58

美は乱調にあり。

449 ：デフォルトの名無しさん：2008/09/07(日) 23:10:29

美しさという言葉が最も似合わない言語なら Java かな

450 ：デフォルトの名無しさん：2008/09/07(日) 23:48:24

機能美なら当て嵌まる

451 ：デフォルトの名無しさん：2008/09/13(土) 08:15:57

プログラミングしりとり
http://schiphol.2ch.net/test/read.cgi/575/1010948472/l50

452 ：デフォルトの名無しさん：2008/09/19(金) 20:36:11

>>245
OOPの枠内で考えるからライブラリに目がいくのではないか？

453 ：452：2008/09/19(金) 20:37:51

なかったことにしてくれ

454 ：デフォルトの名無しさん：2008/10/03(金) 10:51:06

音楽だと不協和音が逆に美しかったりするだろ。
醜さの中にも美しさは見出せると思うんだ

455 ：デフォルトの名無しさん：2008/10/05(日) 10:48:41

真幸乙

456 ：デフォルトの名無しさん：2008/11/28(金) 16:06:31

テキストエディタの着色機能がでかなり変わると思う

457 ：デフォルトの名無しさん：2008/11/28(金) 16:36:46

Whitespaceだろう。
http://ja.wikipedia.org/wiki/Whitespace

458 ：デフォルトの名無しさん：2008/11/28(金) 16:56:32

すでに>>5から既出・頻出なんだがな。

459 ：デフォルトの名無しさん：2008/11/28(金) 17:19:14

リストアップするスレじゃなくて自分の意見を書くスレだから、
別にその言語を推す何人目になっても構わないんじゃないかと。

460 ：デフォルトの名無しさん：2008/11/29(土) 00:28:55

Haskellってことでいい？

461 ：デフォルトの名無しさん：2008/11/29(土) 23:23:04

いいよ

462 ：デフォルトの名無しさん：2008/12/01(月) 10:05:16

重っ苦しいな。

463 ：デフォルトの名無しさん：2009/01/20(火) 20:45:00

96117515
80402966
28237893
29335028
49310357
07361287
0132343

464 ：デフォルトの名無しさん：2009/02/02(月) 03:41:47

javaで完全にクラスの呼び出しのみで出来たプログラムは綺麗に見えるけどな．
他人がそのソースを一目で理解するのは難しいが

465 ：デフォルトの名無しさん：2009/02/03(火) 22:39:52

>>464
所詮、その程度のプログラム
美しくはないな

466 ：デフォルトの名無しさん：2009/02/10(火) 14:50:27

Haskellにしても、OCaml,Ruby,Python,Java,C#などみんな。
Prologならappend一つで済むものを汚い!汚い!

467 ：デフォルトの名無しさん：2009/04/01(水) 23:25:06

inc
dec
set
clr
halt
jz [飛び先]
jnz [飛び先]

の7個の命令だけで出来た言語
チューリングマシン語を分解したようなやつ。

468 ：デフォルトの名無しさん：2009/04/02(木) 02:47:52

>>467
アセンブラ？ニモニック？

469 ：デフォルトの名無しさん：2009/04/02(木) 09:34:49

>>467
jz あれば jnz いらなくないか?

470 ：デフォルトの名無しさん：2009/04/02(木) 23:39:56

>>469
チューリング完全の必要最低限という意味なら不要。
対称性の為に入れた。
jnzを入れるか入れないかに対して大してこだわりはない。

471 ：デフォルトの名無しさん：2009/04/03(金) 02:05:01

>>467
ピュアリスプなら以下のオペレータで可能です
car cdr eq cons quote atom cond(if)

472 ：デフォルトの名無しさん：2009/04/03(金) 23:02:02

こだわりのない言語は美しいとは言えない

473 ：デフォルトの名無しさん：2009/04/04(土) 15:35:50

いいね（微笑

474 ：デフォルトの名無しさん：2009/04/07(火) 00:31:42

ねーよｗ

475 ：デフォルトの名無しさん：2009/04/18(土) 14:02:05

美しさではＨａｓｋｅｌｌが一番だと思ってます。
数学的な美しさを一番素直に表現できる言語かと。
ＩＯモナド使うと他の言語と変わらなくなってしまうけど・・・
個人的にはパターンマッチとガードさえあればif,caseも要らないと思ってしまいます。
言語仕様から排除して問題ないんじゃないかとすら思えて・・・

476 ：デフォルトの名無しさん：2009/04/19(日) 00:50:53

んな事言ったらdo構文こそいらない。

477 ：デフォルトの名無しさん：2009/04/19(日) 09:19:14

＞＞476
私もそれは思いますが、あれは必要悪かと･･･

478 ：デフォルトの名無しさん：2009/04/20(月) 18:13:48

>>477
美しさを評価しているのに必要悪ってなんですか。

479 ：デフォルトの名無しさん：2009/04/20(月) 22:15:11

>>478
何と言いましょうか。純粋関数型言語が手続き型言語と同じ順番に依存した処理をするために手続き型言語をシュミレーションする仕組み(モナド)の構文糖衣なんですよ。
純粋な関数型言語らしい書き方はとても美しいのに、手続き型をシュミレーションしないといけない場面(入出力・代入)がどうしても必要なばっかりに出来た一点のシミ。
Haskellの達人たちはそのシミを必要最小限に抑えられると聞きます。
でも、そういう欠点で言えば他の言語に比べて一番(仕様的に)不満の少ない言語だと感じています。
例えば、Smalltalkはオブジェクト指向言語では最高だと思いますが、メソッドは全てpublic。フィールドは全てprivete。変更不可と言うのが不満です。
Rubyはその点の不満は無いですが、Smalltalkと違い、if文等(+,-,*,/)の制御構文はオブジェクトではありません。
Haskellはもちろん、if文(正確にはif式)すらも関数で、+,-,*,/も関数です。モジュールなどでアクセス制御も不満な点はありません。
何より、アルゴリズムをもっとも素直に表現できる言語であるところが最大の魅力です。

480 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/04/21(火) 00:17:28

要するに全てをHaskellで書けば良いというわけだな？

482 ：デフォルトの名無しさん：2009/04/21(火) 01:21:27

ええと、私もまだ勉強中の身ですが、モナドもHaskellの文法ですので正確に言えば入出力や代入を必要としない処理(少なくともあまり必要としない処理)だととても美しいです。
IOモナドが無いと実行結果がばらばらで出力されてしまいます。(原理的にそうらしいです)
実際にはIOモナド使わないと結果が見れないのでばらばらで出力された所を見た事無いですが･･･
せめて、IOモナドとかを直接見ないですむ仕組みで(個人的にはRAD環境とか何かしらのラッパーとか）Window(X-System含む)アプリとか出力（や状態を保持する処理)の権化みたいなアプリを書ける仕組みがあれば完璧です。

483 ：デフォルトの名無しさん：2009/04/21(火) 01:30:54

何か、長文になる癖でもあるみたいです＾＾；
またまた済みません･･･
今後、なるべく短くなるように頑張ります。

484 ：デフォルトの名無しさん：2009/04/21(火) 03:49:26

よし、君が作るんだ！

485 ：デフォルトの名無しさん：2009/04/21(火) 07:27:51

私じゃ全然実力不足ですよぅ＾＾；

486 ：デフォルトの名無しさん：2009/04/21(火) 10:43:18

ruby の if とかは文じゃなくて式だよ

487 ：デフォルトの名無しさん：2009/04/21(火) 11:28:07

きたねえ言語だな

488 ：デフォルトの名無しさん：2009/04/21(火) 17:03:12

なんでもかんでも式ってのは一様性の観点からみて美しいだろｊｋ

489 ：デフォルトの名無しさん：2009/04/21(火) 20:02:12

>>486
あ、そう言えばどこかで聞いたような･･･
済みません間違いでしたね＾＾；
でも･･･何が不満だったっけ?
と、思い出してみたらRubyは(当たり前だけど)Rubyを動かす環境はオブジェクトじゃなかったのが不満だったんでしたっけ・・・
SmalltalkのOS(仮想OSであるSmalltalk）もオブジェクトで、分からないことはオブジェクトに聞け!!って環境は中々得難い体験でした＾＾

490 ：デフォルトの名無しさん：2009/04/21(火) 20:20:10

>>489
>SmalltalkのOS(仮想OSであるSmalltalk）もオブジェクトで、
>分からないことはオブジェクトに聞け!!って環境は中々得難い体験でした＾＾

Smalltalkは抽象度が高過ぎて、自分にはもどかしかった
汚い物を汚い物として直接触れないのも不便です

491 ：デフォルトの名無しさん：2009/04/21(火) 20:58:06

ええと、まあ・・・分かります。
私も何だかんだとDelphiやVC#メインですし＾＾；
でも、ここは｢美しい（ｒｙ
ある意味、抽象度を高めるのがプログラミング言語の歴史な訳ですし＾＾；
それを言ったらHaskellはSmalltalkよりさらに抽象度高いですよ?

492 ：デフォルトの名無しさん：2009/04/21(火) 21:40:04

ならLispの方が抽象度高いんじゃないの？
更に言えばWhitespaceやBrainfuckの方が・・・・

493 ：デフォルトの名無しさん：2009/04/21(火) 22:57:13

LispのS式って万能のデータ構造とか聞きますし、そうなのかも知れませんね＾＾
残念ながら、私はLisp挫折しているのでまだ分かりませんが･･･
来月辺り、littleSchemerを買って再チャレンジの予定です＾＾
ただ、私が思うに一般の人がプログラミング言語の美しさを理解できる限界がHaskellなんじゃないかと思っています。
数学の表記をほぼそのままコードに落とせますし。
私の想像ですが、Lisp系はさらにその上の抽象度で、一般の人より上の見方が出来る人じゃないと美しさを感じられないのではないかと想像しています。

WhitespaceやBrainfuckは・・・まだ入門すらしていないのですが、ラムダ計算をそのまま書ける言語っぽい雰囲気を感じますね･･･
どこかに良い入門サイトがあれば教えて欲しいです＾＾

494 ：デフォルトの名無しさん：2009/04/21(火) 23:01:59

>>491
抽象と書いたのは、やたらとモデル化したり階層化したがる事を言いたかったんだ。
Haskellはハードウェアの実装から遠いという意味では抽象的ですが、プログラムの
作り方は割りとダイレクトな言語だと思います。

495 ：デフォルトの名無しさん：2009/04/21(火) 23:02:47

Brainfuckはこの板に専用スレがあるからそこからVIPのWikiに行くといい。
λ計算なら寧ろ、grassじゃないかな。それも専用スレがある。

496 ：デフォルトの名無しさん：2009/04/21(火) 23:27:53

…と＾＾が多い文章は全く美しくない

497 ：デフォルトの名無しさん：2009/04/22(水) 11:54:22

つーか、Lisp程度で挫折するヤツが偉そうに限界とか語るなよ。

498 ：デフォルトの名無しさん：2009/04/22(水) 19:48:28

>>495
Brainfuckスレ見てきました。
限りなくチューリング機械に近い言語ですね。
これはこれで凄いです。
幾何学模様で確かに芸術的な美しさがありますね。

>>494
>やたらとモデル化したり階層化したがる事を
ああ、納得です。
家系図みたいに連綿と受け継ぐ傾向はありそうですね。

>>496
まだ書き込み始めて数日なので、ルールとか良く知らないのですが、…や＾＾は書かない方が良いのでしょうか?
一応、書かないように気をつけてみます。

>>497
アマチュアの日曜プログラマーの戯言ですので、あまり気にしないでください。
単純な関数程度ならLispでも書けますけど、プログラミング言語を知らない人が見ても理解できそうな書き方はHaskellの書き方だと感じたもので。

499 ：デフォルトの名無しさん：2009/04/22(水) 20:03:23

死ね

500 ：デフォルトの名無しさん：2009/04/22(水) 20:30:53

あなたらしさが出ているので…や＾＾は書いたほうがいいと思う

501 ：デフォルトの名無しさん：2009/04/22(水) 22:49:53

むしろ…と＾＾だけの言語を作ったほうが良いと思う

502 ：デフォルトの名無しさん：2009/04/22(水) 23:13:10

散々くだをまいといて「日曜プログラマです」とか恥ずかしくないのかね

503 ：デフォルトの名無しさん：2009/04/22(水) 23:17:27

>>498
それでPrologはどう評価するの？

504 ：デフォルトの名無しさん：2009/04/22(水) 23:50:44

>>503
“一般”の人には理解できないから駄目な言語ってんだろ。たぶん。
前提が間違っているととんでもない結論に至るな。

505 ：デフォルトの名無しさん：2009/04/23(木) 00:18:30

A　・・・　Axum ★
B　・・・　B言語
C　・・・　C/C++/C#
D　・・・　D言語
E　・・・　Erlang ★
F　・・・　F# 　　★

実際の世界は並列に動いている。
世の中をモデル化するときに並列という概念がプログラミング言語に備わっていれば
美しくプログラムをかけるんじゃないかと。。。並列指向の★に期待。

506 ：デフォルトの名無しさん：2009/04/23(木) 01:13:03

アルファベット順というのは無意味だったので、パラダイムで整理するとこんな感じか。

構造化　・・・　BASIC
オブジェクト　・・・　C++
関数型　　　　・・・　F#
並列　　　　　・・・ Axum

だんだん下にいくほど美しくプログラムが書けるようになるのかな。

507 ：デフォルトの名無しさん：2009/04/23(木) 01:36:38

マイクロソフト以外だとこんな感じか。

構造化　・・・　C/Perl
オブジェクト　・・・　C++/Java/Python/Ruby
関数型　　　　・・・　Ocaml/Haskel/Lisp/Scheme/Scala
並列　　　　　・・・ Erlang

508 ：デフォルトの名無しさん：2009/04/23(木) 02:00:35

原点回帰　シェルスクリプト

■ソフトウェア・プロダクト・オブ・ザ・イヤー(R)2008
ユニケージ開発手法および同開発コマンドセット
http://www.ipa.go.jp/software/oftheyear/2008/documents/spoty2008r07.pdf

■ユニケージ開発手法

USP(Ｕｎｉｖｅｒｓａｌ　Ｓｈｅｌｌ　Ｐｒｏｇｒａｍｍｉｎｇ)研究所は、
Ｌｉｎｕｘの基本思想である「小さな道具」（コマンド）を組み合わせて「問題を解決する」（シェルスクリプト）手法の研究・普及を行っています。
この手法（ユニケージ開発手法）は、Java、Oracleなどを用いた従来の「手引き型」開発手法と一線を画し、
　　★圧倒的な開発生産性
　　★圧倒的な柔軟性
を特徴としています。
http://www.usp-lab.com/opinion.html

509 ：デフォルトの名無しさん：2009/04/23(木) 02:03:11

Lispはマルチパラダイム言語。

510 ：デフォルトの名無しさん：2009/04/23(木) 02:06:33

C++もね。

511 ：デフォルトの名無しさん：2009/04/23(木) 05:40:09

>>504
君が知らないだけだろ。なんで>>503のタイミングで持ち出したか
理解できていないようだから。

512 ：デフォルトの名無しさん：2009/04/23(木) 06:01:19

きみはプログラミング言語より日本語の勉強をしたほうがいいな

513 ：デフォルトの名無しさん：2009/04/23(木) 11:03:26

>>512
なるほど。>>504をよく読んでいなかった。ごめんなさい。

514 ：デフォルトの名無しさん：2009/04/23(木) 12:39:32

既出ならごめん

ニモニック

515 ：デフォルトの名無しさん：2009/04/23(木) 20:10:25

ちょっとわき道にそれるが、
>>508とも関連するが、
システムを作るときにDSLを作ることはよくある。
その際、システムに最適化されたDSLが作れたとき美しいと感じるときがある。
ある販売管理システムが
　START
　A 100 100
　B 0 0
　C
　END
とかけてしまったら美しいと感じないだろうか。
システム作りでの美しさとはそのような抽象化でもありえるのでは。
まあ、このスレはその抽象化を行うのに美しく作業できる言語は？とうのが主題ではあるけれど。

516 ：デフォルトの名無しさん：2009/04/23(木) 20:38:05

>>499
これは･･･私に言っているのでしょうが何を不満に思ったのか書いていただかないと改善しようが･･･
あ、一応、私らしさが伝わるそうなので戻しますね?
書き方に不満があったら投票でもしましょうか＾＾；
Lisp知りもしないくせにとか言われると耳が痛いですが＾＾；
強力ではあると思いますが直感的ではないなぁ、と。
まだまだLispに数学的な美しさを見出すには修行不足のようです＾＾；

>>502
くだを巻いていた気はないのですが、気に障ったのなら謝ります。
自分を誇張表現するより、ありのままの自分で美しい言語とは?を話したいので正直に自分のレベルを明かしました＾＾；

>>503
ごめんなさいm(__)m
Prologは私の感性との相性が悪いみたいでどうも美しいとは感じていませんm(__)m
理由になっていないと言われるでしょうけど、変数が大文字で始まらなければならないのが、どうしても受け入れられません。
一階述語理論自体には興味はあるのですが、どうも変数が大文字で始まる言語だけは受け付ける事が出来ないようです。（なので、Erlangも同様な理由で受け付けられません＾＾；）
Javaにでも脳を侵されてしまっているな･･･とは感じているんですけど、駄目なんです＞＜

それでも論理型言語の何が魅力なのかちゃんと知りたいと思い、関数論理型言語Curryなるものに注目しています。
まだ、英語のチュートリアルを落としてざっと読んでもHaskellっぽくしか見えなくて、論理型言語の特徴を見分けるに至っていませんが、時間があるときにじっくり読んで勉強するつもりで居ます。

517 ：デフォルトの名無しさん：2009/04/23(木) 20:42:43

Javaばかりを悪者にしてはいけませんでしたね＾＾；
でも、今まで変数はずっと小文字で始めていたのでどうしてもそこを曲げられるのに抵抗を感じてしまいます＾＾；

518 ：デフォルトの名無しさん：2009/04/23(木) 20:47:44

日曜プログラマだから参加してはいけない！とは思わないけれど、
ある程度修練を積まないと見えない美しさって言うのは、
例えば、、、数学にだってあったわけじゃない？

だから、日曜プログラマでは見えてこない部分も有るってのに長文かよ、
みたいに思う人はいて当然かな。と思うよ。
だから俺はいつもROMってる。

519 ：デフォルトの名無しさん：2009/04/23(木) 21:04:49

近年稀にみるウザキャラ。
同年代の人間と会話する訓練でもしたほうがいい。
やっててこれなら周りもおかしいか、
おまえのおかしさを憐れまれているだけだ。

520 ：デフォルトの名無しさん：2009/04/23(木) 23:08:02

理系の学部とか院とかにたまにいるタイプ

521 ：デフォルトの名無しさん：2009/04/24(金) 00:08:43

What a wonderful world!!!!

522 ：デフォルトの名無しさん：2009/04/24(金) 00:26:27

Yet another decent diary!!!

523 ：デフォルトの名無しさん：2009/04/24(金) 07:28:39

>>518
ええ、高卒の私では見えない世界が一杯あると思います＾＾
家が貧乏でなければ大学に行きたかったですね･･･
なるべく短くなるように努力してみます。

>>519
私がウザイと思われているのは理解しました。
そんな些細な事よりも美しいプログラミング言語とは?についてお話して頂きたいです。
私と話したくないのであれば、私のコメントは無視して他の方とお話すれば良いのです。

524 ：デフォルトの名無しさん：2009/04/24(金) 08:54:07

>>523
俺はなんとも思わないけど
自分自身を主張する奴は2chでは嫌がられる。
コテが嫌われるのと同様に。
こういうスレならなおさら意見や考えを主張すればよいのであって、
自分自身を主張する必要はない。
反論するのは筋違いだと思うよ。

PCだけじゃなく携帯から見てる人もいるから、NGすればいいなんて言うのはナシね

525 ：デフォルトの名無しさん：2009/04/24(金) 08:55:34

毎度上げてるしね

526 ：デフォルトの名無しさん：2009/04/24(金) 09:15:08

つい最近まで、マ板の底も底、もうすぐ最下位というところにいたスレなんだから、
たくさん書き込んでもらえるだけでありがたいけどね。

527 ：デフォルトの名無しさん：2009/04/24(金) 09:19:57

ム板だったw

528 ：デフォルトの名無しさん：2009/04/24(金) 10:24:08

動くプログラムは全て美しい

これ言った人、もういないんだよな。

529 ：デフォルトの名無しさん：2009/04/24(金) 15:11:45

つーか、「Haskellに一票」と書けば済む話をなぜだらだらと長文で
他の言語にまでケチを付けて。周りをむかつかせて。馬鹿なの？死ぬの？

530 ：デフォルトの名無しさん：2009/04/24(金) 15:12:21

>>529

531 ：デフォルトの名無しさん：2009/04/24(金) 18:04:54

つーか、「perlに一票」と書けば済む話をなぜだらだらと長文で
他の言語にまでケチを付けて。周りをむかつかせて。馬鹿なの？死ぬの？

532 ：デフォルトの名無しさん：2009/04/24(金) 20:19:59

最強がHaskellで実用性はRuby

533 ：デフォルトの名無しさん：2009/04/24(金) 20:26:19

私の思う美しい。

1.その言語の背景になっているモデルや指向をどれだけ自然に表せるか?
2.記述の簡潔さ。読みやすさ。(思考とコードとの間の齟齬が少ない)
3.上記を保ったまま堅牢性を求めるプログラミングにも耐え得るか?

こんな感じで、Haskellに一票です＾＾
まだ、自己主張してますかね･･･

534 ：デフォルトの名無しさん：2009/04/24(金) 20:50:30

私は GHC
Haskellコンパイラではないよ。

535 ：デフォルトの名無しさん：2009/04/24(金) 21:03:50

あの国家規模でコケたやつか。そのGHCは現代の環境でも並列処理を活かせるの？

536 ：デフォルトの名無しさん：2009/04/24(金) 21:13:20

あ、私も言語としてのGHC気になります＾＾
PCでもコンパイラ使えますか?
良い入門ページもあれば教えて欲しいです＾＾

537 ：デフォルトの名無しさん：2009/04/24(金) 21:58:54

ハット記号を NG 登録で快適

538 ：デフォルトの名無しさん：2009/04/24(金) 22:01:18

わざわざ人の嫌がることをやる人間がプログラミング言語の美しさを語って、
誰がそんな奴の話を聞いてくれると思っているんだろう？

539 ：デフォルトの名無しさん：2009/04/24(金) 22:08:11

そこまで嫌がられていたのなら、もう消えます･･･
お騒がせして済みませんでしたm(__)m

540 ：デフォルトの名無しさん：2009/04/24(金) 22:22:00

>>535
並列処理自体がこれからですからね。 PSI II がないと
検証もままならないという状態は困ったものです。

541 ：デフォルトの名無しさん：2009/04/24(金) 22:50:05

>>523
ｲｲﾊﾅｼﾀﾞﾅｰ　頑張ろうな。

542 ：デフォルトの名無しさん：2009/04/24(金) 22:52:15

つーか、「Schemeに一票」と書けば済む話をなぜだらだらと長文で
他の言語にまでケチを付けて。周りをむかつかせて。馬鹿なの？死ぬの？

543 ：デフォルトの名無しさん：2009/04/24(金) 23:12:14

しつこいよ

544 ：デフォルトの名無しさん：2009/04/25(土) 12:25:41

>>539
少し目立つとケナすのが2chの文化です。
あまり気にする事はないです。

しばらく発言せずにあちこちのスレを覗く事をおすすめします。
これを2ch風に言い表すと以下の様になります。
「半年ROMってろ」

545 ：デフォルトの名無しさん：2009/04/25(土) 12:41:11

Scheme に一票．

546 ：デフォルトの名無しさん：2009/04/26(日) 00:21:17

Z80のニーモニック。

547 ：デフォルトの名無しさん：2009/04/26(日) 00:43:05

ニーモニックの読みやすさならそうだが直交性なら8080だな
てか6809はどうよ？
きれいにまとまってると思うぞ

548 ：デフォルトの名無しさん：2009/04/26(日) 07:38:08

>>547
もっと具体的に教えて。

抽象化してシステム記述言語がアセンブラっぽくなる可能性もあるわけで
参考のために知っておきたい。

549 ：デフォルトの名無しさん：2009/04/26(日) 08:09:03

80系はレジスタが目的別なので、一般的には汚いと言われるね。
6809は16bitを睨んだ為に若干直行性に掛けるが、68000になると寧ろ綺麗な作りだ。

550 ：デフォルトの名無しさん：2009/04/26(日) 08:50:20

>>549
直交性っていうのはどういうこと？似た命令がないってこと？

551 ：デフォルトの名無しさん：2009/04/26(日) 09:06:04

お前らコーディングの汚さを言語のせいにする前に
自分のプログラミングのスキルを磨けボケ！

552 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/04/26(日) 10:36:56

>>552
なるほど。thnx

たしかに直交性が高いプログラミングの自由度があがって柔軟性がでるよね。

同じことをやる場合、直交性が低い方が見た目的には短いプログラムになるのかな。
自由度でいうと直交性が高いほうがいいけど、コードが短くなるなら
きめうちっていうのはある意味システムの抽象化が行われてるってことで場合によっては
美しい（短くてシンプル）なプログラムがかけそうな気がする。。。

554 ：デフォルトの名無しさん：2009/04/26(日) 10:42:26

Aが最強だろ

555 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/04/26(日) 14:56:43

Pascalですね

557 ：デフォルトの名無しさん：2009/04/26(日) 21:17:51

$記法を導入したという点で、並みいる関数型言語の中でも
Haskellは、より美しいといえると思う。
print (map last (a b (c d)))
↓
print $ map last $ a b $ c d
こんな置き換えが可能。
LISP系みたいに括弧だらけにならない。

558 ：デフォルトの名無しさん：2009/04/26(日) 23:29:21

$がきもちわるい
そんな記法ならLISPでもできるし

559 ：デフォルトの名無しさん：2009/04/26(日) 23:49:48

LiSPなんて旧時代のゴミだろwHaskellの美しさの足元におよばない
あらゆる意味でHaskellのほうが優れている

560 ：デフォルトの名無しさん：2009/04/27(月) 00:04:54

そういう変態構文のオナニーショーはLISPer個々でよくやってる事だよ
$記法とやらが読みやすいとはとても思えないし

561 ：デフォルトの名無しさん：2009/04/27(月) 00:16:16

みやすさって概念だったら表形式がみやすいのでは？
いっそのことExcelみたな表でプログラミングするっていうのはどう？表っていうのはリストの特殊形態であるわけだし。

562 ：デフォルトの名無しさん：2009/04/27(月) 02:02:58

($) がいつから記法になったの。ただの関数でしょ。

563 ：デフォルトの名無しさん：2009/04/27(月) 12:54:34

なんで過去の人工知能の研究者にリスパーが多かったんですか？エロい人教えて
あスレ違いか

564 ：デフォルトの名無しさん：2009/04/27(月) 13:10:26

LISPって他人が書いたコードを理解するのが極端に難しくない？
これは俺のアタマが手続き脳だから単に理解できないだけかもしれないけど。

565 ：デフォルトの名無しさん：2009/04/27(月) 13:38:54

>>561
Excelの表を「数式を置けるプログラミング・フィールド（ソースコード置き場）」とみなせば
かなり美しいプログラミング環境のような気もします。
プログラミング「言語」と呼ぶのは難しいでしょうか？

566 ：デフォルトの名無しさん：2009/04/27(月) 13:43:09

>>565
プログラミング言語かどうかは兎も角、環境としてはありだと思う。
実際、私のプロジェクトではそういうケースも多いし。
# アルゴリズムの検証をシート関数で行ない、それを元にC/C++で実装する。
そもそも、保存ファイル形式がXMLなんだしね。

567 ：デフォルトの名無しさん：2009/04/27(月) 13:47:28

>>565
表計算はもちろんプログラム言語だよ。

568 ：デフォルトの名無しさん：2009/04/28(火) 09:40:47

コーディングしないことが最も美しいのでは？

569 ：デフォルトの名無しさん：2009/04/28(火) 12:39:41

ニモニックかわいいよニモニック

570 ：デフォルトの名無しさん：2009/04/28(火) 14:44:14

Delphi prism - Delphiのグリーンスパンの第10法則に従った進化形ｗ

571 ：デフォルトの名無しさん：2009/04/28(火) 22:01:17

delphiというかpascalはピリオドの付け方がよく判らなくて嫌い

572 ：デフォルトの名無しさん：2009/04/30(木) 02:05:11

やっぱりHaskell lisp Smalltalk辺りかな。
例えば、Smalltalkなら、分岐制御、式ブロック、クラスが全てが
オブジェクト表現され、継承やクラス定義は全てメッセージングで表現される。
全てオブジェクトとメッセージ。こういう完結された仕様はやっぱり美しく感じる。
逆に、同じオブジェクト指向を謳うJavaの中途半端さと言ったら醜悪に尽きる。
あそこまで。バランスを崩すなら速度に特化したC++の方がまだ潔い。
Haskell lispは上の方で語られているから詳細は省くが、やっぱり美しい一貫性をもつ。

573 ：デフォルトの名無しさん：2009/04/30(木) 02:26:13

Haskell lispってなんだ。Haskell, Lispってことか？

574 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 07:16:47

美しいのはPythonだけど、
使ってるのはJavaです。
結局、可読性が高くなるかどうかなんて、
実装者の能力次第です。

575 ：デフォルトの名無しさん：2009/04/30(木) 07:31:10

>>574
その言語を熟知している人にとっての可読性ではそうだが、
その言語を全然知らない人間にとっての可読性は言語仕様によるのではないか。

576 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 07:36:12

可読性を上げる要因として、
主要はものは、
凝集度、結合度、明示的なネーミング
の３つである。
これらは言語とは全く関係ない。

凝集度が著しく低いコード、
不必要な結合性を生んでるコード、
意味分からん変数やメソッドがたくさんあるコード、
これらはどれも可読性が低い。
Cでも可読性の高いコードは書けるし、
Pythonでもゴミのようなコードは書ける。

言語への習熟度は、主要な言語においてはそれほど関係ない。

577 ：デフォルトの名無しさん：2009/04/30(木) 10:36:39

ToStringより、toStringがいいし、to_sが一番いい。
言語とその文化がもつ冗長性は美しさにかかわる。

578 ：デフォルトの名無しさん：2009/04/30(木) 11:06:36

>>577
sって何ですか、という疑問は？

579 ：デフォルトの名無しさん：2009/04/30(木) 11:13:55

to_i, to_f, to_aと並べて見せて、類推してもらう。

580 ：デフォルトの名無しさん：2009/04/30(木) 11:25:09

なんだかんだ言っても俺が見て一目で内容がわかる言語が美しいと言うことだろうな。
そんな言語はないけどね

581 ：デフォルトの名無しさん：2009/04/30(木) 11:27:52

どの言語も、汚いと思うのは意外と無いよね。
独自の文化には意外と慣れるから。
C#の命名も苦にならなくなる。

けど、phpとperlだけは馴染めなかった覚えが。
自分が使う期間が短かったのもあるけど。

582 ：デフォルトの名無しさん：2009/04/30(木) 14:56:42

>>580
Prolog

583 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 16:50:51

>>577
それは小さな問題だよ。
結局は、可読性に対するきちんとした知識と実装力を持っているかどうか。
可読性という意味からいえば、toStringの方が高いといえる。
to_sではsが何を意味しているのか分からない。
もちろんRuby出身なおれは分かるけどね。

例えば、
おれに言わせれば、
http://pc12.2ch.net/test/read.cgi/tech/1239708057/567
のコード、これ書いたやつは死ぬべきだと思うんだけど、
なんでだか分かる？

このコード読んで吐き気を覚えないやつは
プログラミングをすべきじゃないよ。

584 ：デフォルトの名無しさん：2009/04/30(木) 17:02:18

おまいは名前のわりにしっかりしてるなｗ

> このコード読んで吐き気を覚えないやつは

すまんが、吐き気を覚えない。
java.util.Scanner使ったこと無いから、
それに関する部分は良く分からんし。

585 ：デフォルトの名無しさん：2009/04/30(木) 17:17:11

>>583
俺も吐き気を覚えない。

可読性はプログラミング言語の美しさとは関係ないと書いている（>>576）ので
これは「最も美しいプログラミング言語」とは関係ない話？

586 ：デフォルトの名無しさん：2009/04/30(木) 17:36:14

美しいものに吐き気を覚えることもあり得るのでこの話はスレ違い

587 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 18:57:52

Scannerがどうとか言ってるんじゃないよ。
おれも使ったことないし、推測でscanfみたいなことかなと思ってるだけ。
おれはこのコードを見て、鳥肌がたち、書いた人間に殺意を覚えた。
おれがプログラムを書くものが読むことを必須とすると考えている本は、

Code Complete（上）
リファクタリング
実装パターン

の３冊だ。
他にもいい本は色々あるが、
とりあえずこの３冊を読まなければダメだ。

特にCode Completeは必須中の必須。
これが分からなくて、何を実装するというのだろうか。
可読性の低いコードは環境汚染に等しい。
無意識に可読性の低いコードを書く人間は、害悪。
おれは美しいコードを書くことについて強い興味を持っている。

そのおれが言う。
もっとも美しい言語はPythonだ、と。
そしてJavaプラットフォーム上で動くJythonを中心にこれからの世界は動き始めるだろう、と。

588 ：デフォルトの名無しさん：2009/04/30(木) 19:03:23

大仰な前フリはいいからｗ
http://pc12.2ch.net/test/read.cgi/tech/1239708057/567
の問題点を簡潔に示しておくんなまし。

> 鳥肌がたち、書いた人間に殺意を覚えた。

吐き気につづき、鳥肌、殺意とくれば、
興味深々になってしまって仕方ない。

ちなみに、俺が吐き気するコードは、
if (isRunning == true) と無用で余計なことをするものとか、
int flgっていう変数をヒョイと作って以下でグデグデ使うもの。
そんなもんかなぁ。

589 ：デフォルトの名無しさん：2009/04/30(木) 19:04:28

×吐き気する
○吐き気を催す

590 ：ちんこ ◆GbXlaaQNk. ：2009/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. ：2009/04/30(木) 19:19:40

>>588
flagを立ててそれを使うというのは、
可読性を落とすという要因から禁止されている。
何かの本に書いてあったから、おれの読んだ本を何年かかけて全部嫁、このクソ虫が。
また、flagというのであればbooleanにして欲しいし、
booleanの変数名には肯定的な名前をつけるというのもルールだ。
flagと言われても、何のことだか分からない。flgなんて論外だ。"a"を省略する意味が分からない。

勉強のために色々コードを読んできた。
どれもひどいものばかりだ。どいつもこいつも狂ってる。

おれが注目するのはすでに述べたとおり、
凝集度、結合度、明示的なネーミングの３つだ。
きちんと１つの仕事をする明示的な名前のついた小さなメソッドに分けることによって、
文を読むがごとく読めるようになってないコードはすべて吐き気がする。

おれがかなり好きなコードがある。
JUNGというソフトウェアのコードだ。
参考にするといい。
これを書いた人はかなり出来る。

592 ：デフォルトの名無しさん：2009/04/30(木) 19:19:57

そ、そんだけ？

593 ：デフォルトの名無しさん：2009/04/30(木) 19:21:00

このスレは、美しいプログラミング「言語」について書くスレです。
>>590 は「美しいプログラミング」について語っているので、
すれ違いだと思います。

594 ：デフォルトの名無しさん：2009/04/30(木) 19:29:11

ポール・グレアムが書いた文書（の翻訳）を読むと、
「LISP最高！Schemeって美しい！」と思うんですが、
いざ使ってみると、「なにこのカッコの多さ！ありえない！」
と思うんですよね（笑）

595 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 19:37:40

美しいプログラミングが分からない人間が、
プログラミング言語の美しさの何を語ろうというのだ。
何も判断基準がないじゃないか。
そこにあるのは、感性だけだ。
ただ美しいと思った、それだけ。
プログラミング言語は芸術ではない。
美しいものには美しいだけの理由がある。

そういう、なぜ美しいかということが分かった上で、
美しさについて語りたまえ、このクソ虫どもが。

もし分からないのであれば、
おれのようなスーパーハカーのいうことを聞いて
Pythonを使ってればいいんだよ。

596 ：デフォルトの名無しさん：2009/04/30(木) 19:38:22

でもまぁ、確かにJavaは美しくないとは思った。

597 ：デフォルトの名無しさん：2009/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. ：2009/04/30(木) 19:41:21

>>596
なぜだ。
なぜ、Javaが美しくないと考えたのか。
それが問題だ。

残念ながら、おれはJavaは最高に美しくはないものの、
それなりに美しく、かつ非常に生産性の高い言語だということで、
とてもお気に入りなんだ。
美しくなくはない、吐き気がするのはC++だ。
C++よりはCの方が美しい。
C++は言語仕様がどうとかいうより、
仕様の設計者はバカなのではないかと思うようなところがある。

599 ：デフォルトの名無しさん：2009/04/30(木) 19:44:02

>>598
具体的に、吐き気がするところは?
俺はクラス定義の中にメンバー関数の定義を書くと
それだけでインライン化するところは、馬鹿じゃないかと思った。
インライン化したければ「inline」と書けばいいのに。

600 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 19:47:38

ごめん、実はC++はあまり知らない。

601 ：デフォルトの名無しさん：2009/04/30(木) 19:49:18

>>599
理由は違うが同意。inlineなんてのはコンパイラに対するヒントでしかないんだから存在意義自体がないと思う。
インラインかしたくない事情があれば、それを指定するようにすればいいんだ。

602 ：デフォルトの名無しさん：2009/04/30(木) 20:07:34

俺は変態的なもののほうが美しく感じる。
C++ サイコー Lisp マンセーチンコシネー

まじめに書くと、なんとか指向とか関数型なんとかなどとのたまう言語は醜くく感じる。
そうしたければそのように書くこともできる、というのは大事だと思う。
でも、そのスタイルを強制されるのはまっぴらゴメン。

で、必然的にハイブリッドなものに美しさを感じるようになる。
いかにブレンドするか、その美しさこそが真の美しさ。

603 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 20:28:23

もうさ、
プログラミング言語はJavaで統一しようぜ。
全員Javaと最悪、Jython, JRuby, GroovyなどのJava実装スクリプトね。
Cを撲滅しようぜ。
Javaは実行速度だって、C++よりずいぶん速いんだ。

604 ：デフォルトの名無しさん：2009/04/30(木) 20:31:37

＞Javaは実行速度だって、C++よりずいぶん速いんだ。
なんだ、妄想癖の人だったのか。

605 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 20:38:50

いや、事実だけど・・・。
今のJavaはまじで速い。
Javaが遅かったというのは過去の話。
今はCと変わらないレベルの速度が出る。

606 ：デフォルトの名無しさん：2009/04/30(木) 20:39:17

【レス抽出】
対象スレ：最も美しいプログラミング言語は？
キーワード：D言語

抽出レス数：1

607 ：デフォルトの名無しさん：2009/04/30(木) 20:40:14

現行、言語の性能はコンパイラ屋の質に依存してるぞ。
意外かも知れんが、Linux上ではJavaとCは同等、C++が一番早い。
the computer language benchmark gameのサイトでスコアが見れる。

608 ：デフォルトの名無しさん：2009/04/30(木) 20:40:57

>>606
おもしろではあるが、美しくはないだろ。
!()だかの使い方が未だにわからんｗ

609 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 20:46:07

単純なプログラムではJavaは不利かも知れない。
だが、プログラムが複雑になるほど、Javaの最適化技術が生きてくるよ。
Javaは可読性の高いコードに対してもっともよい最適化を施す仕組みになってる。

610 ：デフォルトの名無しさん：2009/04/30(木) 20:55:09

はい、はい、はい。
わかったから、もう帰れ＞ちんこ

611 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 20:57:21

帰ります。
ただ、これからはみなさんも可読性というものに高い意識を持って欲しいです。
いや、持ちなさい、持ちやがれ。
可読性の低いコードを書く人は死ぬべきです。
プログラマというのは超のつく知能職だということを知るべきです。

612 ：デフォルトの名無しさん：2009/04/30(木) 21:06:16

C++だって速いからというだけで使われているという考えもどうかと思う。

一応オブジェクト指向も可能でありながら、Cとの互換性のために
OSのAPIやCのライブラリを使え、アセンブリ言語との連携が容易で、大抵のスクリプト言語をホストできる。
D言語とか出てきてはいるんだけど、C++を置き換えるまでには至っていないし……。

613 ：デフォルトの名無しさん：2009/04/30(木) 21:08:49

てかC言語とC++ってもう互換性無いよね？

614 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 21:10:47

現代のプログラムにおいては、
実行速度は関係ないから、
とにかく開発の容易性を重視すべき。
半導体技術の向上は目覚ましい。
だから、ソフトウェアの世界には、
古い時代のハードでやっていた人と、
新しい時代のハードから始めた人（おれとか）の
２つが入り交じってしまっている。
それが害悪なんだ。
若い人は積極的に正しいプログラムの書き方を学んで、
古い人たちを追い出すべきなんだ。

615 ：デフォルトの名無しさん：2009/04/30(木) 21:14:12

> 実行速度は関係ないから、
> とにかく開発の容易性を重視すべき。

はい、これで Java 消えた。

616 ：デフォルトの名無しさん：2009/04/30(木) 21:20:26

さすがに>>615は情弱というか低脳を感じざるを得ない

617 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 21:23:33

Java以上に開発が容易な言語があったら教えてください。
おれは知りません。
Javaにはたくさんの道具があります。
Pythonにはそれがありません。
Eclipse+Javaに開発速度で勝つことは不可能ですし、
Javaならば、美しいプログラムを書けるだけの言語仕様を備えています。

例えば、おれがC++が嫌いな一つの理由は、
コンストラクタチェーンが出来ないことです。
コンストラクタからコンストラクタを呼び出せなければチェーン出来ません。
保守性が著しく低くなります。

618 ：デフォルトの名無しさん：2009/04/30(木) 21:27:59

つ Ruby

619 ：デフォルトの名無しさん：2009/04/30(木) 21:28:41

つ Ruby on Rails

620 ：デフォルトの名無しさん：2009/04/30(木) 21:34:50

Web屋かよ、カスが

621 ：デフォルトの名無しさん：2009/04/30(木) 21:35:31

Twitterにも見捨てられた糞環境、それがRoR。

622 ：デフォルトの名無しさん：2009/04/30(木) 21:38:54

Ruby に仕事を取られたからといって、そう僻むなｗ

623 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 21:38:57

確かにRubyは美しい。
いや、美しさだけで言ったらRubyがマックスかも知れない。
だけど、RubyにはPythonに対して圧倒的に劣る点がある。
それは、コミュニティが小さいという点だ。
また、GoogleがPythonを採用してるなどの状況もあり、
Rubyへ優秀な人材が流れにくくなっている。
よって、RubyのライブラリはPythonに比べるとだいぶしょぼい。
スクリプトの標準がPythonになりつつあるというのもあって、もうこの差は埋まらないだろう。
Rubyはホビーランゲージとして生きていくことになる。

ただ、もし、もし、RubyがPythonと同じくendがいらない設計だったら・・・
そしたら話は変わっていたかも知れない。
Rubyのエンドラダーは害悪、可読性を言語仕様レベルで落とす原因になっている。

624 ：デフォルトの名無しさん：2009/04/30(木) 21:39:57

Rubyの字面は美しいって感じじゃないな。
あまりにも趣味的に過ぎる。

まあそれでもC++の醜悪さには及ぶべくもないが。
C++はパフォーマンスの要求されるところで使われて入るが
マルチコア環境での開発効率があまりにも悪すぎるので
関数型言語の台頭が予測されてるな。

625 ：デフォルトの名無しさん：2009/04/30(木) 21:41:58

>>623
> 確かにRubyは美しい。
> いや、美しさだけで言ったらRubyがマックスかも知れない。
> だけど、RubyにはPythonに対して圧倒的に劣る点がある。
> それは、コミュニティが小さいという点だ。

いいかげん、スレタイ読めや。

626 ：デフォルトの名無しさん：2009/04/30(木) 21:43:53

>>605
Javaでは配列にアクセスするごとにインデックスがはみ出していないかチェックする。
最適化しても、それを取り除くことはできないんじゃない?
C++では両端だけチェックして他は省くように書けるし、
コンパイラによっては、データ並列な部分を自動的にベクトル化してくれる。
(OpenMPを使って指示する必要がある部分もあるけど)
だから、信号処理や行列の計算など、速度が必要なタイプの処理の速度では、
JavaよりC++の方が一般的に言って上じゃないかな。
(私はJavaがメインだけど、嫌々C++を使いまくる場面がまだまだあるよ)

>>617
C++ 0xではコンストラクタチェーンができるようになる予定。
楽しみですな。

http://ja.wikipedia.org/wiki/C%2B%2B0x

627 ：デフォルトの名無しさん：2009/04/30(木) 21:45:08

RoRなんて使ってるとこなんてホントにあるの？
どこの底辺？

628 ：デフォルトの名無しさん：2009/04/30(木) 21:45:50

がっはっは。

> ただ、もし、もし、RubyがPythonと同じくendがいらない設計だったら・・・
> そしたら話は変わっていたかも知れない。

end がなければ google が Ruby を採用し、優秀な人材も集まり、
しょぼいライブラリも目の醒めるようなライブラリとして生まれていた、と。

んな、あほな。

629 ：デフォルトの名無しさん：2009/04/30(木) 21:47:42

さすがに>>627には情弱というか低脳を感じざるを得ない

630 ：デフォルトの名無しさん：2009/04/30(木) 21:50:21

反応が既に終わってるな、まともに答えられんのか

631 ：デフォルトの名無しさん：2009/04/30(木) 21:52:40

ttp://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
PERLもどきならではの汚さを持つRubyの人気はもう落ちてます。

632 ：626：2009/04/30(木) 21:53:50

配列の処理を中心に見ると、美しいと思う言語はSaCかな。

SaCでは配列は全て値渡しで、プリミティブ値はランク0の配列として扱われる。
ランク数不明の配列を引数に取る関数を定義すれば、
プリミティブ値でも任意のランク数の配列でも、一つの関数で処理できる。

概念的には値渡しだけど、内部ではポインタ渡しにした上、
データフロー解析を使って処理は最小限にしてくれる。
ベンチマークではFORTRANよりも速度が出ているくらい速い。
(ちなみにコンパイラが出力するのはCのコード)

研究用の言語なので常用は厳しいし、足りないものも多いけど、
メインストリームの言語に長所が取り込まれればいいと思っている言語だ。

http://www.sac-home.org/

633 ：デフォルトの名無しさん：2009/04/30(木) 21:56:25

>>631
Java の人気の下がり具合のほうが大きいね。

634 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 21:56:54

>>628
それはない。
だが、おれはRubyを好んでいたかも分からん。
いや、やっぱりPythonかな。
Pythonコミュニティには高い可読性を追求する気概がある。
可読性を無視するクズプログラマには用はない。
でもやっぱりRubyもいいよね。
Rubyはインスタンス変数の書き方がいいわ。
Pythonは少しうんこなところがある。
selfがくどかったりね。
あれはC言語でのオブジェクト指向の書き方なんだよ。古い。

>>626
C++の設計者が、
C++が保守性、可読性について言語仕様レベルで問題があることに気づいていた。
それだけで余は満足じゃ。

635 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 22:01:03

>>631
どこが？

Python VS Rubyに関しては
もう逆転出来ないくらいの差がついてしまったよな。
Matz涙目www

636 ：デフォルトの名無しさん：2009/04/30(木) 22:08:04

>>635
英語は読めなくても、下のグラフが何を意味しているかぐらいはわかるだろう。。。

しかし、

> Matz涙目www

なんか、発言にギャッップを感じる。

637 ：デフォルトの名無しさん：2009/04/30(木) 22:10:51

>>636
常識のある人だと，長い目で見た場合 Java は下降気味，
Ruby は上昇気味という傾向を読み取るだろうね．

妄想系の人にこのグラフが一体どのように見えるかまではわからんがw

638 ：デフォルトの名無しさん：2009/04/30(木) 22:13:12

何でRubyヲタがJavaを目の敵にしてるのか知らんが、実際使われてないだろ
はてなとかやってる人？ｗ

639 ：デフォルトの名無しさん：2009/04/30(木) 22:16:15

だーれも Java を目の敵してませんが。
被害妄想系にはそう見えるかも知れませんねｗ

そうか、Ruby に仕事を取られたカワイソウな奴は
そんなに危機意識を持ってるのか。

640 ：デフォルトの名無しさん：2009/04/30(木) 22:18:32

> Ruby に仕事を取られた
という妄想をRubyヲタが好むのは何でだろうね

641 ：デフォルトの名無しさん：2009/04/30(木) 22:19:29

>>640
そんなことはない！と涙目になりながら必死で否定するやつがいるからじゃない？

642 ：デフォルトの名無しさん：2009/04/30(木) 22:20:39

P系言語とよろしくやってるだけで、Web屋以外の人は見向きもせんでしょ

643 ：ちんこ ◆GbXlaaQNk. ：2009/04/30(木) 22:22:52

Pythonのやばいところは、
いちいちself.valueで指定しなきゃいけないところ。
これは可読性を落とすね。
でも、インデントによる論理改行と、
あとはキーワード引数で楽々借金返済出来る。
PythonとRubyのいいとこどりをした言語があったらいいんだけどね。
Rubyのmixinなんかは美しい。
Pythonはmixinをとって、多重継承を捨てるべきだと思う。

Pythonは大体いいけど、時々悪い。
Rubyはかなりいい言語なんだけど、コミュニティが貧弱すぎる。
GoogleはPythonだけど、ThoughtWorksはRubyだ。
おれはGoogleとThoughWorksどっちにでも入れるとしたらThoughtWorksを選ぶ。

644 ：デフォルトの名無しさん：2009/04/30(木) 22:26:18

ところで今日一番恥かしい発言をした>>631はどこに行ったんだろう

645 ：デフォルトの名無しさん：2009/04/30(木) 22:28:06

Rubyが凄い勢いで飽きられてるソースとしては十分だな

646 ：デフォルトの名無しさん：2009/04/30(木) 22:36:03

いや、別に Ruby を擁護する気はさらさらないが、どう考えても

> Rubyが凄い勢いで飽きられてるソースとしては十分だな

は >>631 のリンク先から読み取れないな

647 ：デフォルトの名無しさん：2009/04/30(木) 22:54:20

>>626
普段C++を使うけど、さすがにJavaもそこまで間抜けなわけがないと思うぞ。
範囲チェックを必要最低限に押さえることはJavaの最適化の序の口だろ。

648 ：デフォルトの名無しさん：2009/04/30(木) 22:59:40

>>643
手続き型の言語しかわからない人には
GoogleのMapReduceは何をやっているか
理解するのは難しいでしょう。

Code Completeもいいけど、
プログラムの作り方や
プログラム言語の優劣について論じるならば
SICPあたりも読むべき。

649 ：デフォルトの名無しさん：2009/04/30(木) 23:10:20

ぶっちゃけ、審美眼とうものは恣意的なものであるので、
○○は美しい、　というあらゆる命題は真理を述べることはできない。
○○は可読性が高い、という命題も同様である。

というわけでお前ら乙としか言いようがないわｗ

650 ：デフォルトの名無しさん：2009/05/01(金) 02:30:53

アセンブラやってるとすべての言語の意味がイメージできるので、
自分が美しいと思う言語を選ぶと、ずばりJava。EJBを除く。

651 ：ちんこ ◆GbXlaaQNk. ：2009/05/01(金) 08:16:48

>>648
SICP読んだ人は美しいコードが書けるんですか？
立ち読みしたけど、とてもそんな感じはしなかった。
逆に、あれを読んだら汚いコードを書くようになってしまう気すらした。
事実、情報系の人間のコードを読んだことがあるが、腹抱えて笑うほどだった。
暗号みたいなコード書いて、自分は頭がいいんだと主張しているようだった。
おれはそんな世界には用がないんだ。
おれは正しいソフトウェアをアジャイルに構築することに興味がある。
そのためには急がば回れなんだよ、もっとも美しい設計、高い可読性の保ち方を知らない人間はゴミみたいなソフトウェアしか作れない。
したがって、生きてる意味がない。
おれは日本でもっとも可読性にストイックな男だ。

652 ：デフォルトの名無しさん：2009/05/01(金) 09:00:16

＞おれは日本でもっとも可読性にストイックな男だ。
なんだ、妄想癖の人だったのか。

653 ：ちんこ ◆GbXlaaQNk. ：2009/05/01(金) 09:03:17

じゃあ、おれより可読性にストイックな人間を教えてくれ。
アポイントメントとって会いにいく。

654 ：デフォルトの名無しさん：2009/05/01(金) 09:10:34

>>653
可読性にそこまで拘るなら、
転職して、実行速度なんか気にしなくてもよい環境で、
Prologプログラミングの修練を勧めます。
これ本気。

655 ：ちんこ ◆GbXlaaQNk. ：2009/05/01(金) 09:24:19

>>654
当方学生でつ。

656 ：654：2009/05/01(金) 09:28:31

>>655
いっしょにやろうじゃないか。

657 ：ちんこ ◆GbXlaaQNk. ：2009/05/01(金) 09:31:44

どういう進路にするか迷ってるんでつ。
研究職でいくか、プログラマとして突っ切るか。
おれはプログラミングが好きだし、得意だけど、
日本のプログラマは地位が低すぎる。
年収１０００万はないと嫌だ。

658 ：デフォルトの名無しさん：2009/05/01(金) 09:34:08

可読性にこだわってる割にはちょっとな。
590でその４行が　おまいのいう順番になったときは、
プログラムとして違う動作になる。
事の大小はともかく、入力があった場合にのみ表示が出るという動作を
たったこんな小さなプログラムから読めないやつに可読性なんていう資格は無い。
ちゃんと動くことの方が数倍重要だ。

659 ：ちんこ ◆GbXlaaQNk. ：2009/05/01(金) 09:40:00

あ、そうなの・・・？
知らんけど。

660 ：ちんこ ◆GbXlaaQNk. ：2009/05/01(金) 09:45:50

まず、
入力があった場合にのみ表示が出る、
なんて仕様が狂ってるし、
大体、このプログラムおかしいもん。
日本のソフトウェア業界っていうのは、こういうコードが蔓延してるんだろ。
おれは単純に凝集度の観点から可読性が低いといっただけで、
こんなのそもそもまともなプログラムじゃない。
動作を確認するまでもないコード。
見たその時点で、気持ち悪いという感情を得た、それだけだ。
もちろん、入力を施す為の記述もない、という意味も含めてね。

661 ：デフォルトの名無しさん：2009/05/01(金) 10:53:13

>>651
SICPを読んだら、より美しいコードが書ける。
なぜならば、手続きの抽象化について学ぶことができるから。

Javaが採用しているオブジェクト指向はデータの抽象化を推進する。
もし手続きの抽象化について学べば、それをJavaでも応用できるよ。
綺麗なStrategyパターンを書くとかね。

662 ：デフォルトの名無しさん：2009/05/01(金) 11:04:31

「ケント・ベックの Smalltalk ベストプラクティス・パターン」

これを読むと、ケント・ベックは可読性にストイックな男としては
世界でも上位に入るのではないかと思う。
可読性にこだわった先達として、>>660はこれも読むといいよ。

663 ：デフォルトの名無しさん：2009/05/01(金) 11:04:51

>>590の言語が何かは知らないけれど

Scanner stdIn = new Scanner(System.in);

これは、入力オブジェクトの宣言なのだから、処理とは分けて記述しなければならないのでは?
処理の最中に、これがある方が気持ち悪いのですが...

664 ：デフォルトの名無しさん：2009/05/01(金) 11:10:17

>>660
とりあえず、君の書いたソースを読みたいな

665 ：デフォルトの名無しさん：2009/05/01(金) 11:19:25

>>664
こういう展開でソースを出して見せた奴、みたことないｗ

可読性という話で、十数行のサンプルプログラムみたいなのに大げさに噛み付く姿からして、
彼が取り組んだことのあるプログラムの大きさと複雑さの程度が見て取れる。

666 ：デフォルトの名無しさん：2009/05/01(金) 11:23:46

多面的に物事を見れてないしね

667 ：デフォルトの名無しさん：2009/05/01(金) 13:47:46

>>665
出したところで、
ふーん、俺には可読性が高いようには思われない

と言い出す人が現れて終了

668 ：デフォルトの名無しさん：2009/05/01(金) 15:44:13

このコテはソースの美しさを語る前に自分の日本語をどうにかした方がいいと思う

669 ：デフォルトの名無しさん：2009/05/01(金) 16:11:41

件のコードが書かれた文脈（書き捨てのサンプル）を考えると
>>660 はアホとしか思えん

いくらソースの可読性が高かろうが、文脈を読み取れないやつが
読むんじゃなあｗ

670 ：デフォルトの名無しさん：2009/05/01(金) 17:11:30

>>605,634
　C++もLLVMなんかのVMで動くし。ネイティブに最適化された
バイナリよりも早い。当然、JVMより遥に早い訳だが。
言語の話をしてる時に環境の話を出すなよ。不毛だ。
>selfがくどかったりね。
>あれはC言語でのオブジェクト指向の書き方なんだよ。古い。
あんまり、オブジェクト指向しらんだろ？マルチディスパッチとか
Smalltalk学んでこいよ。

　著名人の間で美しいと言われるのはLispだが、
基本的に統一性のある文法の言語が美しいとされるね。
　Rubyの話も度々出るが、改行が不自由でメソッド呼び出しに
糖衣構文があるってのは汚いな。概念上はSmalltalkに似て
綺麗なんだけどな。あと、最近人気が下降気味らしいな。
(書籍販売数・プロジェクト数・他　が縮小してるらしい)

　Objective-Cなんかは、C言語に埋め込みできるオブジェクト
指向言語だと考えれば綺麗だと考える著名人も少なくないだろうね。

671 ：ちんこ ◆GbXlaaQNk. ：2009/05/01(金) 18:59:36

お前ら、ずいぶんと偉そうだな。
日本のソフトウェアエンジニアなんて、高卒とか文系とかばかりだろ。
相手にならんよw
日本人が書いたコードで美しいコードを見たことがない。
もしオープンソースでそういうものがあるのなら教えてくれ。
情報学科卒でSICPなどは当然読んでるだろうと思われる人間のコードも読んだことがあるが、
カス同然だった。
よってSICPなど意味ない。

672 ：デフォルトの名無しさん：2009/05/01(金) 19:18:03

>>671
そっすね。

673 ：ちんこ ◆GbXlaaQNk. ：2009/05/01(金) 19:20:44

ところでだけど、
Python3.0とPython2.6だったら、
どっちを使うべき？
対して差、ないよね？
Python3.0ってこれから広く使われる予定あるの？
互換性切ってるし、美しくなったといっても、使われるかどうかは別な気がする。

674 ：デフォルトの名無しさん：2009/05/01(金) 19:33:43

＞　ちんこ
そこまで自惚れられる根拠は何かね？

675 ：デフォルトの名無しさん：2009/05/01(金) 20:26:36

> ちんこ

マーチン・ファウラーが評価している「fluent interface（流れるようなインターフェイス）は
デメテルの法則を破っているからCode Complete的にはNGだと思うんだけど、
ちんことしては、これはOKなの？NGなの？

676 ：ちんこ ◆GbXlaaQNk. ：2009/05/01(金) 20:36:49

絶対にNG
他にも、おれはインターフェイスの設計として、
メソッドの引数を単純データ結合に保たないような設計
（
これは、
場合によっては引数オブジェクトの導入リファクタリングによって改善されるが、
最初は絶対に、結合度を低く保つべき
）
や、
メソッドチェイニングを前提とした設計、
とりわけ、可変オブジェクトを返す設計を嫌う。
Immutableなオブジェクトを生成して返すのであればそれは許されないこともない。
Mutableなオブジェクトを返すのはかなりやばい。
このFluent Interfaceというのは返したオブジェクトが可変になっているから、相当悪い。

これをおれが悪いと思う理由は、
おれがテスト駆動とリファクタリングを前提にプログラムを書くようにしているからであり、
経験的に、結合度をとにかく低く保った方がリファクタリングがしやすいからだ。
確かに、メソッドチェイニングを回避するために、委譲メソッドを作るのは手間だが、
IDEを前提とした場合、そこまでの手間でもないし、
何より結合度を低く保つことのメリットの方が断然大きいと感じている。

677 ：ちんこ ◆GbXlaaQNk. ：2009/05/01(金) 20:43:23

マーチンはたまにおかしなことをいう。
ケントベックのいうことはほとんどの場合信じられる
（
例えば、おれは美しい設計のために
常にstaticファクトリを使うべきだと思っていたが、
ケントは、ただの生成の為にstaticファクトリを作るのは愚であると、
実装パターンにおいて説いている。
確かにそうだと思ったので、それ以降、おれは無駄なstaticファクトリを作ることをやめた
）。

あと、Code Completeに書いてあることもほぼ１００％信じられる。
マーチンのリファクタリングもほとんどは信じられるが、
おれは、仲介人の導入メソッドだったか、名前は忘れたが、
委譲するのが大変だからやめる、と言った主旨のリファクタリングは訂正して消去して欲しいと思った。
マーチンは尊敬出来るソフトウェア開発者だが、彼とおれとの間には少しだけ設計に対して意見の相違がある。

678 ：675：2009/05/01(金) 21:00:22

>>676
ありがとう。
流れるようなインターフェイスは読みやすいので、
読みやすさとどっちを優先するか聞きたかった。

俺もクラス間の結合度を低く保つように心がけているけど、
メソッドが7つを超えたら別のクラスに分けて、
元のクラスに分けたクラスのオブジェクトを返すファクトリメソッドを作ってる。

679 ：ちんこ ◆GbXlaaQNk. ：2009/05/01(金) 21:03:31

メソッドの数は関係ない。
仮にメソッドの数が増えたらクラスを分離して、
そのクラスに処理を委譲するようにしろ。
実装コードが増えすぎるのが問題なので、あって、
インターフェイスの数が増えることが問題なのではない。
これを勘違いしてるやつが多すぎる。

そして、
元のクラスにわけたクラスのファクトリを作るという設計も意味不明だ。
君はちゃんとオブジェクト指向を学んでいない。
よって死ね。

680 ：デフォルトの名無しさん：2009/05/01(金) 22:34:40

「俺は、ビックマグナムだ!!!」
と思っていられるうちは自惚れる事もできるさ
まあ、大抵の場合、銭湯に行って己の矮小さに気付くわけだがなwww

681 ：デフォルトの名無しさん：2009/05/02(土) 00:49:24

だから、ソースは？

682 ：デフォルトの名無しさん：2009/05/02(土) 01:13:54

自演乙

683 ：デフォルトの名無しさん：2009/05/02(土) 01:43:55

よしいまからHaskerubyつくる

684 ：デフォルトの名無しさん：2009/05/02(土) 03:56:41

夜郎自大とはまさにこのことだ

685 ：デフォルトの名無しさん：2009/05/02(土) 16:00:30

「プログラム言語ツクール」とかあったら、
みんなで作って見せ合えるのにね。
文法をBNFで書けば言語ができるようなの。
ライブラリは.NETのを使えばいいね。

…単に.NET用のyacc/lexを使えばいいのか？
っていうか、最も美しい言語はBNFか？

686 ：デフォルトの名無しさん：2009/05/02(土) 16:32:42

>>685
ようこそ♪

http://pc12.2ch.net/test/read.cgi/tech/1233143342/

yaccやbisonは使いにくいので、個人的にはCaperがお薦め。
BNFを書くと、構文解析機と、解析後に呼びだす
(意味解析用の) 関数が一通り定義されたインターフェースを
生成してくれる。
(言語はC++, C#, Java, D, JavaScriptに対応)

後はそのインターフェースを、構文に対応する
処理をするよう実装すれば、自分の言語ができてしまうよ。

687 ：デフォルトの名無しさん：2009/05/02(土) 16:39:28

>>685
システムトレードの話かとおもった

688 ：デフォルトの名無しさん：2009/05/02(土) 16:44:34

言語の美しさが構文の美しさに還元されると思ってる人がいるけど・・・
そもそも、仕様が美しければ実装はどうでもいい的なことを最初に言い出したのは
いったい誰なんだろう

689 ：デフォルトの名無しさん：2009/05/02(土) 16:47:20

Lispでいいじゃん

690 ：デフォルトの名無しさん：2009/05/02(土) 16:47:55

実装なければ言語がないのも同じ。　
ひとつでも実装あって動けばその言語はある。
実装あればその動作は関係ないだろう。

691 ：デフォルトの名無しさん：2009/05/02(土) 16:54:17

>>685
既存の言語を使いこなせないと新しい言語を作れないから、
既存の言語が使いにくいと思う人達は
新しい言語を作るところまでいきつかない。
そういう人達こそ言語に革新をもたらすかもしれないのにね。

誰でも簡単に動く言語を使えるツクールがあれば、
言語の開発が促進されるかもね。
面白いアイデアだと思う。

字句解析と構文解析は定義ファイルから自動生成できるとして、
難しいのは意味解析の自動生成かな。

自動生成できなくてもツクール内に動作を用意しておいて選択する
方法もあるけど、典型的な機能以外は実装できなくなってしまう。

692 ：デフォルトの名無しさん：2009/05/02(土) 16:56:27

>>688
仕様が最適化を難しくすることもあるから、
個人的には言語の仕様と実装はセットで考えるべきだと思う。

>>689
Schemeをいじってみたけど、if-then-elseなどの
普通の関数とは動作 (評価の順序) が違う機能も
同じS式で統一してあるのが嫌だった。
意味が違うものは構文も別にするべきだと思う。
Haskellのように全て最外簡約ならいいんだけど。

>>690
使える道具を探す立場ではそうなのだけど、
仕様を示すだけでも、言語を作りたい人達の参考になるよ。
(私も含めて)

693 ：デフォルトの名無しさん：2009/05/02(土) 18:02:35

なんだかんだCOBOLが一番読みやすい。

694 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/05/03(日) 05:06:44

そんなあなたにSmalltalk。予約語なんてなし。分岐も繰り返しもただただメッセージングあるのみ。

696 ：デフォルトの名無しさん：2009/05/03(日) 07:00:01

>>686
汎用の言語と範囲限定の言語（いわゆるDSL)の2種類あると思うよ。

汎用の言語は、既存の言語をこえるものはでてこないし、Lispでいいじゃんで終わってしまったりすると思う。

面白いのは範囲限定の言語で、
～のような目的のシステムを書くために、○○のような言語を作ってみました。
っていうアイデアをもちよるのは面白いかもしれない。

美しさのひとつにシンプルさってあると思ってて、ある程度自由度をもったシステムがいかに簡潔かけたかというのがポイントの一つになり得ると思う。

697 ：デフォルトの名無しさん：2009/05/03(日) 07:54:00

>>696
システムの簡潔さはどうやって評価するの？
たとえば、DSLを利用するためのライブラリをリンクしなければならないとしたら、
そのライブラリを必要としないシステムよりも複雑になったと言うこともできるけど。

698 ：デフォルトの名無しさん：2009/05/03(日) 13:19:34

Objective-Cはなんかゾクゾクくる。

Javaさんざんやって、
Smalltalkやそのコミュニティにはなんかしらんが畏敬の念を抱きつつ、
C++行ってモヤモヤして、
Rubyをやってウハウハしてると。

699 ：デフォルトの名無しさん：2009/05/03(日) 16:35:35

Objective-C最高。

700 ：デフォルトの名無しさん：2009/05/03(日) 21:32:00

>>697
そういう評価もそれはそれでありなのでは。いろいろ評価方法はあっていいと思う。目的によって違うのでしょうから。
将来同じような目的にであったとき、そういえばこういう局面でこういう言語を使えば効率よくなるって話があったなっていう引き出しをたくさん
用意しておくのもいいのでは。

701 ：デフォルトの名無しさん：2009/05/03(日) 23:41:05

>>692
Schemeのifは「文」なんですよね。
特別扱いのようです。
Haskellは最外簡約で、
smalltalkはブロック（lambdaと同じ）で
無理なくクリアしているのが美しいと思います。

702 ：デフォルトの名無しさん：2009/05/03(日) 23:45:02

こんなのやってたんだ。。。

言語開発合宿
・2泊3日の期間内に、オレ言語の仕様とその処理系を作るというイベントです
http://wiki.fdiary.net/ldev/

703 ：デフォルトの名無しさん：2009/05/04(月) 17:27:23

>>696, >>697, >>700
「言語の」複雑さを評価する指標なら、
ASTのノード数なんてどうだろう。
同じ処理を少ないノード数で記述できたら
その言語は簡潔ということにならないかな?

704 ：デフォルトの名無しさん：2009/05/04(月) 19:06:02

>>703
それ全然意味ない！lambda 一発になるwW
最終的には、なにがしかの形式意味を、いかに簡潔に書きうるかだろ？

705 ：デフォルトの名無しさん：2009/05/05(火) 00:05:28

>>704
> lambda 一発になるwW

lambdaを使って書いた無名関数の定義が含むノード数も
評価するわけだから、それなりに妥当なんじゃない?
無名関数を使う側が1ノードになるのは、コード自体の簡潔さに対応する。

> 最終的には、なにがしかの形式意味を、いかに簡潔に書きうるかだろ？

簡潔であることを「どう評価 (数値化) するか」の話をしているんでしょ。

>>704は>>694かな?

706 ：705：2009/05/05(火) 00:16:53

>>703-704
問題になるのは無名関数ではなく、マクロかな、と思う。

707 ：デフォルトの名無しさん：2009/05/05(火) 02:22:14

>>705 ASTでは構文の持つ意味まで説明できないって言ってるんじゃないの?

708 ：デフォルトの名無しさん：2009/05/05(火) 03:37:30

>>702
自分で言語を開発したい/してる人って、案外いそうですね。
この板にはそういうスレが無いので、
もしこのスレにそういう人がいたら、
様子を聞かせて (読ませて) もらえると面白いと思います。

>>707
>>703の「同じ処理を少ないノード数で記述できたら」が
>>704の「なにがしかの形式意味を、いかに簡潔に書きうるか」
に対応していると見ると「処理」は「形式意味」に対応しますね。

そうだとすると、>>703は
「処理 == 形式意味」が「同じ」場合、
つまり「構文の持つ意味」を統一済みの場合についての話なので、
構文の持つ意味を説明する必要は無いのでは。

思うに、

>>707が真だとすると、>>704は既に存在するコードを対象に、
同じ量のコードがどれだけの量の形式意味に還元されるか、
という話をしているのでは。

それに対し、>>703と>>705はおそらく、
決まった課題を与えて (あらかじめ形式意味を統一して)
それをどれだけの量のコードで表現できるか、
という話をしていると思います。

709 ：デフォルトの名無しさん：2009/05/05(火) 19:17:58

最も美しいプログラミング言語は賛否両論あるだろうが、
最も汚いプログラミング言語の一つがC++であることに異論がある人は
少ないだろう。

710 ：デフォルトの名無しさん：2009/05/05(火) 20:13:38

つ COBOL

711 ：デフォルトの名無しさん：2009/05/05(火) 20:46:42

つ Objective-C

712 ：ちんこ ◆GbXlaaQNk. ：2009/05/05(火) 21:34:31

もっとも美しい言語はPythonです。
ほんと、この言語で仕事ができるところに就職したい。
やっぱベンチャーを作るべきなのかな？かな？

713 ：デフォルトの名無しさん：2009/05/05(火) 22:12:05

>>712
ベンチャー作るのに賛成!
Pythonに反対!

714 ：ちんこ ◆GbXlaaQNk. ：2009/05/05(火) 22:50:49

Pythonはもっとも美しい言語だろjk
これ以上に美しい言語があったら教えてくれ。
おれは知らない。

715 ：デフォルトの名無しさん：2009/05/05(火) 22:53:32

ぱいそんはどのあたりがうとぅくしぃのかおせーてくれ

716 ：デフォルトの名無しさん：2009/05/05(火) 23:01:21

>>712
宣言的とは見えない点。
オブジェクト指向である点。
インデント構文を必要とした点。

リストの内包表記は評価するけど。

717 ：デフォルトの名無しさん：2009/05/05(火) 23:02:25

>>715 だったね。>>712というより。

718 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/05/05(火) 23:36:07

>>718-719
乙。
COBOLはアンチが多い一方で、魅力を語るのをなかなか見かけない。
でも、一時代を築いた言語だし、何か美しさがあるんじゃないかな。
(>>693あたり、語ってくれないかな)

721 ：デフォルトの名無しさん：2009/05/05(火) 23:43:03

>>719
FORTRAN訂正。。。やっぱCOBOLか。ほかはだいたい同じ感じだな。

FORTRAN 言語の検索結果約 204,000 件
　FORTRAN 言語美しいの検索結果約 5,180 件
　→2.53%

722 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/05/06(水) 00:31:22

>>709
激しく同意。
そして俺はC++をさらに拡張しようとしている連中の思考が理解できない。
もう既にぐっちゃんぐっちゃんの闇なべの残飯みたいな状態なんだから、
さらに何個か残り物ぶち込んでも分かんないだろ？みたいな感じなのだろうか。
そしてそんな物をいったい誰が食うというのだろうか。

724 ：デフォルトの名無しさん：2009/05/06(水) 01:04:53

お前や俺が食うんだよ！　ヒッヒッヒ

725 ：デフォルトの名無しさん：2009/05/06(水) 06:05:56

>>723
闇鍋から嫌いな物を除いて好きなものだけにすると、
あら不思議、至高のお鍋になるんだよ。

726 ：デフォルトの名無しさん：2009/05/06(水) 06:51:21

>>708
おれがこの合宿に参加して、
この中のどれかのテーマの言語を開発するとする。
そして、そのテーマの命題＋美しい言語に仕上げることを目標とする。
そのとき、Lispのような言語にするだろうか。
いざ、そうなったときにはシンプルな命令体系にして、BASIC風なスクリプトにするんじゃないかなと思う。
つまり、美しい＝覚えることが最小限の言語（文法が最小）
となるような気がする。

727 ：デフォルトの名無しさん：2009/05/06(水) 07:01:34

>>726
そういう意味では Guarded Horn Clauses のような言語が
一番美しいのではないか。

728 ：デフォルトの名無しさん：2009/05/06(水) 10:01:05

>>727
平行プログラミング言語がもっともシンプルというのも考えてみれば不思議だね。

729 ：デフォルトの名無しさん：2009/05/06(水) 11:17:06

>>726
> シンプルな命令体系にして、BASIC風なスクリプト

HSP?

730 ：デフォルトの名無しさん：2009/05/06(水) 12:01:19

>>727
Guarded Horn Clauses（KL1）について調べてみた。
これは美しいね。
しかし、これの仕様と実行環境を作るのに570億円もかかっているとは…。
これといい、Σプロジェクトといい、官主導のものって無駄に金を食ってる気がする。

731 ：デフォルトの名無しさん：2009/05/06(水) 12:30:41

気がする？
今さら何を・・・。

732 ：デフォルトの名無しさん：2009/05/06(水) 13:03:30

Σプロジェクトなんて２億円を使ったあげく
結局OSはUNIXが一番いいという結論を出しただけのプロジェクトだもんな。
官僚ってアホばっかりだな

733 ：デフォルトの名無しさん：2009/05/06(水) 13:16:11

>>727,729
KL1は、論理や並行処理の部分を抽象化してあって、HSPはある範囲ないのGUIアプリのためにカスタマイズされているよね。

空想の話だが、
>>702のような合宿があって、そこの審査員を依頼されたとしよう。
担当は作成された言語を「美しさ」という点から評価するとする。
この場合、どういう評価観点が考えられるかな。例えば
・目的に対し最適化された命令体系・文法になっている
・目的に対して最適のパラダイムまで抽象化が行われている（構造化、オブジェクト、関数型、論理型、並行）
・ライブラリ、、、
などかな。

734 ：デフォルトの名無しさん：2009/05/06(水) 17:19:01

CはうつくC
なっつっ亭

735 ：デフォルトの名無しさん：2009/05/06(水) 19:08:13

駄洒落は寒いが、Cが美しいことは真理。

736 ：デフォルトの名無しさん：2009/05/06(水) 23:22:02

Pythonは'Python'という名前以外は美しい

737 ：デフォルトの名無しさん：2009/05/07(木) 01:24:01

>>736
あなたなら、なんと名付けるの?

738 ：デフォルトの名無しさん：2009/05/07(木) 01:54:56

oppai

739 ：デフォルトの名無しさん：2009/05/07(木) 02:13:14

HSPって昔の8bitマシンのBASICみたいだね。
美しいかどうかは議論の余地があるけど、とっつきやすく、初心者でもプログラミングしやすいと思う。

740 ：デフォルトの名無しさん：2009/05/07(木) 04:13:26

>>739

>とっつきやすく、初心者でもプログラミングしやすいと思う。
それって「美しい」の必要条件になり得ると思うんだけどなぁ。

741 ：デフォルトの名無しさん：2009/05/07(木) 06:51:23

高度なアートは素人には分からないというのもあるのでは

742 ：デフォルトの名無しさん：2009/05/07(木) 07:33:11

　　　　2
E=mc

743 ：デフォルトの名無しさん：2009/05/07(木) 10:29:42

逐次的に書けてシンプル
動作がスタック操作のみでシンプル
関数に副作用がなくてシンプル
すべてがリストでシンプル
すべてがオブジェクトへのメッセージ送信でシンプル
すべてがホーン節のみでシンプル

744 ：ちんこ ◆GbXlaaQNk. ：2009/05/07(木) 18:33:22

とりあえず、今インターンとやらで、WinAPIを触ってる。
ひどい・・・。
C++もちょっと勉強したけど、
ひどい・・・。
Javaのありがたみが分かったのと同時に、
Pythonとかゆとり用言語だな、と感じた。

745 ：デフォルトの名無しさん：2009/05/07(木) 19:19:07

ハードウェアを触ればもっとひどいと思うよ。
そして、プリインストールされているOSのありがたみが分かる
または、ゆとり用OSだなと感じる。

746 ：デフォルトの名無しさん：2009/05/07(木) 19:31:19

haskellとかprologこそ真のゆとり言語だよ

747 ：ちんこ ◆GbXlaaQNk. ：2009/05/07(木) 19:35:12

>>745
ハードからのシグナルをコールバック関数で受けるというプログラムを書いている。
なんか、オブザーバパターンってレベルじゃなくて、
依存の方向が逆な気がするんだよね・・・。
美しいプログラムしか知らないおれにとっては地獄も同然だぜ。

>>746
それらに実用性はないだろ。
Pythonには高い実用性がある、それに書いててwktkする何かがある。

748 ：デフォルトの名無しさん：2009/05/07(木) 20:12:43

>>746
'70年代のSmalltalk（＝暫定ダイナブック環境）はさながら、ゆとりＯＳか。

749 ：デフォルトの名無しさん：2009/05/07(木) 20:17:56

>>747 ハードからのシグナルをコールバック関数で受ける

(with-signal-handler (signal)
(case signal
(rx-ready (...))
(tx-ready (...))))

なにか問題でも?

750 ：デフォルトの名無しさん：2009/05/08(金) 00:04:17

>>747
Pythonはメタオブジェクトがらみになるととたんに美しさを失うからなぁ…。俺は嫌い。

751 ：デフォルトの名無しさん：2009/05/08(金) 00:26:52

インパクトという点ではLISPが一番びっくりした

この衝撃はあと50年は続くだろう

752 ：デフォルトの名無しさん：2009/05/08(金) 00:51:59

Prologのユニフィケーションほどの衝撃はなかったなぁ。
構文木がファーストクラスてだけじゃんと。

753 ：デフォルトの名無しさん：2009/05/08(金) 01:57:51

えー、やっぱFORTHじゃねーの？
「この世にコンピュータ言語は二種類ある。それはFORTHとそれ以外だ。」
まさにこの言葉がぴったりだと思ったよ。

754 ：デフォルトの名無しさん：2009/05/08(金) 05:11:45

>>738
第一回LLVM勉強会での主催者さんの資料に、
そういう名前が自作処理系の名前の候補として出てくるよ (笑
ユーモアのある、魅力的な人だったな。

>>ちんこ
ttp://blog.livedoor.jp/dankogai/archives/50718227.html

C++の「醜さ」には、設計ミスとしか思えないような部分と、
意図的にやっている部分がある。
JavaやPythonとは違った「美しさ」に気付くと、
君のようにこだわりがある人は、案外気に入るかもよ。

755 ：ちんこ ◆GbXlaaQNk. ：2009/05/08(金) 18:17:21

>>754
いや、ふつうにやばいわ・・・。
上でもいったけど、今WinAPIのプログラムしてる。
学内インターンってやつだ。
それで、泣きたくなってる、なんだこの言語。
不完全にもほどがある。

まず、.hにはpublicなインターフェイスのみ記述するようにしろくそがっ！
だってそうだろ、.cppに実装を書くんだから、そういう意味では、
実装でフィールド設定を定義したり、privateメソッドを定義したり出来るようにすべきだ。
そうじゃないと、リファクタリングがめんどくさいだろ！くそがっ！！
C++でリファクタリングの文化が広がらないのはこのせいだな、くそがっ！！
致命的すぎて泣きたくなる。

他には
namespaceって何だよ。
なんだこのクソ仕様。
Javaのパッケージとかまじゆとりだわ。
Eclipseくんが自動でインポート文を書いてくれるしね。

C++では絶対に仕事したくない。
MSではVCとかC#とか使ってると思うけど、
MSには誘われても行きたくない。
C++で仕事するくらいならちんこ切って死んだ方がマシ。

756 ：デフォルトの名無しさん：2009/05/08(金) 18:24:19

> まず、.hにはpublicなインターフェイスのみ記述するようにしろくそがっ！
> だってそうだろ、.cppに実装を書くんだから、そういう意味では、
> 実装でフィールド設定を定義したり、privateメソッドを定義したり出来るようにすべきだ。

ちんこやるじゃんｗ
俺もヘッダでフィールドについて宣言させれらたりすんのはクソと思う。

あとnamespaceのネストはせめてC#みたいに namespace Foo.Bar.Baz {} で書ければね。

> MSには誘われても行きたくない。

誘われるかボケ。

757 ：ちんこ ◆GbXlaaQNk. ：2009/05/08(金) 18:33:23

オブジェクト指向の本質を知っているおれからすれば、
ある言語をちょっと触れば、たちまちその言語のクソ仕様が分かってしまうのだ。
そのおれがいうのだから間違いない。

Pythonは神言語だ。
そして、お前らはPythonが美しいと言っているが、
なぜ美しいのかは分かっているのは日本ではおれだけだろう。

おれのオブジェクト指向は理詰めなのだ。
可読性には理がある。可読性の高いコードには高いなりのしっかりとした理由がある。
それは、どこどこの教授が書いたからというハクではなく、
どえらい教授が書いたコードだろうが何だろうが、クソなもんはクソだ。

Javaがいかに素晴らしい言語かということがよく分かるから、
ここにインターン行って良かったわ。
オブジェクト指向が不完全な世界がいかに危険でまたストレスフルなものかということがよく分かった。
おれは、オブジェクト指向についておれ未満の知識しか持っていない人間はコードを書くべきではないと思っている。
人間がものを作るとゴミが出る。
人間の資産はどんどんハードウェアからソフトウェアにシフトしていっている。
産業も、例えば、FPGAに見られるように、ハードの世界でもソフトを重視しはじめている。
これからいえることは、
クソ設計、クソ可読性のコードはまさしく"環境破壊"であるということだ。
よって、クソみたいなコードを書くやつは、コードを書いてはいけない。自重しろ害悪クソ野郎が。

758 ：デフォルトの名無しさん：2009/05/08(金) 18:45:31

C++も実装部分は美しかったりするけどな

759 ：デフォルトの名無しさん：2009/05/08(金) 18:50:39

なんでこのスレで最も小汚い言語の話をしているのかと

760 ：デフォルトの名無しさん：2009/05/08(金) 18:52:07

C++がばっちいのはCとの互換性という諸刃の剣が原因だろう

761 ：ちんこ ◆GbXlaaQNk. ：2009/05/08(金) 19:27:24

とはいえ、
実をいうとおれは、
Pythonで開発なんかしたこたねえんだw
今、ある文章に含まれる各単語にすべて、
headとtail以外シャッフルしても可読性が保たれるという話を見て、
Pythonの練習にと思ってやってみた。
30分かかったw
しかも不完全すぎてうんこすぎる。
Pythonはダメだ。

762 ：デフォルトの名無しさん：2009/05/08(金) 19:32:41

> Pythonで開発なんかしたこたねえんだw

そもそも何一つ開発などしたこねえだろ。

763 ：デフォルトの名無しさん：2009/05/08(金) 19:34:02

>>761
可読性をどれだけ考慮しているか、
みんなに見せるチャンスじゃないか。

それを見せてみろよ。

764 ：ちんこ ◆GbXlaaQNk. ：2009/05/08(金) 19:46:35

>>762
お前みたいな低学歴プログラマと一緒にすんなクズw

>>763
てめえのビューティフルコードを見せてからだ。

765 ：ちんこ ◆GbXlaaQNk. ：2009/05/08(金) 19:55:22

地道にPythonが書けるようにトレーニングしていこうと思う。
おれはJavaしか出来ないのだ。
Javaならアホみたいにプログラミング出来るが、
他の言語ではクソだ。
オブジェクト指向や設計など、そっち側に知識が偏りすぎて、
Javaにしか実装が出来ない人になってしまっている。

これではダメだ。
希望的にはCとPythonを勉強しておきたいんだ。
Pythonってどうやって勉強すればいいの？
クックブック読めばいいのかな？
Rubyなら、ピッケル本とか全部読んだんだけど、
Rubyのendラダーと、コミュニティのしょぼさに吐き気がして、Rubyはもうやめようと思った。
で、Pythonが美しいことに気づいて、Pythonをしたいんだけど、
似たような言語だし、一生懸命勉強する気が起きない。

766 ：デフォルトの名無しさん：2009/05/08(金) 20:22:36

Rubyにしとけ

767 ：デフォルトの名無しさん：2009/05/08(金) 20:27:57

>>765
君の視点は美しさを語るには偏りすぎている。
Python のスレに行って勉強した方がいいと思うよ。
私は>>389だが、これはそれまでの流れをまとめてみただけで、
私の意見という訳ではない。

768 ：ちんこ ◆GbXlaaQNk. ：2009/05/08(金) 20:28:21

どして？
Pythonの方が美しいでしょ。

769 ：デフォルトの名無しさん：2009/05/08(金) 20:39:46

お前の中ではな

770 ：デフォルトの名無しさん：2009/05/08(金) 20:40:33

py3で大分ましになったな。

771 ：ちんこ ◆GbXlaaQNk. ：2009/05/08(金) 20:48:18

Rubyでは
array.sizeと書いて配列の長さを取得する。
一方、
Pythonでは、
len(sequence)
と書いて配列の長さを取得する。

これの優劣を述べよ。

772 ：デフォルトの名無しさん：2009/05/08(金) 20:50:54

誰だか知らないけど、Pythonにはこないでー

773 ：デフォルトの名無しさん：2009/05/08(金) 20:55:04

>>771
オブジェクト指向言語と命令型言語の違い。
優劣は特にないが前者の方が好きだ。

774 ：ちんこ ◆GbXlaaQNk. ：2009/05/08(金) 21:07:24

優劣は特にない
と、どうして言い切れるの？
言い切るだけの根拠をお願いします。
明らかに優劣はあります。
例えば、Pythonのような実装にすると、
lenというメソッドと、sequenceとの結合度が上がります。
これだけでも明らかなデメリットです。
しかし、Pythonでは上述のようなインターフェイスを公開しています。
なぜでしょうか？

775 ：デフォルトの名無しさん：2009/05/08(金) 21:22:49

例えば、dot(array, "size") のような構文にすると、結合度が上がるの？

776 ：ちんこ ◆GbXlaaQNk. ：2009/05/08(金) 21:42:54

どうやって実装しますか？

777 ：デフォルトの名無しさん：2009/05/08(金) 22:19:36

evalを使う

778 ：デフォルトの名無しさん：2009/05/08(金) 23:08:54

>ある文章に含まれる各単語にすべて、
>headとtail以外シャッフルしても可読性が保たれるという話

おもしろそうなので、Smalltalkで書いてみた。ナイーブな実装だけど。

| input shuffledWords outStream |
input := 'I couldnt believe that I could actualy understand what I was reading'.

shuffledWords := input subStrings collect: [:each |
　each size <= 2
　　ifTrue: [each]
　　ifFalse: [(each first: 1), each allButFirst allButLast shuffled, (each last: 1)]].

outStream := String new writeStream.
shuffledWords do: [:each | outStream nextPutAll: each] separatedBy: [outStream space].

^outStream contents
"=> 'I cudnlot bleveie that I cloud auctaly udtnesrnad what I was radneig' "

779 ：ちんこ ◆GbXlaaQNk. ：2009/05/09(土) 00:23:48

可読性のかけらもない。
この言語を作ったアホは誰だ。

780 ：ちんこ ◆GbXlaaQNk. ：2009/05/09(土) 00:29:13

俺の読めない言語と知らない言語は糞

781 ：デフォルトの名無しさん：2009/05/09(土) 00:48:35

Rubyで。

input.split.each{ |w| w.size<2 ? w : w[0]+w.scan(/./)[1..-2].shuffle.join+w[-1] }.join(" ")

782 ：ちんこ ◆GbXlaaQNk. ：2009/05/09(土) 00:59:25

>>781
素晴らしい。
あってるかどうかは知らんけど。
でもscanが美しくないな。
Pythonならこれがもっとも美しいかどうかは別にして
list(str)でストリングをばらばらに出来る。

783 ：ちんこ ◆GbXlaaQNk. ：2009/05/09(土) 01:03:07

例えばこんな感じ。

>>> list = list("chinko")
>>> list
['c', 'h', 'i', 'n', 'k', 'o']
>>> shuffle(list)
>>> list
['k', 'c', 'o', 'h', 'i', 'n']

Pythonで、
["a", "b"]
というのを
"ab"にするメソッドがあればいいんだけど、ないの？

784 ：デフォルトの名無しさん：2009/05/09(土) 01:48:23

''.join(list('abc'))

785 ：デフォルトの名無しさん：2009/05/09(土) 01:57:45

> list = list("chinko")
もうこれだけでお腹いっぱいです

786 ：デフォルトの名無しさん：2009/05/09(土) 04:38:04

>>10
Obviously, strongly typed language is the better, you know.

787 ：デフォルトの名無しさん：2009/05/09(土) 06:53:09

>>785
うーん。
イコールの意味の変遷を問うスレさへあるというのに。
美的センスを私も疑う。

788 ：デフォルトの名無しさん：2009/05/09(土) 08:49:17

>>779
SmalltalkはForthについで（そして特殊形式がないぶんLispよりも）シンプルな言語だから、
英語に見立てて、おおざっぱに読み下せればそれでおｋ。難しく考えなくてもいい。

789 ：ちんこ ◆GbXlaaQNk. ：2009/05/09(土) 09:34:04

>>785
すまん。
おれもきめぇと思ったが、
左辺に適切な名前をぱっと思いつかなかった。
インタラクティブモードだし、動いてたらいいやと。
今は反省してる。
これじゃ何か再帰がかかってるような印象すら起きるな。

>>784
とんくる。
Ruby派なおれはシーケンス系のところを探していたのだが、
まさかstrのメソッドになってるとは、Python歪みなさすぎ。

790 ：デフォルトの名無しさん：2009/05/09(土) 10:37:02

文字列を文字として扱いたいなら、C/C++の方が簡単だろ
何しろ文字列が無く、文字集合ならあるって言語だし

791 ：ちんこ ◆GbXlaaQNk. ：2009/05/09(土) 10:53:25

>>790
じゃあお前はそうしてろよ。
おれは高級言語しか使わない主義だ。

792 ：デフォルトの名無しさん：2009/05/09(土) 11:10:22

>>791
C/C++は高級言語

793 ：デフォルトの名無しさん：2009/05/09(土) 11:18:55

すっかりちんこにハメまくられるスレになったな

794 ：ちんこ ◆GbXlaaQNk. ：2009/05/09(土) 11:33:20

C/C++は中級言語です。
高級言語には、ガベージコレクタがついていなければいけません。
メモリ管理をしなければいけない時点で高級言語とは言えません。

795 ：デフォルトの名無しさん：2009/05/09(土) 11:46:14

>高級言語
機械語、アセンブリ言語と比べてのFortranやC、またはそれに準ずるものの事を言うんじゃなかったっけ？
基本情報の参考書ではそういう風な定義が書いてあったと思う。
GCとかrepl、パッケージシステムを備えたインタプリタ環境が要求されるものに限定するなら、
LL言語という方が適切な希ガス

796 ：デフォルトの名無しさん：2009/05/09(土) 12:15:41

そろそろNG登録すべきかな

797 ：デフォルトの名無しさん：2009/05/09(土) 12:33:44

ちんこは独自理論で断定することが多くて嫌になる。
付き合っていると勉強にはなるけどなｗ

JavaとPythonとRubyができる程度で
このスレで大きな顔をしているのは恥ずかしいな。

このスレにはアセンブラからスタートして「CPUの動きが透けて見える人」や
CやC++はもとより、LISP、Haskell、Smalltalkや
PrologやFORTHの偉い人もたくさんいるだろ。
少なくとも俺は80～90年代にプログラミング系雑誌に記事を書いてたよ。

798 ：デフォルトの名無しさん：2009/05/09(土) 13:21:12

>>794
C++はテンプレートとか活用してGCからラムダ関数まで実現してやがるぞ
美しい言語には程遠いけど

美しいと思うのはSchemeかな
よくまとまってる
別の意味で美しいのはPerl

799 ：ちんこ ◆GbXlaaQNk. ：2009/05/09(土) 13:43:24

スマートポインタとかいうやつだっけ？
クソだよね、どうせ遅いんでしょ。
JavaのGCは超高速だし、
最適化技術が超優秀だから、
これらはコードの書き方すらも変えてしまった。

例えば、一般的にいえば、
メソッドの凝集度を高めるために違うメソッドで同じループが回ることもあるが、
これすらも、ちゃんと無駄なループを削除してくれる前提で、凝集度を高めることに専念出来る。
保守性を高める方向に全力投球出来る。これはC++では出来ないことだ。
C++では、生成と破棄が遅いから、メモリを使いまわしたりする必要があるが、
Javaは生成と破棄が神がかって速いので、
多くの場合、メモリを使いまわすより、再生成した方が速い。
また、ローカルなオブジェクトはキャッシュで処理されるから、
計算なども事前に計算するよりその場で計算した方が速いということが多い。
メソッドオブジェクトなどは、C++では考えられない手法だろうが、
Javaではむしろ高速で、しかも凝集度を高める。
そのオブジェクトへの参照が小さなスコープで閉じているからだ。

優秀なIDEの存在も手伝って、
Javaはもはや無敵の言語となっている。
もしJavaに勝てる言語があるとしたら、すさまじい可読性を潜在的に持っている言語。
言い換えれば、バカが書いてもきれいに書ける言語だろう。
Javaは、バカが書くととんでもないことになる。
そして、コードを書くのはみんなおれのように可読性について知ってる人間ばかりではない。
だからバカが書いたコードをどうにかする言語がこれから必要になる。

１つの解としてPythonがある。
何かするために道が少ないというのは、可読性を上げる大きな要因になる。
LISPをやっていたから、Prologをやっていたから、とかは全く無意味。
老害プログラマはさっさと死ね。

800 ：デフォルトの名無しさん：2009/05/09(土) 13:54:07

>>799 の書き込みを見て、Java コミュニティがクロージャを排除するような
低能を大量に抱えている集団だって事だけは良くわかった

801 ：デフォルトの名無しさん：2009/05/09(土) 13:56:35

経験薄いだろこいつ

802 ：デフォルトの名無しさん：2009/05/09(土) 13:59:36

Javaって実践で使ったことないんだけどthrowsってどうなん？
きっちり活用できてるの？

803 ：デフォルトの名無しさん：2009/05/09(土) 14:06:36

クーロンのバラック群だって近くでみれば汚いが、
遠目に見るとなにやら芸術的に見えてくる。
そんなもんさ

804 ：デフォルトの名無しさん：2009/05/09(土) 14:12:38

美人は遠くからみろだな

805 ：デフォルトの名無しさん：2009/05/09(土) 15:06:04

言語利用者から見た「美しい言語」と
言語開発者から見た「美しい言語」は違うよね。

806 ：デフォルトの名無しさん：2009/05/09(土) 15:24:43

ちんこはJavaの凄さについて語っている。
それは問題ない。
問題なのは、Javaの凄さを語っているこいつ自身がぜんぜん凄くないのに威張っていることだ。
Javaも満足に使いこなせない初心者が他人をバカ呼ばわりするのは、みんなに対して失礼だろ。

807 ：デフォルトの名無しさん：2009/05/09(土) 15:37:27

Javaの凄さの半分はVMを長年ひっしこで磨き上げてきたSunの社員の凄さ。

808 ：ちんこ ◆GbXlaaQNk. ：2009/05/09(土) 21:08:28

>>806
別に威張ってないよ。
Javaはコードの書き方すら変えてしまうほどすごい言語だ、
この言語に勝てる言語はPythonしかないだろうといってるだけで、
いつおれがJavaを作ったなんて言ったんだ？
いっとくが、おれは情報系の出身ではないので、
独学でコンパイラは少し勉強したが、
基本的に池沼だよ。
ソフトウェアの作り方そのものに興味があるだけで、
そこにおけるおれのニーズを満たしてくれる言語が美しいといってるだけ。
言語そのものの美しさなんて、語ってない。
おれの美しいと言ってる言語は単に、生産性が高いというだけ。
それがおれの美しさの基準。

>>807
だからSunの天才たちには感謝しているよ。
これって、Sunの中でも基礎研究をしてるエリートが作ってるんだろ。
プログラム自体は知らんけど、理論方面は。
おれはそれがどういう言語で、どういう特性があるかというのを、
コードをどう書くかという点からおっざっぱに調べている。
パーサの実装だとかはどうでもいいw

とりあえずブログを作った。
Pythonを勉強していくつもりだw
Javaは基礎的な部分を書く時に使って、ほとんどの部分はJythonで実装する形にしたい。
そのために、Pythonを極める必要がある。

809 ：デフォルトの名無しさん：2009/05/09(土) 21:59:08

Sun煮天才はいないだろ。。

810 ：デフォルトの名無しさん：2009/05/09(土) 22:10:55

>>802
throwsっていうかチェック例外は失敗だったんじゃないかなぁ。

811 ：デフォルトの名無しさん：2009/05/09(土) 22:12:12

googleなら奇抜な天才いそう

812 ：デフォルトの名無しさん：2009/05/09(土) 22:20:41

ガイ・スティールは天才。

813 ：デフォルトの名無しさん：2009/05/09(土) 23:10:38

>>800
マジレスすると、クロージャを取り入れたい人は多いのだけど、
方針が複数あって折り合いがつかないんだよね。
Java SE 5へのアップデートの時に取り入れた仕様の一部を
醜いと感じる人が多く、新しい仕様の導入に慎重になっているらしい。
俺はJavaを7年くらい使っているけど、クロージャを待望しているよ。

814 ：デフォルトの名無しさん：2009/05/09(土) 23:52:34

クロージャねぇ。無名内部クラスで十分じゃない? 値の書き替えができない
てのも、適当なラッパクラスでも用意すれば回避できるだろうし。

スレ違いすまそ。

815 ：デフォルトの名無しさん：2009/05/09(土) 23:58:52

>>808
>>591
>>764

816 ：デフォルトの名無しさん：2009/05/10(日) 00:00:11

C++もそうだけど手持ちの機能で無理やりクロージャもどきやるとすごい不自然なんだよな。
うだうだ入ってないでさっさとつけろって感じ。

817 ：デフォルトの名無しさん：2009/05/10(日) 01:55:23

Scala がアップを始めたようです

818 ：デフォルトの名無しさん：2009/05/10(日) 02:09:18

>>ちんこ
Javaの限界を理解すると、おそらくC++の必要性も理解できるよ。
Javaではいくら最適化しても間に合わないような、
リアルタイム性が必要な処理を、Javaで書いてみるといい。

私は昔、Javaがあるのになぜあんな醜いものをいまだに使うんだ、
と憤りを感じ、何でもJavaでやってやろうと思ったことがあった。
そして、まだJava製OSSが存在しなかったので、
MPEG2のデコーダーを途中まで、Javaで書いたんだよね。

そして、コンテナから映像を取り出して、それを複合化して、
BMP画像として書きだすところまで作った。
(書き出すだけならJavaのAPIで簡単にできるから)
しかし結局、どう頑張ってコードレベルで最適化しても、
論文を読んで速いというアルゴリズムを使うようにしても、
Cとアセンブラで書かれたコードのような速度は出なかったんだ。

そして「もっと速くするには言語自体に～する機能が欲しい」と
考えるうち、C++がそういう言語じゃないか、と気付いた。
あれは少しでも速度を犠牲にするものは全て拒否した結果だと思う。

今考えると傲慢で恥ずかしい話なんだけど、いい勉強になったよ。

例えばシミュレーションの分野では、ハードウェアが速くなれば
精度を上げるだけなので、いつまで経っても「もう充分」にはならない。
(これはゲームなども一緒)
MPEGも、ハードウェアが速くなるたびに圧縮率を上げることで
慢性的に性能不足の状態が続いている。
こういう分野には、ああいう言語が必要なんじゃないかな?

819 ：デフォルトの名無しさん：2009/05/10(日) 02:14:42

今のところは必要でいいんじゃねーの

820 ：ちんこ ◆GbXlaaQNk. ：2009/05/10(日) 06:33:07

>>818
何をもって限界と言ってるのか分からない。
あなたは限界を知り尽くしてるのですか？
理論的に、その先がないことをすべて証明出来るということですね？
ただ、あなたが経験した中から限界だと感じたというだけであれば、やすやすと限界という言葉は使わないでください。

Javaが問題となる１つの領域は、
メモリについて厳しい領域です。それは自明です。
しかし、計算パフォーマンスでいえば、すでにJavaが遅いということはありえません。
それは、プログラム自体が悪いです。
あなたが使ったのは昔のJavaであって、今のJavaはとても高速です。
また、Javaにとってコードレベルでの最適化はむしろ最適化を妨げる傾向にあるので、
決して行わないでください。
大体、あなたごときが、コンパイラが行う以上の最適化をコード上で行うことは不可能です。

821 ：デフォルトの名無しさん：2009/05/10(日) 08:10:31

JavaはC#のようには元々JITコンパイラ向けに設計された言語
ではないので、C#ほどの速度は出ない

多分JavaのJITコンパイラが相性が悪いか、設計が糞なのだ

Javaで書かれたソフトウェアを動かしてみろ、例外なく動作が
もっさりしているのを感じるだろう

C#でもわずかだがもっさりするのにJavaなら言わずもがなだ

822 ：デフォルトの名無しさん：2009/05/10(日) 08:14:00

OSのようなパフォーマンス第一の環境を構築するのに未だに
Javaが使われない事を考えればその事は自明である

未だにC/C++なのだ

823 ：デフォルトの名無しさん：2009/05/10(日) 08:26:48

もはや美しさとは関係のない話だなぁ。

824 ：デフォルトの名無しさん：2009/05/10(日) 08:38:02

速いものは必ず美しい

825 ：デフォルトの名無しさん：2009/05/10(日) 08:45:17

使いやすいかどうか＝自分が理解できるかどうかで語ってるしなぁ

826 ：デフォルトの名無しさん：2009/05/10(日) 08:50:05

速さを追求するあまりマルチステートメントで1行に命令ギッチリ詰め込み、変数名は全部1文字、GOTOでそこら中飛びまくり
な行番号付きBASICも美しいと申すか

827 ：デフォルトの名無しさん：2009/05/10(日) 08:51:56

>>825
まあ、理解できないものを美しいかどうかなんて判断できないじゃん

828 ：デフォルトの名無しさん：2009/05/10(日) 08:55:03

>>824
それはおかしい

x86のアーキテクチャの汚さを知っているだろう
なのにx86は早いではないか

829 ：デフォルトの名無しさん：2009/05/10(日) 09:03:52

いやいや、熱心な信者がいるのは認めるけど、86は遅いだろ。
車でもプロセッサでも。

830 ：デフォルトの名無しさん：2009/05/10(日) 09:11:34

x86が遅い？
RISCを蹴散らした怒濤のクロックアップ戦争の勝者ですよ
DrystoneではIntelのx86がトップです
Wetstoneではまた違うCPUですが

831 ：デフォルトの名無しさん：2009/05/10(日) 09:19:54

>>829
ロクに知らない癖に書くなよな恥ずかしい

832 ：デフォルトの名無しさん：2009/05/10(日) 09:53:41

質量からエネルギーの値を得るとしきつかう式（関数、システム）を作ってみたら美しかった。
　　　2
E=mc

しかし、それにいたる理論は理解するのが簡単ではにあ。。だが使う人にとっては必ずしも理解する必要はない。

そこで質量からエネルギーの値を得るシステム記述言語、Albertを作ってみた。
こんな感じ。
SET M 1000 FROM STDIN
SET C FROM CONFIG
PRINT CONDITION
EXEC
PRINT RESULT
このシステム記述言語は理解したり使うのはやさしい。こういう言語は美しいと思う。
でもこれ作るにある程度複雑なプログラミングが必要だった。

そういうことだと思う。

833 ：デフォルトの名無しさん：2009/05/10(日) 09:57:21

先生！さっぱりわかりません！！

834 ：818：2009/05/10(日) 16:11:34

>>820
> あなたが使ったのは昔のJavaであって、今のJavaはとても高速です。

以前SunのJava SE 6がかなり速くなったと聞いて
それで動かしてみたんだけど、やっぱり遅かったよ。
(細かいバージョンは忘れたけど)

一例を挙げると、今時のCPUはSSEなどのSIMD命令をだいたい備えている。
C/C++でもコンパイラの自動検出には限界があり、
プロファイラでボトルネックを探した後は
コンパイラマクロなどで置き換えて、そこだけ手書きでSIMD化する。
Javaでは言語やVMのレベルでSIMD命令をサポートしていないので、
こういうことができないんだよね。

> また、Javaにとってコードレベルでの最適化は
> むしろ最適化を妨げる傾向にあるので、決して行わないでください。

「最適化を妨げる」話は以前IBMかどこかのWebサイトで
見たことがあるけど、ちょっと誤解してるみたいだね。

データフロー解析にしてもループバージョニングにしても
できることには限りがあるから、
解析の結果、不要な処理をJITコンパイラが理解できる
コードを書いてやる必要があるよね。
コンパイラの勉強をしていると、逆にそう思うんじゃないかな?

それから、逆に最適化を助けているか妨げているかは、
ちゃんとプロファイラを使って調べないとね。
今時のPCは複雑だから、最終的には実行時間を測ってみないと。

835 ：834続き：2009/05/10(日) 16:20:03

> 大体、あなたごときが、コンパイラが行う以上の最適化を
> コード上で行うことは不可能です。

やってみる前から「人間はコンパイラ以下」と決めつけない方がいいよ。
コンパイラのアルゴリズムも結局は、人間の手動書き換えを法則化したものだから、
まだ法則化できていないものや、セマンティクスが分からないと
書き換えられない部分は、人間が書き換えた方が速くなるよね。

> 何をもって限界と言ってるのか分からない。
> あなたは限界を知り尽くしてるのですか？
> 理論的に、その先がないことをすべて証明出来るということですね？

HotSpot VMが生成するものが何かを考えれば、
理論的な限界がアセンブラより手前にあるのは分かるよね。
では、そのアセンブラをインラインで書けるC++は?
…と書くと、ちょっと意地悪かな (笑

理論的な限界が遠くても人間に扱いにくければ無意味だから、
理論的な限界は気にし過ぎない方がいいよ。
JavaがC++より優れているところだって、
一番は人間にとっての扱いやすさでしょう。
(結果、実用上はJava製の方が速くなることが多々ある)

836 ：835続き：2009/05/10(日) 16:21:24

重要なのは、C++が優れているか、Javaが優れているか、ではないんだ。
言語の仕様以外にも、プログラムを書いていると、
様々な場面でトレードオフが発生する。
そういう時に、一方が絶対的に優れているという
原理主義的な考えに陥らないで、状況に応じて使い分けられること、
「当然だからそうした」と思考停止するのではなく、
何と何の (上の例では速度と生産性他) トレードオフの結果
自分がそれを選んだのか、自覚しておくことじゃないかな。

つまり「言語の美しさ」の基準は目的に応じて変わることがあると。

長々とつまらないことを語ってしまってごめんね。
以降は静観してまつ。

837 ：デフォルトの名無しさん：2009/05/10(日) 16:30:16

>>820
VMは生コードに比べたら遅いにきまってるのに何ほざいてるの？
とにかく一度コンパイラ関係の本をざっと読んでみろ。

838 ：デフォルトの名無しさん：2009/05/10(日) 17:02:09

>>837
CPUはASICに比べたら遅いにきまってるのに何ほざいてるの？
というのは冗談としても、
ALGOL系がまるごとHDL系+FPGAに蹂躙される未来もありえるよ。

839 ：デフォルトの名無しさん：2009/05/10(日) 17:04:56

別に決まってはいない。
オプティマイジングの弱いコンパイラなんて山ほどある。

840 ：デフォルトの名無しさん：2009/05/10(日) 17:16:14

速度を主目的としたVM
http://www.llvm.org/

841 ：デフォルトの名無しさん：2009/05/10(日) 17:27:36

>ALGOG系がHDL系＋FPGAに蹂躙
最近出ているHDLってもう殆どMLとかHaskellみたいなもんだからな。
関数型言語がメジャーになるというのはそういう方向からなのかもしれんな。
あとは定理証明器の技法を使ったモデル検査とかの形式的手法とか、
ハードの世界じゃそういう本流の計算機科学を使った技術が結構広く使われてるらしいじゃない。
lispとか使ってる人にとってはそちらの未来の方が理想に近いんだろうなぁ。

842 ：デフォルトの名無しさん：2009/05/10(日) 21:30:39

>>799
>例えば、一般的にいえば、
>メソッドの凝集度を高めるために違うメソッドで同じループが回ることもあるが、
>これすらも、ちゃんと無駄なループを削除してくれる前提で、凝集度を高めることに専念出来る。

これって本当？
違うメソッドに同じ構成のループがあったら統合してくれるの？
Javaってそんなにすごい最適化をするのか。
Web上に参考になりそうな情報はある？

843 ：デフォルトの名無しさん：2009/05/10(日) 21:31:01

何を基準にするかで変わってくると思うが,
自分が美しいと思うのは, 次の4つかな.

●D言語:
美しく「書くことができる」と思う.
scope とか, エラー処理も比較的分かりやすく書けると思う.

●Scheme:
言語自体が美しいと思う.
慣れると, 洗練されていてちょっと感動を覚えた.
※見た目は美しくない気もする...orz

●Python:
コードの見た目が美しい.
コードを見たとき, あぁんきれいだと思った.

●アセンブリ言語
見たまんま, CPUに忠実で美しい.
期待を裏切らない!

ここのタイトルで言っている美しいは, Scheme になるのかな.
まぁ, 有名な言語は悪い点はあるにせよ, どれもなかなか美しいと思う.

ただ, 開発で C++ はあまり使いたくないけどな・・・
余りにもきしょいコードが「書けてしまう」ってのが・・・orz

大人数開発で言語選べるなら, やっぱ Java かな.

844 ：デフォルトの名無しさん：2009/05/10(日) 21:39:49

> コードを見たとき, あぁんきれいだと思った.
キメエ、死ね

845 ：デフォルトの名無しさん：2009/05/10(日) 21:44:42

美しいって言いたいだけなのか

846 ：デフォルトの名無しさん：2009/05/10(日) 21:57:06

>コードの見た目が美しい.
Whitespaceですね、わかります。

847 ：デフォルトの名無しさん：2009/05/10(日) 22:10:08

美(空)白ですからね

848 ：デフォルトの名無しさん：2009/05/10(日) 23:44:12

>>844のような短絡的な書き方、思考は2chの仕様です。

849 ：デフォルトの名無しさん：2009/05/11(月) 09:20:18

Javaを推したら荒れるかなとwktkしてたら別な人がJavaを推してた
意外と荒れてなくてワロタ

長くて真面目に読む気にならないせいかもしれんが…

850 ：デフォルトの名無しさん：2009/05/11(月) 09:32:05

Javaは美しい、がもっさりしている

851 ：ちんこ ◆GbXlaaQNk. ：2009/05/11(月) 09:57:39

>>834
じゃああんたは勝手に自分最適化してればいいよ。
絶対にそんなの無意味だから。
おれはJavaでは99%の領域では言語レベルでのパフォーマンスに何の問題もないプログラムを、
保守性の高いコードを書いてあとは全部VMに任せることで作ることが出来ると思っている。
よっぽど特殊なユースでない限りこれでまったく問題ない。
それどころかPython程度の速度でも何か問題が起きることはありえない。
これでも95%のユースには耐えられる。
ダメだとしたら設計やアルゴリズムが悪い。
ソフトウェアは単純になりえないから、人間が頑張るべきところはコードを単純にするところであって、もはや見た目の速さをあげることではない。
そういう領域で戦ってる人はどんまいとしかいいようがない。
例えば、シミュレーションとか、数値解析の類はそうかもしれないね。

>>837
一度、なんかふざけたJavaでコンパイラを作ろうみたいな本をちょっとだけ読んだことがある。
しかし、サンプルコードがめちゃくちゃ、凝集度がゴミだし、可読性のかけらもなかった。
それで、コンパイラやさんっていうのは池沼だなという結論に至った。
ドラゴンブックも途中まで読んだ。こちらのコードはそれなりだったが、飽きたので止めた。おれには必要ない。コンパイラやさんになるつもりがなければ概要だけ分かればいい。

852 ：デフォルトの名無しさん：2009/05/11(月) 13:51:45

>スクリプト言語はコンパイラ言語より遅いのか？！
>ttp://enbug.tdiary.net/20060318.html

ここに、Shiroさん（Schemeの偉い人、Gauche作者）が
次のようなコメントを書いていて興味深いです。

「『開発効率が実行効率に影響を及ぼす』というのは現場で何度も経験しています」
「アルゴリズムによる高速化というのは10^2?10^3以上のオーダーで効いてくることが
あるのに対し、アセンブラレベルでの高速化は10^1以下のオーダーであることが多いです」

853 ：デフォルトの名無しさん：2009/05/11(月) 19:48:46

>>850
リスナ(笑)

854 ：ちんこ ◆GbXlaaQNk. ：2009/05/11(月) 20:57:12

>>852
さんくる、それは良い記事だ。
開発の容易な言語こそが神だと言っているのだろ。

ところでおまいらに相談がある。
それは、おれがJavaで開発するかCPythonで開発するかということだ。
今、おれは研究に使う言語をJavaにするかCPythonにするか、究極の選択を迫られている。
しかし、そこに問題があり、おれはとても悩んでいる。
JavaにもJythonという言語があるが、この言語からはCPythonで記述されたライブラリが使えない、これがその問題だ。
仮にこれが解決されるのであれば、おれは迷いなくCPythonを使う。
グラフィックライブラリはVTKだとかVPythonとかあるし、openGLバインディングもある。

Java系を使うと、C系が使えなくなる。
おまいらもこのジレンマに陥ったことがあるはずだ。
誰か、おれにアドバイスをくれないか。

855 ：デフォルトの名無しさん：2009/05/11(月) 21:10:02

>>854
スレ違い。あまり調子に乗るな

856 ：ちんこ ◆GbXlaaQNk. ：2009/05/11(月) 21:32:09

ガチなんだけど。
スレ違いなのは分かってる。
だけど、言語の美しさに敏感なお前のアドバイスをもらいたいんだ。
ここのレベルはそれなりに高い。
他は分からないからおちょくって終わるようなレベルの低い池沼ばかりだ。
きちんとファクトベースで議論出来ないやつとなんて話す必要ない。

857 ：デフォルトの名無しさん：2009/05/11(月) 22:01:03

>Java系を使うと、C系が使えなくなる
使えるだろ。
ただし、美しくない方法なので、それを教えるとJavaが美しくないことがバレてしまう。

858 ：ちんこ ◆GbXlaaQNk. ：2009/05/11(月) 22:03:31

>>857
JNI使うとか言い出すのか？
それは禁忌だ。
大体、めんどくさすぎる。

JythonからPure Pythonのライブラリを呼び出せるのかどうかが問題なんだ。

859 ：デフォルトの名無しさん：2009/05/11(月) 22:05:35

俺が隔離スレ立ててやるからそこを日記帳にしろ
そして二度とそこから出てくるなカスコテ

860 ：デフォルトの名無しさん：2009/05/12(火) 01:44:41

スレタイからは外れているけど一言．Javaの動作がもっさりして感じるのは
通常の実行方法だとJVMを生成してからユーザプログラムを実行しているから．
ユーザプログラムの実行時間が短い場合，相対的にJVMの生成に費やされる時間が
長くなるため，もっさりした感じを受けてしまうだけなのである．ユーザプロ
グラム部分の実行速度はもはやnative codeの速度とあまり変わらないのだ．

861 ：デフォルトの名無しさん：2009/05/12(火) 02:01:01

>>860
ソースは？

862 ：デフォルトの名無しさん：2009/05/12(火) 02:07:30

>>860
> 通常の実行方法だとJVMを生成してからユーザプログラムを実行しているから
いつからAndroidスタイルになったんだよ…
つか値型くらい導入しろよ…

863 ：デフォルトの名無しさん：2009/05/12(火) 11:00:54

だれも反応しなければここが隔離スレだ

864 ：デフォルトの名無しさん：2009/05/12(火) 11:02:24

>>860
あのさあ
Javaに特別な思い入れがあるのかもしんないけどさ
実測という厚い壁はどうやっても超えられんから
そのつもりで

865 ：デフォルトの名無しさん：2009/05/12(火) 11:08:41

俺も好きこのんであの汚いC++を使ってる訳じゃないぞ
実績に裏書きされた高速性があるから仕方なく使ってるわけで
Javaのよい点のソースの美しさは認める

でも速度に関しちゃC++に絶対勝てないから
だいたいJavaそのものがC++で書いてあるしな

866 ：デフォルトの名無しさん：2009/05/12(火) 12:05:00

Javaは例外処理が美しくないだろ

867 ：デフォルトの名無しさん：2009/05/12(火) 19:05:53

throwなんて去勢されたgo toだろ

868 ：デフォルトの名無しさん：2009/05/12(火) 19:51:37

それを言うなら洗練されたlongjmp()と言ってくれ

869 ：デフォルトの名無しさん：2009/05/12(火) 21:41:54

// Javaのエラー処理
// 変数名とかは申し訳ない m(__)m
try {
　FileReader fr = new FileReader("sample.txt");
　try {
　　BufferedReader br = new BufferedReader(fr);
　　try {
　　　// br.readLine() とかごにょごにょ
　　} catch (IOException e) {
　　　e.printStackTrace();
　　} finally {
　　　br.close();
　　}
　} catch (IOException e) {
　　e.printStackTrace();
　} finally {
　　fr.close();
　}
} catch (IOException e) {
　e.printStackTrace();
}

// 綺麗とは言えないな・・・ラップとかすればマシにはなるが・・・
// どなたかエレガントな感じに書けないでしょうか。

870 ：デフォルトの名無しさん：2009/05/13(水) 03:12:18

例外オブジェクトの生成部分をフックして
一元的にスタックトレース吐かせたりは出来ないの？

あとリソースの廃棄を自動化は出来ないのか。
C#のusingみたいに。

Javaって美しいというよりシンプルなだけって気が。

871 ：デフォルトの名無しさん：2009/05/13(水) 06:44:30

>>870 例外オブジェクトの生成部分をフックして
こんな表現が出てくる事自体、全然美しくない。

872 ：デフォルトの名無しさん：2009/05/13(水) 07:19:39

おまえら、自分が推す言語で>>869を書き換えてやれよ
いいだしっぺのおれはWhitespaceでいくぜ↓
--ここから--

--ここまで--

873 ：デフォルトの名無しさん：2009/05/13(水) 07:45:20

D言語:
BufferedFile file = new BufferedFile("sample.txt");
scope(exit) file.close();
// file.readLine() などごにょごにょ

Java: (例外を上に投げるパターン)
FileReader fr = new FileReader("sample.txt");
try {
　　BufferedReader br = new BufferedReader(fr);
　　try {
　　　　// br.readLine() とかごにょごにょ
　　} finally {
　　　　br.close();
　　}
} finally {
　　　fr.close();
}

874 ：デフォルトの名無しさん：2009/05/13(水) 07:52:48

C言語

FILE* fp = fopen("sample.txt", "r");
if (fp != NULL)
{
　　/* fgets などごにょごにょ */
　　fclose(fp);
}

意外とすっきりしてるが・・・
ごにょごにょ部分でエラー発生したときを考えると
ちょっとややこくなるか？

875 ：デフォルトの名無しさん：2009/05/13(水) 09:12:33

876 ：デフォルトの名無しさん：2009/05/13(水) 11:42:25

Haskell:

(readFile "path-to-file" >>= {- リスト処理関数などごにょ -}) `catch` (\err -> {- errをごにょごにょ -} )

877 ：デフォルトの名無しさん：2009/05/13(水) 13:13:34

Ruby:

begin
　open('sample.txt') do |f|
　　# 処理
　end
rescue
　# エラー処理
end

878 ：873：2009/05/13(水) 21:49:15

Ruby はかじった程度しかしらんが、
ensure で close とかしなくてもいいもんなん？

879 ：デフォルトの名無しさん：2009/05/13(水) 22:25:19

openにブロックを渡すとcloseを保証してくれる
with-open-fileの高階関数版みたいなもん

880 ：デフォルトの名無しさん：2009/05/13(水) 22:42:49

無名関数、無名クラス、ブロック
美しいのはどれ？

881 ：デフォルトの名無しさん：2009/05/13(水) 22:49:13

Squeak Smalltalk で。

[FileStream fileNamed: 'sample.txt' do: [:file | "処理" ]]
　　on: Exception do: [:ex | "エラー処理"]

ちなみに #fileNamed:do: は Ruby の open にインスパイアｗされて導入された。

882 ：デフォルトの名無しさん：2009/05/14(木) 01:36:12

Java はその柔軟さゆえに、どうにでもなるさ。

abstract class Proc<P extends Closeable> {
private final P port;
public Proc(P port) { this.port = port; }
public void run() {
try {
process();
} finally {
port.close();
}
abstract void process();
}

883 ：デフォルトの名無しさん：2009/05/14(木) 01:42:13

python美しいとかいうから、見てみたが
文法強制されてんのね。
まぁ、美しいかは分からんが、可読性はありそうね。

つうか美しさって、しっかり定義しとかないと永遠と続くだろ
実用の美しさ
可読性の美しさ
簡潔差（その代わり言語の内部処理が泥臭いだろうが）
効率

色々あるっしょ

884 ：ちんこ ◆GbXlaaQNk. ：2009/05/14(木) 01:47:36

ソフトウェアは芸術ではない。
ソフトウェアは工学である。
そしてそのプロセスにおいて重要なのは人間である。
なぜならば、コードは、人間によって書かれ、そして読まれるからである。
だから、プログラミング言語にとってもっとも重要なのは、可読性の高さである。
可読性の高い言語は、開発効率の直結する。
開発効率の高い言語が美しいとおれは考える。
なぜならば、プログラムは芸術でも何でもなく、
唯一の価値は、それが動くことによって生み出されるからである。
Lispみたいな言語が美しいと言ってる人は頭がどうかしてる。

885 ：デフォルトの名無しさん：2009/05/14(木) 01:53:03

いいや、プログラマーはアーティストだ。
じゃなければ、ただの作業員だ

886 ：デフォルトの名無しさん：2009/05/14(木) 02:06:40

内部の美しさもあるだろうに

887 ：デフォルトの名無しさん：2009/05/14(木) 03:22:11

S式で統一されている美しさとその実用性が理解出来ないんだろうな
哀れな

888 ：デフォルトの名無しさん：2009/05/14(木) 03:33:18

>>884
開発効率に直結する可読性なら、断然、Prologだろう。

889 ：デフォルトの名無しさん：2009/05/14(木) 06:03:43

>>888
だから美しいとはいえない。

890 ：デフォルトの名無しさん：2009/05/14(木) 07:34:39

美しい、美しくないなんて個人の主観が100%
そんな観点で語りあっても宗教論争以上にはならん

891 ：デフォルトの名無しさん：2009/05/14(木) 07:44:37

>>890
個人の主観をぶつけ合うスレがあったっていいじゃないか。

892 ：デフォルトの名無しさん：2009/05/14(木) 07:53:02

それなら、美しい言語とは、客観的な言語である、と定義すればいいかも

893 ：デフォルトの名無しさん：2009/05/14(木) 07:55:37

○○の美しさで言えば、○○が一番。
理由は○○
って感じの言い方で主張すればよろしいかと。

894 ：843：2009/05/14(木) 07:57:41

>>884
一度Lisp極めてみたら考え方変わると思う。

俺も何この括弧だらけの言語・・・
読みにくくてしゃーねーじゃんと思っていたが、
ある頃からこれはこれで、美しいと思い始めてしまう。

俺・・・もしかして、
Lisp(Scheme)に洗脳されてる？

895 ：デフォルトの名無しさん：2009/05/14(木) 08:56:45

>>882
なにその厨ソース
アプレットでもやってろよw

896 ：デフォルトの名無しさん：2009/05/14(木) 09:09:15

>894
演算子の優先順位とか結合度とか全く気にする必要ないもんな
パーザの挙動は全て括弧に書いてあるから

897 ：デフォルトの名無しさん：2009/05/14(木) 09:48:13

>>879
> with-open-fileの高階関数版みたいなもん
with-open-file のボディはマクロ展開すると unwind-protect に渡される
高階関数なんだが…

898 ：デフォルトの名無しさん：2009/05/14(木) 10:31:29

単純に「マクロじゃない」という意味だろうｊｋ

899 ：ちんこ ◆GbXlaaQNk. ：2009/05/14(木) 10:34:19

>>893
だからおれはそうしてんだろ。
主観で話してもしょうがねえんだよ。
これだから文系出身プログラマどもはwww

Lispなんてまともな開発出来ねえよ。
LispでTDDなんて出来るのか？
おれはソースコードへのこだわりはあるが、
言語の内部構造、つまり実装や設計についてはこだわりはない。
ソースコードを美しくしてくれて、開発効率の高い言語が、設計としても美しい。
Pythonの開発者はそこらへんが分かってる。
本当にソフトウェア開発の効率を上げることで、人類の進化に貢献しようという気概がある。

900 ：デフォルトの名無しさん：2009/05/14(木) 10:34:54

・ファイルのクローズをする
・エラー処理をする
という両方を入れた場合、
Java >>869 はどう考えても可読性や開発効率が他の言語より劣っているよね。
Ruby >>877 と比べれば一目瞭然。
ちんこはどう思う？

901 ：デフォルトの名無しさん：2009/05/14(木) 10:38:28

Javaは発表当時は美しかったよ。当時主流だったC++と比べると。
C#は一体どこまでぶくぶくと肥大化していくんだろう。もう誰も仕様把握できてなくね？ｗ

902 ：デフォルトの名無しさん：2009/05/14(木) 10:46:47

ここはまずちんこにPythonで書いた場合を出して解説・他と比較してもらうのがスジだろう。

903 ：デフォルトの名無しさん：2009/05/14(木) 10:54:38

lispでまともな開発ができるという実証はPaul Grahamが行った
あとlispにもclunitとかTDDのライブラリはあるよ

904 ：デフォルトの名無しさん：2009/05/14(木) 11:04:01

>>902
こういうながれでソース出した奴みたことない。
ちんこはまた単に言い逃れをするだけ。
ちんこはこの例をPythonで書いて見せることすらできない。

905 ：ちんこ ◆GbXlaaQNk. ：2009/05/14(木) 11:05:28

>>903
実際にTDDをLispで行ってる人はいますか？
現状で行われてるTDDのほとんどはJavaかRubyかPythonによるものだろ。
C++でユニットテスト書く人すらも少ない。

>>900
よくファイルの読み書きで美しいだとかなんだとかいう人がいるけど、
あなたは一体、１つのソフトウェアを作る中で何回ファイルの読み書きをするつもりですか？
これは開発効率の中でボトルネックとなる部分なのですか？
あなたは読み書きをして終了するだけのソフトウェアは実用性があると思いますか？

おれはないと思います。
この、開発におけるボトルネックという考え方が日本人には出来ないらしい。
日本人はリスク管理が出来ないからね、それと同じなんだ。

ファイル読み書きとか、
生のコードについて美しいだとか美しくないだとか言ってる人は知れてる。
そういう人は、
メソッドの構造化リファクタリングとか、
メソッドオブジェクトの抽出リファクタリングだとかいうものを知らないんだろうな。

906 ：デフォルトの名無しさん：2009/05/14(木) 11:08:05

ものすごい飛躍を見た

907 ：デフォルトの名無しさん：2009/05/14(木) 11:13:48

ということで、ファイルの件はもういいから、通常の開発で
何度も出てくるようなボトルネックとなるコードをクタる例で美しさを語ってもらおうか。＞ち

908 ：デフォルトの名無しさん：2009/05/14(木) 11:14:53

>>583 >>590
において、たった十数行のサンプルプログラムのようなものに噛み付いて、
吐き気がするだの死ぬべきだだの大げさに言ってた奴が、

> よくファイルの読み書きで美しいだとかなんだとかいう人がいるけど、

ちんこよ、それはイカン。その態度ではお前は価値を下げる。

909 ：デフォルトの名無しさん：2009/05/14(木) 11:27:19

>>905
>あなたは一体、１つのソフトウェアを作る中で何回ファイルの読み書きをするつもりですか？
>これは開発効率の中でボトルネックとなる部分なのですか？
>あなたは読み書きをして終了するだけのソフトウェアは実用性があると思いますか？

違う違う。
エラー処理をする際の、リソースの後始末はどうするかという話だよ。
これなら実用的なコードのあちこちで見る典型的な処理だろ？

じゃ、言い換えよう。
・使用したリソースの後始末をする
・エラー処理をする
という両方を入れたコードの例を示した場合、
Java >>869 はどう考えても可読性や開発効率が他の言語より劣っているよね。
Ruby >>877 と比べれば一目瞭然。
ちんこはどう思う？

910 ：デフォルトの名無しさん：2009/05/14(木) 11:32:02

>>905
C++でもBoostのライブラリは殆どがBoost.Testによるテスト付きで、
そのBoost.Testもオープンソースのソフトを中心に広く使われている。
Boost以外でもcppunitとかテストライブラリは古くから出てるし、
C++の世界でもTDDの概念はそうマイナーなものではないと思う。

lispのclunit以外でもgaucheとかテストライブラリが添付の処理系もある
gaucheは処理系のソースにテストコード付いてるぐらいだしね。

911 ：デフォルトの名無しさん：2009/05/14(木) 11:35:06

>>884 ちんこ「プログラミング言語にとってもっとも重要なのは、可読性の高さである。
　　可読性の高い言語は、開発効率の直結する」
↓
>>900 俺「Javaは可読性や開発効率が他の言語より劣っているよね」
↓
>>905 ちんこ「あなたは読み書きをして終了するだけのソフトウェアは実用性があると思いますか？
ファイル読み書きとか、生のコードについて美しいだとか美しくないだとか言ってる人は知れてる」

この流れ、論理的でないと思うが、どうだろう？＞ちんこ

912 ：デフォルトの名無しさん：2009/05/14(木) 11:50:18

用は開発効率なんて、慣れだろ。
文法が強制されるってことは、ある程度のものを書くと
ひとつの形に集約されてくるってことだろ。
スタイルを強制されるのはびもーだな。

>あなたは読み書きをして終了するだけのソフトウェアは実用性があると思いますか？
えっとね、UNIXだとあるよ？
勉強不足だね。
ファイルが存在するか否かを確認するだけのプログラムもある。

913 ：デフォルトの名無しさん：2009/05/14(木) 11:52:09

そもそも、「俺はAという言語で○○という処理をしているが、Bと言う言語で、○○という処理は出来るのか」なんてのは
出来るってしか言いようが無いだろうに...

機械語使えばなんでも出来るってのと同レベルの話だろ

914 ：ちんこ ◆GbXlaaQNk. ：2009/05/14(木) 11:52:27

>>908
それは違うね。
おれが言ったのは凝集度の問題であって、
ファイル読み書きのコードはそれ自体、凝集度が高い。
悪いところがない。
Pythonでも凝集度の低いコードは書けるよ、
それはプログラマの能力次第な部分だ。
しかし、Pythonには凝集度が高くなるような誘導がある。
ヘボが書いてもそれなりの可読性を保てるようになっている。
例えば、不変オブジェクトを導入することによって可読性が高くなるということがよく分かっている。
メソッドオブジェクトは不変オブジェクトの特化だ。
メソッドオブジェクトの抽出は、コードの可読性を上げる。

915 ：デフォルトの名無しさん：2009/05/14(木) 11:54:37

お前ら働けよ

916 ：デフォルトの名無しさん：2009/05/14(木) 11:56:11

>>915
おまえもなー

917 ：ちんこ ◆GbXlaaQNk. ：2009/05/14(木) 11:56:33

>>912
では、あなたはファイルの存在を確認するプログラムを１００個くらい量産してください。
さぞ素晴らしい読み書きプログラムが１００個生産されるのでしょう、とても楽しみです。

ソフトウェアは再利用されるものです。
すでに存在するプログラムを二度作る必要はありません。

ソフトウェアは作り、使われるものです。
そして、新規に作る場合、それはこの世に存在しないものであるべきです。
存在するのであれば、作る必要はありません。

918 ：デフォルトの名無しさん：2009/05/14(木) 12:08:23

>>917
だから、UNIXには既に「在る」って書いてるだろ

919 ：デフォルトの名無しさん：2009/05/14(木) 12:09:25

UNIXの世界観を何もしらないのかコイツは

920 ：デフォルトの名無しさん：2009/05/14(木) 12:09:35

ソフトウェア関連で一番馬鹿らしい話が「車輪の再発明」だよな
"再発明"などと言う大上段に構えた言い方で、初心者の学習機会を奪っている

子供のころ工作で、厚紙で車輪を作ったことがあるだろう
厚紙だと細すぎて上手く回らないから、ダンボールを使って車輪を作っただろう
創意工夫というのは、自分で作ることから始まるものだ

どんな些細な物でも、自分で作って納得して初めて自分の技術になる
興味がある物ならば作ってみる
それが技術習得の一番の近道だと俺は思う

921 ：デフォルトの名無しさん：2009/05/14(木) 12:15:45

ちんこって頭悪いな
自分で何を言ってるのか全然把握せずに書き込んでる

922 ：デフォルトの名無しさん：2009/05/14(木) 12:18:54

言語の優劣の議論なんて一流の技術者、研究者がやってもgdgdになるものを
素人の俺等やちんこがやったらgdgdどころじゃないだろうなと思ったら案の定

923 ：デフォルトの名無しさん：2009/05/14(木) 12:27:13

まぁただのJava厨だしな

924 ：デフォルトの名無しさん：2009/05/14(木) 12:41:04

ただのJava厨か

Javaの仕事なんて下請けでオバサンが家で仕事してる時代なのにｗ

925 ：デフォルトの名無しさん：2009/05/14(木) 15:25:20

>>884
>869と>875を見比べた時、明らかに>875の方が可読性が高いんだが。

詩でも書いてるつもりになってオナニーしてんじゃねえよ。

926 ：デフォルトの名無しさん：2009/05/14(木) 16:00:58

>>925
可読性高くねーよ
デタラメ言ってんじゃねえ
慣れの問題だ

927 ：デフォルトの名無しさん：2009/05/14(木) 16:08:22

どっちが指が疲れるかのほうが重要だろ

928 ：デフォルトの名無しさん：2009/05/14(木) 16:44:22

>>869 は逐次的で処理がわかりやすい。
>>875 はコードが短くて（抽象度が高くて）わかりやすい。
そこでRuby >>877 ですよ。いかがですかｗ

929 ：デフォルトの名無しさん：2009/05/14(木) 17:23:43

ぶっちゃけ、いつも使っている言語が一番

930 ：デフォルトの名無しさん：2009/05/14(木) 17:45:11

美人は三日で飽きるんだよ

931 ：デフォルトの名無しさん：2009/05/14(木) 20:05:37

>>917
どでもええけど、TDD が必要なのはなぜか良く考えてみよう

副作用前提(状態持ちまくり)の糞言語から見たら別の話なんだろうけどなw

932 ：デフォルトの名無しさん：2009/05/14(木) 21:09:42

>>920
再発明は×、再製作は○、この違い分かる？

933 ：デフォルトの名無しさん：2009/05/14(木) 21:18:16

iPhoneのサンプルコード眺めてたら字面の醜悪さに眩暈がしてきた･･･

934 ：デフォルトの名無しさん：2009/05/14(木) 21:34:04

>>931 をみて、ふと思ったんだが

「あ、きれいなコードだな」って思うコードは
使ってる言語問わず、副作用をうまく隠蔽してある、つか
例外条件が少なくなるようにデザインしてるなと感じる

935 ：デフォルトの名無しさん：2009/05/14(木) 23:17:11

>>934
それを考えるとC言語は既に十分醜いな
副作用に動作が依存する場面がすごく多い

また演算子の記号がAPLに次いで2番目に多い
(C++があるから今はどうなのかわからないが)ので
プログラムをコンパクトに書ける反面直感に反した
結果を出す事が多い

演算子の優先順位があり、しかも適応方向が
右から左か左から右かバラバラに混在しているから

C言語の宣言なんかはパッと見て理解できない場合
が多い

936 ：デフォルトの名無しさん：2009/05/14(木) 23:25:47

副作用って代入か入出力ですよね
代入を隠蔽するのはいわゆるカプセル化だと思いますが
入出力を隠蔽することがあるんでしょうか

937 ：デフォルトの名無しさん：2009/05/14(木) 23:31:42

>>935
いあ、うまい奴がつくると C でも本当にきれいに書いてある

>>936
> 入出力を隠蔽することがあるんでしょうか
デバドラ回りの階層化ってのはそのためにやってあるんじゃないんでしょうか?

938 ：デフォルトの名無しさん：2009/05/14(木) 23:45:30

>>936
割り込みを使ったストラテジーに分解する事はある意味隠蔽だと思います。
OS側からデータを送る部分とバッファに溜まったデータを割り込みによって
ハードウェアに吐き出す部分は明確に区別されています

入力も順序が逆なだけで似たようなものです

939 ：デフォルトの名無しさん：2009/05/14(木) 23:52:07

>>936
直接、入出力の話じゃないけど………

キャッシュの容量だとかラインサイズだとか、誰も気にせずにプログラムしてるだろ？
仮想記憶のページサイズとかもほとんど気にせずプログラムできるだろ？

940 ：デフォルトの名無しさん：2009/05/15(金) 00:09:27

Cの仕様には入出力がないっていう話があって、
既にもうそれ以上隠蔽しようがなくなってる気がする。

941 ：デフォルトの名無しさん：2009/05/15(金) 00:13:22

はあ？

942 ：デフォルトの名無しさん：2009/05/15(金) 00:17:23

にゃ
くぱぁ。

943 ：ちんこ ◆GbXlaaQNk. ：2009/05/15(金) 00:26:29

だからおれはイミュータブルなメソッドオブジェクトを好めって言ってるんだよ。
状態っていうのは、害悪でしかない。
状態はなるべく少ないように設計しなければいけない。
それが、ThoughWorksアンソロジーに書いてある、
インスタンス変数は１つまでというプラクティスの有力な根拠だ。
もちろん凝集度の話もあるけどね。

信じられるだろうか。
おれは信じられない。
問い合わせと更新を同時に行うメソッドを実装する人を。
リファクタリングで分離しなければならない。
美しいソースコードの書き方を知らないカスが、
美しい言語を語るなんていうのは、
プログラミング言語を芸術かなんかだと勘違いしている証拠だ。
そこに哲学は存在するが、芸術ではない。
プログラミング言語は眺めて楽しむものではなく、
動くソフトウェアを作ってこそ価値を見出せるものだからだ。

944 ：デフォルトの名無しさん：2009/05/15(金) 00:29:55

俺はケツの毛を剃った。まで読んだ。

945 ：デフォルトの名無しさん：2009/05/15(金) 00:32:13

>>943
ポエマーなあなたは、言語なんか探してないで、自分でポエミーな言語を
作っちゃいなさい。

946 ：デフォルトの名無しさん：2009/05/15(金) 00:49:33

>>943
言ってることは支離滅裂だわ
都合の悪い事は語らないわ
お前はいったい誰に愚痴をいってるんだ？

そこら辺に転がってた考え方を唯並べてるようにしか見えんな

947 ：デフォルトの名無しさん：2009/05/15(金) 00:53:38

最近基地外の振りしてでも構ってもらいたがるレス乞食が急増しててその中の一人って事だろ。
寂しいんだよ。

948 ：デフォルトの名無しさん：2009/05/15(金) 01:19:11

もしかしたら、ここがお話が出来る唯一の場所なのかもしれん。
そうだったら、かわいそうな気がしてきた。。。

949 ：デフォルトの名無しさん：2009/05/15(金) 01:39:58

>>943
問い合わせと更新を同時に行うのは信じられないらしいけど
それじゃキューやスタックはどうやって実装する？＞ちんこ

950 ：デフォルトの名無しさん：2009/05/15(金) 01:46:58

やめとけ
ちんこはお触り禁止

951 ：デフォルトの名無しさん：2009/05/15(金) 10:16:28

相変わらず空気読めない奴だ。

952 ：デフォルトの名無しさん：2009/05/15(金) 17:05:22

STLのvectorとかstackとかは更新と問い合わせが別々じゃなかったっけ

953 ：ちんこ ◆GbXlaaQNk. ：2009/05/15(金) 22:54:32

>>952
Stackというものが、
popしたオブジェクトを返すという仕様なので違うと思います。
STLのことは知りませんが。

問い合わせと更新は、基本的には一緒にすべきではありません。
http://www.refactoring.com/catalog/separateQueryFromModifier.html

とりあえずみなさん、
ちゃんとしたコードを書いてください。
ゴミみたいなコードを書かないでください。
ちゃんと学んでください。
マーチンのリファクタリングを読んでない人は、
コードを書かないでください。お願いします。

954 ：デフォルトの名無しさん：2009/05/15(金) 23:26:35

参照だけするtop()もあるじゃん

955 ：デフォルトの名無しさん：2009/05/15(金) 23:31:47

>>953
そこまでこだわりをもってるということは、プログラムで生業を立ててるの？

956 ：デフォルトの名無しさん：2009/05/16(土) 00:18:25

問い合わせ回数を記録しておく場合はどう実装するの？

957 ：デフォルトの名無しさん：2009/05/16(土) 00:39:09

スレ違いの話ばかりしやがって
糞コテのオナニーになんか付き合うなよ

958 ：デフォルトの名無しさん：2009/05/16(土) 01:09:25

オナニーつーか、薄っぺらいわな

959 ：デフォルトの名無しさん：2009/05/16(土) 02:38:29

現場の土方グラマはこういう基本を疎かにしがちだから
ちんこに教えを請うのもいいかもしれないな。

960 ：デフォルトの名無しさん：2009/05/16(土) 02:42:03

ねぇねぇ、なんでここID非表示なの？

961 ：デフォルトの名無しさん：2009/05/16(土) 10:20:27

自演するためだよ

962 ：ちんこ ◆GbXlaaQNk. ：2009/05/16(土) 11:50:11

土方どころか、
多くの日本人プログラマは、
リファクタリングすらも読んだことないんだろ。
まじで環境汚染だからコード書くな池沼どもw

>>956
デコレータなどを作ってください。
おれが言ってるのは、なるべくという話です。
分離出来るなら分離した方がいいくらい。
Stackの場合は、
参照してから取り出す（この時、取り出したものは返さない）
という風にすればいいですが、あまりよくないです。
Stackというものが概念的に確立されたものだからです。

このおれがPythonが美しいというのだから、
お前らは全員Python使ってりゃいいんだよ。
バカな自分の意見をもつことすら許されないんだよ＾＾とうまー

963 ：デフォルトの名無しさん：2009/05/16(土) 11:56:17

金玉に毛が生えてきた、まで読んだ

964 ：デフォルトの名無しさん：2009/05/16(土) 13:01:46

>>956の要件だとHaskellだとWriter monad使うかな
MonadWriterというものが概念的に確立されたものだからいいよな

965 ：デフォルトの名無しさん：2009/05/16(土) 14:20:39

糞共よく聞け
人間なんてものは、「ボトルガム」を「ボルトガンダム」と読んじまうような奴ばっかりだ

966 ：デフォルトの名無しさん：2009/05/16(土) 14:28:42

>>962
ちょっと質問なんだけど、君はGlenford J. Myers の1970年代の
一連の著作(複合設計など)を読んだことあるかい？

967 ：ちんこ ◆GbXlaaQNk. ：2009/05/16(土) 14:50:45

>>966
誰だそいつ。

そんな古い本読む必要ないよ。

968 ：デフォルトの名無しさん：2009/05/16(土) 14:58:25

The Art of Software Testingは古いけどいい本だよ

969 ：デフォルトの名無しさん：2009/05/16(土) 15:43:53

デバッグの良い本ってないかのう

970 ：デフォルトの名無しさん：2009/05/16(土) 15:47:05

>>967
研究者でないならいいんだ。しかしね、Myersの研究と著作がなかったら、
君が、>>576 >>591 >>676 >>774 の中で結合度というキーワードを使う
ことにはならなかったと思うよ。

971 ：デフォルトの名無しさん：2009/05/16(土) 15:48:38

古きを尻、新しきを汁
若いのさ

972 ：デフォルトの名無しさん：2009/05/16(土) 16:04:59

そういえばCode Completeのbibliographyにも彼の著作であるStructured, Designがあった

973 ：ちんこ ◆GbXlaaQNk. ：2009/05/16(土) 16:05:45

>>970
おれは研究者志望ではあるが、
ソフトウェアの研究者になる方針ではない。
ソフトウェアの設計やその他もろもろについては、
欧米の誰かが研究したものをまとめたサーベイ論文のようなもの
（Code Completeはその類だろう）
を読んで理解して、自分なりの設計指針を固めていけばいいと思っている。
自分の設計指針が正しいのをみんなに知らしめるには、
どの分野もそうだろうが、理論的アプローチと実験的アプローチがある。
おれは、後者を選びたいし、ソフトウェアにおいては圧倒的に後者が正しいと思っている。
数学など、理論ガチガチの世界でも、ソフトウェアを使った証明が少しずつ導入されているようで、
そういう意味では、これからの世界では理論ベースから実験ベース、
ハードウェアからソフトウェアにシフトしていくのだろう。FPGAのような感じで。

結合度に関しては、
TDDと可読性の視点から指摘している。
理論的な結合度の理論などどうでもいい。
TDDを実践するには結合度の低いコードの方がやりやすい
（リファクタリングもしやすいし、コードも書きやすい）し、
可読性という点を考えた場合も、
結合度の高いコードは何がなんだか分からない。
爆発的によく分からなさが増大していく傾向がある。
結合度という概念を知ってそうしているならまだ許せるが、
無関心にそういうクズコードを書いて他人に読むことを強制する人間は到底許されない。
法律で裁かれるべきだとすら思っている。
このように、おれはソフトウェアに対してこだわりがあるが、
日本のソフトウェア業界にはおれレベルのこだわりを持った人間がいないということは納得している。
日本人は思考停止が好きだからな。なんでもおざなりにやっつけて、最後には愛想笑いだ。はははwはははw
は！？
よって、おれはプログラマにはなる気がないから、研究者になるしかない。

974 ：デフォルトの名無しさん：2009/05/16(土) 16:06:27

なんだかんだいって、忠告してあげるんだから
優しいなお前ら

975 ：デフォルトの名無しさん：2009/05/16(土) 16:08:43

>>973
で、結局読んでもいないし、知りもしないわけね。

976 ：ちんこ ◆GbXlaaQNk. ：2009/05/16(土) 16:09:58

おれが優秀で有望な人間だからだろ。
おれなら、日本の腐ったソフトウェア業界を変えてくれるはず、
そう信じているんだよ。
おれは、言ってみりゃ、仙道のような男だということだろ。
でも、おれは日本でプログラマになる気はさらさらないんだ。
妥協妥協、正しい道があるのに、それに目を瞑って腐った上司の命令に従順しなければいけない。
おれは東大か京大の理系大学院を出た人間にしか命令されたくない。
あるいはハーバードとかMITとかそのレベルの人間にしか従いたくない。
よって、おれは企業に入る気をなくしている。
おれと同等に優秀な人間とだけ付き合いたいんだ。

977 ：デフォルトの名無しさん：2009/05/16(土) 16:12:59

>>976
ならさっさとここから出て行って、良い仲間みつけとけ

978 ：デフォルトの名無しさん：2009/05/16(土) 16:14:35

その書き方だと
やりやすいコードを結合度の低いコードって表現してるだけのように取れる
わかりにくいコード→結合度の高いコードとか

参照グラフとクラス図の相関として数値で出すような手法(これだと凝集度だけど)
とかもありそうなんだけどなー

979 ：デフォルトの名無しさん：2009/05/16(土) 16:17:18

まぁ、やりたいことはわかるがー
もういいよ。飽きたー

980 ：デフォルトの名無しさん：2009/05/16(土) 16:24:15

定量化できるなら誰も苦労しないでしょ

981 ：デフォルトの名無しさん：2009/05/16(土) 16:29:57

コンポーネント間の凝集度の定量化はLCOM3とか方法はいくつかあるみたい
ただ人間に役立つ情報にしようとすると大変っぽい
それを踏まえると、これよりさらに「人間寄り」な結合度という概念は、
同じように参照グラフを使ってなんとかしようとしてもさらに苦労するんだろうな

982 ：デフォルトの名無しさん：2009/05/16(土) 16:35:03

問題を定量化して計算機の力で解決するのがITの持つ価値創造能力なのに
それを最初から諦めるとは何事だ
むしろ言語の美しさに形式的定義を与えてこの長年の論争に終止符を打つぐらいの気概を持つべき