09/04/26 07:38:08
>>547
もっと具体的に教えて。
抽象化してシステム記述言語がアセンブラっぽくなる可能性もあるわけで
参考のために知っておきたい。
549:デフォルトの名無しさん
09/04/26 08:09:03
80系はレジスタが目的別なので、一般的には汚いと言われるね。
6809は16bitを睨んだ為に若干直行性に掛けるが、68000になると寧ろ綺麗な作りだ。
550:デフォルトの名無しさん
09/04/26 08:50:20
>>549
直交性っていうのはどういうこと？似た命令がないってこと？
551:デフォルトの名無しさん
09/04/26 09:06:04
お前らコーディングの汚さを言語のせいにする前に
自分のプログラミングのスキルを磨け ボケ！
552:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/04/26 10:36:56
>>552
なるほど。thnx
たしかに直交性が高いプログラミングの自由度があがって柔軟性がでるよね。
同じことをやる場合、直交性が低い方が見た目的には短いプログラムになるのかな。
自由度でいうと直交性が高いほうがいいけど、コードが短くなるなら
きめうちっていうのはある意味システムの抽象化が行われてるってことで場合によっては
美しい（短くてシンプル）なプログラムがかけそうな気がする。。。
554:デフォルトの名無しさん
09/04/26 10:42:26
Aが最強だろ
555:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/04/26 14:56:43
Pascalですね
557:デフォルトの名無しさん
09/04/26 21:17:51
$記法を導入したという点で、並みいる関数型言語の中でも
Haskellは、より美しいといえると思う。
print (map last (a b (c d)))
↓
print $ map last $ a b $ c d
こんな置き換えが可能。
LISP系みたいに括弧だらけにならない。
558:デフォルトの名無しさん
09/04/26 23:29:21
$がきもちわるい
そんな記法ならLISPでもできるし
559:デフォルトの名無しさん
09/04/26 23:49:48
LiSPなんて旧時代のゴミだろwHaskellの美しさの足元におよばない
あらゆる意味でHaskellのほうが優れている
560:デフォルトの名無しさん
09/04/27 00:04:54
そういう変態構文のオナニーショーはLISPer個々でよくやってる事だよ
$記法とやらが読みやすいとはとても思えないし
561:デフォルトの名無しさん
09/04/27 00:16:16
みやすさって概念だったら表形式がみやすいのでは？
いっそのことExcelみたな表でプログラミングするっていうのはどう？表っていうのはリストの特殊形態であるわけだし。
562:デフォルトの名無しさん
09/04/27 02:02:58
($) がいつから記法になったの。ただの関数でしょ。
563:デフォルトの名無しさん
09/04/27 12:54:34
なんで過去の人工知能の研究者にリスパーが多かったんですか？エロい人教えて
あスレ違いか
564:デフォルトの名無しさん
09/04/27 13:10:26
LISPって他人が書いたコードを理解するのが極端に難しくない？
これは俺のアタマが手続き脳だから単に理解できないだけかもしれないけど。
565:デフォルトの名無しさん
09/04/27 13:38:54
>>561
Excelの表を「数式を置けるプログラミング・フィールド（ソースコード置き場）」とみなせば
かなり美しいプログラミング環境のような気もします。
プログラミング「言語」と呼ぶのは難しいでしょうか？
566:デフォルトの名無しさん
09/04/27 13:43:09
>>565
プログラミング言語かどうかは兎も角、環境としてはありだと思う。
実際、私のプロジェクトではそういうケースも多いし。
# アルゴリズムの検証をシート関数で行ない、それを元にC/C++で実装する。
そもそも、保存ファイル形式がXMLなんだしね。
567:デフォルトの名無しさん
09/04/27 13:47:28
>>565
表計算はもちろんプログラム言語だよ。
568:デフォルトの名無しさん
09/04/28 09:40:47
コーディングしないことが最も美しいのでは？
569:デフォルトの名無しさん
09/04/28 12:39:41
ニモニックかわいいよニモニック
570:デフォルトの名無しさん
09/04/28 14:44:14
Delphi prism - Delphiのグリーンスパンの第10法則に従った進化形ｗ
571:デフォルトの名無しさん
09/04/28 22:01:17
delphiというかpascalはピリオドの付け方がよく判らなくて嫌い
572:デフォルトの名無しさん
09/04/30 02:05:11
やっぱりHaskell lisp Smalltalk辺りかな。
例えば、Smalltalkなら、分岐制御、式ブロック、クラスが全てが
オブジェクト表現され、継承やクラス定義は全てメッセージングで表現される。
全てオブジェクトとメッセージ。こういう完結された仕様はやっぱり美しく感じる。
逆に、同じオブジェクト指向を謳うJavaの中途半端さと言ったら醜悪に尽きる。
あそこまで。バランスを崩すなら速度に特化したC++の方がまだ潔い。
Haskell lispは上の方で語られているから詳細は省くが、やっぱり美しい一貫性をもつ。
573:デフォルトの名無しさん
09/04/30 02:26:13
Haskell lispってなんだ。Haskell, Lispってことか？
574:ちんこ ◆GbXlaaQNk.
09/04/30 07:16:47
美しいのはPythonだけど、
使ってるのはJavaです。
結局、可読性が高くなるかどうかなんて、
実装者の能力次第です。
575:デフォルトの名無しさん
09/04/30 07:31:10
>>574
その言語を熟知している人にとっての可読性ではそうだが、
その言語を全然知らない人間にとっての可読性は言語仕様によるのではないか。
576:ちんこ ◆GbXlaaQNk.
09/04/30 07:36:12
可読性を上げる要因として、
主要はものは、
凝集度、結合度、明示的なネーミング
の３つである。
これらは言語とは全く関係ない。
凝集度が著しく低いコード、
不必要な結合性を生んでるコード、
意味分からん変数やメソッドがたくさんあるコード、
これらはどれも可読性が低い。
Cでも可読性の高いコードは書けるし、
Pythonでもゴミのようなコードは書ける。
言語への習熟度は、主要な言語においてはそれほど関係ない。
577:デフォルトの名無しさん
09/04/30 10:36:39
ToStringより、toStringがいいし、to_sが一番いい。
言語とその文化がもつ冗長性は美しさにかかわる。
578:デフォルトの名無しさん
09/04/30 11:06:36
>>577
sって何ですか、という疑問は？
579:デフォルトの名無しさん
09/04/30 11:13:55
to_i, to_f, to_aと並べて見せて、類推してもらう。
580:デフォルトの名無しさん
09/04/30 11:25:09
なんだかんだ言っても俺が見て一目で内容がわかる言語が美しいと言うことだろうな。
そんな言語はないけどね
581:デフォルトの名無しさん
09/04/30 11:27:52
どの言語も、汚いと思うのは意外と無いよね。
独自の文化には意外と慣れるから。
C#の命名も苦にならなくなる。
けど、phpとperlだけは馴染めなかった覚えが。
自分が使う期間が短かったのもあるけど。
582:デフォルトの名無しさん
09/04/30 14:56:42
>>580
Prolog
583:ちんこ ◆GbXlaaQNk.
09/04/30 16:50:51
>>577
それは小さな問題だよ。
結局は、可読性に対するきちんとした知識と実装力を持っているかどうか。
可読性という意味からいえば、toStringの方が高いといえる。
to_sではsが何を意味しているのか分からない。
もちろんRuby出身なおれは分かるけどね。
例えば、
おれに言わせれば、
ｽﾚﾘﾝｸ(tech板:567番)
のコード、これ書いたやつは死ぬべきだと思うんだけど、
なんでだか分かる？
このコード読んで吐き気を覚えないやつは
プログラミングをすべきじゃないよ。
584:デフォルトの名無しさん
09/04/30 17:02:18
おまいは名前のわりにしっかりしてるなｗ
> このコード読んで吐き気を覚えないやつは
すまんが、吐き気を覚えない。
java.util.Scanner使ったこと無いから、
それに関する部分は良く分からんし。
585:デフォルトの名無しさん
09/04/30 17:17:11
>>583
俺も吐き気を覚えない。
可読性はプログラミング言語の美しさとは関係ないと書いている（>>576）ので
これは「最も美しいプログラミング言語」とは関係ない話？
586:デフォルトの名無しさん
09/04/30 17:36:14
美しいものに吐き気を覚えることもあり得るのでこの話はスレ違い
587:ちんこ ◆GbXlaaQNk.
09/04/30 18:57:52
Scannerがどうとか言ってるんじゃないよ。
おれも使ったことないし、推測でscanfみたいなことかなと思ってるだけ。
おれはこのコードを見て、鳥肌がたち、書いた人間に殺意を覚えた。
おれがプログラムを書くものが読むことを必須とすると考えている本は、
Code Complete（上）
リファクタリング
実装パターン
の３冊だ。
他にもいい本は色々あるが、
とりあえずこの３冊を読まなければダメだ。
特にCode Completeは必須中の必須。
これが分からなくて、何を実装するというのだろうか。
可読性の低いコードは環境汚染に等しい。
無意識に可読性の低いコードを書く人間は、害悪。
おれは美しいコードを書くことについて強い興味を持っている。
そのおれが言う。
もっとも美しい言語はPythonだ、と。
そしてJavaプラットフォーム上で動くJythonを中心にこれからの世界は動き始めるだろう、と。
588:デフォルトの名無しさん
09/04/30 19:03:23
大仰な前フリはいいからｗ
ｽﾚﾘﾝｸ(tech板:567番)
の問題点を簡潔に示しておくんなまし。
> 鳥肌がたち、書いた人間に殺意を覚えた。
吐き気につづき、鳥肌、殺意とくれば、
興味深々になってしまって仕方ない。
ちなみに、俺が吐き気するコードは、
if (isRunning == true) と無用で余計なことをするものとか、
int flgっていう変数をヒョイと作って以下でグデグデ使うもの。
そんなもんかなぁ。
589:デフォルトの名無しさん
09/04/30 19:04:28
×吐き気する
○吐き気を催す
590:ちんこ ◆GbXlaaQNk.
09/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.
09/04/30 19:19:40
>>588
flagを立ててそれを使うというのは、
可読性を落とすという要因から禁止されている。
何かの本に書いてあったから、おれの読んだ本を何年かかけて全部嫁、このクソ虫が。
また、flagというのであればbooleanにして欲しいし、
booleanの変数名には肯定的な名前をつけるというのもルールだ。
flagと言われても、何のことだか分からない。flgなんて論外だ。"a"を省略する意味が分からない。
勉強のために色々コードを読んできた。
どれもひどいものばかりだ。どいつもこいつも狂ってる。
おれが注目するのはすでに述べたとおり、
凝集度、結合度、明示的なネーミングの３つだ。
きちんと１つの仕事をする明示的な名前のついた小さなメソッドに分けることによって、
文を読むがごとく読めるようになってないコードはすべて吐き気がする。
おれがかなり好きなコードがある。
JUNGというソフトウェアのコードだ。
参考にするといい。
これを書いた人はかなり出来る。
592:デフォルトの名無しさん
09/04/30 19:19:57
そ、そんだけ？
593:デフォルトの名無しさん
09/04/30 19:21:00
このスレは、美しいプログラミング「言語」について書くスレです。
>>590 は「美しいプログラミング」について語っているので、
すれ違いだと思います。
594:デフォルトの名無しさん
09/04/30 19:29:11
ポール・グレアムが書いた文書（の翻訳）を読むと、
「LISP最高！Schemeって美しい！」と思うんですが、
いざ使ってみると、「なにこのカッコの多さ！ありえない！」
と思うんですよね（笑）
595:ちんこ ◆GbXlaaQNk.
09/04/30 19:37:40
美しいプログラミングが分からない人間が、
プログラミング言語の美しさの何を語ろうというのだ。
何も判断基準がないじゃないか。
そこにあるのは、感性だけだ。
ただ美しいと思った、それだけ。
プログラミング言語は芸術ではない。
美しいものには美しいだけの理由がある。
そういう、なぜ美しいかということが分かった上で、
美しさについて語りたまえ、このクソ虫どもが。
もし分からないのであれば、
おれのようなスーパーハカーのいうことを聞いて
Pythonを使ってればいいんだよ。
596:デフォルトの名無しさん
09/04/30 19:38:22
でもまぁ、確かにJavaは美しくないとは思った。
597:デフォルトの名無しさん
09/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.
09/04/30 19:41:21
>>596
なぜだ。
なぜ、Javaが美しくないと考えたのか。
それが問題だ。
残念ながら、おれはJavaは最高に美しくはないものの、
それなりに美しく、かつ非常に生産性の高い言語だということで、
とてもお気に入りなんだ。
美しくなくはない、吐き気がするのはC++だ。
C++よりはCの方が美しい。
C++は言語仕様がどうとかいうより、
仕様の設計者はバカなのではないかと思うようなところがある。
599:デフォルトの名無しさん
09/04/30 19:44:02
>>598
具体的に、吐き気がするところは?
俺はクラス定義の中にメンバー関数の定義を書くと
それだけでインライン化するところは、馬鹿じゃないかと思った。
インライン化したければ「inline」と書けばいいのに。
600:ちんこ ◆GbXlaaQNk.
09/04/30 19:47:38
ごめん、実はC++はあまり知らない。
601:デフォルトの名無しさん
09/04/30 19:49:18
>>599
理由は違うが同意。inlineなんてのはコンパイラに対するヒントでしかないんだから存在意義自体がないと思う。
インラインかしたくない事情があれば、それを指定するようにすればいいんだ。
602:デフォルトの名無しさん
09/04/30 20:07:34
俺は変態的なもののほうが美しく感じる。
C++ サイコー Lisp マンセー チンコシネー
まじめに書くと、なんとか指向とか関数型なんとかなどとのたまう言語は醜くく感じる。
そうしたければそのように書くこともできる、というのは大事だと思う。
でも、そのスタイルを強制されるのはまっぴらゴメン。
で、必然的にハイブリッドなものに美しさを感じるようになる。
いかにブレンドするか、その美しさこそが真の美しさ。
603:ちんこ ◆GbXlaaQNk.
09/04/30 20:28:23
もうさ、
プログラミング言語はJavaで統一しようぜ。
全員Javaと最悪、Jython, JRuby, GroovyなどのJava実装スクリプトね。
Cを撲滅しようぜ。
Javaは実行速度だって、C++よりずいぶん速いんだ。
604:デフォルトの名無しさん
09/04/30 20:31:37
＞Javaは実行速度だって、C++よりずいぶん速いんだ。
なんだ、妄想癖の人だったのか。
605:ちんこ ◆GbXlaaQNk.
09/04/30 20:38:50
いや、事実だけど・・・。
今のJavaはまじで速い。
Javaが遅かったというのは過去の話。
今はCと変わらないレベルの速度が出る。
606:デフォルトの名無しさん
09/04/30 20:39:17
【レス抽出】
対象スレ：最も美しいプログラミング言語は？
キーワード：D言語
抽出レス数：1
607:デフォルトの名無しさん
09/04/30 20:40:14
現行、言語の性能はコンパイラ屋の質に依存してるぞ。
意外かも知れんが、Linux上ではJavaとCは同等、C++が一番早い。
the computer language benchmark gameのサイトでスコアが見れる。
608:デフォルトの名無しさん
09/04/30 20:40:57
>>606
おもしろではあるが、美しくはないだろ。
!()だかの使い方が未だにわからんｗ
609:ちんこ ◆GbXlaaQNk.
09/04/30 20:46:07
単純なプログラムではJavaは不利かも知れない。
だが、プログラムが複雑になるほど、Javaの最適化技術が生きてくるよ。
Javaは可読性の高いコードに対してもっともよい最適化を施す仕組みになってる。
610:デフォルトの名無しさん
09/04/30 20:55:09
はい、はい、はい。
わかったから、もう帰れ＞ちんこ
611:ちんこ ◆GbXlaaQNk.
09/04/30 20:57:21
帰ります。
ただ、これからはみなさんも可読性というものに高い意識を持って欲しいです。
いや、持ちなさい、持ちやがれ。
可読性の低いコードを書く人は死ぬべきです。
プログラマというのは超のつく知能職だということを知るべきです。
612:デフォルトの名無しさん
09/04/30 21:06:16
C++だって速いからというだけで使われているという考えもどうかと思う。
一応オブジェクト指向も可能でありながら、Cとの互換性のために
OSのAPIやCのライブラリを使え、アセンブリ言語との連携が容易で、大抵のスクリプト言語をホストできる。
D言語とか出てきてはいるんだけど、C++を置き換えるまでには至っていないし……。
613:デフォルトの名無しさん
09/04/30 21:08:49
てかC言語とC++ってもう互換性無いよね？
614:ちんこ ◆GbXlaaQNk.
09/04/30 21:10:47
現代のプログラムにおいては、
実行速度は関係ないから、
とにかく開発の容易性を重視すべき。
半導体技術の向上は目覚ましい。
だから、ソフトウェアの世界には、
古い時代のハードでやっていた人と、
新しい時代のハードから始めた人（おれとか）の
２つが入り交じってしまっている。
それが害悪なんだ。
若い人は積極的に正しいプログラムの書き方を学んで、
古い人たちを追い出すべきなんだ。
615:デフォルトの名無しさん
09/04/30 21:14:12
> 実行速度は関係ないから、
> とにかく開発の容易性を重視すべき。
はい、これで Java 消えた。
616:デフォルトの名無しさん
09/04/30 21:20:26
さすがに>>615は情弱というか低脳を感じざるを得ない
617:ちんこ ◆GbXlaaQNk.
09/04/30 21:23:33
Java以上に開発が容易な言語があったら教えてください。
おれは知りません。
Javaにはたくさんの道具があります。
Pythonにはそれがありません。
Eclipse+Javaに開発速度で勝つことは不可能ですし、
Javaならば、美しいプログラムを書けるだけの言語仕様を備えています。
例えば、おれがC++が嫌いな一つの理由は、
コンストラクタチェーンが出来ないことです。
コンストラクタからコンストラクタを呼び出せなければチェーン出来ません。
保守性が著しく低くなります。
618:デフォルトの名無しさん
09/04/30 21:27:59
つ Ruby
619:デフォルトの名無しさん
09/04/30 21:28:41
つ Ruby on Rails
620:デフォルトの名無しさん
09/04/30 21:34:50
Web屋かよ、カスが
621:デフォルトの名無しさん
09/04/30 21:35:31
Twitterにも見捨てられた糞環境、それがRoR。
622:デフォルトの名無しさん
09/04/30 21:38:54
Ruby に仕事を取られたからといって、そう僻むなｗ
623:ちんこ ◆GbXlaaQNk.
09/04/30 21:38:57
確かにRubyは美しい。
いや、美しさだけで言ったらRubyがマックスかも知れない。
だけど、RubyにはPythonに対して圧倒的に劣る点がある。
それは、コミュニティが小さいという点だ。
また、GoogleがPythonを採用してるなどの状況もあり、
Rubyへ優秀な人材が流れにくくなっている。
よって、RubyのライブラリはPythonに比べるとだいぶしょぼい。
スクリプトの標準がPythonになりつつあるというのもあって、もうこの差は埋まらないだろう。
Rubyはホビーランゲージとして生きていくことになる。
ただ、もし、もし、RubyがPythonと同じくendがいらない設計だったら・・・
そしたら話は変わっていたかも知れない。
Rubyのエンドラダーは害悪、可読性を言語仕様レベルで落とす原因になっている。
624:デフォルトの名無しさん
09/04/30 21:39:57
Rubyの字面は美しいって感じじゃないな。
あまりにも趣味的に過ぎる。
まあそれでもC++の醜悪さには及ぶべくもないが。
C++はパフォーマンスの要求されるところで使われて入るが
マルチコア環境での開発効率があまりにも悪すぎるので
関数型言語の台頭が予測されてるな。
625:デフォルトの名無しさん
09/04/30 21:41:58
>>623
> 確かにRubyは美しい。
> いや、美しさだけで言ったらRubyがマックスかも知れない。
> だけど、RubyにはPythonに対して圧倒的に劣る点がある。
> それは、コミュニティが小さいという点だ。
いいかげん、スレタイ読めや。
626:デフォルトの名無しさん
09/04/30 21:43:53
>>605
Javaでは配列にアクセスするごとにインデックスがはみ出していないかチェックする。
最適化しても、それを取り除くことはできないんじゃない?
C++では両端だけチェックして他は省くように書けるし、
コンパイラによっては、データ並列な部分を自動的にベクトル化してくれる。
(OpenMPを使って指示する必要がある部分もあるけど)
だから、信号処理や行列の計算など、速度が必要なタイプの処理の速度では、
JavaよりC++の方が一般的に言って上じゃないかな。
(私はJavaがメインだけど、嫌々C++を使いまくる場面がまだまだあるよ)
>>617
C++ 0xではコンストラクタチェーンができるようになる予定。
楽しみですな。
URLﾘﾝｸ(ja.wikipedia.org)
627:デフォルトの名無しさん
09/04/30 21:45:08
RoRなんて使ってるとこなんてホントにあるの？
どこの底辺？
628:デフォルトの名無しさん
09/04/30 21:45:50
がっはっは。
> ただ、もし、もし、RubyがPythonと同じくendがいらない設計だったら・・・
> そしたら話は変わっていたかも知れない。
end がなければ google が Ruby を採用し、優秀な人材も集まり、
しょぼいライブラリも目の醒めるようなライブラリとして生まれていた、と。
んな、あほな。
629:デフォルトの名無しさん
09/04/30 21:47:42
さすがに>>627には情弱というか低脳を感じざるを得ない
630:デフォルトの名無しさん
09/04/30 21:50:21
反応が既に終わってるな、まともに答えられんのか
631:デフォルトの名無しさん
09/04/30 21:52:40
URLﾘﾝｸ(www.tiobe.com)
PERLもどきならではの汚さを持つRubyの人気はもう落ちてます。
632:626
09/04/30 21:53:50
配列の処理を中心に見ると、美しいと思う言語はSaCかな。
SaCでは配列は全て値渡しで、プリミティブ値はランク0の配列として扱われる。
ランク数不明の配列を引数に取る関数を定義すれば、
プリミティブ値でも任意のランク数の配列でも、一つの関数で処理できる。
概念的には値渡しだけど、内部ではポインタ渡しにした上、
データフロー解析を使って処理は最小限にしてくれる。
ベンチマークではFORTRANよりも速度が出ているくらい速い。
(ちなみにコンパイラが出力するのはCのコード)
研究用の言語なので常用は厳しいし、足りないものも多いけど、
メインストリームの言語に長所が取り込まれればいいと思っている言語だ。
URLﾘﾝｸ(www.sac-home.org)
633:デフォルトの名無しさん
09/04/30 21:56:25
>>631
Java の人気の下がり具合のほうが大きいね。
634:ちんこ ◆GbXlaaQNk.
09/04/30 21:56:54
>>628
それはない。
だが、おれはRubyを好んでいたかも分からん。
いや、やっぱりPythonかな。
Pythonコミュニティには高い可読性を追求する気概がある。
可読性を無視するクズプログラマには用はない。
でもやっぱりRubyもいいよね。
Rubyはインスタンス変数の書き方がいいわ。
Pythonは少しうんこなところがある。
selfがくどかったりね。
あれはC言語でのオブジェクト指向の書き方なんだよ。古い。
>>626
C++の設計者が、
C++が保守性、可読性について言語仕様レベルで問題があることに気づいていた。
それだけで余は満足じゃ。
635:ちんこ ◆GbXlaaQNk.
09/04/30 22:01:03
>>631
どこが？
Python VS Rubyに関しては
もう逆転出来ないくらいの差がついてしまったよな。
Matz涙目www
636:デフォルトの名無しさん
09/04/30 22:08:04
>>635
英語は読めなくても、下のグラフが何を意味しているかぐらいはわかるだろう。。。
しかし、
> Matz涙目www
なんか、発言にギャッップを感じる。
637:デフォルトの名無しさん
09/04/30 22:10:51
>>636
常識のある人だと，長い目で見た場合 Java は下降気味，
Ruby は上昇気味という傾向を読み取るだろうね．
妄想系の人にこのグラフが一体どのように見えるかまではわからんがw
638:デフォルトの名無しさん
09/04/30 22:13:12
何でRubyヲタがJavaを目の敵にしてるのか知らんが、実際使われてないだろ
はてなとかやってる人？ｗ
639:デフォルトの名無しさん
09/04/30 22:16:15
だーれも Java を目の敵してませんが。
被害妄想系にはそう見えるかも知れませんねｗ
そうか、Ruby に仕事を取られたカワイソウな奴は
そんなに危機意識を持ってるのか。
640:デフォルトの名無しさん
09/04/30 22:18:32
> Ruby に仕事を取られた
という妄想をRubyヲタが好むのは何でだろうね
641:デフォルトの名無しさん
09/04/30 22:19:29
>>640
そんなことはない！と涙目になりながら必死で否定するやつがいるからじゃない？
642:デフォルトの名無しさん
09/04/30 22:20:39
P系言語とよろしくやってるだけで、Web屋以外の人は見向きもせんでしょ
643:ちんこ ◆GbXlaaQNk.
09/04/30 22:22:52
Pythonのやばいところは、
いちいちself.valueで指定しなきゃいけないところ。
これは可読性を落とすね。
でも、インデントによる論理改行と、
あとはキーワード引数で楽々借金返済出来る。
PythonとRubyのいいとこどりをした言語があったらいいんだけどね。
Rubyのmixinなんかは美しい。
Pythonはmixinをとって、多重継承を捨てるべきだと思う。
Pythonは大体いいけど、時々悪い。
Rubyはかなりいい言語なんだけど、コミュニティが貧弱すぎる。
GoogleはPythonだけど、ThoughtWorksはRubyだ。
おれはGoogleとThoughWorksどっちにでも入れるとしたらThoughtWorksを選ぶ。
644:デフォルトの名無しさん
09/04/30 22:26:18
ところで今日一番恥かしい発言をした>>631はどこに行ったんだろう
645:デフォルトの名無しさん
09/04/30 22:28:06
Rubyが凄い勢いで飽きられてるソースとしては十分だな
646:デフォルトの名無しさん
09/04/30 22:36:03
いや、別に Ruby を擁護する気はさらさらないが、どう考えても
> Rubyが凄い勢いで飽きられてるソースとしては十分だな
は >>631 のリンク先から読み取れないな
647:デフォルトの名無しさん
09/04/30 22:54:20
>>626
普段C++を使うけど、さすがにJavaもそこまで間抜けなわけがないと思うぞ。
範囲チェックを必要最低限に押さえることはJavaの最適化の序の口だろ。
648:デフォルトの名無しさん
09/04/30 22:59:40
>>643
手続き型の言語しかわからない人には
GoogleのMapReduceは何をやっているか
理解するのは難しいでしょう。
Code Completeもいいけど、
プログラムの作り方や
プログラム言語の優劣について論じるならば
SICPあたりも読むべき。
649:デフォルトの名無しさん
09/04/30 23:10:20
ぶっちゃけ、審美眼とうものは恣意的なものであるので、
○○は美しい、 というあらゆる命題は真理を述べることはできない。
○○は可読性が高い、という命題も同様である。
というわけでお前ら乙としか言いようがないわｗ
650:デフォルトの名無しさん
09/05/01 02:30:53
アセンブラやってるとすべての言語の意味がイメージできるので、
自分が美しいと思う言語を選ぶと、ずばりJava。EJBを除く。
651:ちんこ ◆GbXlaaQNk.
09/05/01 08:16:48
>>648
SICP読んだ人は美しいコードが書けるんですか？
立ち読みしたけど、とてもそんな感じはしなかった。
逆に、あれを読んだら汚いコードを書くようになってしまう気すらした。
事実、情報系の人間のコードを読んだことがあるが、腹抱えて笑うほどだった。
暗号みたいなコード書いて、自分は頭がいいんだと主張しているようだった。
おれはそんな世界には用がないんだ。
おれは正しいソフトウェアをアジャイルに構築することに興味がある。
そのためには急がば回れなんだよ、もっとも美しい設計、高い可読性の保ち方を知らない人間はゴミみたいなソフトウェアしか作れない。
したがって、生きてる意味がない。
おれは日本でもっとも可読性にストイックな男だ。
652:デフォルトの名無しさん
09/05/01 09:00:16
＞おれは日本でもっとも可読性にストイックな男だ。
なんだ、妄想癖の人だったのか。
653:ちんこ ◆GbXlaaQNk.
09/05/01 09:03:17
じゃあ、おれより可読性にストイックな人間を教えてくれ。
アポイントメントとって会いにいく。
654:デフォルトの名無しさん
09/05/01 09:10:34
>>653
可読性にそこまで拘るなら、
転職して、実行速度なんか気にしなくてもよい環境で、
Prologプログラミングの修練を勧めます。
これ本気。
655:ちんこ ◆GbXlaaQNk.
09/05/01 09:24:19
>>654
当方学生でつ。
656:654
09/05/01 09:28:31
>>655
いっしょにやろうじゃないか。
657:ちんこ ◆GbXlaaQNk.
09/05/01 09:31:44
どういう進路にするか迷ってるんでつ。
研究職でいくか、プログラマとして突っ切るか。
おれはプログラミングが好きだし、得意だけど、
日本のプログラマは地位が低すぎる。
年収１０００万はないと嫌だ。
658:デフォルトの名無しさん
09/05/01 09:34:08
可読性にこだわってる割にはちょっとな。
590でその４行が おまいのいう順番になったときは、
プログラムとして違う動作になる。
事の大小はともかく、入力があった場合にのみ表示が出るという動作を
たったこんな小さなプログラムから読めないやつに可読性なんていう資格は無い。
ちゃんと動くことの方が数倍重要だ。
659:ちんこ ◆GbXlaaQNk.
09/05/01 09:40:00
あ、そうなの・・・？
知らんけど。
660:ちんこ ◆GbXlaaQNk.
09/05/01 09:45:50
まず、
入力があった場合にのみ表示が出る、
なんて仕様が狂ってるし、
大体、このプログラムおかしいもん。
日本のソフトウェア業界っていうのは、こういうコードが蔓延してるんだろ。
おれは単純に凝集度の観点から可読性が低いといっただけで、
こんなのそもそもまともなプログラムじゃない。
動作を確認するまでもないコード。
見たその時点で、気持ち悪いという感情を得た、それだけだ。
もちろん、入力を施す為の記述もない、という意味も含めてね。
661:デフォルトの名無しさん
09/05/01 10:53:13
>>651
SICPを読んだら、より美しいコードが書ける。
なぜならば、手続きの抽象化について学ぶことができるから。
Javaが採用しているオブジェクト指向はデータの抽象化を推進する。
もし手続きの抽象化について学べば、それをJavaでも応用できるよ。
綺麗なStrategyパターンを書くとかね。
662:デフォルトの名無しさん
09/05/01 11:04:31
「ケント・ベックの Smalltalk ベストプラクティス・パターン」
これを読むと、ケント・ベックは可読性にストイックな男としては
世界でも上位に入るのではないかと思う。
可読性にこだわった先達として、>>660はこれも読むといいよ。
663:デフォルトの名無しさん
09/05/01 11:04:51
>>590の言語が何かは知らないけれど
Scanner stdIn = new Scanner(System.in);
これは、入力オブジェクトの宣言なのだから、処理とは分けて記述しなければならないのでは?
処理の最中に、これがある方が気持ち悪いのですが...
664:デフォルトの名無しさん
09/05/01 11:10:17
>>660
とりあえず、君の書いたソースを読みたいな
665:デフォルトの名無しさん
09/05/01 11:19:25
>>664
こういう展開でソースを出して見せた奴、みたことないｗ
可読性という話で、十数行のサンプルプログラムみたいなのに大げさに噛み付く姿からして、
彼が取り組んだことのあるプログラムの大きさと複雑さの程度が見て取れる。
666:デフォルトの名無しさん
09/05/01 11:23:46
多面的に物事を見れてないしね
667:デフォルトの名無しさん
09/05/01 13:47:46
>>665
出したところで、
ふーん、俺には可読性が高いようには思われない
と言い出す人が現れて終了
668:デフォルトの名無しさん
09/05/01 15:44:13
このコテはソースの美しさを語る前に自分の日本語をどうにかした方がいいと思う
669:デフォルトの名無しさん
09/05/01 16:11:41
件のコードが書かれた文脈（書き捨てのサンプル）を考えると
>>660 はアホとしか思えん
いくらソースの可読性が高かろうが、文脈を読み取れないやつが
読むんじゃなあｗ
670:デフォルトの名無しさん
09/05/01 17:11:30
>>605,634
C++もLLVMなんかのVMで動くし。ネイティブに最適化された
バイナリよりも早い。当然、JVMより遥に早い訳だが。
言語の話をしてる時に環境の話を出すなよ。不毛だ。
>selfがくどかったりね。
>あれはC言語でのオブジェクト指向の書き方なんだよ。古い。
あんまり、オブジェクト指向しらんだろ？マルチディスパッチとか
Smalltalk学んでこいよ。
著名人の間で美しいと言われるのはLispだが、
基本的に統一性のある文法の言語が美しいとされるね。
Rubyの話も度々出るが、改行が不自由でメソッド呼び出しに
糖衣構文があるってのは汚いな。概念上はSmalltalkに似て
綺麗なんだけどな。あと、最近人気が下降気味らしいな。
(書籍販売数・プロジェクト数・他 が縮小してるらしい)
Objective-Cなんかは、C言語に埋め込みできるオブジェクト
指向言語だと考えれば綺麗だと考える著名人も少なくないだろうね。
671:ちんこ ◆GbXlaaQNk.
09/05/01 18:59:36
お前ら、ずいぶんと偉そうだな。
日本のソフトウェアエンジニアなんて、高卒とか文系とかばかりだろ。
相手にならんよw
日本人が書いたコードで美しいコードを見たことがない。
もしオープンソースでそういうものがあるのなら教えてくれ。
情報学科卒でSICPなどは当然読んでるだろうと思われる人間のコードも読んだことがあるが、
カス同然だった。
よってSICPなど意味ない。
672:デフォルトの名無しさん
09/05/01 19:18:03
>>671
そっすね。
673:ちんこ ◆GbXlaaQNk.
09/05/01 19:20:44
ところでだけど、
Python3.0とPython2.6だったら、
どっちを使うべき？
対して差、ないよね？
Python3.0ってこれから広く使われる予定あるの？
互換性切ってるし、美しくなったといっても、使われるかどうかは別な気がする。
674:デフォルトの名無しさん
09/05/01 19:33:43
＞ ちんこ
そこまで自惚れられる根拠は何かね？
675:デフォルトの名無しさん
09/05/01 20:26:36
> ちんこ
マーチン・ファウラーが評価している「fluent interface（流れるようなインターフェイス）は
デメテルの法則を破っているからCode Complete的にはNGだと思うんだけど、
ちんことしては、これはOKなの？NGなの？
676:ちんこ ◆GbXlaaQNk.
09/05/01 20:36:49
絶対にNG
他にも、おれはインターフェイスの設計として、
メソッドの引数を単純データ結合に保たないような設計
（
これは、
場合によっては引数オブジェクトの導入リファクタリングによって改善されるが、
最初は絶対に、結合度を低く保つべき
）
や、
メソッドチェイニングを前提とした設計、
とりわけ、可変オブジェクトを返す設計を嫌う。
Immutableなオブジェクトを生成して返すのであればそれは許されないこともない。
Mutableなオブジェクトを返すのはかなりやばい。
このFluent Interfaceというのは返したオブジェクトが可変になっているから、相当悪い。
これをおれが悪いと思う理由は、
おれがテスト駆動とリファクタリングを前提にプログラムを書くようにしているからであり、
経験的に、結合度をとにかく低く保った方がリファクタリングがしやすいからだ。
確かに、メソッドチェイニングを回避するために、委譲メソッドを作るのは手間だが、
IDEを前提とした場合、そこまでの手間でもないし、
何より結合度を低く保つことのメリットの方が断然大きいと感じている。
677:ちんこ ◆GbXlaaQNk.
09/05/01 20:43:23
マーチンはたまにおかしなことをいう。
ケントベックのいうことはほとんどの場合信じられる
（
例えば、おれは美しい設計のために
常にstaticファクトリを使うべきだと思っていたが、
ケントは、ただの生成の為にstaticファクトリを作るのは愚であると、
実装パターンにおいて説いている。
確かにそうだと思ったので、それ以降、おれは無駄なstaticファクトリを作ることをやめた
）。
あと、Code Completeに書いてあることもほぼ１００％信じられる。
マーチンのリファクタリングもほとんどは信じられるが、
おれは、仲介人の導入メソッドだったか、名前は忘れたが、
委譲するのが大変だからやめる、と言った主旨のリファクタリングは訂正して消去して欲しいと思った。
マーチンは尊敬出来るソフトウェア開発者だが、彼とおれとの間には少しだけ設計に対して意見の相違がある。
678:675
09/05/01 21:00:22
>>676
ありがとう。
流れるようなインターフェイスは読みやすいので、
読みやすさとどっちを優先するか聞きたかった。
俺もクラス間の結合度を低く保つように心がけているけど、
メソッドが7つを超えたら別のクラスに分けて、
元のクラスに分けたクラスのオブジェクトを返すファクトリメソッドを作ってる。
679:ちんこ ◆GbXlaaQNk.
09/05/01 21:03:31
メソッドの数は関係ない。
仮にメソッドの数が増えたらクラスを分離して、
そのクラスに処理を委譲するようにしろ。
実装コードが増えすぎるのが問題なので、あって、
インターフェイスの数が増えることが問題なのではない。
これを勘違いしてるやつが多すぎる。
そして、
元のクラスにわけたクラスのファクトリを作るという設計も意味不明だ。
君はちゃんとオブジェクト指向を学んでいない。
よって死ね。
680:デフォルトの名無しさん
09/05/01 22:34:40
「俺は、ビックマグナムだ!!!」
と思っていられるうちは自惚れる事もできるさ
まあ、大抵の場合、銭湯に行って己の矮小さに気付くわけだがなwww
681:デフォルトの名無しさん
09/05/02 00:49:24
だから、ソースは？
682:デフォルトの名無しさん
09/05/02 01:13:54
自演乙
683:デフォルトの名無しさん
09/05/02 01:43:55
よしいまからHaskerubyつくる
684:デフォルトの名無しさん
09/05/02 03:56:41
夜郎自大とはまさにこのことだ
685:デフォルトの名無しさん
09/05/02 16:00:30
「プログラム言語ツクール」とかあったら、
みんなで作って見せ合えるのにね。
文法をBNFで書けば言語ができるようなの。
ライブラリは.NETのを使えばいいね。
…単に.NET用のyacc/lexを使えばいいのか？
っていうか、最も美しい言語はBNFか？
686:デフォルトの名無しさん
09/05/02 16:32:42
>>685
ようこそ♪
ｽﾚﾘﾝｸ(tech板)
yaccやbisonは使いにくいので、個人的にはCaperがお薦め。
BNFを書くと、構文解析機と、解析後に呼びだす
(意味解析用の) 関数が一通り定義されたインターフェースを
生成してくれる。
(言語はC++, C#, Java, D, JavaScriptに対応)
後はそのインターフェースを、構文に対応する
処理をするよう実装すれば、自分の言語ができてしまうよ。
687:デフォルトの名無しさん
09/05/02 16:39:28
>>685
システムトレードの話かとおもった
688:デフォルトの名無しさん
09/05/02 16:44:34
言語の美しさが構文の美しさに還元されると思ってる人がいるけど・・・
そもそも、仕様が美しければ実装はどうでもいい的なことを最初に言い出したのは
いったい誰なんだろう
689:デフォルトの名無しさん
09/05/02 16:47:20
Lispでいいじゃん
690:デフォルトの名無しさん
09/05/02 16:47:55
実装なければ言語がないのも同じ。
ひとつでも実装あって動けばその言語はある。
実装あればその動作は関係ないだろう。
691:デフォルトの名無しさん
09/05/02 16:54:17
>>685
既存の言語を使いこなせないと新しい言語を作れないから、
既存の言語が使いにくいと思う人達は
新しい言語を作るところまでいきつかない。
そういう人達こそ言語に革新をもたらすかもしれないのにね。
誰でも簡単に動く言語を使えるツクールがあれば、
言語の開発が促進されるかもね。
面白いアイデアだと思う。
字句解析と構文解析は定義ファイルから自動生成できるとして、
難しいのは意味解析の自動生成かな。
自動生成できなくてもツクール内に動作を用意しておいて選択する
方法もあるけど、典型的な機能以外は実装できなくなってしまう。
692:デフォルトの名無しさん
09/05/02 16:56:27
>>688
仕様が最適化を難しくすることもあるから、
個人的には言語の仕様と実装はセットで考えるべきだと思う。
>>689
Schemeをいじってみたけど、if-then-elseなどの
普通の関数とは動作 (評価の順序) が違う機能も
同じS式で統一してあるのが嫌だった。
意味が違うものは構文も別にするべきだと思う。
Haskellのように全て最外簡約ならいいんだけど。
>>690
使える道具を探す立場ではそうなのだけど、
仕様を示すだけでも、言語を作りたい人達の参考になるよ。
(私も含めて)
693:デフォルトの名無しさん
09/05/02 18:02:35
なんだかんだCOBOLが一番読みやすい。
694:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/05/03 05:06:44
そんなあなたにSmalltalk。予約語なんてなし。分岐も繰り返しもただただメッセージングあるのみ。
696:デフォルトの名無しさん
09/05/03 07:00:01
>>686
汎用の言語と範囲限定の言語（いわゆるDSL)の2種類あると思うよ。
汎用の言語は、既存の言語をこえるものはでてこないし、Lispでいいじゃんで終わってしまったりすると思う。
面白いのは範囲限定の言語で、
～のような目的のシステムを書くために、○○のような言語を作ってみました。
っていうアイデアをもちよるのは面白いかもしれない。
美しさのひとつにシンプルさってあると思ってて、ある程度自由度をもったシステムがいかに簡潔かけたかというのがポイントの一つになり得ると思う。
697:デフォルトの名無しさん
09/05/03 07:54:00
>>696
システムの簡潔さはどうやって評価するの？
たとえば、DSLを利用するためのライブラリをリンクしなければならないとしたら、
そのライブラリを必要としないシステムよりも複雑になったと言うこともできるけど。
698:デフォルトの名無しさん
09/05/03 13:19:34
Objective-Cはなんかゾクゾクくる。
Javaさんざんやって、
Smalltalkやそのコミュニティにはなんかしらんが畏敬の念を抱きつつ、
C++行ってモヤモヤして、
Rubyをやってウハウハしてると。
699:デフォルトの名無しさん
09/05/03 16:35:35
Objective-C最高。
700:デフォルトの名無しさん
09/05/03 21:32:00
>>697
そういう評価もそれはそれでありなのでは。いろいろ評価方法はあっていいと思う。目的によって違うのでしょうから。
将来同じような目的にであったとき、そういえばこういう局面でこういう言語を使えば効率よくなるって話があったなっていう引き出しをたくさん
用意しておくのもいいのでは。
701:デフォルトの名無しさん
09/05/03 23:41:05
>>692
Schemeのifは「文」なんですよね。
特別扱いのようです。
Haskellは最外簡約で、
smalltalkはブロック（lambdaと同じ）で
無理なくクリアしているのが美しいと思います。
702:デフォルトの名無しさん
09/05/03 23:45:02
こんなのやってたんだ。。。
言語開発合宿
・2泊3日の期間内に、オレ言語の仕様とその処理系を作るというイベントです
URLﾘﾝｸ(wiki.fdiary.net)
703:デフォルトの名無しさん
09/05/04 17:27:23
>>696, >>697, >>700
「言語の」複雑さを評価する指標なら、
ASTのノード数なんてどうだろう。
同じ処理を少ないノード数で記述できたら
その言語は簡潔ということにならないかな?
704:デフォルトの名無しさん
09/05/04 19:06:02
>>703
それ全然意味ない！lambda 一発になるwW
最終的には、なにがしかの形式意味を、いかに簡潔に書きうるかだろ？
705:デフォルトの名無しさん
09/05/05 00:05:28
>>704
> lambda 一発になるwW
lambdaを使って書いた無名関数の定義が含むノード数も
評価するわけだから、それなりに妥当なんじゃない?
無名関数を使う側が1ノードになるのは、コード自体の簡潔さに対応する。
> 最終的には、なにがしかの形式意味を、いかに簡潔に書きうるかだろ？
簡潔であることを「どう評価 (数値化) するか」の話をしているんでしょ。
>>704は>>694かな?
706:705
09/05/05 00:16:53
>>703-704
問題になるのは無名関数ではなく、マクロかな、と思う。
707:デフォルトの名無しさん
09/05/05 02:22:14
>>705 ASTでは構文の持つ意味まで説明できないって言ってるんじゃないの?
708:デフォルトの名無しさん
09/05/05 03:37:30
>>702
自分で言語を開発したい/してる人って、案外いそうですね。
この板にはそういうスレが無いので、
もしこのスレにそういう人がいたら、
様子を聞かせて (読ませて) もらえると面白いと思います。
>>707
>>703の「同じ処理を少ないノード数で記述できたら」が
>>704の「なにがしかの形式意味を、いかに簡潔に書きうるか」
に対応していると見ると「処理」は「形式意味」に対応しますね。
そうだとすると、>>703は
「処理 == 形式意味」が「同じ」場合、
つまり「構文の持つ意味」を統一済みの場合についての話なので、
構文の持つ意味を説明する必要は無いのでは。
思うに、
>>707が真だとすると、>>704は既に存在するコードを対象に、
同じ量のコードがどれだけの量の形式意味に還元されるか、
という話をしているのでは。
それに対し、>>703と>>705はおそらく、
決まった課題を与えて (あらかじめ形式意味を統一して)
それをどれだけの量のコードで表現できるか、
という話をしていると思います。
709:デフォルトの名無しさん
09/05/05 19:17:58
最も美しいプログラミング言語は賛否両論あるだろうが、
最も汚いプログラミング言語の一つがC++であることに異論がある人は
少ないだろう。
710:デフォルトの名無しさん
09/05/05 20:13:38
つ COBOL
711:デフォルトの名無しさん
09/05/05 20:46:42
つ Objective-C
712:ちんこ ◆GbXlaaQNk.
09/05/05 21:34:31
もっとも美しい言語はPythonです。
ほんと、この言語で仕事ができるところに就職したい。
やっぱベンチャーを作るべきなのかな？かな？
713:デフォルトの名無しさん
09/05/05 22:12:05
>>712
ベンチャー作るのに賛成!
Pythonに反対!
714:ちんこ ◆GbXlaaQNk.
09/05/05 22:50:49
Pythonはもっとも美しい言語だろjk
これ以上に美しい言語があったら教えてくれ。
おれは知らない。
715:デフォルトの名無しさん
09/05/05 22:53:32
ぱいそんはどのあたりがうとぅくしぃのかおせーてくれ
716:デフォルトの名無しさん
09/05/05 23:01:21
>>712
宣言的とは見えない点。
オブジェクト指向である点。
インデント構文を必要とした点。
リストの内包表記は評価するけど。
717:デフォルトの名無しさん
09/05/05 23:02:25
>>715 だったね。>>712というより。
718:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/05/05 23:36:07
>>718-719
乙。
COBOLはアンチが多い一方で、魅力を語るのをなかなか見かけない。
でも、一時代を築いた言語だし、何か美しさがあるんじゃないかな。
(>>693あたり、語ってくれないかな)
721:デフォルトの名無しさん
09/05/05 23:43:03
>>719
FORTRAN訂正。。。やっぱCOBOLか。ほかはだいたい同じ感じだな。
FORTRAN 言語 の検索結果 約 204,000 件
FORTRAN 言語 美しい の検索結果 約 5,180 件
→2.53%
722:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/05/06 00:31:22
>>709
激しく同意。
そして俺はC++をさらに拡張しようとしている連中の思考が理解できない。
もう既にぐっちゃんぐっちゃんの闇なべの残飯みたいな状態なんだから、
さらに何個か残り物ぶち込んでも分かんないだろ？みたいな感じなのだろうか。
そしてそんな物をいったい誰が食うというのだろうか。
724:デフォルトの名無しさん
09/05/06 01:04:53
お前や俺が食うんだよ！ ヒッヒッヒ
725:デフォルトの名無しさん
09/05/06 06:05:56
>>723
闇鍋から嫌いな物を除いて好きなものだけにすると、
あら不思議、至高のお鍋になるんだよ。
726:デフォルトの名無しさん
09/05/06 06:51:21
>>708
おれがこの合宿に参加して、
この中のどれかのテーマの言語を開発するとする。
そして、そのテーマの命題＋美しい言語に仕上げることを目標とする。
そのとき、Lispのような言語にするだろうか。
いざ、そうなったときにはシンプルな命令体系にして、BASIC風なスクリプトにするんじゃないかなと思う。
つまり、美しい＝覚えることが最小限の言語（文法が最小）
となるような気がする。
727:デフォルトの名無しさん
09/05/06 07:01:34
>>726
そういう意味では Guarded Horn Clauses のような言語が
一番美しいのではないか。
728:デフォルトの名無しさん
09/05/06 10:01:05
>>727
平行プログラミング言語がもっともシンプルというのも考えてみれば不思議だね。
729:デフォルトの名無しさん
09/05/06 11:17:06
>>726
> シンプルな命令体系にして、BASIC風なスクリプト
HSP?
730:デフォルトの名無しさん
09/05/06 12:01:19
>>727
Guarded Horn Clauses（KL1）について調べてみた。
これは美しいね。
しかし、これの仕様と実行環境を作るのに570億円もかかっているとは…。
これといい、Σプロジェクトといい、官主導のものって無駄に金を食ってる気がする。
731:デフォルトの名無しさん
09/05/06 12:30:41
気がする？
今さら何を・・・。
732:デフォルトの名無しさん
09/05/06 13:03:30
Σプロジェクトなんて２億円を使ったあげく
結局OSはUNIXが一番いいという結論を出しただけのプロジェクトだもんな。
官僚ってアホばっかりだな
733:デフォルトの名無しさん
09/05/06 13:16:11
>>727,729
KL1は、論理や並行処理の部分を抽象化してあって、HSPはある範囲ないのGUIアプリのためにカスタマイズされているよね。
空想の話だが、
>>702のような合宿があって、そこの審査員を依頼されたとしよう。
担当は作成された言語を「美しさ」という点から評価するとする。
この場合、どういう評価観点が考えられるかな。例えば
・目的に対し最適化された命令体系・文法になっている
・目的に対して最適のパラダイムまで抽象化が行われている（構造化、オブジェクト、関数型、論理型、並行）
・ライブラリ、、、
などかな。
734:デフォルトの名無しさん
09/05/06 17:19:01
CはうつくC
なっつっ亭
735:デフォルトの名無しさん
09/05/06 19:08:13
駄洒落は寒いが、Cが美しいことは真理。
736:デフォルトの名無しさん
09/05/06 23:22:02
Pythonは'Python'という名前以外は美しい
737:デフォルトの名無しさん
09/05/07 01:24:01
>>736
あなたなら、なんと名付けるの?
738:デフォルトの名無しさん
09/05/07 01:54:56
oppai
739:デフォルトの名無しさん
09/05/07 02:13:14
HSPって昔の8bitマシンのBASICみたいだね。
美しいかどうかは議論の余地があるけど、とっつきやすく、初心者でもプログラミングしやすいと思う。
740:デフォルトの名無しさん
09/05/07 04:13:26
>>739
>とっつきやすく、初心者でもプログラミングしやすいと思う。
それって「美しい」の必要条件になり得ると思うんだけどなぁ。
741:デフォルトの名無しさん
09/05/07 06:51:23
高度なアートは素人には分からないというのもあるのでは
742:デフォルトの名無しさん
09/05/07 07:33:11
2
E=mc
743:デフォルトの名無しさん
09/05/07 10:29:42
逐次的に書けてシンプル
動作がスタック操作のみでシンプル
関数に副作用がなくてシンプル
すべてがリストでシンプル
すべてがオブジェクトへのメッセージ送信でシンプル
すべてがホーン節のみでシンプル
744:ちんこ ◆GbXlaaQNk.
09/05/07 18:33:22
とりあえず、今インターンとやらで、WinAPIを触ってる。
ひどい・・・。
C++もちょっと勉強したけど、
ひどい・・・。
Javaのありがたみが分かったのと同時に、
Pythonとかゆとり用言語だな、と感じた。
745:デフォルトの名無しさん
09/05/07 19:19:07
ハードウェアを触ればもっとひどいと思うよ。
そして、プリインストールされているOSのありがたみが分かる
または、ゆとり用OSだなと感じる。
746:デフォルトの名無しさん
09/05/07 19:31:19
haskellとかprologこそ真のゆとり言語だよ
747:ちんこ ◆GbXlaaQNk.
09/05/07 19:35:12
>>745
ハードからのシグナルをコールバック関数で受けるというプログラムを書いている。
なんか、オブザーバパターンってレベルじゃなくて、
依存の方向が逆な気がするんだよね・・・。
美しいプログラムしか知らないおれにとっては地獄も同然だぜ。
>>746
それらに実用性はないだろ。
Pythonには高い実用性がある、それに書いててwktkする何かがある。
748:デフォルトの名無しさん
09/05/07 20:12:43
>>746
'70年代のSmalltalk（＝暫定ダイナブック環境）はさながら、ゆとりＯＳか。
749:デフォルトの名無しさん
09/05/07 20:17:56
>>747 ハードからのシグナルをコールバック関数で受ける
(with-signal-handler (signal)
(case signal
(rx-ready (...))
(tx-ready (...))))
なにか問題でも?
750:デフォルトの名無しさん
09/05/08 00:04:17
>>747
Pythonはメタオブジェクトがらみになるととたんに美しさを失うからなぁ…。俺は嫌い。
751:デフォルトの名無しさん
09/05/08 00:26:52
インパクトという点ではLISPが一番びっくりした
この衝撃はあと50年は続くだろう
752:デフォルトの名無しさん
09/05/08 00:51:59
Prologのユニフィケーションほどの衝撃はなかったなぁ。
構文木がファーストクラスてだけじゃんと。
753:デフォルトの名無しさん
09/05/08 01:57:51
えー、やっぱFORTHじゃねーの？
「この世にコンピュータ言語は二種類ある。それはFORTHとそれ以外だ。」
まさにこの言葉がぴったりだと思ったよ。
754:デフォルトの名無しさん
09/05/08 05:11:45
>>738
第一回LLVM勉強会での主催者さんの資料に、
そういう名前が自作処理系の名前の候補として出てくるよ (笑
ユーモアのある、魅力的な人だったな。
>>ちんこ
URLﾘﾝｸ(blog.livedoor.jp)
C++の「醜さ」には、設計ミスとしか思えないような部分と、
意図的にやっている部分がある。
JavaやPythonとは違った「美しさ」に気付くと、
君のようにこだわりがある人は、案外気に入るかもよ。