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

[1 デフォルトの名無しさん 2010/03/23(火) 16:44:08]

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

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

[430 デフォルトの名無しさん 2013/03/06(水) 04:39:28.65]

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

[431 デフォルトの名無しさん 2013/04/04(木) 15:15:53.33]

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

[432 デフォルトの名無しさん 2013/04/18(木) 20:12:14.48]

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

[433 デフォルトの名無しさん 2013/04/19(金) 18:17:51.41]

ヒエログリフか

[434 デフォルトの名無しさん 2013/06/14(金) 18:26:58.45]

機械語

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

[435 デフォルトの名無しさん 2013/06/15(土) 07:15:10.84]

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

[436 デフォルトの名無しさん 2013/06/15(土) 08:25:29.33]

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

[437 デフォルトの名無しさん 2013/06/15(土) 10:35:31.93]

>>435
もち

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

[438 デニス・リッチー 2013/06/15(土) 23:23:39.72]

>>436
任せとけ

[439 デフォルトの名無しさん 2013/06/17(月) 08:18:40.68]

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

[440 デフォルトの名無しさん 2013/06/17(月) 09:28:46.85]

>>439
少し違うみたい。

[441 デフォルトの名無しさん 2013/06/17(月) 11:57:39.68]

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

[442 デフォルトの名無しさん 2013/06/17(月) 12:09:31.93]

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

[443 デフォルトの名無しさん 2013/06/17(月) 12:16:52.96]

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

[444 デフォルトの名無しさん 2013/06/17(月) 17:19:47.23]

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

[445 デフォルトの名無しさん 2013/06/17(月) 19:10:08.24]

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

あえてやってみた

The C-- Language Specification

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

[446 デフォルトの名無しさん 2013/06/17(月) 20:30:27.49]

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

[447 デフォルトの名無しさん 2013/06/18(火) 22:03:33.51]

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

[448 デフォルトの名無しさん 2013/06/19(水) 02:00:23.50]

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

[449 デフォルトの名無しさん 2013/06/19(水) 02:01:13.02]

辛いなーそれ

[450 デフォルトの名無しさん 2013/06/21(金) 10:31:44.70]

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

[451 デフォルトの名無しさん 2013/06/21(金) 11:19:39.99]

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

[452 デフォルトの名無しさん 2013/06/22(土) 22:01:45.75]

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

[453 デフォルトの名無しさん 2013/06/22(土) 22:18:16.03]

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

[454 デフォルトの名無しさん 2013/06/22(土) 22:54:09.39]

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

[455 デフォルトの名無しさん 2013/06/27(木) 00:13:09.68]

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

[456 デフォルトの名無しさん 2013/06/27(木) 08:12:55.38]

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

[457 デフォルトの名無しさん 2013/06/27(木) 08:27:58.81]

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

[458 デフォルトの名無しさん 2013/06/27(木) 11:05:49.21]

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

[459 デフォルトの名無しさん 2013/06/28(金) 12:33:38.83]

メガネっ娘

[460 デフォルトの名無しさん 2013/06/29(土) 00:17:54.24]

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

[461 デフォルトの名無しさん 2013/06/29(土) 01:48:56.14]

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

[462 デフォルトの名無しさん 2013/06/29(土) 01:52:10.58]

IF　条件 THEN →　臭ぁ〜い！

[463 デフォルトの名無しさん 2013/06/30(日) 20:46:54.48]

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

[464 デフォルトの名無しさん 2013/06/30(日) 21:28:47.13]

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

[465 デフォルトの名無しさん 2013/07/03(水) NY:AN:NY.AN]

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

[466 デフォルトの名無しさん 2013/07/03(水) NY:AN:NY.AN]

ねーよw

[467 デフォルトの名無しさん 2013/07/03(水) NY:AN:NY.AN]

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

[468 デフォルトの名無しさん 2013/07/03(水) NY:AN:NY.AN]

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

[469 デフォルトの名無しさん 2013/07/03(水) NY:AN:NY.AN]

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

[470 デフォルトの名無しさん 2013/07/04(木) NY:AN:NY.AN]

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

[471 デフォルトの名無しさん 2013/07/04(木) NY:AN:NY.AN]

なにいってんのコイツ

[472 デフォルトの名無しさん 2013/07/04(木) NY:AN:NY.AN]

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

[473 デフォルトの名無しさん 2013/07/04(木) NY:AN:NY.AN]

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

[474 デフォルトの名無しさん 2013/07/04(木) NY:AN:NY.AN]

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

[475 デフォルトの名無しさん 2013/07/05(金) NY:AN:NY.AN]

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

[476 デフォルトの名無しさん 2013/07/06(土) NY:AN:NY.AN]

>>474

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

[477 デフォルトの名無しさん 2013/07/06(土) NY:AN:NY.AN]

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

[478 デフォルトの名無しさん 2013/07/06(土) NY:AN:NY.AN]

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

[479 デフォルトの名無しさん 2013/07/07(日) NY:AN:NY.AN]

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

[480 デフォルトの名無しさん 2013/07/07(日) NY:AN:NY.AN]

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

[481 デフォルトの名無しさん 2013/07/07(日) NY:AN:NY.AN]

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

[482 デフォルトの名無しさん 2013/07/07(日) NY:AN:NY.AN]

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

[483 デフォルトの名無しさん 2013/07/07(日) NY:AN:NY.AN]

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

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

[484 デフォルトの名無しさん 2013/07/07(日) NY:AN:NY.AN]

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

[485 デフォルトの名無しさん 2013/07/07(日) NY:AN:NY.AN]

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

[486 デフォルトの名無しさん 2013/07/07(日) NY:AN:NY.AN]

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

[487 デフォルトの名無しさん 2013/07/07(日) NY:AN:NY.AN]

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



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

[488 デフォルトの名無しさん 2013/07/07(日) NY:AN:NY.AN]

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

はつみみです

[489 デフォルトの名無しさん 2013/07/08(月) NY:AN:NY.AN]

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

[490 デフォルトの名無しさん 2013/07/08(月) NY:AN:NY.AN]

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

[491 デフォルトの名無しさん 2013/07/10(水) NY:AN:NY.AN]

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

[492 デフォルトの名無しさん 2013/07/13(土) NY:AN:NY.AN]

Bだろ
美

[493 デフォルトの名無しさん 2013/07/13(土) NY:AN:NY.AN]

味

[494 デフォルトの名無しさん 2013/07/13(土) NY:AN:NY.AN]

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

[495 デフォルトの名無しさん 2013/07/13(土) NY:AN:NY.AN]

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

[496 デフォルトの名無しさん 2013/07/13(土) NY:AN:NY.AN]

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

[497 デフォルトの名無しさん 2013/07/13(土) NY:AN:NY.AN]

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

[498 デフォルトの名無しさん 2013/07/14(日) NY:AN:NY.AN]

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

[499 デフォルトの名無しさん 2013/07/14(日) NY:AN:NY.AN]

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

[500 デフォルトの名無しさん 2013/07/14(日) NY:AN:NY.AN]

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

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

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

[501 デフォルトの名無しさん 2013/07/14(日) NY:AN:NY.AN]

整数の加算は、の間違い

[502 デフォルトの名無しさん 2013/07/14(日) NY:AN:NY.AN]

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

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

[503 デフォルトの名無しさん 2013/07/14(日) NY:AN:NY.AN]

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

[504 デフォルトの名無しさん 2013/07/14(日) NY:AN:NY.AN]

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

[505 デフォルトの名無しさん 2013/07/14(日) NY:AN:NY.AN]

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

[506 デフォルトの名無しさん 2013/07/15(月) NY:AN:NY.AN]

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

[507 デフォルトの名無しさん 2013/07/15(月) NY:AN:NY.AN]

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

[508 デフォルトの名無しさん 2013/07/20(土) NY:AN:NY.AN]

html/css/js/

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

[509 デフォルトの名無しさん 2013/07/21(日) NY:AN:NY.AN]

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

[510 デフォルトの名無しさん 2013/07/22(月) NY:AN:NY.AN]

>>506
AND と NOT だけでOK

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

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

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

[511 デフォルトの名無しさん 2013/07/22(月) NY:AN:NY.AN]

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

[512 デフォルトの名無しさん 2013/07/23(火) NY:AN:NY.AN]

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

[513 デフォルトの名無しさん 2013/07/23(火) NY:AN:NY.AN]

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

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

[514 デフォルトの名無しさん 2013/07/24(水) NY:AN:NY.AN]

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

[515 デフォルトの名無しさん 2013/07/24(水) NY:AN:NY.AN]

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

[516 デフォルトの名無しさん 2013/07/27(土) NY:AN:NY.AN]

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

[517 デフォルトの名無しさん 2013/07/27(土) NY:AN:NY.AN]

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

[518 デフォルトの名無しさん 2013/07/27(土) NY:AN:NY.AN]

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

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

[519 デフォルトの名無しさん 2013/07/27(土) NY:AN:NY.AN]

典型的な洗脳じゃん

[520 デフォルトの名無しさん 2013/07/30(火) NY:AN:NY.AN]

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

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

[521 デフォルトの名無しさん 2013/07/30(火) NY:AN:NY.AN]

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

[522 デフォルトの名無しさん 2013/07/30(火) NY:AN:NY.AN]

皆で認定の皆って誰だよ

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

[523 デフォルトの名無しさん 2013/07/30(火) NY:AN:NY.AN]

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

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

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

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

[524 デフォルトの名無しさん 2013/07/30(火) NY:AN:NY.AN]

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

[525 デフォルトの名無しさん 2013/07/31(水) NY:AN:NY.AN]

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

[526 デフォルトの名無しさん 2013/07/31(水) NY:AN:NY.AN]

機械語が一番美しいだろ

[527 デフォルトの名無しさん 2013/07/31(水) NY:AN:NY.AN]

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

[528 デフォルトの名無しさん 2013/07/31(水) NY:AN:NY.AN]

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

[529 デフォルトの名無しさん 2013/07/31(水) NY:AN:NY.AN]

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