最も美しいプログラミング言語を語れ
前スレ
http://pc12.2ch.net/test/read.cgi/tech/1262707694/
探検
最も美しいプログラミング言語は? Part6
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2010/03/23(火) 16:44:08127デフォルトの名無しさん
2010/05/09(日) 21:24:58 数値計算、金融計算、OS、言語処理系、組み込み系で考えたら、
他の言語の方が特化しているのは確かだろうけど、
多方面で扱うこと考えたらC++じゃないか
OOPやテンプレートで簡潔に書ける場面は存在するし
純粋な何々指向は、その縛りでかえって複雑になったり、
後々で不純物が混じったり。
なら、初めから不純物含んだものの方が目的達成するのがはやそう
という、プログラムの組めない奴の妄想
メリットが不明なのは、boostのconceptとか、lambdaとかファンクタとか
他の言語の方が特化しているのは確かだろうけど、
多方面で扱うこと考えたらC++じゃないか
OOPやテンプレートで簡潔に書ける場面は存在するし
純粋な何々指向は、その縛りでかえって複雑になったり、
後々で不純物が混じったり。
なら、初めから不純物含んだものの方が目的達成するのがはやそう
という、プログラムの組めない奴の妄想
メリットが不明なのは、boostのconceptとか、lambdaとかファンクタとか
128デフォルトの名無しさん
2010/05/09(日) 21:40:59 スレタイの「美しさ」とは無関係な議論だな
もうスレタイ的な意味の議論は終了してしまったから他の話をやってるだけか
templateは俺は嫌い
総称型、ダックタイピング、コンパイル時計算、メタプログラミングと
少なくとも4種類の目的の異なる仕事を(汚く/無理やり)扱っているのが
好きになれない
そもそも本当に全てが必要か、という問題もあるわけだが
OOPのための言語としてもC++はあまり良くないよね
純粋じゃない、というのはさておき、GC無いのとオブジェクトが
自己記述的じゃないのがOOP言語として見るとちょっとな
もうスレタイ的な意味の議論は終了してしまったから他の話をやってるだけか
templateは俺は嫌い
総称型、ダックタイピング、コンパイル時計算、メタプログラミングと
少なくとも4種類の目的の異なる仕事を(汚く/無理やり)扱っているのが
好きになれない
そもそも本当に全てが必要か、という問題もあるわけだが
OOPのための言語としてもC++はあまり良くないよね
純粋じゃない、というのはさておき、GC無いのとオブジェクトが
自己記述的じゃないのがOOP言語として見るとちょっとな
129デフォルトの名無しさん
2010/05/09(日) 22:12:16 最近にublasを知って、templateが好きになったんだが、たぶん、
すぐに嫌いになるかもしれない。普通に配列で書く方が速そうだし。
数値計算するのに、C++は不要だろうが視認性が良いんだ。
GCのある言語だと数値計算、やたら遅いイメージが拭えないし。
純粋なOOPに、どれだけメリットと恩恵があるのか疑問。
SmalltalkよりJavaが勝利したあたりで、それほど必要だとも思えない
すぐに嫌いになるかもしれない。普通に配列で書く方が速そうだし。
数値計算するのに、C++は不要だろうが視認性が良いんだ。
GCのある言語だと数値計算、やたら遅いイメージが拭えないし。
純粋なOOPに、どれだけメリットと恩恵があるのか疑問。
SmalltalkよりJavaが勝利したあたりで、それほど必要だとも思えない
130デフォルトの名無しさん
2010/05/09(日) 22:17:48 >>129
Javaも純粋じゃないけど、GCとまともに使える例外があって
オブジェクトが自己記述的だから、C++よりはずっと自然にOOPしやすいでしょ
まあJavaはJavaで融通が利かないから俺は好きじゃないんだけどな
Javaも純粋じゃないけど、GCとまともに使える例外があって
オブジェクトが自己記述的だから、C++よりはずっと自然にOOPしやすいでしょ
まあJavaはJavaで融通が利かないから俺は好きじゃないんだけどな
131デフォルトの名無しさん
2010/05/10(月) 00:19:45 GCはプログラミングがルーズになるし制御できない部分が気持ち悪い
作ったものくらい自分で始末しろとw
作ったものくらい自分で始末しろとw
132デフォルトの名無しさん
2010/05/10(月) 00:33:43 >>124
速度に目を瞑ればJavaScriptが割といい線いってるな
速度に目を瞑ればJavaScriptが割といい線いってるな
133デフォルトの名無しさん
2010/05/10(月) 00:39:59 ブラウザを除けばJavaScriptのユーザは0だけどな
134デフォルトの名無しさん
2010/05/10(月) 01:27:14135デフォルトの名無しさん
2010/05/10(月) 01:32:52 OCaml全然詳しくねーけど、チラ見した感じではなーんか微妙
関数型のくせにstringがmutableとか、意味不明なセンスの悪さをそこかしこに感じる
structural subtyping一見良さそうだけど、実行時情報ねーから
ダウンキャスト(風のこと)はできないっしょ?
"O"とかいいつつ、あれで下手にOOの真似事やろうとすると怪我すると思う
あとは、ありがちだけどライブラリが未成熟で、Unix系以外ではあんま使い物に
ならないっぽいよね
関数型のくせにstringがmutableとか、意味不明なセンスの悪さをそこかしこに感じる
structural subtyping一見良さそうだけど、実行時情報ねーから
ダウンキャスト(風のこと)はできないっしょ?
"O"とかいいつつ、あれで下手にOOの真似事やろうとすると怪我すると思う
あとは、ありがちだけどライブラリが未成熟で、Unix系以外ではあんま使い物に
ならないっぽいよね
136デフォルトの名無しさん
2010/05/10(月) 01:53:47 OCamlの良いところはな、OCamlかじってなんとも言えない気持ちの悪さ
を感じた時にHaskellかじると、なんだ関数プログラミング言語って実は
分かりやすいじゃんって思えるところナンテネ
を感じた時にHaskellかじると、なんだ関数プログラミング言語って実は
分かりやすいじゃんって思えるところナンテネ
137デフォルトの名無しさん
2010/05/10(月) 01:59:47 一般的なプログラミング言語は計算能力において等価だから、
一昔前の言語で能力的には既に十分。
残された問題は、複雑なロジックをいかに簡潔に記述できるか、
それが他人にも理解されるかというだけ。
進歩の方向性はそれくらいしか考えられない。
一昔前の言語で能力的には既に十分。
残された問題は、複雑なロジックをいかに簡潔に記述できるか、
それが他人にも理解されるかというだけ。
進歩の方向性はそれくらいしか考えられない。
138デフォルトの名無しさん
2010/05/10(月) 12:03:50 >>136
これ正に俺だ
最初にHaskell触った時は全然理解できなかったけど
OCamlを触った後に再びHaskell触ったら割とすんなりなじむことができた
OCamlの表記法はなんともなじめなかったけど
これ正に俺だ
最初にHaskell触った時は全然理解できなかったけど
OCamlを触った後に再びHaskell触ったら割とすんなりなじむことができた
OCamlの表記法はなんともなじめなかったけど
139デフォルトの名無しさん
2010/05/10(月) 20:50:48 言語進化とか言いながら、単に暗黙の前提仮定が増えただけだったりする。
ルールを知らないと読むこともできない。言語解説書バカ売れ。
制限は減ったのかもしれないけどな。
ルールを知らないと読むこともできない。言語解説書バカ売れ。
制限は減ったのかもしれないけどな。
140デフォルトの名無しさん
2010/05/10(月) 22:05:42 Haskel,lispが勝利したのは英語圏と米で流行ったからとか言ってみるテスト
141デフォルトの名無しさん
2010/05/10(月) 23:11:16142デフォルトの名無しさん
2010/05/10(月) 23:13:06 いつ流行ったんだよw
143デフォルトの名無しさん
2010/05/10(月) 23:43:39 流行ったっていうか、関数型の中でもメジャーで市民権を得ているあたり
144デフォルトの名無しさん
2010/05/10(月) 23:52:43145デフォルトの名無しさん
2010/05/11(火) 05:36:39 >>139
グローバルスタンダードってそういうものでしょ。
グローバルスタンダードってそういうものでしょ。
146デフォルトの名無しさん
2010/05/12(水) 01:02:35147デフォルトの名無しさん
2010/05/12(水) 05:55:53 半年くらい前にここ覗いた時は何かJavaキチガイコテが連投してた気がするんだけど、
あいつは結局あの後どうなったん?
あいつは結局あの後どうなったん?
148デフォルトの名無しさん
2010/05/12(水) 06:24:21149デフォルトの名無しさん
2010/05/12(水) 10:54:05 >>148
thx
超大雑把に流し読みしたが、誰かがガチで叩いたのかw
面白い流れを見逃したかもしれんなぁ
つーかよくあんなの真面目に叩く気になったもんだ、良くも悪くもすげーな
まぁこんなとこ見てる俺が言えた義理じゃねーけど
thx
超大雑把に流し読みしたが、誰かがガチで叩いたのかw
面白い流れを見逃したかもしれんなぁ
つーかよくあんなの真面目に叩く気になったもんだ、良くも悪くもすげーな
まぁこんなとこ見てる俺が言えた義理じゃねーけど
150デフォルトの名無しさん
2010/05/13(木) 10:40:08 一番美しいと思うのはアセンブラとLISP
151デフォルトの名無しさん
2010/05/13(木) 12:47:17 アセンブラなら CPUにもよるだろ
152デフォルトの名無しさん
2010/05/13(木) 12:57:23 彼は特定のアセンブラ言語ではなく、アセンブラ言語の本質的な特性を好んでいるのだろう。
lispだって複数の言語の総称だ。
lispだって複数の言語の総称だ。
153デフォルトの名無しさん
2010/05/14(金) 03:10:01 通訳無しにプロセッサと話せるのはアセンブラだけだしな
厳密には機械語だが、まぁ本質は同じだ
厳密には機械語だが、まぁ本質は同じだ
154デフォルトの名無しさん
2010/05/14(金) 11:11:42155デフォルトの名無しさん
2010/05/14(金) 11:29:35156デフォルトの名無しさん
2010/05/14(金) 12:21:59157デフォルトの名無しさん
2010/05/14(金) 12:44:29 まあ Ook! と Whitespace は、美しさで言えば同質。
158デフォルトの名無しさん
2010/05/14(金) 13:45:22 あの辺はみんな同じだな
まぁ見た目重視言語の一派だから、見た目の違いが大事になる可能性はあるが
まぁ見た目重視言語の一派だから、見た目の違いが大事になる可能性はあるが
159デフォルトの名無しさん
2010/05/14(金) 13:46:57 ×見た目重視
○見た目も重視する
つーかこれで置換すると俺がバカな文章書いたことがよく分かるな
○見た目も重視する
つーかこれで置換すると俺がバカな文章書いたことがよく分かるな
160デフォルトの名無しさん
2010/05/14(金) 14:29:29 アセンブラと言ってもmasm系とgas系では書式違う。
cpuやアーキテクチャによって使える命令違うから、アルゴリズムをスマートに書けるかどうかも変わってくる。
ノイマン型でなければ逐次実行もままならない。
だからアセンブラが共通して持つ本質的な美しさなんてありえない。
cpuやアーキテクチャによって使える命令違うから、アルゴリズムをスマートに書けるかどうかも変わってくる。
ノイマン型でなければ逐次実行もままならない。
だからアセンブラが共通して持つ本質的な美しさなんてありえない。
161デフォルトの名無しさん
2010/05/14(金) 14:42:53 >>160
> コンピュータの挙動を厳密にコントロールできる
> コンピュータの挙動を厳密にコントロールできる
162デフォルトの名無しさん
2010/05/14(金) 14:44:34 >>161
言語の美しさじゃない
言語の美しさじゃない
163デフォルトの名無しさん
2010/05/14(金) 15:01:16 このスレを見ると、何をもってして美しいと感じるか、それは人それぞれなんだぁと
つくづく思う、だが○○オメーはダメだ!
Q.○○に当てはまるプログラミング言語を挙げなさい
つくづく思う、だが○○オメーはダメだ!
Q.○○に当てはまるプログラミング言語を挙げなさい
164デフォルトの名無しさん
2010/05/14(金) 15:04:42165デフォルトの名無しさん
2010/05/14(金) 15:07:47 masmだろうがgasだろうが本質は一緒だろ
機械語とアセンブラが違うのかどうかの話の後にそんなことを言ってる時点で的外れ
全てのアセンブラに共通する点というのはある(同じ名前でくくられてるんだから当然)
その共通する点について美しいと思うなら、それはアセンブラを美しいと感じることに等しい
機械語とアセンブラが違うのかどうかの話の後にそんなことを言ってる時点で的外れ
全てのアセンブラに共通する点というのはある(同じ名前でくくられてるんだから当然)
その共通する点について美しいと思うなら、それはアセンブラを美しいと感じることに等しい
166デフォルトの名無しさん
2010/05/14(金) 15:11:53 そりゃざっくりすぎるんじゃないか
167デフォルトの名無しさん
2010/05/14(金) 15:12:27 >>164
ツッコミがいかにも浅いなぁ。CRISC以降は同時実行云々どころじゃねーだろw
どう言おうが、プロセッサが用意したI/Fを直接叩けるのはアセンブラだけだわな。
他の言語では「最適化」でも、アセンブラでは「クロックを削る」というような感覚に
近付く。それが美しいといえば美しいんじゃねーの。少なくとも共通して特異だ。
ツッコミがいかにも浅いなぁ。CRISC以降は同時実行云々どころじゃねーだろw
どう言おうが、プロセッサが用意したI/Fを直接叩けるのはアセンブラだけだわな。
他の言語では「最適化」でも、アセンブラでは「クロックを削る」というような感覚に
近付く。それが美しいといえば美しいんじゃねーの。少なくとも共通して特異だ。
168デフォルトの名無しさん
2010/05/14(金) 15:14:09169デフォルトの名無しさん
2010/05/14(金) 16:01:05170デフォルトの名無しさん
2010/05/14(金) 16:11:36 マクロアセンブラのマクロの力を知らぬな。そういう自分ももう忘れたが。
171デフォルトの名無しさん
2010/05/15(土) 00:39:43 この"美しい"の意味を明確に定義しとく必要があるでしょ。ソースコードの見た目が美しい(他者が読みやすい)
のか、用途が美しい(曖昧だけど)のかどうなのか・・・・
ハード方向でCを使ってレジスタ、アドレス演算ができるようになればCがいいんじゃないw 破壊力は抜群。
同じプログラムを組むのでも、素人とプロが組むのでは実行速度も行数もまったく異なる、天と地の差を見せ付ける
ことができるのがC言語。そこに美しさを感じる僕ですb
のか、用途が美しい(曖昧だけど)のかどうなのか・・・・
ハード方向でCを使ってレジスタ、アドレス演算ができるようになればCがいいんじゃないw 破壊力は抜群。
同じプログラムを組むのでも、素人とプロが組むのでは実行速度も行数もまったく異なる、天と地の差を見せ付ける
ことができるのがC言語。そこに美しさを感じる僕ですb
172デフォルトの名無しさん
2010/05/15(土) 09:57:14 コードが美しい、ってのはわかりやすいけど、言語が美しい、ってのはなあ。
173デフォルトの名無しさん
2010/05/17(月) 08:59:02 分からん奴は参加しなくてよし
174デフォルトの名無しさん
2010/05/17(月) 10:11:55175デフォルトの名無しさん
2010/05/17(月) 10:17:22 最も美しい言語は Haskell と定義されている。
176デフォルトの名無しさん
2010/05/17(月) 22:56:30 美しい言語鈴木を誰か作ればいい
177デフォルトの名無しさん
2010/05/18(火) 02:04:05178デフォルトの名無しさん
2010/05/18(火) 08:29:11 美しい言語鈴木「美しい言語だけにコンパイルされる権利を与える」
179デフォルトの名無しさん
2010/05/18(火) 22:53:29 じゃあ俺インタプリタでいいや
180デフォルトの名無しさん
2010/05/19(水) 23:17:41 どの言語も似たり寄ったりだからな
ifはどの言語でもifだし
インクルードやデファインも意味と書き方こそ違えどの言語も同じような記述法だし
書こうと思えばどの言語でも他のどんな言語の流儀でも書ける
それを踏まえても美しいと言い切れるには何を観点とすればいいのか
ifはどの言語でもifだし
インクルードやデファインも意味と書き方こそ違えどの言語も同じような記述法だし
書こうと思えばどの言語でも他のどんな言語の流儀でも書ける
それを踏まえても美しいと言い切れるには何を観点とすればいいのか
181デフォルトの名無しさん
2010/05/20(木) 00:01:20 謎の仕様が少ないものは美しいといえるだろう。
言語の普及と発展、互換の足かせとともに、もともとあった美しさを穢していく。
言語の普及と発展、互換の足かせとともに、もともとあった美しさを穢していく。
182デフォルトの名無しさん
2010/05/20(木) 00:25:30 Q なぜ謎を解かないのか
A その謎はけがれているから
A その謎はけがれているから
183デフォルトの名無しさん
2010/05/20(木) 00:37:18 >>180
言語設計者の思想とか哲学
言語設計者の思想とか哲学
184デフォルトの名無しさん
2010/05/23(日) 13:41:43 Prologに言語設計者なんていたかな。
185デフォルトの名無しさん
2010/05/25(火) 12:20:43 >>184
lispもそうだが、新しいパラダイムを研究する過程で提案された言語は、
ただの表記でしかない。
実用的な目的のために詳細にまで注意して設計されたものではない。
設計の改善は後の人たちの役割。
lispもそうだが、新しいパラダイムを研究する過程で提案された言語は、
ただの表記でしかない。
実用的な目的のために詳細にまで注意して設計されたものではない。
設計の改善は後の人たちの役割。
186デフォルトの名無しさん
2010/05/25(火) 18:58:33 言語のセマンティクス=パラダイムを議論するんだな
論文を読めばいい
論文を読めばいい
187デフォルトの名無しさん
2010/05/25(火) 23:55:11 その手の論文の探し方おしえて
188デフォルトの名無しさん
2010/05/26(水) 06:23:12 自分で探せよ
189デフォルトの名無しさん
2010/05/26(水) 23:56:02 ciniiしか知らんのだよ
190デフォルトの名無しさん
2010/05/27(木) 02:11:06 最近の中間コード言語は美しくないね
namespaceやらclass階層の中にじかに関数定義書くもんだから
@ネストが無駄に深くなる
Anamespace,classの開き括弧、閉じ括弧の対応が追いにくい。それを防ぐためにネストを無駄に深くしなければならないので@。
JAVAもそうだし、.NET系言語はこれから主流扱いになるらしいけど、先行きは暗い
こんな仕様は小さなコードなら良いだろうけど大きくなったら読みづらくなって仕方ない
大粒のライブラリ使えばコードは大きくならないだろうという見通しでしてるんだったら、たいていそういう予測は外れてるしね
namespaceやらclass階層の中にじかに関数定義書くもんだから
@ネストが無駄に深くなる
Anamespace,classの開き括弧、閉じ括弧の対応が追いにくい。それを防ぐためにネストを無駄に深くしなければならないので@。
JAVAもそうだし、.NET系言語はこれから主流扱いになるらしいけど、先行きは暗い
こんな仕様は小さなコードなら良いだろうけど大きくなったら読みづらくなって仕方ない
大粒のライブラリ使えばコードは大きくならないだろうという見通しでしてるんだったら、たいていそういう予測は外れてるしね
191デフォルトの名無しさん
2010/05/28(金) 09:47:41192デフォルトの名無しさん
2010/05/28(金) 19:20:26 $@&*のない綺麗なperlが欲しいと思っていたら、pikeがそうだった
流行らんかな。これ
流行らんかな。これ
193デフォルトの名無しさん
2010/06/11(金) 21:10:55 Rob?
194デフォルトの名無しさん
2010/06/19(土) 23:20:26 Lisp
195デフォルトの名無しさん
2010/08/25(水) 02:46:02 Vala
196デフォルトの名無しさん
2010/11/10(水) 01:19:29 >>192
Perl はシギルがあるからキレイなんじゃないか
Perl はシギルがあるからキレイなんじゃないか
197デフォルトの名無しさん
2010/11/10(水) 02:09:29 CかC++で書かれててPythonがガチガチの静的型付けになったような言語が理想だ
型推論もいらない。高機能なIDEは必須。
型推論もいらない。高機能なIDEは必須。
198デフォルトの名無しさん
2010/11/10(水) 02:40:41 >>197
Cython?
Cython?
199デフォルトの名無しさん
2010/11/10(水) 08:04:22200デフォルトの名無しさん
2010/11/11(木) 09:49:11 >>197
今売り出し中のNimrodはどうよ
今売り出し中のNimrodはどうよ
201デフォルトの名無しさん
2010/11/12(金) 20:43:04 >>197
いまどきの静的型付けの言語は似たようなものだが。
いまどきの静的型付けの言語は似たようなものだが。
202デフォルトの名無しさん
2010/11/16(火) 22:22:50 IDEなしで書ける直感的なメソッド体系の言語が理想だ
マニュアル片手に書くのはめんどい
マニュアル片手に書くのはめんどい
203デフォルトの名無しさん
2010/12/27(月) 15:43:59 >>202
メソッド体系?
メソッド体系?
204デフォルトの名無しさん
2010/12/27(月) 19:39:54 IDEなしで書けるぐらいにメソッドが直感的に体系化された言語
ってことじゃね
ってことじゃね
205デフォルトの名無しさん
2010/12/27(月) 20:03:09 メソッドって基本的にユーザが立てるもの
ではないのかな。組み込み的な意味なら、
無いに越したことはない。少なくとも美しさを
論じるなら。
ではないのかな。組み込み的な意味なら、
無いに越したことはない。少なくとも美しさを
論じるなら。
206デフォルトの名無しさん
2010/12/28(火) 15:00:00 >>205 標準APIかなんかの話じゃないの。
207デフォルトの名無しさん
2010/12/28(火) 15:17:59 J
208デフォルトの名無しさん
2010/12/29(水) 22:00:40 >>202
どういうこと?
IDEと連携取りやすい言語ならばむしろマニュアル片手にする必要ないぞ。リファレンスが内蔵されているようなものだからな。
チュートリアルは別途やればいい。
そもそも直感的なメソッド体系の言語というのが誰にとっての?というところがある。
C#はC系の言語利用者にとっても直感的ではなかったが、DelphiやVCLの利用者やJavaかじったことある人間にはむしろ直感的だった。
RubyはかつてはモダンではないPerl利用者には直感的だったかも知れないが、
今やRails以降のRubyやモダンPerlは双方ともバラバラ全くの別物。直感的でない。
しかも、これらも個人の感覚だ。
中学生にとっての直感的な言語も違うだろうし。
どういうこと?
IDEと連携取りやすい言語ならばむしろマニュアル片手にする必要ないぞ。リファレンスが内蔵されているようなものだからな。
チュートリアルは別途やればいい。
そもそも直感的なメソッド体系の言語というのが誰にとっての?というところがある。
C#はC系の言語利用者にとっても直感的ではなかったが、DelphiやVCLの利用者やJavaかじったことある人間にはむしろ直感的だった。
RubyはかつてはモダンではないPerl利用者には直感的だったかも知れないが、
今やRails以降のRubyやモダンPerlは双方ともバラバラ全くの別物。直感的でない。
しかも、これらも個人の感覚だ。
中学生にとっての直感的な言語も違うだろうし。
209デフォルトの名無しさん
2010/12/29(水) 22:43:44 COBOLはそれをめざしたとか。
AppleScriptもそうかも。
AppleScriptもそうかも。
210デフォルトの名無しさん
2010/12/30(木) 07:30:37 >>1 実用的な言語の中で一番自由度が高いという意味で、 Prolog
211デフォルトの名無しさん
2011/05/24(火) 23:21:41.72 >>208
少なくともhtonl();よりhost.to<NetworkLong>()の方が解りやすいだろ。
ライブラリの詳細な知識はいらんからな。
やっぱり綺麗となるとどうしてもLispだよ
(+ 5 10 20)は(+ . (5 . (10 . 20) ) )というデータ。
極一部の特殊シンボルを除いて全てデータだからな。
言語の機能とデータに殆ど壁が無くて、機能の拡張を
データの入力と捉えられる。
少なくともhtonl();よりhost.to<NetworkLong>()の方が解りやすいだろ。
ライブラリの詳細な知識はいらんからな。
やっぱり綺麗となるとどうしてもLispだよ
(+ 5 10 20)は(+ . (5 . (10 . 20) ) )というデータ。
極一部の特殊シンボルを除いて全てデータだからな。
言語の機能とデータに殆ど壁が無くて、機能の拡張を
データの入力と捉えられる。
212デフォルトの名無しさん
2011/06/04(土) 15:43:02.98 >>211
だからきれい?
だからきれい?
213デフォルトの名無しさん
2011/06/19(日) 07:58:22.97 半年近く前のレスにアンカーってどうなんだろうな
レス全部見る気がしないので適当に書くが、見方じゃね?
プログラマ側のインプットとしてはPython、Java、Lispで意見が分かれると思う
価値観としか言いようが無い
プログラマ側のアウトプットはLisp、Java、c#
Rubyが美しいと思う奴はこっちだと思うが、その感性は理解できん
CPU側というか、コンパイラ側というか…そっち側ではアセンブラ、Pascal、c
Haskellもこっちに入ると思うが、これまた理解が出来ん
慣れと覚えたては読みやすく書きやすいし、いつまでも平行線だろうな
俺が美しいと思うのはJava、Pythonだ
レス全部見る気がしないので適当に書くが、見方じゃね?
プログラマ側のインプットとしてはPython、Java、Lispで意見が分かれると思う
価値観としか言いようが無い
プログラマ側のアウトプットはLisp、Java、c#
Rubyが美しいと思う奴はこっちだと思うが、その感性は理解できん
CPU側というか、コンパイラ側というか…そっち側ではアセンブラ、Pascal、c
Haskellもこっちに入ると思うが、これまた理解が出来ん
慣れと覚えたては読みやすく書きやすいし、いつまでも平行線だろうな
俺が美しいと思うのはJava、Pythonだ
214デフォルトの名無しさん
2011/06/19(日) 09:04:22.15 Javaはない。
215デフォルトの名無しさん
2011/06/19(日) 11:37:46.14 俺はPythonが美しいとは思わないなあ
便利だけど、統一感が無くて
便利だけど、統一感が無くて
216デフォルトの名無しさん
2011/06/19(日) 12:12:37.66 統一感は、ある方だと思うけど。Rubyに比べたら。
SchemeとかForthと比べたら無いけど。
SchemeとかForthと比べたら無いけど。
217デフォルトの名無しさん
2011/06/19(日) 12:16:04.43 確かに C++ よりは統一感あるかもねw
218デフォルトの名無しさん
2011/06/20(月) 01:02:19.16 やっぱり S 式は美しいな
データとコードの形式が共通で、プログラムからプログラムを操作するのが容易だったり、
プログラムをデータとしてやり取りするのが容易だったりするのは素晴らしい
唯一(最大)の欠点は一般的なオブジェクト指向の記法と相性が悪い事なんだが...
データとコードの形式が共通で、プログラムからプログラムを操作するのが容易だったり、
プログラムをデータとしてやり取りするのが容易だったりするのは素晴らしい
唯一(最大)の欠点は一般的なオブジェクト指向の記法と相性が悪い事なんだが...
219デフォルトの名無しさん
2011/06/20(月) 01:27:53.30 ASTをそのまま書き下せる言語が良いな
220uy ◆yyC0rYWEq2
2011/06/20(月) 02:17:08.24 (class C
(attr_accessor x)
(attr_accessor y)
(def initialize x y
(setq @x x)
(setq @y y) )
(def function
(new CC 2 3 4 5) ) )
class C
attr_accessor :x
attr_accessor :y
def initialize x , y
@x = x
@y = y
end
def function
CC.new 2 , 3 , 4 , 5
end
end
(attr_accessor x)
(attr_accessor y)
(def initialize x y
(setq @x x)
(setq @y y) )
(def function
(new CC 2 3 4 5) ) )
class C
attr_accessor :x
attr_accessor :y
def initialize x , y
@x = x
@y = y
end
def function
CC.new 2 , 3 , 4 , 5
end
end
221uy ◆yyC0rYWEq2
2011/06/20(月) 02:23:10.69 #include < stduo.h >
int main( int argc , char ** argv ) {
printf( "test %d" , 444 ) ;
return 0;
}
(include "stdio.h")
(def (int main) (int argc) (char argv)
(printf "test %d" 444)
(return 0) )
(include "stdio.h")
(def int main int argc char argv
(printf "test %d" 444)
(return 0) )
int main( int argc , char ** argv ) {
printf( "test %d" , 444 ) ;
return 0;
}
(include "stdio.h")
(def (int main) (int argc) (char argv)
(printf "test %d" 444)
(return 0) )
(include "stdio.h")
(def int main int argc char argv
(printf "test %d" 444)
(return 0) )
222デフォルトの名無しさん
2011/06/20(月) 02:32:44.26 プログラムはツリーである
故に、ツリーを華麗に扱える言語が最も美しい
故に、ツリーを華麗に扱える言語が最も美しい
224uy ◆yyC0rYWEq2
2011/06/20(月) 03:32:46.69 現在、一般浸透してる言語はツリーを軽視しすぎてる
ツリー構造で管理していないプログラムっていうのは
たとえば深度4から、深度5〜n まで、参照可能にさせておきたい変数があっても
深度1の場所に名前がかぶらないように定義してるだけなんだよ
ネームスペースを使って NAMESPACE::NAMESPACE::変数
と、してるだけ 砕いていっちゃえば ネームスペースなんて、アンダーバーつかってかぶらない変数名かいてるのと同じようなもん
hensuu___henssuss__susususus__susus = 4 ← けっきょくせかいの平均はここから進歩してない
だから、深度1〜n全ての場所でその変数が普通の方法でも参照できてしまうため
そこまで気にする必要はないにしてもわずかに名前衝突は気をつけなくてはいけない
特に名前のかぶりそうな、Windowクラスとか、Mainクラスといったもののなまえしょうとつを起こす可能性を消せない
これをツリーで管理すると
深度4の場所で Windowクラスを定義すれば
深度1〜3の場所では、どうやっても普通の方法ではWindowクラスまでたどり着けないので
名前衝突が完全に100%といっていいほどなくなる
君たちは全く名前衝突を意識せずにプログラミングできるプログラミングをプログラミングした事はあるかね?
心の清清しさが違う・・・・・ すっげー適当な変数名でプログラミングしても大丈夫、むしろ名前なんて付けない
無名関数でプログラミングしていく、自分で根幹部分のほうに、名前を指定しなければランダムで名前をつけるようにしてしまう
でもツリーを効率的に扱う
そのための言語がないからね、ツリー操作に長けていて、なおかつドキュメント、ライブラリ、人気、見た目
そういうものを全部クリアした言語がまだでてきていない
お話しゅうりょ。
ツリー構造で管理していないプログラムっていうのは
たとえば深度4から、深度5〜n まで、参照可能にさせておきたい変数があっても
深度1の場所に名前がかぶらないように定義してるだけなんだよ
ネームスペースを使って NAMESPACE::NAMESPACE::変数
と、してるだけ 砕いていっちゃえば ネームスペースなんて、アンダーバーつかってかぶらない変数名かいてるのと同じようなもん
hensuu___henssuss__susususus__susus = 4 ← けっきょくせかいの平均はここから進歩してない
だから、深度1〜n全ての場所でその変数が普通の方法でも参照できてしまうため
そこまで気にする必要はないにしてもわずかに名前衝突は気をつけなくてはいけない
特に名前のかぶりそうな、Windowクラスとか、Mainクラスといったもののなまえしょうとつを起こす可能性を消せない
これをツリーで管理すると
深度4の場所で Windowクラスを定義すれば
深度1〜3の場所では、どうやっても普通の方法ではWindowクラスまでたどり着けないので
名前衝突が完全に100%といっていいほどなくなる
君たちは全く名前衝突を意識せずにプログラミングできるプログラミングをプログラミングした事はあるかね?
心の清清しさが違う・・・・・ すっげー適当な変数名でプログラミングしても大丈夫、むしろ名前なんて付けない
無名関数でプログラミングしていく、自分で根幹部分のほうに、名前を指定しなければランダムで名前をつけるようにしてしまう
でもツリーを効率的に扱う
そのための言語がないからね、ツリー操作に長けていて、なおかつドキュメント、ライブラリ、人気、見た目
そういうものを全部クリアした言語がまだでてきていない
お話しゅうりょ。
225デフォルトの名無しさん
2011/06/20(月) 10:28:58.30226デフォルトの名無しさん
2011/06/20(月) 21:17:19.85 X-BASIC
AppleScript
AppleScript
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- サナエノミクスについて力説 積極的な財政出動で「所得増える 消費マインド上がる 税収増える」片山さつき財務大臣 ★3 [少考さん★]
- 中国軍機のレーダー照射1週間 駆け引き続く 中国、米のレッドライン模索 日本、米以外の同志国とも連携探る 米は対立から距離置く★2 [ぐれ★]
- 鈴木農相「おこめ券はお米しか買えないわけではない。例えば卵、味噌、しょうゆ、こうした購入に利用可能」 ★4 [Hitzeschleier★]
- 【芸能】粗品、日本テレビに苦言 客のレベルが「かなり低い。あいつら分かってない」「拍手したいだけやねん」 [冬月記者★]
- 橋下徹氏「総理なら岡田さんに何を聴かれても耐えてほしかった」 高市首相の台湾有事めぐる答弁に# [jinjin★]
- 「ヒートテックに寿命があります」ユニクロが明かした“3年劣化”の理由 暖かさが落ちる意外な原因とは [ぐれ★]
- お前らもちろんマモンキングやってるよな?
- 助けて!!地元でテレビ番組の超絶美人のアナウンサーさんが退社した。゚(゚´Д`゚)゚。
- (´・ω・`)VIPにおける現在確認している不具合について
- 吉田死ね
- ( ´・ω・` )起きたよ
- 国内生産制限・輸入制限(関税)頭おかしい。 [929852992]
