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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2010/03/23(火) 16:44:08
最も美しいプログラミング言語を語れ

前スレ
http://pc12.2ch.net/test/read.cgi/tech/1262707694/
2011/06/04(土) 15:43:02.98
>>211
だからきれい？
2011/06/19(日) 07:58:22.97
半年近く前のレスにアンカーってどうなんだろうな
レス全部見る気がしないので適当に書くが、見方じゃね？
プログラマ側のインプットとしてはPython、Java、Lispで意見が分かれると思う
価値観としか言いようが無い
プログラマ側のアウトプットはLisp、Java、c#
Rubyが美しいと思う奴はこっちだと思うが、その感性は理解できん
CPU側というか、コンパイラ側というか…そっち側ではアセンブラ、Pascal、c
Haskellもこっちに入ると思うが、これまた理解が出来ん
慣れと覚えたては読みやすく書きやすいし、いつまでも平行線だろうな

俺が美しいと思うのはJava、Pythonだ
2011/06/19(日) 09:04:22.15
Javaはない。
2011/06/19(日) 11:37:46.14
俺はPythonが美しいとは思わないなあ
便利だけど、統一感が無くて
2011/06/19(日) 12:12:37.66
統一感は、ある方だと思うけど。Rubyに比べたら。
SchemeとかForthと比べたら無いけど。
2011/06/19(日) 12:16:04.43
確かに C++ よりは統一感あるかもねw
2011/06/20(月) 01:02:19.16
やっぱり S 式は美しいな

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

唯一（最大）の欠点は一般的なオブジェクト指向の記法と相性が悪い事なんだが...
219デフォルトの名無しさん
垢版 |
2011/06/20(月) 01:27:53.30
ASTをそのまま書き下せる言語が良いな
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
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) )
222デフォルトの名無しさん
垢版 |
2011/06/20(月) 02:32:44.26
プログラムはツリーである
故に、ツリーを華麗に扱える言語が最も美しい
2011/06/20(月) 02:34:16.67
>>222
全俺が納得
2011/06/20(月) 03:32:46.69
現在、一般浸透してる言語はツリーを軽視しすぎてる
ツリー構造で管理していないプログラムっていうのは

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

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

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

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

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

お話しゅうりょ。
2011/06/20(月) 10:28:58.30
>>218
確かにメソッドの、特にチェインした場合は
かなり読みづらくなるなあ
そういえばClojureが多少マシになる解決策を出してなかったっけ？
226デフォルトの名無しさん
垢版 |
2011/06/20(月) 21:17:19.85
X-BASIC
AppleScript
2011/06/21(火) 15:27:07.66
とりあえず美しいかどうかはさておいて
世界にとってプラスになりそうなのはD言語
最も複雑で最も概念数の多い言語が神

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

C++の20倍くらいの仕様の詰まった言語がこの世には必要
2011/06/21(火) 18:04:29.00
>>227
黙れよ出会い厨
2011/06/21(火) 18:55:43.39
w
uy ◆yyC0rYWEq2は巡回好きだな〜
ちなみに、この能無しだれ？
230uy
垢版 |
2011/06/24(金) 00:34:30.93
※　あぼーん推奨
2011/06/25(土) 07:25:42.29
ほんっと人の話をきけない奴ってゴミだよな
俺の説明の劣化を語ってる名無しに、こぞって興味持ってる流れを見てると微笑ましいよ

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

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

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

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

俺のせいにされても困るからね
2011/06/29(水) 13:21:37.69
ここまでSNOBOLとJ言語なし
233デフォルトの名無しさん
垢版 |
2011/07/02(土) 23:53:43.83
uy ◆yyC0rYWEq2

こいつ、精神病んでるから放置な
2011/07/03(日) 13:23:04.73
コテハン放置は常識
自己主張だか差別化、優越感だかわからんが、２chで求める時点でカス
無意味なコテハンはリアで寂しい奴、無能な奴と決まってる
2011/07/03(日) 16:01:01.89
まるでおまえたちは自分が精神病だとわかっていないみたいな
やっぱり自覚のないゴミだな
236デフォルトの名無しさん
垢版 |
2011/07/03(日) 16:53:06.69
だまれ、さっさと精神病院に収容されろ。
どうせ、どっかの教員だろ
2011/07/03(日) 17:16:32.40
美しいのは Scheme か Smalltalk かな
SML も良い
2011/07/03(日) 17:33:04.39
よくわからないけど、美しいっていうのは、機能美のことなの？
ソースコードの見た目の綺麗さとかPiet的なものではなく？
2011/07/03(日) 17:34:36.42
よくわからないけど、基準を共通化してどうしたいの？
2011/07/03(日) 17:52:41.56
>>236
おまえみたいな奴のことだよ　ゴミって
2011/07/03(日) 18:10:37.48
Adaとか結構好きだったりするんだが
ちょっとおでぶさんだよなぁ…
2011/07/03(日) 19:30:11.32
>>238
俺がみるとあぼ〜んになってるレスへの疑問かもしれないが、
数学的な方面から見れば、表記ブレの発生しないコードじゃないか。

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

例えば数学のラムダ演算では、全ての数が関数に統一され、全て関数の操作法で
そうさできる。数字と関数の間を行き来する必要がなくなった。これって綺麗だと思わないかい？
2011/07/03(日) 20:05:56.09
そういうのは確かに美しいが、だからといって例えば
チャーチ数で数値計算しろと言われても困るわけで、
実用性を伴う美しさが求められる
2011/07/03(日) 20:33:43.99
逆に言えば、汚れのないコードだよね。
ちょっとした違いの為にわざわざこんなこと書いてるなんてってのは醜い。
2011/07/03(日) 20:45:34.28
プログラムとは違うが、電波の周波数帯はキモイと想う。
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って数字にして欲しい。
2011/07/03(日) 20:54:13.90
しょうがないだろ。

元々火花送信機から始まって、真空管を使ってなんとかそれらしく電波を
飛ばせるようになった頃の LF MF HF という区別から始まって、あとから
あとから増やしていったものなんだから。
2011/07/04(月) 19:10:16.02
美しいって意味わかってなくね？
汚れのないコードなんていったら書き手の問題がでかくなるだろ
言語としての違いからくるもの以外は切り捨てろよ
「書かざるおえない」言語と「不必要」な言語、「こう書く」言語と「こう書ける」言語
似てるようでまるで違う
普通は自由度の高い言語は美しいと言えない
それを美しいと思うのは感性だから閉まっとけって思えるレベルでないとお話にならない
意味がわかってない人って多いよね
2011/07/04(月) 19:11:45.58
そういう俺はJavaだな
2011/07/04(月) 19:33:04.73
そこそこ実用的で美しい
・Python（ソースコードの見た目）
・Scheme（言語仕様の簡潔さ）

実用性度外視で美しい
・Lazy K（関数型言語部門）
・Brainfuck（手続き型部門）
2011/07/04(月) 19:45:46.77
Python は言語仕様が美しければな...
2011/07/05(火) 00:37:28.00
Pythonの言語仕様は好む言語から見るから賛否要論なんだと思う
素直に見ればよう出来てる
249のつっこみ所はLazy KとBrainfuckだろ
関数型言語はそもそも一貫性？が無いから美しいと言ってはいけないと思う
でもOCamlやLISP系は美しくないが見やすいのもわかる
Brainfuckは論外だろ
2011/07/05(火) 01:02:24.60
>>251
haskellは？
2011/07/05(火) 01:23:10.19
haskellは美しい玩具じゃなくて汚い実用言語というイメージ
2011/07/05(火) 01:40:40.17
>>248
Javaはプリミティブがオブジェクトじゃなかったり、
文字列に中途半端な演算子のオーバーライドがあったり汚れすぎだろ。
2011/07/05(火) 01:45:47.21
>>253
OCamlやF＃がその立ち位置だと思ってた
2011/07/05(火) 01:47:16.27
実用のための言語ならたいがい美しくないところはありそうなもんだなあ
性能とか便利さとか歴史的経緯とか、そういう理由で
2011/07/05(火) 02:10:53.67
Prologさんたらどこかに消えた♪ｗ
2011/07/05(火) 02:26:22.65
>>257
実用のための言語だから。
2011/07/05(火) 03:58:18.11
>>251
>素直に見ればよう出来てる

そう思うなら、もう一度見直した方が良いよ
普通にクロージャが作れないとか意味が分からん
2011/07/05(火) 07:05:41.18
>>259
クロージャは、いろいろ問題あるからいらん。
2011/07/05(火) 10:10:17.07
>>260
問題って具体的に何?
いろいろという事は複数あるんだよね?

Python 以外の殆どの LL では問題無くクロージャが使えてるんだけど?
2011/07/05(火) 11:04:05.05
実装上の問題。
気を付けないとわかりにくい。
ラムダ式でいい。
2011/07/05(火) 11:18:16.11
Pythonにもクロージャはあるだろ
まあlambdaの制限のことを言いたいのは分かるが
2011/07/05(火) 11:22:02.71
一応レキシカルだけど関数スコープで、2だと上位スコープの変数を素直に
書き換える手段が無いとか、その辺の話でもあるのかなと思った
3だと出来るけどnonlocal文って美しくは無いわな

2011/07/05(火) 20:39:24.65
>>262
『具体的に』
2011/07/06(水) 12:23:37.30
>>265
実装が大変、スコープがわかりにくいと言うのも具体的だと思うが。
ラムダ式がないなら、それでもメリットあるが、あるなら別に。
2011/07/06(水) 20:14:58.09
>>266
実装は別に大変じゃないよ
そこら中の LL が持ってる機能だからね
スコープで混乱している人も見掛けないし
Python の lambda みたいに中途半端な物を有り難がる必要も無い


結局、具体例は無しか
ソースコードの一つでも出て来るかと期待したのが間違いだったかな
2011/07/06(水) 20:27:12.23
まあ Python の場合は、インデントしないとブロックが作れないという妙な制約の所為で、
クロージャの構文を考えるのが面倒くさかったのかもな
269デフォルトの名無しさん
垢版 |
2011/07/06(水) 22:26:09.36
やっぱコレぐらいの機能を持ってないとダメだろ
・文脈構造が黒髪ツーサドアップ
・関数リストの定義がミニスカニーソ
・インターフェースが童顔
・Foundationは薄化粧
・研究所で開発されてた頃のあだ名が猫
2011/07/06(水) 22:32:26.74
趣味が幼稚だよね。
ていうか汚らしい。
（倫理的に不潔という意味でなく文字通り細菌的に不衛生という意味）
2011/07/07(木) 04:49:25.74
>>267
要らないといっているのに、ソースコードを張れって意味フ。Python では、書けないコードを出して。
クロージャーは、巨大になってくるとGloal変数と同じ問題あり。Pythonは、うまく対処している。
実装は面倒。克服しているだけの話。妙な制限があるのもその都合。
2011/07/07(木) 09:18:55.25
>>271
>クロージャーは、巨大になってくるとGloal変数と同じ問題あり。
>実装は面倒。

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

きちんと理由を書かないと話にならないぜ。
2011/07/07(木) 09:27:35.16
もちろん Lisp の所は Smalltalk と読み替えても良いし、JS でも良いし、他の LL でも良いよ。
クロージャなんて殆どどこにでもあるありふれた機能で、有って当たり前の物。
2011/07/07(木) 09:29:07.18
つーか、Pythonでも multi-statement lambda を実装しようと思えば出来た
Guidoが実装しないことを選んだだけ
http://www.artima.com/weblogs/viewpost.jsp?thread=147358
2011/07/07(木) 09:35:19.72
そのおかげで、残念な言語仕様になってしまったね
2011/07/07(木) 09:37:20.77
Zen of Python とか言いながら、メソッド定義に毎回 self を書かせる素敵仕様な
言語になっちゃうんだもんなあw
2011/07/07(木) 09:45:02.01
>>276
なぜ self を明示的に書くのか by Guido
http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html
2011/07/07(木) 10:25:29.64
>>277
構文解析で関数定義とメソッド定義の場合分けするのが面倒だったからだろ
2011/07/07(木) 10:33:10.77
Python にクロージャが無いのはオフサイドルールの犠牲になったんだと思うわ。

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

インデントが強制されない、他の言語では何の問題も無い話だけどね。
2011/07/07(木) 10:58:47.18
クロージャに（lambdaに）文が書けないのは、だろうけど、
別にそこだけHaskellの { ; } みたいな構文を導入してもいいわけだし、
説得力ないと思うなぁ。
2011/07/07(木) 11:36:45.19
>>278
実装が面倒だったのではなく、インスタンスメソッドを特別扱いしたくなかっただけ
関数とメソッドを一貫性のある形で扱うことを選んだのと、
デコレータがある場合にselfの省略に問題があることが>>277で議論されてるだろ

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

簡潔に言えば、理由は「Guidoの好み」だ
2011/07/07(木) 11:50:22.11
>>277
和訳 : なぜPythonのメソッド引数に明示的にselfと書くのか
http://coreblog.org/ats/translation-of-why-explicit-self-has-to-stay
2011/07/07(木) 11:56:01.88
まあ、俺もPythonが美しいとは思わないし、selfはともかく
multi-statement lambda は在った方が良いと思うけどさ
そうなってる理由が実装が面倒とかいう理由では無いと言いたい
2011/07/07(木) 21:28:21.12
>>281
でも、lambda についての議論の結果がこれでしょ

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

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

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

>>280
『そこだけ変えれば良い』というのが受け入れられる
文化じゃないでしょ
2011/07/07(木) 22:12:51.14
>>284
> オフサイドルール
これが最悪なんですよ.
手続き書き換えてて途中に判定分入った場合エディタまかせにできない
2011/07/08(金) 01:27:40.15
>>251
何を言っているんだろう？

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

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

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

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

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

Smalltalk もかなり美しいな

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

Lisp もかなり美しい

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

もちろん例外もあるので、異論は好きなだけどうぞ
2011/07/08(金) 01:53:37.92
ブログでやれ
そして、自分で言語（の仕様）を作れといいたい
289デフォルトの名無しさん
垢版 |
2011/07/08(金) 02:10:48.84
美しいかどうかは置いといて、BASICからプログラミングへ入れたのは良い時代だったな
2011/07/08(金) 04:30:17.92
>>287
「現実の」「実践的な」JavaScriptのコードを見たうえで美しいとか言ってるの？
それとも言語の設計思想のことを言ってるの？
前者だとしたら、お前100年遅れてるわ
2011/07/08(金) 04:54:16.62
>>289
BASICから入ると一生プログラマになれない、と言われてた時代が懐かしいな。
2011/07/08(金) 08:11:15.56
>>290
>>287のレスの中身を見てそれが判別できないなら、100年進んでいても意味無いなw
ご苦労なこった
2011/07/08(金) 08:20:27.82
どう見ても判別できると思えませんが
ご苦労な脳味噌はおまえだろw
2011/07/08(金) 09:33:19.56
JavaScriptはvar宣言はあるけど関数スコープだったり
for〜inループやthisの扱いがちょっと好きじゃないな
同じ系統だとJavaScriptよりはLuaのほうがまだすっきりしてるように見える
2011/07/08(金) 17:11:34.93
>>294
JavaScriptのthisは動的スコープだからな。

動的スコープありやなしや、結構むずかしい問題。
オレは静的スコープ脳だけど、Lispとかで動的スコープを使ったトリックをみると、なるほどなーと思う。
2011/07/08(金) 18:20:34.10
毎回 var self = this; を書くのはあんまり美しくはないよね
クラスにあたる存在とメソッドにあたる存在の区別が付かないのに
その1行で何とかなっちゃうように出来てるのは凄いんだけど
2011/07/08(金) 19:10:43.94
>>293
君が判別できないだけ

面倒くさいから、下らない事で突っかかってくるなよ
2011/07/08(金) 19:16:50.69
>>294
>関数スコープ

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

2011/07/08(金) 20:02:37.23
>>299
JavaScript は Scheme と同じで、削ぎ落とした所が良いんだと思う

object で scope が代用できるなら object だけでいいし、
本質的には block scope は単なる syntax sugar でしょ
2011/07/08(金) 20:07:39.36
>>300
letがただのlambdaのsyntax sugarだとしても
Lisp族はマクロでletを作れるので、実用上の視点からは
Schemeとは一緒にできないような気がする
…んだけど、スレタイからするとあまり関係の無い視点のような気はしてきた

確かに言語の美しさとは関係が無いのかもしれない
2011/07/08(金) 20:16:12.17
>>301
そこは、JS にはマクロの様な構文を拡張する機能が無い、
だから let を（新たに）用意したって事なんじゃないかな

元々 block scope にしておけば良かったかというと、
それでは JavaScript らしくないんじゃないかなと思う
2011/07/08(金) 20:22:04.65
> 元々 block scope にしておけば良かったかというと、
> それでは JavaScript らしくないんじゃないかなと思う

これはとくにそうは思わない、かなあ
わりとJSに似たところの多いLuaはブロックスコープだし
2011/07/08(金) 20:28:31.01
だからそれは Lua なんでしょ
2011/07/08(金) 20:32:28.63
要は、「ブロックスコープでJSらしさが欠損する」理由が俺には見えないってことね
letを後から入れるぐらいなら、simplicityも絶対の理由ではない気がするし
2011/07/08(金) 20:34:05.12
うまくいえないけど
letにはPythonのnonlocalのような後付感、蛇足感がつきまとうっていうか……
2011/07/08(金) 20:39:51.02
>>305
元々、オブジェクトを唯一の道具立てとして言語を組み立てたのが JS で、
スコープというか環境フレームもオブジェクトで実装するのが自然だよね
というのが俺の理解

let は元々プラン外だったんだから蛇足に見えて当たり前
308デフォルトの名無しさん
垢版 |
2011/07/10(日) 04:44:23.75
MIPS が美しいって言うよね
いつか試してみたいなあ
2011/07/10(日) 06:54:00.80
>>258
p :- p1, ... ,pn,fail.
p.

これは美しくない。
2011/07/10(日) 13:57:23.65
>>309
haskellより、やることが制限されて簡潔で
lispのようにS式まみれにならず、
容易にバックトラックやエキスパートシステムを実現できる
優れた言語じゃないか
演習でしか使ったことないけど
311デフォルトの名無しさん
垢版 |
2011/07/16(土) 22:35:02.38
美しくない言語は幾らでも挙げられるけど、美しい言語となると難しいな
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況