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

最も美しいプログラミング言語を語れ

前スレ
http://pc12.2ch.net/test/read.cgi/tech/1262707694/

↑天才チンパンジーのアイちゃん
↓天才チンパンジーのアイちゃん

前スレではC#が圧倒的優勢でしたが他の言語も負けないでください。

特に Python は危機的です、もっと頑張りましょう！

美しく書かれたソースを貼ると効果的です

じゃあ Quine を。

Whitespace

とりあえずC、python、lisp等のみたいな美しい言語について語るスレです
排他的なC#は論外です

CやPythonのどこが美しいのかわからん
Lisp-2は#'だのfuncallだのが関数型言語として見ると鬱陶しくキモい
C#が排他的だとして、それが言語の美しさと何の関係があるのかもさっぱり分からん

じゃあどんな言語が美しいというの言ってみろ。
批判だけして、自分の意見を言わずに逃げるのは卑怯だろ。

Haskell Forth Prolog Scheme

J

　　　 　 ,―ヽ＿（（（（（＿、―
　　　,／　　ノ　　　　　　　ヽ　　~＼
　 ／　　 ノ　　　ＩＰＡ　　　　ヽ　　　~＼
／　　　ノ　　　　　　　　　　　ヽ、　　`ヽ
|　　　 ﾉ /￣＼　　　／￣~ヽ　ヽ 　　 i
|　　 ノ　　　　　　　　　　　　　　|　　ノ
＼　 |　　＜●＞　　＜●＞　 （　 ）
　＼ |　　　　　 ｜　|　　　　　　 i /
　 　 |　　　　　 /　　ヽ　 　 　 　ﾚ
　　　i　　　　　（●_●）　 　　　 /　　
　　　 i、　　　 ,-――-、　 　・ /
　　　　i、　　<（EEEEE）>　∵/　　　　IPA Ruby最高、他は糞。
　　　 　 i、 　＼　　　.／　　/
　　　 　　 ＼ 　 ーー　　 ,ノ　　　　　　　
　　,,.....イ.ヽヽ、ー-―一ノﾞ-､.
　　:　 　| 　';　＼_____ ノ.| ヽ　i
　　　 　 |　　＼/ﾞ（__)＼,| 　i　|

>>12
お引取りください

VB6は美しい。

前スレ最後の話題。
慣れを排除した上で
「書いたコードが読みやすい」
「他人が見ても内容が理解しやすい」
という言語は、結局どれなんだろう？

自分が書きやすい言語に、ソースにコメントを添えた方が何より楽。

慣れを排除すると、C++とperlが脱落

perlは入門書の最初とかで
｢perlならこんな長文がこんなに短くかけますよ｣的な記述をみて
理解できなくてやめた奴いると思うんだけど
おれがそうだった

今なら分かるかもしれんがプログラム覚えたてのときに見るのはつらい。
可読性って意味では最悪だとおもう

直感で理解できない記号が大量に出てくる言語はダメだな

APLのことか

APLまでいくと、別世界。
たぶん、ネイティブには、プログラムの記述に英単語を使うというのは、直観的ではないんだろう。
日本語BASICは、何が悪いというわけでもないのに、キモかった。

awkはCと同じ記号を使ったが、perlはshと同じ記号を使った、という印象がある

ここで言われる「読みやすい」は、「美しい」と同等の意味を持つのか？

パラメーターだよ

>>23
俺はスレタイとは全然別の質問だと思ってるけど

>>23
同等ではなく、
「読みやすい」は「美しい」を満たす条件の一つ
だと思うよ。

文法は言語の機能だと思う。
だから、読みやすいプログラムを書けるような文法を備えた言語は
美しい機能を持っていると言えるのではないかと思う。

>>27
文法が機能だとしたらどうして
「読みやすい」が「美しい」になるの？
まったく意味不明。

読みやすさと美しさには特に相関が無い気がするな

前スレで出てたがCOBOLは誰が書いても同じようなコードになり
英文に近いという意味で「読みやすい」と言える
が、プログラミング言語として「美しい」というのとは違うと思う

美しいよりかわいい言語に興味があるんだけど。

ほう、かわいい言語とな

tinyなんとかっていうのは、かわいいとも言える

TL/1萌え

美しいプログラミング言語ってのはなくて、美しく書けるプログラミング言語だけがある
どう頑張っても無理なのはたとえばＢＡＳＩＣとか

全くの素人の女の子だったら、
ruby か perl が美しそうって言うだろう。

おっさんだったら俺はCだなとか言いそう。あ、これは関係ないか。

BASICできれいなプログラムがかけないといっているやつは、能力が低い。

>>36
そうそう。大昔だけど、
BASICのコードは、Cを知ってるプログラマとBASICオンリーのプログラマが書のとでは、
天と地の差があったよ。

>>36
一口にBASICといっても、いろいろある。
モダンとクラシックは別物なので、
きちんと区別するべき。

昔のBASICがスタックマシンでないインタプリタであることを考えると、非常に優れた設計。

子供の頃はGOTO文とGOSUB文の違いに対する意識が希薄だった。
雑誌の投稿プログラムが手本だったのでスパゲティに疑問を抱かなかった。

>>39
PCに内蔵されてて電源入れるだけで使えた。
今思うとこれも凄い。
OSはないのにBASICだけはあったｗ

>>40
あーわかるわかるｗ

>>40
I/Oとかの記事でPascalやLispも齧ってたから
構造化は意識してたっけ
>>41
8bitBASICはそれ自体がOSみたいなものでもあったからな

Haskellが最もふつくしひ

今も昔もBASICはスタックマシンじゃないだろ。

それにひどく昔のTinyBASIC（たとえば東京版TinyBASIC）でもスタックは内部で使ってるぞ？

10 print"Hello world!"

これが最初の一歩だという人が多いのでは。

>>46
ちがうよ

10 PRINT "baka "
20 GOTO 10

を電気屋のパソコンで実行するのが第一歩だよ。

BASICはスタックを使ってるよ。
スタックがなければZ80のCALLステートメントすら動かないよ。

スタックを使う><スタックマシン

>>46
それはない。
この時代はC言語やK&L本が認知されるより前だよ。

>>47
いや
10 PRINT "baka ";
20 GOTO 10
でしょｗ

>>50
K&Rだよ
一般人使えるようになったのは、
BASICはFD装置が出る前だし、C言語はFD装置が必須だったな。

C#やJavaのコードは最終的にはスタックマシンの上で実行される。

>>53
仮想マシンなんだから最終という言い方は×

>>53
CLRもスタックマシンだったっけ？
違うと思ってたが。

>>47
おもわずわろた
それだ

あ、51な。w

デバガでおえばわかるけC# はすぐにネイティブコードになっちゃうぞ

美しいプログラミング言語には、マクロ、つまり実行前にプログラムを書き換える機能はあった方がいいのかな？
それとも、ない方がいいのかな？

>>58
すぐじゃないだろ。少なくとも実行後にしかネィティブコードはにならい。

>>60
実行前だろ

>>61
コンパイラはネイティブコードを吐いたりしない。
実行後にネイティブコードに変換されんだよ。

常識だぞこんなこと。

実行の意味が違う。また、その意味ではngenを使った場合を説明していない

>>63
ngen にしたってすぐじゃないだろ。
インストール時か最初の実行時であって、コンパイル時でないことは明白。

けど ngen の話になるんだ？
それもと「すぐに」というのは ngen 使うから「すぐに」と言いたかったのか。
ngen ってただのキャッシュだよ。根本的なこと勘違いしてんじゃね？

けど ngen の話になるんだ？
それもと「すぐに」というのは ngen 使うから「すぐに」と言いたかったのか。

→けどどうして ngen の話になるんだ？
→それとも「すぐに」というのは ngen 使うから「すぐに」と言いたかったのか。

>>59
必要、もしくは無いほうがいいと俺は思う。

トークンを置換するプリプロセッサマクロと、
構文木を変形するいわゆるLispのマクロは、一絡げにできないだろう

>>67
Lispとかもとから対象外だし

Lispのよさが理解できない人発見

初カキコだがweb に特化すれば php, perl, java は美しい。

それぞれの言語でサイト作った感想から言えば、
phpはどんな環境でもそれなりに動くという点で美しい。
それこそ月300円の鯖にでも納品できる。
スレ的な美しさとは違うだろうが、これも言語仕様による
美しさだと思うがな。

個人的に一番好きなのはPerlだったりするが。
力技が一番効く言語だと思うし。なんでもあり。

10年ROMってろ。

多分一生わからんのだろ

>>70
＞初カキコだがweb に特化すれば php, perl, java は美しい。
自分が使ったことのある言語を羅列してるだけだろ。
クライアントとサーバーサイドの違いを認識しているのかも怪しい。

春だから仕方ない

>>60-65
実行前
xxx.exe
return
実行後

実行前
xxx.exe
実行後
return

xxx.exe
実行前
実行後
return

xxx.exe
実行前
実行
return
実行後

一体どれのことを言ってるんだ

>>53 の「最終的にスタックマシンで実行される」に対して
実行時にはネイティブコードだよ出来なことを言ったつもりだった。
IL インタプリタなんかウォッチ式を評価するとき位しか使われないよね。

Haskellの勉強を始めたんだけど、遅延評価は美しいと思った。

>>76
純粋なILインタプリタかJITコンパイルするかはVMの実装の問題だからね

中間コード⇒ネイティブ
って最適化されてるん？
まさか中間コードを置き換えただけってことはないよね

http://msdn.microsoft.com/ja-jp/library/ht8ecch6(VS.80).aspx
MSIL (Microsoft Intermediate Language) は、実行する前に .NET Framework の Just-In-Time (JIT) コンパイラによってネイティブ コードに変換する必要があります。
ネイティブ コードは CPU 固有のコードで、JIT コンパイラと同じコンピュータ アーキテクチャ上で実行されます。
JIT コンパイルは、実行時に呼び出されることがないコードがあることを考慮しています。
つまり、ポータブル実行可能 (PE) ファイル内にあるすべての MSIL をネイディブ コードに変換するために時間とメモリを費やすのではなく、
実行時に必要になった MSIL を変換し、その結果生成されたネイティブ コードを保存して、以降の呼び出しで利用できるようにしておきます。

>>64
http://msdn.microsoft.com/ja-jp/library/ht8ecch6.aspx
ネイティブ イメージ ジェネレータ (Ngen.exe) を使用して、
JIT コンパイラと同様に MSIL アセンブリをネイティブ コードに変換します。

ただし、Ngen.exe の動作は、以下の 3 つの点で JIT コンパイラの動作と異なります。
・MSIL からネイティブ コードへの変換を、アプリケーション実行中ではなく、実行前に行います。
・メソッドを 1 つずつではなく、アセンブリ全体を一度にコンパイルします。
・生成したコードを、ディスク上のファイルとしてネイティブ イメージ キャッシュに保持します。

はじめからネイティブコンパイルすりゃいいのに

>>79
getter, setterをインライン展開するぐらいには最適化する。デバッガ上で実行すると最適化しないので、誤解をしている人もいるけど。

最近Haskellが美しく感じられてきた

いいことじゃないか

止まったね

ちんこも別の所で遊んでるしな

Haskellはflipとかポイントフリースタイルとかそういうのをやんなければ
かなり読みやすい部類だと思うぜ
簡潔なラムダとか関数適用演算子とかは他の言語にも欲しい

flip はまぁ分かるが、Haskell のポイントフリースタイルは
冗長な記述が省かれて読みやすくなる場合も結構あるぞ。

たとえば演算子をリフトアップで定義する場合。
instance (Num a) => Num (Hoge a) where
  (+) = liftA2 (+)

この場合 (+) x y = liftA2 (+) x y なんて冗長で、
こんな定義が何行も続くとかえって読みにくいだろ。

Scalaは？

Scala?ないない

Simplicityは必要条件だな。

>>91

友人がメッチャScalaプッシュしてくるんだけど、どう断れば良いか
分からん。（興味無いとか、ピンと来ないとか言ってはいるんだが）

ちなみにおいらはLisperで最近Haskellに手を染め始めたところ
友人はPerl使い。

なんかビシッと言う方法無い？

>>93
「俺、副作用が嫌いなんだよね」

「Javaな人とはお付き合いできません！」とか

>>93
Scalaって欲張り過ぎでしょ
二兎を追う者一兎も得ず

美しいプログラミング言語 ＝ 実用性がない
っていうと、みんな怒っちゃう？

ああ機械語は0と1だけで単純かつ美しいが実用性はないよな

"Everything should be made as simple as possible, but no simpler." -- Albert Einstein

>>97

Scalaは汚いってことか？

KISS

objective-Cが最強。

Macなんか使ってる時点で人生終了ｗ

いやいや、美しさを競うなら圧倒的に

mac >>>>>>>>>> windows

でしょ。

Windowsなんて比較対象に入らない
Linuxだよ

もしくは日本語ベーシック。

>>104
ハードとソフトの違いもわからない馬鹿ですね＾＾

>>103
ハードとソフトの違いもわからない馬鹿ですね＾＾

パイソンだろ。

>>109

ぱいそんなんて子供の玩具だろ？

ではPythonがほぼ標準で入ってるLinuxなんかも子供の玩具なのか〜

>>111

標準で入ってる　＝　子供の玩具

Pythonはちょっと複雑なことをさせると
途端に汚なくなる

どっちにしろ >>102 は池沼

美しさを競うなら圧倒的に

windows >>>>>>>>>> mac

でしょ。

Windowsってたくさんあるからね

１番美しいのは Haskell で結論出たんじゃないの？

これから 2番目に美しい言語を語ろうず　これはなかなか難しいぞな

ココでそれからWindowsとかMacとか言ってるヤツはな、全然面白くないから
死ね　な？　氏ねでも市ねでもなく　死ね　ＯＫ？

現状ではHaskellでFAに賛成

流行りものに弱いよねみんなｗ
Haskellの次って何だと思う？俺それが一番美しいと思う

次に来るのはHaskellにできないことができる言語だと思う

>>119
Curry. 関数論理型言語。Haskellと違って不完全情報の記述ができる。

>>119
実質、現存するまともな言語って、C++ぐらいだろ。
個人的にはOcamlが好き。

C++がまとも、ってのはどういう意味のまともなん?

規格化されてる。複数の実装が存在する。ユーザーの数。ライブラリ数。
書籍。プログラムの速度。この辺で、まとも。
まともでないのは、よく分からない、かつ、速度が遅くて、
メリットの不明な機能の作成に熱心な方々。

その基準だと、C++は FORTRAN、COBOL、C に負けているな。

項目によっては、Javaにも負けているかも。

数値計算、金融計算、OS、言語処理系、組み込み系で考えたら、
他の言語の方が特化しているのは確かだろうけど、
多方面で扱うこと考えたらC++じゃないか
OOPやテンプレートで簡潔に書ける場面は存在するし
純粋な何々指向は、その縛りでかえって複雑になったり、
後々で不純物が混じったり。
なら、初めから不純物含んだものの方が目的達成するのがはやそう
という、プログラムの組めない奴の妄想
メリットが不明なのは、boostのconceptとか、lambdaとかファンクタとか

スレタイの「美しさ」とは無関係な議論だな
もうスレタイ的な意味の議論は終了してしまったから他の話をやってるだけか

templateは俺は嫌い
総称型、ダックタイピング、コンパイル時計算、メタプログラミングと
少なくとも4種類の目的の異なる仕事を（汚く／無理やり）扱っているのが
好きになれない
そもそも本当に全てが必要か、という問題もあるわけだが

OOPのための言語としてもC++はあまり良くないよね
純粋じゃない、というのはさておき、GC無いのとオブジェクトが
自己記述的じゃないのがOOP言語として見るとちょっとな

最近にublasを知って、templateが好きになったんだが、たぶん、
すぐに嫌いになるかもしれない。普通に配列で書く方が速そうだし。
数値計算するのに、C++は不要だろうが視認性が良いんだ。
GCのある言語だと数値計算、やたら遅いイメージが拭えないし。
純粋なOOPに、どれだけメリットと恩恵があるのか疑問。
SmalltalkよりJavaが勝利したあたりで、それほど必要だとも思えない

>>129
Javaも純粋じゃないけど、GCとまともに使える例外があって
オブジェクトが自己記述的だから、C++よりはずっと自然にOOPしやすいでしょ
まあJavaはJavaで融通が利かないから俺は好きじゃないんだけどな

GCはプログラミングがルーズになるし制御できない部分が気持ち悪い
作ったものくらい自分で始末しろとｗ

>>124
速度に目を瞑ればJavaScriptが割といい線いってるな

ブラウザを除けばJavaScriptのユーザは０だけどな

>>122
OCamlはまともでないほうに入るんじゃないか？
ユーザ少ないし、速度も静的言語では遅いほうだろ

OCaml全然詳しくねーけど、チラ見した感じではなーんか微妙

関数型のくせにstringがmutableとか、意味不明なセンスの悪さをそこかしこに感じる
structural subtyping一見良さそうだけど、実行時情報ねーから
ダウンキャスト（風のこと）はできないっしょ？
"O"とかいいつつ、あれで下手にOOの真似事やろうとすると怪我すると思う

あとは、ありがちだけどライブラリが未成熟で、Unix系以外ではあんま使い物に
ならないっぽいよね

OCamlの良いところはな、OCamlかじってなんとも言えない気持ちの悪さ
を感じた時にHaskellかじると、なんだ関数プログラミング言語って実は
分かりやすいじゃんって思えるところﾅﾝﾃﾈ

一般的なプログラミング言語は計算能力において等価だから、
一昔前の言語で能力的には既に十分。

残された問題は、複雑なロジックをいかに簡潔に記述できるか、
それが他人にも理解されるかというだけ。
進歩の方向性はそれくらいしか考えられない。

>>136
これ正に俺だ
最初にHaskell触った時は全然理解できなかったけど
OCamlを触った後に再びHaskell触ったら割とすんなりなじむことができた
OCamlの表記法はなんともなじめなかったけど

言語進化とか言いながら、単に暗黙の前提仮定が増えただけだったりする。
ルールを知らないと読むこともできない。言語解説書バカ売れ。
制限は減ったのかもしれないけどな。

Haskel,lispが勝利したのは英語圏と米で流行ったからとか言ってみるテスト

>>140

おれHaskell好きだけど　勝利してんの？　マジで？

いつ流行ったんだよw

流行ったっていうか、関数型の中でもメジャーで市民権を得ているあたり

>>133
rhinoとかspidermonkey,seedなんてマイナーそうな実装あるけど
あれもブラウザでしか動かないのか？

>>139
グローバルスタンダードってそういうものでしょ。

遅レスだけど…

>>97
美しい物を美しいまま使いこなせるかどうかは人による

半年くらい前にここ覗いた時は何かJavaキチガイコテが連投してた気がするんだけど、
あいつは結局あの後どうなったん？

>>147
今はScalaにはまってる
ttp://pc11.2ch.net/test/read.cgi/prog/1262227165/

>>148
thx
超大雑把に流し読みしたが、誰かがガチで叩いたのかｗ
面白い流れを見逃したかもしれんなぁ

つーかよくあんなの真面目に叩く気になったもんだ、良くも悪くもすげーな
まぁこんなとこ見てる俺が言えた義理じゃねーけど

一番美しいと思うのはアセンブラとLISP

アセンブラなら CPUにもよるだろ

彼は特定のアセンブラ言語ではなく、アセンブラ言語の本質的な特性を好んでいるのだろう。
lispだって複数の言語の総称だ。

通訳無しにプロセッサと話せるのはアセンブラだけだしな
厳密には機械語だが、まぁ本質は同じだ

>>153が遠回しに>>152を否定しててわろた

間接的に>>150を否定してるんじゃないか？

アセンブラ=コンピュータの挙動を厳密にコントロールできる
機械語=バイナリ
という違いがある

>>154-155
別に否定してないぞ
アセンブラと機械語は違うけど、美しさで言えば同質と言っていいんじゃね

まあ Ook! と Whitespace は、美しさで言えば同質。

あの辺はみんな同じだな
まぁ見た目重視言語の一派だから、見た目の違いが大事になる可能性はあるが

×見た目重視
○見た目も重視する

つーかこれで置換すると俺がバカな文章書いたことがよく分かるな

アセンブラと言ってもmasm系とgas系では書式違う。
cpuやアーキテクチャによって使える命令違うから、アルゴリズムをスマートに書けるかどうかも変わってくる。
ノイマン型でなければ逐次実行もままならない。

だからアセンブラが共通して持つ本質的な美しさなんてありえない。

>>160
> コンピュータの挙動を厳密にコントロールできる

>>161
言語の美しさじゃない

このスレを見ると、何をもってして美しいと感じるか、それは人それぞれなんだぁと
つくづく思う、だが○○オメーはダメだ！



Ｑ．○○に当てはまるプログラミング言語を挙げなさい

>>161
できない。
命令を同時実行する仕組みのせいで機械語の実行順序が入れ替わることがある。

masmだろうがgasだろうが本質は一緒だろ
機械語とアセンブラが違うのかどうかの話の後にそんなことを言ってる時点で的外れ

全てのアセンブラに共通する点というのはある（同じ名前でくくられてるんだから当然）
その共通する点について美しいと思うなら、それはアセンブラを美しいと感じることに等しい

そりゃざっくりすぎるんじゃないか

>>164
ツッコミがいかにも浅いなぁ。CRISC以降は同時実行云々どころじゃねーだろｗ
どう言おうが、プロセッサが用意したI/Fを直接叩けるのはアセンブラだけだわな。
他の言語では「最適化」でも、アセンブラでは「クロックを削る」というような感覚に
近付く。それが美しいといえば美しいんじゃねーの。少なくとも共通して特異だ。

>>166
>>160のざっくりすぎる意見と同じパラダイムで返したからな

>>167
それは機械語が美しいんであって、アセンブラはそのおこぼれにあずかってるだけだよね。
大体、アセンブラとしての役割が何一つ評価されてないじゃん。

マクロアセンブラのマクロの力を知らぬな。そういう自分ももう忘れたが。

この"美しい"の意味を明確に定義しとく必要があるでしょ。ソースコードの見た目が美しい（他者が読みやすい）
のか、用途が美しい（曖昧だけど）のかどうなのか・・・・

ハード方向でＣを使ってレジスタ、アドレス演算ができるようになればＣがいいんじゃないｗ　破壊力は抜群。
同じプログラムを組むのでも、素人とプロが組むのでは実行速度も行数もまったく異なる、天と地の差を見せ付ける
ことができるのがＣ言語。そこに美しさを感じる僕ですｂ

コードが美しい、ってのはわかりやすいけど、言語が美しい、ってのはなあ。

分からん奴は参加しなくてよし

>>172
言語それぞれ、目指してる美しさが違うだろうね

それと同じで、プログラマの目指してる美しさもどれぞれ違う

それだけでしょ

最も美しい言語は Haskell と定義されている。

美しい言語鈴木を誰か作ればいい

>>176
鈴木と言う時点ですでに美しく無い

美しい言語鈴木「美しい言語だけにコンパイルされる権利を与える」

じゃあ俺インタプリタでいいや

どの言語も似たり寄ったりだからな
ifはどの言語でもifだし
インクルードやデファインも意味と書き方こそ違えどの言語も同じような記述法だし
書こうと思えばどの言語でも他のどんな言語の流儀でも書ける
それを踏まえても美しいと言い切れるには何を観点とすればいいのか

謎の仕様が少ないものは美しいといえるだろう。
言語の普及と発展、互換の足かせとともに、もともとあった美しさを穢していく。

Q なぜ謎を解かないのか
A その謎はけがれているから

>>180
言語設計者の思想とか哲学

Prologに言語設計者なんていたかな。

>>184
lispもそうだが、新しいパラダイムを研究する過程で提案された言語は、
ただの表記でしかない。
実用的な目的のために詳細にまで注意して設計されたものではない。
設計の改善は後の人たちの役割。

言語のセマンティクス＝パラダイムを議論するんだな
論文を読めばいい

その手の論文の探し方おしえて

自分で探せよ

ciniiしか知らんのだよ

最近の中間コード言語は美しくないね
namespaceやらclass階層の中にじかに関数定義書くもんだから
�@ネストが無駄に深くなる
�Anamespace,classの開き括弧、閉じ括弧の対応が追いにくい。それを防ぐためにネストを無駄に深くしなければならないので�@。
JAVAもそうだし、.NET系言語はこれから主流扱いになるらしいけど、先行きは暗い
こんな仕様は小さなコードなら良いだろうけど大きくなったら読みづらくなって仕方ない
大粒のライブラリ使えばコードは大きくならないだろうという見通しでしてるんだったら、たいていそういう予測は外れてるしね

>>190
あのさ、だからHaskellだのLispだのPrologだのの名前が挙がってるのが
このスレなわけで、何を今さら言ってるの？

$@&*のない綺麗なperlが欲しいと思っていたら、pikeがそうだった
流行らんかな。これ

Rob？

Lisp

Vala

>>192
Perl はシギルがあるからキレイなんじゃないか

CかC++で書かれててPythonがガチガチの静的型付けになったような言語が理想だ
型推論もいらない。高機能なIDEは必須。

>>197
Cython?

>>1
Python, Prolog, Grass

>>197
今売り出し中のNimrodはどうよ

>>197
いまどきの静的型付けの言語は似たようなものだが。

IDEなしで書ける直感的なメソッド体系の言語が理想だ
マニュアル片手に書くのはめんどい

>>202
メソッド体系？

IDEなしで書けるぐらいにメソッドが直感的に体系化された言語
ってことじゃね

メソッドって基本的にユーザが立てるもの
ではないのかな。組み込み的な意味なら、
無いに越したことはない。少なくとも美しさを
論じるなら。

>>205 標準APIかなんかの話じゃないの。

J

>>202
どういうこと？
IDEと連携取りやすい言語ならばむしろマニュアル片手にする必要ないぞ。リファレンスが内蔵されているようなものだからな。
チュートリアルは別途やればいい。


そもそも直感的なメソッド体系の言語というのが誰にとっての？というところがある。
C#はC系の言語利用者にとっても直感的ではなかったが、DelphiやVCLの利用者やJavaかじったことある人間にはむしろ直感的だった。

RubyはかつてはモダンではないPerl利用者には直感的だったかも知れないが、
今やRails以降のRubyやモダンPerlは双方ともバラバラ全くの別物。直感的でない。

しかも、これらも個人の感覚だ。
中学生にとっての直感的な言語も違うだろうし。

COBOLはそれをめざしたとか。
AppleScriptもそうかも。

>>1 実用的な言語の中で一番自由度が高いという意味で、 Prolog

>>208
少なくともhtonl();よりhost.to<NetworkLong>()の方が解りやすいだろ。
ライブラリの詳細な知識はいらんからな。

やっぱり綺麗となるとどうしてもLispだよ
(+ 5 10 20)は(+ . (5 . (10 . 20) ) )というデータ。
極一部の特殊シンボルを除いて全てデータだからな。
言語の機能とデータに殆ど壁が無くて、機能の拡張を
データの入力と捉えられる。

>>211
だからきれい？

半年近く前のレスにアンカーってどうなんだろうな
レス全部見る気がしないので適当に書くが、見方じゃね？
プログラマ側のインプットとしてはPython、Java、Lispで意見が分かれると思う
価値観としか言いようが無い
プログラマ側のアウトプットはLisp、Java、c#
Rubyが美しいと思う奴はこっちだと思うが、その感性は理解できん
CPU側というか、コンパイラ側というか…そっち側ではアセンブラ、Pascal、c
Haskellもこっちに入ると思うが、これまた理解が出来ん
慣れと覚えたては読みやすく書きやすいし、いつまでも平行線だろうな

俺が美しいと思うのはJava、Pythonだ

Javaはない。

俺はPythonが美しいとは思わないなあ
便利だけど、統一感が無くて

統一感は、ある方だと思うけど。Rubyに比べたら。
SchemeとかForthと比べたら無いけど。

確かに C++ よりは統一感あるかもねw

やっぱり S 式は美しいな

データとコードの形式が共通で、プログラムからプログラムを操作するのが容易だったり、
プログラムをデータとしてやり取りするのが容易だったりするのは素晴らしい

唯一（最大）の欠点は一般的なオブジェクト指向の記法と相性が悪い事なんだが...

ASTをそのまま書き下せる言語が良いな

(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

#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) )

プログラムはツリーである
故に、ツリーを華麗に扱える言語が最も美しい

>>222
全俺が納得

現在、一般浸透してる言語はツリーを軽視しすぎてる
ツリー構造で管理していないプログラムっていうのは

たとえば深度４から、深度5〜n　まで、参照可能にさせておきたい変数があっても

深度１の場所に名前がかぶらないように定義してるだけなんだよ

ネームスペースを使って　NAMESPACE::NAMESPACE::変数
と、してるだけ　砕いていっちゃえば　ネームスペースなんて、アンダーバーつかってかぶらない変数名かいてるのと同じようなもん
hensuu___henssuss__susususus__susus = 4　　　←　けっきょくせかいの平均はここから進歩してない
だから、深度1〜n全ての場所でその変数が普通の方法でも参照できてしまうため
そこまで気にする必要はないにしてもわずかに名前衝突は気をつけなくてはいけない
特に名前のかぶりそうな、Windowクラスとか、Mainクラスといったもののなまえしょうとつを起こす可能性を消せない

これをツリーで管理すると
深度４の場所で　Windowクラスを定義すれば
深度１〜３の場所では、どうやっても普通の方法ではWindowクラスまでたどり着けないので
名前衝突が完全に100%といっていいほどなくなる
君たちは全く名前衝突を意識せずにプログラミングできるプログラミングをプログラミングした事はあるかね？
心の清清しさが違う･････　すっげー適当な変数名でプログラミングしても大丈夫、むしろ名前なんて付けない
無名関数でプログラミングしていく、自分で根幹部分のほうに、名前を指定しなければランダムで名前をつけるようにしてしまう

でもツリーを効率的に扱う
そのための言語がないからね、ツリー操作に長けていて、なおかつドキュメント、ライブラリ、人気、見た目
そういうものを全部クリアした言語がまだでてきていない

お話しゅうりょ。

>>218
確かにメソッドの、特にチェインした場合は
かなり読みづらくなるなあ
そういえばClojureが多少マシになる解決策を出してなかったっけ？

X-BASIC
AppleScript

とりあえず美しいかどうかはさておいて
世界にとってプラスになりそうなのはD言語
最も複雑で最も概念数の多い言語が神

使えない？覚えれない？しらねーよｋｓ
そもそも人にプログラミングが扱えると思うなよ
言語構文など全て覚えることが実時間上、不可能であるくらいの超巨大な言語がほしい
C++とか、まだ全然余裕、小さい、仕様小さすぎワロタｗ

C++の20倍くらいの仕様の詰まった言語がこの世には必要

>>227
黙れよ出会い厨

w
uy ◆yyC0rYWEq2は巡回好きだな〜
ちなみに、この能無しだれ？

※　あぼーん推奨

ほんっと人の話をきけない奴ってゴミだよな
俺の説明の劣化を語ってる名無しに、こぞって興味持ってる流れを見てると微笑ましいよ

そういう奴らって、深層心理のどっかでuyを認めなくちゃならないんだよね
そうしないとuyの説明していることのすべてが否って事にしちゃうと
とんでもない重荷を背負って生きることになるんだよね
uyがいってるんだから違う、間違ってる、　なんて決め付けちゃうと

真実12121　=　嘘
真実2342　=　嘘
真実433243　=　嘘

こうやって、脳内の真実変数がどんどん　嘘　代入されてって、　まともな思考も出来なくなる
だからuyを認めたくない奴はｗ　俺が説明してる概念を、俺が書き込むよりも先に学習しとくか、透明削除してろって話

もう何人か精神病にさせてしまった気がするけど、プログラミングなんてやってんのが悪いわけだしね･･･　それは俺のせいじゃないし

俺のせいにされても困るからね

ここまでSNOBOLとJ言語なし

uy ◆yyC0rYWEq2

こいつ、精神病んでるから放置な

コテハン放置は常識
自己主張だか差別化、優越感だかわからんが、２chで求める時点でカス
無意味なコテハンはリアで寂しい奴、無能な奴と決まってる

まるでおまえたちは自分が精神病だとわかっていないみたいな
やっぱり自覚のないゴミだな

だまれ、さっさと精神病院に収容されろ。
どうせ、どっかの教員だろ

美しいのは Scheme か Smalltalk かな
SML も良い

よくわからないけど、美しいっていうのは、機能美のことなの？
ソースコードの見た目の綺麗さとかPiet的なものではなく？

よくわからないけど、基準を共通化してどうしたいの？

>>236
おまえみたいな奴のことだよ　ゴミって

Adaとか結構好きだったりするんだが
ちょっとおでぶさんだよなぁ…

>>238
俺がみるとあぼ〜んになってるレスへの疑問かもしれないが、
数学的な方面から見れば、表記ブレの発生しないコードじゃないか。

同じ種類のデータを並び替えるのに、処理箇所毎に全く違うとか一貫性が無いのは汚いと感じる。
できるだけ複数の処理を同じように書けるってのは重要だと想う。

例えば数学のラムダ演算では、全ての数が関数に統一され、全て関数の操作法で
そうさできる。数字と関数の間を行き来する必要がなくなった。これって綺麗だと思わないかい？

そういうのは確かに美しいが、だからといって例えば
チャーチ数で数値計算しろと言われても困るわけで、
実用性を伴う美しさが求められる

逆に言えば、汚れのないコードだよね。
ちょっとした違いの為にわざわざこんなこと書いてるなんてってのは醜い。

プログラムとは違うが、電波の周波数帯はキモイと想う。
ELF
SLF
ULF
VLF
LF
MF
HF
VHF
UHF
SHF
EHF
THz

Very High Frequencyとか汚すぎる名前だろ。K,M,G,Tとかみたいに
もっと一貫性のある名前にするか、Wave1、Wave2とかいつまでも増やせる名前にしろよっておもう。

そういや、WindowsのAPIも、
・EnumDateFormatsExEx
・ExtSelectClipRgn
・GetTextExtentExPoint
てな感じで一貫性がなくてキモイ。だったら2,3,4,5って数字にして欲しい。

しょうがないだろ。

元々火花送信機から始まって、真空管を使ってなんとかそれらしく電波を
飛ばせるようになった頃の LF MF HF という区別から始まって、あとから
あとから増やしていったものなんだから。

美しいって意味わかってなくね？
汚れのないコードなんていったら書き手の問題がでかくなるだろ
言語としての違いからくるもの以外は切り捨てろよ
「書かざるおえない」言語と「不必要」な言語、「こう書く」言語と「こう書ける」言語
似てるようでまるで違う
普通は自由度の高い言語は美しいと言えない
それを美しいと思うのは感性だから閉まっとけって思えるレベルでないとお話にならない
意味がわかってない人って多いよね

そういう俺はJavaだな

そこそこ実用的で美しい
・Python（ソースコードの見た目）
・Scheme（言語仕様の簡潔さ）

実用性度外視で美しい
・Lazy K（関数型言語部門）
・Brainfuck（手続き型部門）

Python は言語仕様が美しければな...

Pythonの言語仕様は好む言語から見るから賛否要論なんだと思う
素直に見ればよう出来てる
249のつっこみ所はLazy KとBrainfuckだろ
関数型言語はそもそも一貫性？が無いから美しいと言ってはいけないと思う
でもOCamlやLISP系は美しくないが見やすいのもわかる
Brainfuckは論外だろ

>>251
haskellは？

haskellは美しい玩具じゃなくて汚い実用言語というイメージ

>>248
Javaはプリミティブがオブジェクトじゃなかったり、
文字列に中途半端な演算子のオーバーライドがあったり汚れすぎだろ。

>>253
OCamlやF＃がその立ち位置だと思ってた

実用のための言語ならたいがい美しくないところはありそうなもんだなあ
性能とか便利さとか歴史的経緯とか、そういう理由で

Prologさんたらどこかに消えた♪ｗ

>>257
実用のための言語だから。

>>251
>素直に見ればよう出来てる

そう思うなら、もう一度見直した方が良いよ
普通にクロージャが作れないとか意味が分からん

>>259
クロージャは、いろいろ問題あるからいらん。

>>260
問題って具体的に何?
いろいろという事は複数あるんだよね?

Python 以外の殆どの LL では問題無くクロージャが使えてるんだけど?

実装上の問題。
気を付けないとわかりにくい。
ラムダ式でいい。

Pythonにもクロージャはあるだろ
まあlambdaの制限のことを言いたいのは分かるが

一応レキシカルだけど関数スコープで、2だと上位スコープの変数を素直に
書き換える手段が無いとか、その辺の話でもあるのかなと思った
3だと出来るけどnonlocal文って美しくは無いわな

>>262
『具体的に』

>>265
実装が大変、スコープがわかりにくいと言うのも具体的だと思うが。
ラムダ式がないなら、それでもメリットあるが、あるなら別に。

>>266
実装は別に大変じゃないよ
そこら中の LL が持ってる機能だからね
スコープで混乱している人も見掛けないし
Python の lambda みたいに中途半端な物を有り難がる必要も無い


結局、具体例は無しか
ソースコードの一つでも出て来るかと期待したのが間違いだったかな

まあ Python の場合は、インデントしないとブロックが作れないという妙な制約の所為で、
クロージャの構文を考えるのが面倒くさかったのかもな

やっぱコレぐらいの機能を持ってないとダメだろ
・文脈構造が黒髪ツーサドアップ
・関数リストの定義がミニスカニーソ
・インターフェースが童顔
・Foundationは薄化粧
・研究所で開発されてた頃のあだ名が猫

趣味が幼稚だよね。
ていうか汚らしい。
（倫理的に不潔という意味でなく文字通り細菌的に不衛生という意味）

>>267
要らないといっているのに、ソースコードを張れって意味フ。Python では、書けないコードを出して。
クロージャーは、巨大になってくるとGloal変数と同じ問題あり。Pythonは、うまく対処している。
実装は面倒。克服しているだけの話。妙な制限があるのもその都合。

>>271
>クロージャーは、巨大になってくるとGloal変数と同じ問題あり。
>実装は面倒。

だからさ、もっと具体的に書こうぜ。
Global 変数と同じ『どんな』問題があると思うの?
実装が面倒だったら、世の中にあまたある Lisp の処理系はどんな超絶技巧を使っているというの?

きちんと理由を書かないと話にならないぜ。

もちろん Lisp の所は Smalltalk と読み替えても良いし、JS でも良いし、他の LL でも良いよ。
クロージャなんて殆どどこにでもあるありふれた機能で、有って当たり前の物。

つーか、Pythonでも multi-statement lambda を実装しようと思えば出来た
Guidoが実装しないことを選んだだけ
http://www.artima.com/weblogs/viewpost.jsp?thread=147358

そのおかげで、残念な言語仕様になってしまったね

Zen of Python とか言いながら、メソッド定義に毎回 self を書かせる素敵仕様な
言語になっちゃうんだもんなあw

>>276
なぜ self を明示的に書くのか by Guido
http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

>>277
構文解析で関数定義とメソッド定義の場合分けするのが面倒だったからだろ

Python にクロージャが無いのはオフサイドルールの犠牲になったんだと思うわ。

クロージャはデータだから、引数の位置や代入分の右辺の位置でも定義可能にしないと
いけない訳だけど、Python ではそれらの位置にブロックを書かせる（＝インデントを
書かせる）のは都合が悪い。関数の 3 番目の引数からインデントが始まるコードなんて
誰も読みたくないからね。

インデントが強制されない、他の言語では何の問題も無い話だけどね。

クロージャに（lambdaに）文が書けないのは、だろうけど、
別にそこだけHaskellの { ; } みたいな構文を導入してもいいわけだし、
説得力ないと思うなぁ。

>>278
実装が面倒だったのではなく、インスタンスメソッドを特別扱いしたくなかっただけ
関数とメソッドを一貫性のある形で扱うことを選んだのと、
デコレータがある場合にselfの省略に問題があることが>>277で議論されてるだろ

>>279
ちゃんと>>274のリンク先を読んだ？従来の lambda と後方互換性がある形式で
multi-statement lambda へ拡張できる方法があると議論されてる

簡潔に言えば、理由は「Guidoの好み」だ

>>277
和訳 : なぜPythonのメソッド引数に明示的にselfと書くのか
http://coreblog.org/ats/translation-of-why-explicit-self-has-to-stay

まあ、俺もPythonが美しいとは思わないし、selfはともかく
multi-statement lambda は在った方が良いと思うけどさ
そうなってる理由が実装が面倒とかいう理由では無いと言いたい

>>281
でも、lambda についての議論の結果がこれでしょ

http://mail.python.org/pipermail/python-dev/2006-February/060654.html

括弧でブロックを表す事が受け入れられるなら、
最初からオフサイドルールの強制なんてしない訳で、
非現実的な提案なんじゃないかな?

Python 的に受け入れ可能な文法でクロージャを
組み入れるのは、無理な話だと思うよ

>>280
『そこだけ変えれば良い』というのが受け入れられる
文化じゃないでしょ

>>284
> オフサイドルール
これが最悪なんですよ.
手続き書き換えてて途中に判定分入った場合エディタまかせにできない

>>251
何を言っているんだろう？

Lazy Kの一貫性は完璧であり、その意味ではもっとも美しい言語だろう。
Lazy K以上に簡明で一貫した意味論、構文を持つ言語を考えるのは難しい。
それが分からないようじゃ、「関数型言語はそもそも一貫性？が無い」とは、何も分かっていないんだろうなとしか思えん。

> クロージャーは、巨大になってくるとGloal変数と同じ問題あり。

たぶん、LISPなどの非純粋型言語のクロージャを考えているんだろう。
たしかに、そういった言語のクロージャは、グローバル変数と同じというかCのスタティック変数と同じように、ライブラリ使用者から隠された変数によって関数の挙動が変わる、という問題がある。
しかし、じゃぁ、いかなる意味でもグローバルな識別子が存在しないか、あるいはグローバルな識別子を使用したどの関数呼び出しも、決して隠されたパラメータによって関数の挙動が変わることがない、ということが保障された言語なんでどれほどある？
(オレが思いつきかぎりでは、Lazy Kしか存在しない。)

クロージャよりも、クラスメソッドやクラス変数のほうが理解しやすい、混乱しにくいというのならそういう頭の人もいるだろうから、個人の好みの問題といしては否定はしない。
でも、それは好みの問題に過ぎない。

JavaScript はかなり美しいな

全てはオブジェクトだよ
全てはハッシュだよ

Smalltalk もかなり美しいな

全てはオブジェクトだよ
全てはメッセージだよ

Lisp もかなり美しい

全てはリストだよ
全てはラムダだよ

もちろん例外もあるので、異論は好きなだけどうぞ

ブログでやれ
そして、自分で言語（の仕様）を作れといいたい

美しいかどうかは置いといて、BASICからプログラミングへ入れたのは良い時代だったな

>>287
「現実の」「実践的な」JavaScriptのコードを見たうえで美しいとか言ってるの？
それとも言語の設計思想のことを言ってるの？
前者だとしたら、お前100年遅れてるわ

>>289
BASICから入ると一生プログラマになれない、と言われてた時代が懐かしいな。

>>290
>>287のレスの中身を見てそれが判別できないなら、100年進んでいても意味無いなw
ご苦労なこった

どう見ても判別できると思えませんが
ご苦労な脳味噌はおまえだろw

JavaScriptはvar宣言はあるけど関数スコープだったり
for〜inループやthisの扱いがちょっと好きじゃないな
同じ系統だとJavaScriptよりはLuaのほうがまだすっきりしてるように見える

>>294
JavaScriptのthisは動的スコープだからな。

動的スコープありやなしや、結構むずかしい問題。
オレは静的スコープ脳だけど、Lispとかで動的スコープを使ったトリックをみると、なるほどなーと思う。

毎回 var self = this; を書くのはあんまり美しくはないよね
クラスにあたる存在とメソッドにあたる存在の区別が付かないのに
その1行で何とかなっちゃうように出来てるのは凄いんだけど

>>293
君が判別できないだけ

面倒くさいから、下らない事で突っかかってくるなよ

>>294
>関数スコープ

lexical addressing が lambda 単位なのはスッキリしてていいと思うけど

>>298
個人的な好みの問題といわれるとそれまでだけど
ブロックスコープの代用として
(function(){})()
みたいなのが多用されるのを見ると、ちょっとな……
まあ他にもletとかwithとか色々あるみたいだが、
それなら最初からブロックスコープのほうがナンボかいいと俺は思う

>>299
JavaScript は Scheme と同じで、削ぎ落とした所が良いんだと思う

object で scope が代用できるなら object だけでいいし、
本質的には block scope は単なる syntax sugar でしょ

>>300
letがただのlambdaのsyntax sugarだとしても
Lisp族はマクロでletを作れるので、実用上の視点からは
Schemeとは一緒にできないような気がする
…んだけど、スレタイからするとあまり関係の無い視点のような気はしてきた

確かに言語の美しさとは関係が無いのかもしれない

>>301
そこは、JS にはマクロの様な構文を拡張する機能が無い、
だから let を（新たに）用意したって事なんじゃないかな

元々 block scope にしておけば良かったかというと、
それでは JavaScript らしくないんじゃないかなと思う

> 元々 block scope にしておけば良かったかというと、
> それでは JavaScript らしくないんじゃないかなと思う

これはとくにそうは思わない、かなあ
わりとJSに似たところの多いLuaはブロックスコープだし

だからそれは Lua なんでしょ

要は、「ブロックスコープでJSらしさが欠損する」理由が俺には見えないってことね
letを後から入れるぐらいなら、simplicityも絶対の理由ではない気がするし

うまくいえないけど
letにはPythonのnonlocalのような後付感、蛇足感がつきまとうっていうか……

>>305
元々、オブジェクトを唯一の道具立てとして言語を組み立てたのが JS で、
スコープというか環境フレームもオブジェクトで実装するのが自然だよね
というのが俺の理解

let は元々プラン外だったんだから蛇足に見えて当たり前

MIPS が美しいって言うよね
いつか試してみたいなあ

>>258
p :- p1, ... ,pn,fail.
p.

これは美しくない。

>>309
haskellより、やることが制限されて簡潔で
lispのようにS式まみれにならず、
容易にバックトラックやエキスパートシステムを実現できる
優れた言語じゃないか
演習でしか使ったことないけど

美しくない言語は幾らでも挙げられるけど、美しい言語となると難しいな

prologはプログラミングしてるってより、データベース作ってる気分になる。。。
haskellベースに論理型言語を足したcurry

もしくは、prologベースに関数型言語を足したmars辺りは美しいんかね？

関数スコープなのって、実装が簡単だからでしょ。
関数スコープで十分だとかって言うのは、酸っぱいブドウ。
ブロックスコープに越したことはない。

Lisp を勉強すれば分かる

手続き型はobjective-cが綺麗
cはオブジェクト指向が使えん。汎用的なコレクションライブラリがない
c＋＋は山ほどのドキュメントを読まないと怖くてSTLすら使えない。cとの中途半端な互換性
javaは命名規則が長い。オペレータをオーバーロードできない。プロパティがない。GUIが発展しない
c＃はネストが深い。ヘッダが読めん。ポインタ使い辛い

Objective-Cは、必要な機能がない。

>>315
GObjectつかえばCでも現代的なOOはできるぞ。

>>299
ブロックスコープ使うならwithが綺麗。
with({ a: 1, b: 0})
{
　　b = a++; //withで宣言したラベルを使う
}
//ここでaとb消滅

早とちりした。ごめん。なんでもない。

>>315
C++べつに使えるよ
自分が覚えにくい＆挙動が不審な部分は絶対に触らないようにしていけばいいだけ
複数人で組む場合は知らない。そもそもそれはC++に想定された使い方ではないと思う

あとobjective-cはゴミ
あんなゴミは見たことない


そういや神オブジェクトって奴いたなぁと思ってみにきたが
死んだのか？

大言はいてたわりにはあっさりと消えたな

見た目が綺麗なのはPythonかLispだろうな


ただ俺はRubyのソースコードのほうが自分の中で思考がまとめやすいってだけかな
キチガイに刃物ってこういうことだと思う

rubyはuyに持たせてはいけない刃物だったんじゃないかと最近思う
俺がかくrubyコードとネットにあがるrubyコードって質がまず違うよね、何故俺にはここまでrubyが使えるのだろう
Matzには本当に感謝をしている、rubyがなければ自分が何年間もかけて言語を作らなければならなくなった
俺が何年間もかけて言語を作っていたはずの、その時間で俺は別のことをやれる
とてもこれは感謝以外に何ものでもないよ

別なことって2chの書き込みかよ

ttp://twitter.com/akiradeveloper
奴ならここに

>>322
礼をいうべきか否か
リンクたどっていったら冗談きついくらいのヒゲ画像と本名が出てきて
さらにググったら京都大学スレでも晒されてるし涙でてきた

とりあえず、なんか技術者としては平凡以下に収まってしまったようだな
Rubyプログラミング関数型プログラミングって３年前も同じことを言ってるの見たわ
この３年間何やってた。。

少しは期待していたのに化ける事がなかった残念
やっぱりJAVAなんて使っているから･･･

>>321
誰へのレスかと思ったら俺へのレスか
俺が１日中2chしかやっていないと思っているのだろうか？
書き込み数はコテハンだから多く見えるだけ

神オブジェクトはでもRubyに興味持ち始めたんだったら、
まだ救う価値はある
どうせあの手のタイプはPython側に行くのはなんとなくわかるけどね
小手先の技術が必要になるようなCやperl等での
手続き型プログラミングのロジックや小さく圧縮されたショートコーディングのようなものは絶対かけないから
rubyはきっと向いていないだろう
自分でrubyはかけても他人のrubyコードが読めないとか前言ってたのは、おそらくそれのせい。
俺にとってはどんなrubyコードでも読みやすいけど
奴はPythonに収まるだろうな

【うゆ】uyスレ6【クソコテホイホイ】
http://kohada.2ch.net/test/read.cgi/prog/1316933376/

http://yutori.2ch.net/test/read.cgi/news4viptasu/1200955041/

ああ、大学楽しそうでいいな

学校でSchemeを勉強して以来Schemeが好きになった。
括弧の多さなんて気にならない。
見た目はそんなに美しいってわけでもないけど、
非常に書きよい、心地よい。

汚いのは英数字と記号だからね

文字のすべてが
・　―　|　　■　あたりで構成されていれば綺麗だよ

ここまでpiet無し

ランク付けは要らないが、各言語の「考え方」と「記法」を区別してスマートさの得失整理するのは有意義。

パールパイソンルビーには特色があって
開発者のやりたかったことも伝わってくるけど
PHPやJSにはそれがないんだ
主張のようなものを何も感じない
ただのなんのへんてつもない言語A、言語Bって感じ
あとC#にも主張がなにもないな
C++にはかなりある
javaには少しある


俺様にとってプログラミングは道具ではなく一般的じゃない変な方法を探し出しその上で効率よく目的を達成するゲームだから
言語に癖がないとさ
プレイする価値のないクソゲなんだよ

やはりPrologが美しい

誰も聞いてない

Prologは極めて美しくもなるし、醜悪に書くこともできる。
自在性のプログラム言語。

>>333 まぁ、分類としては概ね同意するよ。
perl/php/JS あたりは、そもそもが綺麗なプログラミング言語を作ろう、というのが主目的で作られたものじゃないから。JS はそれでもよくできているが。

c#は、javaとc++の失敗から学んで生まれた実践から出来た言語だよ。
jsとrubyも同じようなもの
perlとPHPがユーザーのニーズから後付で膨れて失敗したか、失敗しそうな言語
c++は、どっちかっていうとアカデミックな立ち位置から生まれ、
速度といった十字架を背負った唯一無二のソフトウェアを書くための言語

>>333
このスレで美しさの欠片もない言語をいくら並べてみても仕方ないだろう

美しいというのは基準が酷く漠然としているが
長いプログラマー経験から思う、一般的に美しい
プログラムと言われやすい書き方の特徴を挙げてみよう。
１．変数名、関数名が極端に長くならず、かつほぼ一定の長さで揃えられている
　おおむね8-10文字である事が多い。
２．変数名や関数名に大文字が使われることはなく、連続した単語の
　結合にはアンダーバーが使われる。
３．大部分の関数の定義は50行以下で、main関数のような中心的な
　処理のみ100行を少し超えるくらいである
４．間延びした印象になる空白行は避けられ、if分の開始ブレースは
ifキーワードと同じ行に書かれる
例：
if(user_id < 10){
以下の書き方は避けられる
if(user_id < 10)
{
５．カラム数が80桁を超えることは無い
６．インデントが揃っているのは当然であるか、字下げが3段以上深くなるようなことは無い。
　それを誇示するようにエディターのTABを8文字に設定する古参プログラマーも多い
７． 関数のヘッダー部分のコメントは一貫した書式で清書され
　SCCSで装飾されていることで格調が高くなる。

はっきり言えば、上記は古い環境の制限から仕方なくおこなわれてきた物が多く
現代の環境では全く推奨されるべき物では無い。しかし、経験の積んだエンジニアは
古い慣習を引きずっていることが多いし、それをお手本として学ぶ事になる場合が多い

まぁ、80桁超えないように書くのは今のモニタだとむしろ読みにくいかもしれんね。

オブジェクト指向言語は一体にゴツくて美しいとはいえない。
しかし、主流ではあるし、このクラスは独自に美しさを競うべきではないか。

lispは勝ち抜けとして考えると次点はpython
閉じ括弧はソースリーディング時にはいらないんだよ
でもコーディング時には必要

Haskellは数式だし、Prologは論理式。
姿は美しいが、実は、先にモデルがあって、記号を入れ替えただけ。
独創性は感じられない。

Scheme Prolog SmallTalk それに手続き型から Python でいいんじゃないか

美しいという定義が何なのかによる。
可読性なのか、コード量が少なさなのか、それは人それぞれだ。

C#は読みやすくて好きだけど、
WPFで使うラムダ演算子とか見ると、読みにくくてきたねーと思う。

PHPは標準関数の名前がグダグタで汚いと思うけど
シンプルに書けるところは綺麗だと思う。

C言語は好きなんだけど、標準じゃ文字列とか解放とか面倒で、色々ライブラリ入れるんだけど、
入れたライブラリを作った人のセンスがマチマチで、何というか関数名の統一の無さが気に入らない。

学術的な部分で強い言語と実用的な言語も分けた方がいいね

>>347
Prologは今日では学術的の方に分類されるだろうがカットは実用的な要請によって
使われて見苦しくなっている

>>348
Prologで美しくない部分って ! だけだろ。

>>349
書き方による

assert,retractでグローバル変数定義なんて糞だと思った
1年ぐらい演習と講義でオタクな準教授から教わったけれども、
現実世界のどこで使われてるのかがわからないし、使いこなすには1年の講義なんて時間は短すぎた。
はっきりいっておく。古典AIなら動的言語で実装した方がマシである。

そんなの調べりゃ５分でわかること
AIに関わらずそれ何も出来ないよ

assert,retractはグローバル変数ではなく、述語定義(デーベース定義)だし、
Prologは動的言語だ。それにPrologは4時間で使えるようになるよ。

>>353
(データベース定義)ねw
理解するには4時間で十分だが、典型的なプログラムのパターンを知らないと、
書けないね。

APL

>>350
一度全部リストの読み上げて、というようなことを許せる人にとっては、
十分に美しいよ。プログラムパターンもプログラム言語の中で最少だろうし。

>>356
リストに読み上げてとは、findallで節から引数のリストに変更することかな？
それともファイルからの入力を全て一度リストに取り込むこと？

>>357
両方

>>353
4時間で扱えるって、せいぜいサザエさん課題ぐらいの問題じゃないか
ビッグマウスもほどほどにしろよ。それともΣプロジェクトに加わった人？
大手って、これで自然言語処理だったり仕様記述してたりするのかしら

>>359
そんなこといってもPrologの講習会はほとんどが2+2の4時間だよ
教えることとしてはそれで十分 あとは受講者が工夫する

Prologは
オブジェクト、クラスはもちろん 型、ブロック、スコープ、マクロ、クロージャ、遅延評価、
グローバル変数、ローカル変数、議論の対象となる概念のほとんどと無縁
極論すれば、IF文もループもない 教えることなんてほとんどない
append/3が理解できたらおわり

関数型厨がλあればなんでもできるとかほざいてるのと一緒で
本当に意味がないんだよそれｗ

ようはどんな方法でもいいから0と1が表現できたらすべて表現可能

つまりですね

「変数宣言する。変数宣言しない」

01表現できてるよな
これですべてのプログラム組めるよ

こんなことはとっくにわかってんだから
今更珍しがる事とかなんにもないんだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>362
少なくとも先輩達が難しいこと言って勉強しなくてはならないということは起こらない

>>360
つかってないのに妄想で答えるなよ

Prologは単一化とバックトラックを再帰の枠の中で理解することが必要。
囲碁のルールよりは少し複雑というレベルの一人ゲームのようなもの。
初心者向きの課題を考えて少しずつ「強く」なっていく以外にない。

他言語の重要な構成要素のものでPrologにはないというものがあり、
例えば配列だが、これを用いているアルゴリズムはリストに置き換える
必要がある。そういう時のための情報は外部サイトにほとんどないから
これも自分で考える。
一般に最初から難しい課題が与えられる傾向にあり、これがPrologの
難しさの原因。初心者に初段の課題をやらせても実力向上にはならない。

>>365
囲碁にはどちらが勝つかつまりどうなったら勝負がつくかの難問がありPrologよりずっと難しい。

確かに勝ち負けは帰納的？

囲碁ソフトではルール化されているだろう。問題は人間がどれだけ終局のルールを教えられて
理解できるか。超再帰的直感で理解する人もいるだろうが、ほとんどの人は何回もやってみて
回りにいる人の助言を受けつつ理解していく。

Prologは確かに美しくも、醜悪にも書けますが、
美しく書くことも、醜悪に書くことも、どちらも楽しいですよ。そんなつもりで
書いてみることを勧めます。コードが長いか短いかとか、実行速度が速いか
遅いかなどどうでもよい言語です。書いたものから何か得られれば十分。

きめえ

MicrosoftとXamarinが業務提携！C#でiPhone/iPad/Androidのアプリ開発ができる！Mono大勝利！
http://engawa.2ch.net/test/read.cgi/poverty/1348536694/l50

オブジェクト指向のクラスではC#っていうのは美しい方に入るのかい？

C#, Javaは、実用的、安全（プログラマを守る）

守らない
30で使い捨てｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

Javaなんてドカタでも使えるように
わざわざ低能向けに設計されてるんだぜ
設計者の心が美しいよな

波括弧のブロックに慣れたら、Pythonなんかのインデントブロックには違和感を感じる。

PGを使い捨てると競合増えるから、今後は飼い殺しにする悪寒

オブジェクト指向クラスの言語で美しさの観点から上位3言語をあげてください

クラスベースオブジェクト指向？

>>379
いや、オブジェクト指向を取り込んだプログラム言語全体。クラスといっているのは
オブジェクト指向言語はどうしても構造体表現がゴツくてこのコンテストの対象言語に
なり難いから、これを最初から別クラスとして評価しようという意味。

いみふ(´・ω・｀)

マジで日本語がおかしいよそいつ。。。。

ほんとに終わってる業種だな

>>381
オブジェクト指向言語と非オブジェクト指向言語を分けて評価しようということだよ。

>>383
ズバリ言えばいいじゃないか。オブジェクト指向は醜いと。
見た目がだけどね。

うるさいしね

>>383
その提案はこのスレでは何度か出てきたと思うけど一度も実現していない

＞構造体表現がゴツくてこのコンテストの対象言語になり難いから
ゴツいの意味がわからんがね

冗長って意味だよ
OO厨はそれが最善だと思ってるのかね

http://toro.2ch.net/test/read.cgi/tech/1197720520/
ちんこの恥ずかしい過去スレ落ちた

SmalltalkやEiffelなんかのオブジェクト指向言語と
オブジェクト指向をめざした「オブジェクト指向指向言語」を
分けるほうが先じゃないか。

もっと一般化して、Lisp、Smalltalk、APL等々のようにスタイルの結晶化を実践した言語と、
COBOL、PL/1、Adaみたいに普通に機能の充実を目指した言語とをきちんと分けたほうが
よい気がする。前者は徹底の度合いで、後者も機能の取捨選択でその美しさを論じられる。

たとえばSmalltalkはメッセージングのＯＯを実践した言語だけど、クラス指向（抽象データ型）の
ＯＯに汚染されているし、徹底度合いとしてなら Io http://www.iolanguage.com/ のほうが
美しい、とかいうふうに。

>>391
>スタイルの結晶化を実践した言語
Prologのように天から舞い降りた言語もある

>>392
これっきり これっきり もうこれっきりですか

という仕様

>>392
文法の美しさに反して汚いことしないと、いろいろと実装できないことがわかる

俺様がC++で書いたコードが最も美しい。

>>394
よく知らないんだけど ! は最初の実装にはなかったのかな

>>396
伝説によると、カルメラウアはカナダのケベック州の研究所でqという
自然言語のトップダウン解析システムを自作し研究していた。
帰国と共にこれを持ち帰り使用しているうちに、引数評価の部分に
ユニフィケーションを加えれば、論理式がそのままプログラムとして
働く系を作ることができるのではないかということになり、案外簡単に
Prologが生まれた。
この話の雰囲気からは最初の実装ではカットにまで手を伸ばさなかった
のではないか。

オブジェクト指向言語の変数（プロパティ）のget setの羅列が汚い
C#なんかもう自動生成だし本末転倒
本来はこんなのいらないように書くべきなんだよね

publicなんか自動でプロパティになるべき

C#の自動プロパティはViewとコードの分離のためだし
全部をコードビハインドで書いてる人には価値が分からないだろうな

これは圧倒的に

Pascal

やはりCかな

アセンブラに一番近いくせに、アセンブラ臭を完全に消し去っている
表現に無駄がないのに、何でもできてしまう
コンピュータが現在の仕組みである以上考えられる、最も自然な表現だ

ただし残念ながら、標準ライブラリは醜い部類にすら入る
ここを補完する方法が何かないかな

>>402
C++。
Cのスーパーセットだから大体何でもできる。

C++の標準ライブラリは醜いだろ

Lispかな

Prolog
何にでも化けられる点は他の言語とは違う。軽くはないけど、自在。

そうか?
当時の PDP シリーズのインストラクションセットを,
んま仕様にして見ましたって, 雰囲気ありありなんだが… >初版 K&R

Cはポインタを引数に渡して出力値を受け取れる、というか
複数の出力を受け取る手段がそれしかないというのが美しくない

>>408
アセンブラの手法というか
かりに複数出力を受け取れたとしても、それは単なる糖衣構文というか

構造体使えよ

ごほ、ごほ、こ、構造体、じ、自体を、か、返すことはできぬ、ぽ、ポインタを返すことで、ごほ、ごほ、結果を受け取ることは、>>408 と、ごほ、お、同じ、ごほごほ、ごほ

>>411
何言ってんだ？ http://ideone.com/pAoOWy
値のコピーが発生するからあまりやらないってだけで、
別にポインタ返ししか出来ない訳じゃねえだろ

>>412
ご、ごほごほ、おぬし、K&R1、を、し、知らぬのか、ごほごほごほ

いまどきK&Rとか言ってる奴はCを語るな、この老害が
他言語はやれ「Ruby1.9なら」「Python3だと」「Java8は」とかやってるのに
C99やC11を無視してK&Rかよ

K&Rを知らぬものにCは語れぬ、ボーヤは帰って寝んねしな

まあUNIXが使いづらいのと同じ理由で、K&Rも使いづらかった
Linuxが出てきたのと同じように、Cも変な癖が取り除かれて今の姿になったって

>>415
リッチーもくたばったことだし、そろそろあんたも寝たきりの状態から
足洗ってあの世へ行ったらどうだいｗ

>>417
おいおい、C++11 の右辺値参照をしらないのか？K&R2 の構造体リターンこそ黒歴史なんだぜ

さすがに>>408みたいな書き方で標準化前のK&RのCを想定するやつはいないと思うけど
規格・標準化された言語の標準化前の大昔の仕様を取り出して「美しくない」とかいう
論評は意味不明もはなはだしいし

PrologにもISO標準規格があるけど、気に掛ける人はほとんどいない。

Prologでグローバル変数使っている人いますか？

>>421
使わないし、全くのナンセンス。
標準規格に加えるなんて話、どこから、なぜ出てきたのだろう。

このスレでLISPといった場合、処理系は何を思い浮かべるものですか？

>>423

今時は common lisp かな
「LISP 系」って、なると話は変わるだろうけど、
scheme はある意味、伝統的な lisp と袂を分かった言語なので
scheme 使ってる奴らは scheme って言うだろうし…

>>424
このスレに限っていえば、Schemeだろう。Common Lispは全然美しくないから。

TIOBE INDEX では、Common Lisp, Scheme の他に単にLISPというのがあって、
これは上位(15位前後)に入っている。Common Lisp,Schemeはずっと下位。
この言語は具体的な処理系というより、イメージで「語られる」ことが多い
ということだろう。

二番目に古い言語ですから

>>427
ALGOLとどちらを古いとするか微妙ですね。

最も美しいプログラミング言語は？ Perl6 に見えた。

>>429
このスレの判断基準はそのくらいユニークでありたい。

ttp://akiradeveloper.hatenadiary.com/
ちんこhaskellやってるな

古代エジプト文字でプログラムを書けたら面白そう。

ヒエログリフか

機械語

ハード設計者の渾身の作であり
もっと評価されるべき

ニモニックも使わないという話？

機械語はどのCPUも似たり寄ったりの癖に
微妙に違うのが美観を損ねている
統一規格できないもんかな

>>435
もち

>>436
デファクトならあるやん
俺はそんなことが言いたいんじゃないけど

>>436
任せとけ

>>436
そのために生まれたのがコンパイルの概念でしょ

>>439
少し違うみたい。

日本ではその昔、SIP という統一アセンブラみたいなものが作られたこともあったけどね。
後に続かなかったってことは無理があったんでしょう。

>>432
キリル文字とかギリシャ文字とかも面白そうだな

ハードの特長を使い切るのが機械語の使命なんだから
統一・共通化するのはそれに反する
あえてやろうすればＣの劣化版になるだけ

機械語にちょっと何か被せる程度だと
機械語レベルで直接操作できなくなるわ抽象化の恩恵がないわで、デメリットしかない
LLVMぐらいまでの水準まで上げないとダメだろうなあ

>>443
>あえてやろうすればＣの劣化版になるだけ

あえてやってみた

The C-- Language Specification

https://github.com/aistrate/Articles/blob/master/Haskell/The%20C--%20Language%20Specification%20(Ramsey,%20Peyton%20Jones,%20Lindig).pdf

スタックを叩きたい、とか、Cを言語処理系の中間言語として使うには、明確に弱い点があったから、
それを補強するというアプローチは普通にありえた。

キャリーフラグやゼロフラグを普通に扱えたらいいのにね、あとローテート命令をサポートしてほしかったね

インラインアセンブラとマクロを駆使すればライブラリの範囲で実現できるんじゃね

辛いなーそれ

最も美しいのはjavascriptだと思うんだけど

>>450
確かに美は乱調にあり、だな。

具体的には挙げないが、ドキュメント参照する頻度が少なくてすむ言語が一番いい

有能なPGに自然言語か
ハワードヒューズあたりが愛用しそうだな

ドキュメント参照する頻度が少ない＝機能が少ない

俺みたいな有能な人間がコードを書くとC++がいちばん美しく見える。

C++自体が美しくないから却下

眼鏡を掛ければC++も美しくなるということか。

めがねを取れば？じゃないの

メガネっ娘

>>459
かわいい男の娘ならなおよろし。

複雑な正規表現をあれほど書くなと言ったのに、てんこ盛りにしやがった・・・
あいつは俺に恨みでもあるのか？

IF　条件 THEN →　臭ぁ〜い！

書く方は楽で読む方に苦痛を強いる言語は美しくないよね

APLか？　書いた本人が自爆する・・・俺も自爆した

文字列処理を正規表現に頼っている言語は全部美しくない。

ねーよw

文字コードの世界が既に美しくないので
文字列を少しでも処理すると美しくなくなるよね

なんのためのオブジェクト指向だよ
全部 String オブジェクトに押し込めちゃえばいいんだよ

>>465
漢字覚えるのが面倒だから全部カタカナにしようぜってことだな

その側面からコメントするなら、
「漢字の読み書きをできない人が大量にいるのだけどどうしよう」ということだろう。

なにいってんのコイツ

正規表現読めません書けませんっていう「自称技術者」に対する揶揄じゃね？

>>470
素人は記号処理なんてやらないから別段構わないんじゃないか。

記号処理って正規表現と全く関係ない分野を指す用語なんだけど

プログラム内で正規表現を使うことは皆無だけど
それ以外の文書作業ではたまに使うな

>>474

チョムスキーあたりでは同一カテゴリじゃないか?

GUIのリソース込みならXAMLとポインタを多用したC#との組み合わせが美しい。

>>476
生成文法とか正直わけわかめ

>>476
確かに形式言語論で取り扱う言語は記号の並びだが、
だからといって記号処理とは言わんと思う

>>479
文字列は文字のリストにすると扱いやすいから、LISPなど記号処理言語向きだ。
正規表現の理論的な背景は有限オートマトンでこれは記号処理の世界。

オートマトンとか形式言語の分野を「記号処理」って言うんだっけ？

コンピュータの数値計算的な利用以外の領域を指す言葉だから、
離散系は一体に記号処理なんではないか。

文字列っぽいデータの処理はストリング処理、
Lispが得意とするのはリスト処理。

それらを使ってS式みたいなデータを切った貼ったして、数式みたいなデータを
表現して処理するのが記号処理。

記号処理は記号積分から発して、それでLISPが作られたのだから、
もっとずっと汎い概念だよ。長い間、記号処理=LISPだったんだから。

コンピュータの世界で記号と文字、文字列の区別なんてないだろう。
文字、文字列も当然記号。記号処理の対象となる。

諸氏の抽象化能力の差が見えてくるな。

諸氏の抽象化能力の差が見えてくるな。



だっておーwww ﾊﾞﾝﾊﾞﾝﾊﾞﾝ

> 記号処理は記号積分から発して、それでLISPが作られた

はつみみです

>>480
そもそも記号処理ってのが何から何までを指すのかは知らんけど、
DFAはある種の言語を認識するだけのものなので、
記号を操作していない気がするんだが

>>488
すなぎもとそり、それとお銚子もう一本頼んます

まだ美しい言語の話してるの？
それなら Clean

Bだろ
美

味

情報処理とは記号処理そのものでないの
数値だっておけらだって文字列だってみんなみんな記号なんだよ

普通「記号処理」って言葉が指す範囲、というものがあるから

シニフィアンとシニフィエ

androidだとおもう。
簡単にいろんなことできるもん

>>495
数値処理も見方を変えれば記号処理っていうのが、LISPやPROLOG

>>498
Prologは確かに組込述語isに数値演算を閉じ込めているが
LISPはどう考えたらよいのだろうか？

記号処理というか、チャーチ数とかを使えばなんだって同じ処理になるけど、
冗談言語か、純粋に研究目的以外で、そんな言語ないと思うぞ。

普通は、たとえば整数の計算は、コンピュータの加算命令にマッピングする。

ソースコードの 12345 という文字列も、見方を変えればただのワード、という
言語は Forth だけど（実行中に読み込みルーチンが認識する基数を変えられるので、
ソースコード中の同じ 12345 でも十進としても16進としても読ませることができる）。

整数の加算は、の間違い

>>498
X: 数値処理も見方を変えれば記号処理っていうのが、LISPやPROLOG
O: 数式処理は記号処理であるっていうのが、LISPやPROLOG

ここで言う数式処理というのは、因数分解や微分のように、
定理を適用して書き換えることで数式の簡略化を進める記号処理のこと。
FortranやCが主流な(一般には科学技術計算とよばれる)数値計算とはまったく異なる世界

そういう根本的な指摘をしちゃったら、ちまちま間違いを指摘する楽しみが無くなっちゃうじゃないw

数式処理が記号処理なのは当たり前だろ
数値もそうだというのが今の論点

>>502
> FortranやCが主流な(一般には科学技術計算とよばれる)数値計算
そんなこと言ったら MAXIMA とか mathematica とかの立場が…
チューニングすると大きな差ができるけど、そこらのアホの書いた
コードより早いわけだし…

どんな計算でもデジタルならANDとORとNOTの組み合わせで計算できるから、
それは論理演算だ、と主張しているようなもの。無意味で無理筋。

>>506
上の方の話は、3.14でも'3.14'で実は構わなくて、いちいち'3.14' -> 3.14と
変換してから計算するのでは堪らなく遅いから3.14を認めている、ということでは。
ただし、その計算部分は組込述語is/2に全て公理だとして押し込めた。

html/css/js/

このあたりだろな
本のデザイン的にも

乱雑さとロジックの難しさは比例しないよね
悩ましい

>>506
AND と NOT だけでOK

量子アルゴリズム持ちだされると状況は変わるが
今んとこ, 内部で走ってるのは, 実質的にに論理演算じゃないのか,
インタプリタとかコンパイラってのは???

だから, インタプリタとかコンパイラってのは
「与えられた命題をどうやって AND と NOT に翻訳するか?」
が仕事.

問題は, アルゴリズムの記述方法で
「その記述形式で, どれだけ何でも簡潔に記述できるか?」
だと思ぞ

論理演算で表現できるということと、実質とは違うでしょ。

>>510
NORだけでじゅうぶんNANDだけでじゅうぶん

> 「その記述形式で, どれだけ何でも簡潔に記述できるか?」

「簡潔」という俺様定義を使われても困る

>>513
「美しい」より、大分ましなのでは。

世の中にはPerlで無理やり短く書いて「簡潔」とか言ってるバカも多いからなぁ

コーディング中に「美しく書かなきゃ」と思わせてくれる点ではJavaだな
結局いくら言語自体がどうであれ、使用者達の空気感や
そういう部分で保守してくれないとあまり意味がない

ただし、美しさのセンスがぶっこわれてるので
冗長なメソッド名とか付けて悦に入ってる奴多し

>>516
そう思わせてくれる点を説明できないのなら、
あいまいな「美しさ」という評価基準と同じ

ただ「そう思わないとやってられない」のが
Javaだという点は、大いに同意したい

典型的な洗脳じゃん

>>518
＞そう思わせてくれる点

標準APIというお手本があることがでかい
ここから書き方を学んでいる人のコードは見ればわかるよね
「あっこいつ標準APIのソースすらみてないなオープンソースなのに」ってのが言語使用者間で共有できる
世知がらいけど、糞コードを糞コードだと皆で認定しやすいのがJava
で、結局美しいコードとはいかに糞コードを書かずに一歩一歩進むかどうかにかかっている、
ということにも気づきやすい言語

あくまで「美しいプログラミング言語」が、生きたソースコードで判断されるならの話

皆で認定の皆って誰だよ

そーゆー定量性を欠く議論（？）をするやつが出力するコードが
いったいどうやって糞でなくなりうるのか、隙のない論理構成を拝聴したいねえ

>>520
>標準APIというお手本があることがでかい

標準API(ライブラリ？)であれば、今時はどの言語にも用意されている
もちろんどの言語でもその言語の特性を活かしたお手本だ
従って、それがJavaの優位性であるという主張には根拠が無い

>..... 糞コードを糞コードだと皆で認定しやすい
>..... ということにも気づきやすい言語

これも同様に、なぜ認定しやすいのか、なぜ気付きやすいのかについて
JavaのXXXXという仕掛けがあるからとか、Java APIがOOOOだからのように
「技術的な(=客観的な)視点で説明」ができないのなら、
洗脳(>>519)と言われてもしかたないのではなかろうか？

ありとあらゆる書き方を追求して、そうしながら自分のスタイルを
見つけ出すのが、良いプログラミングスタイルだと思う。その結果として
美しいプログラミングも発見できるのではないかな。

プログラミングスタイルを考えるのは楽しい
しかし究極に美しい言語がシンプルすぎてスタイルが一通りしかなかったらつまらないと思わないか？
まあステップ数よりもよい評価単位が生まれるメリットがあるがプログラマーはサボることができなくなる

機械語が一番美しいだろ

機械語は美しくない
あれはとにかく動けばいいやくらいの勢いででっち上げたものだ
ハードの進化で洗練され極大値に収まってるだけ

全ての言語が機械語に逆らえないだろ

30年前にタイムスリップしたいなら行ってらっしゃーい

プログラミング言語における美しさは、読みやすさだと思うんだ。

Javaは無駄にコードが延びる部分を以外は、読みやすくて好き

jsはパッと見が嫌いだが、Javaに習ってる点で将来性がある
Javaから遠い言語ほど汚い

python はいいかんじだと思うんだが

python は self がウザい
せめて @ とか一文字にまとめられないか

Pyhtonはバランスのとれた優等生な手続き型スクリプト言語だと思うが、
1) 手続き型言語へ後付けでオブジェクト指向を中途半端に追加
2) 手続き型言語へ後付けで関数型を中途半端に追加
3) 中途半端なオフサイドルールである醜い行末の : (セミコロン)
を考えれば、「美しさ」の基準には当てはまらないと思う

実用言語として優秀とは言えるが....

流れとか全然無視してのアレだけど brain**** を初めて触ったときはなんか感動した

こういう醜いコードがtwitterに載っていた。
(defun chunker(list) (loop :for ptr :on list :by #'cddr :collect (list (car ptr) (cadr ptr))))

>>536
美しすぎる

Schemeな人には耐えられないだろうが、CLな人にとってループ使うのはなんの抵抗も無いしな。

Jこそがもっとも美しい。

([ , >:)@:((2&(~:/\)@:* , 0:) # i.@:#)@:(2&{@:|:) ({"1) 2 0&{@:|:

で、これはどんな処理をするコードなの？

喜怒哀楽の激しいコードだな

>>540
周波数-位相特性（をサンプルした配列）から位相0の周波数を推定する関数

だったと思う。

(:-@)

(;-@)ならJのコードなんだけどなw

(´-｀)

|spelling error
| (´-｀)
| ^

>>333
いやいや、phpの->と===はなかなか主張強いでっせ

PHPの === ってそんな主張のある仕様だっけ？

JavaScriptの == と === と同じで、== はあれこれ癖があるけど、=== は素直じゃなかったっけ？

>>548
他言語は==ですむところphpだと===まみれになるっていう意味ね

JavaScript が同じだし、単に慣れの問題じゃね？

文字列置換だとうまくないけど、トークンを認識するようなプリプロセッサで
== を全部 === に変えちゃうとかでも良いような、ごく表層レベルの話じゃん？

少なくとも美しくは無いわ

審美的なこと言ったら代入という、意味が数学と違う方が = で、
等号が == というCの仕様も美しくない。

みんな慣れちゃってるけどさ。

むしろ代入も等号も方程式も恒等式もみ〜んな '=' ですましている数学のほうがどうかと

>>553
使用する局面によって別の記号を使ってるし
原則, 数学の "=" 記号は代入ではなくて等値を示す記号だし

>>554
そう？微分方程式に現れる = って普通の方程式の = と違うのにしれっと混在してたりしない？≡に書きわけるなんてみたことないなあ‥
「Σのi=1から10まで」って、どう考えても代入だし

何を持って違うといってるんだ？

違いの分かる男
ダバダー

関係演算子の記号はそのままで
代入を分かり易くするとどんな記号？

int a <-- 10;

とか？

APLやSmalltalkとかの古い言語だと代入には ← を使ってる。
http://cdn-ak.f.st-hatena.com/images/fotolife/f/fxrobot/20131123/20131123083529.png
http://cdn-ak.f.st-hatena.com/images/fotolife/s/sumim/20060121/20060121123538.png

最近のSmalltalk処理系では日和って := になっちゃたけど。
http://smalltalk.cincom.jp/tutorials/primers/libraries/images/fileHandling09.gif
http://2.bp.blogspot.com/_wbkiNwEGJQo/TOqAoTKNd1I/AAAAAAAAAfE/TfOMfrktiBU/s1600/WS000007.JPG

Rだと -> や <-
=も使えるけど。

>>559
ひよっても何も Smalltalk の := って C の trigraph みたいなもんだろ?

>>556
x = 2 「であるのか」、x = 2 「にするのか」
あと f(x)=0 「である瞬間を捉えるのか」、f'(x)=0 「に常になっているとき」を考えるのか

変えたいいと思うな

束縛変数と自由変数の違い？

あるいはPASCALの(* *)みたいなもんだな。

つか代入構文letでの記号なんだから問題ない

箱モデルは良くないという点から考えると、

a → [1, 2, 3]

のほうが、a という変数が [1, 2, 3] というようなオブジェクトを指すようになりますよ、
という感じで良い。（という主張を見たことがある）

連想配列リテラルや、関数をあらわす型の記法と似てるのが弱点か。

>566
C言語の
　　int *pa = [1, 2, 3];
だね
ポインタ変数 pa へ配列インスタンスのアドレスを設定するイメージだから、
ポインタモデルとでも呼べばいいのかねぇ....

Cやアセンブリ言語の経験者ならばイメージしやすいから、
もしかすると好まれるかもしれない

むしろ低水準言語だけだよ、そんな風に明示的に書かなきゃ
なんないのは。高水準言語ではあたり前。

高水準言語では有名どころではPerlと、その影響を受けたごく一部の
変なのを別にすると、何らかの意図が無い限り、デリファレンスを
明示的に書かなければならない、なんて言語は無い。

あともう一つ。てか、書いてから気付いた。

C言語のその記法は、宣言時の変な一貫性のためにそうなってるだけで、
本文中で「*pa = 」としたら、その場合だと 1 が入ってる所に代入されちゃうんだから、
ちょっと違うかな？

代入より束縛のがエロいと思う

束縛より緊縛のがエロいと思う

緊縛より高融点、高融点より低融点のほうがエロいと思う

彼氏の部屋にすごいHがあった。死にたい。

H本に敗北して死ぬようじゃ３次元女も終わりだな。

彼氏の部屋に豪華な C/hocoがあった。死にたい。

最も美しいはC♯だな。ビジネスにはこれっきゃない！本格プログラマー言語C♯だけ！

そりゃヘルスたんだもの

linqって息してるの?

久々にジャンプを立ち読みしたら、トラブルが、すごい闇に包まれてた...

Clojureのコード見てからJavaのコード見ると発狂しそうになる

>>576
後始末他人任せの散らかし言語
足りないものは否定したはずのネイティブ言語から持ってくるような言語
は美しくない

イミフ

C#はCの汚いアナルに綺麗な膜をかぶせることに性交してるよ
汚いが美しいという見方もある

>>583
御説お下劣だが美しいね

一方 VC++ は、マネージドコードサポートのため一層汚く

今でも、そう思うの？

FL

>>1-1000 以外の言語

588 `elem` [1 .. 1000]