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

最も美しいプログラミング言語は何か語れ

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

もう続けなくていいです

>>1 乙
このスレは勉強になるので続けてほしいです

Ruby

終了。

Rubyだけは絶対にない
最初にRubyなんかやるとひどい癖がつくぞ
あのちんこのようになｗ

ちんこの悪いところはコーディンクテクニック以前に優柔不断さだろ。

美しいという主観的なことを議論するのは不毛。
縞パンとレースのパンツのどちらかが美しいか、というのと同じ

ＲＵＢＹＹＹＹＹＹＹＹＹＹＹＹ！！！！！！！！！！！！！！！


このスレは終了しました・・・

＝＝＝＝＝＝ 重要 ＝＝＝＝＝＝
　このスレの内容は
　スレタイとは一切関係ありません
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

>>7
縞パンやレースのパンツをはいて何をするのかで美しさが変わるように、
プログラミング言語も何をどうプログラムするのかで美しさが変わる。

次スレタイトルは、ちんこ総合でいいよ

ちんこって誰なの

知らなくていい

一体、お前らはおれよりどの点において優れていると思っているのか？

おごらないところ

お前とは違い色んな言語、パラダイムを学習しているところ
Java、OOPだけに囚われていたら前に進むことは出来ない
関数型言語、C、機械語といった下層レイヤも勉強しれ
スタートラインに立つにはまずそこからだ

>>16
「学習した」のか「理解した」のかどちらだ？
学習することなら誰にでも出来るわけだが。

ちんこ言語まだー？
コンパイラは諦めたの？ｗ

ぶっちゃけGCなんか無いCでLispとか作るのが一番勉強になるのにな

時間がない。
とりあえず今書くべき論文２つ書いたらコンパイラに戻る。

ちんこによると下層の技術なら誰でも理解できるんじゃなかったのか？

Rubyが美しいとかいってるやしは、どの辺が美しいかいってみ
高階関数で済むものをイテレーターとかブロックとか手続きオブジェクトとか混乱した別物を導入した挙げ句、
結局変数スコープが破綻してるとか、ありえんだろjk

動的言語という時点で論外。

Rubyはオブジェクト指向に拘りすぎだし
構造も統一されてる訳でないから醜い
PerlにSmalltalkを混ぜてみただけのごった煮って感じ
素のPerlでも使ってるほうがまだマシ

それはない。PerlよりはRubyの方がいい。だけど、動的言語だからカス。型がないと意味不明になる。

ちんこ見ていると池沼のc_と高テスのkami_を思い出してしまう
っていうか高テスの方だった

Javaを究めるのもいいけど、グラフに困っているのであれば、
土台を固めるためにも離散数学や『アルゴリズムイントロダクション』を読むことをお薦めする
コードコンプレート　リファクタリング　後なんだっけ、デザインパターンかな

>>25
それらの本は全部読んだ。
いや、正確にいうとSkienaの本は最初の方とグラフのところしか読んでない。
他は困ったら読む。
おれはJavaを極めているつもりはない。
言語じゃない、もっと根本的なものだ。設計理論は不変の事実。どの言語でも共通。
Javaは修行の場に過ぎない。これが終わったらおれはScalaに移って二度と他の言語は触らない。

アルゴリズムイントロダクションの方か、Algorithm Design Manualと勘違いした。
それに、困ってるわけではない。
実装で困ってるのではなくて、設計で困ってるだけだ。
おれは設計について、悪いという点がすぐに見えてしまう。天才ゆえに。それだけさ。

Rubyは美しくはないが、左から右に書きやすい感じがする
メソッドチェーン使いまくる設計だからかねえ
だから、書き捨てには楽だと思うよ

RubyなんかやるぐらいならPythonかLispだな
シンプルなのが美しい

Ruby とか Perl とかは、そもそも美しさを求めるものじゃない。
求めちゃダメ。

Rubyなんて本気で純粋なインタープリタなんだぜ
1986年に世に出たperlですら、その時点でバイトコンパイルした上で実行してたのに
何周遅れてるんだよ
男は黙ってML
型付きλ計算の美しさに酔ってくれ

Java : 酒池 - 飲んだら楽しい幻覚が見える
C++ : 肉林 - 現実的な喜びがある

Ruby と Perl, Scheme と CL, SML と OCaml でも良いけど…

酒池も肉林もその先には身の破滅が待ってる気がするが。

チンコさんいた！！
リスペクト<m(__)m>

. 1. HTML　　　　で検索した結果　1〜10件目 / 約5,040,000,000件
. 2. PHP 　 　　　で検索した結果　1〜10件目 / 約2,970,000,000件
. 3. Java......　　　で検索した結果　1〜10件目 / 約　835,000,000件
. 4. Forth.　　　　で検索した結果　1〜10件目 / 約　323,000,000件
. 5. Ruby..　　　　で検索した結果　1〜10件目 / 約　275,000,000件
. 6. perl.....　　　　で検索した結果　1〜10件目 / 約　245,000,000件
. 7. Python...　 　で検索した結果　1〜10件目 / 約　204,000,000件
. 8. pascal...　　　で検索した結果　1〜10件目 / 約　170,000,000件
. 9. Delphi　　　　で検索した結果　1〜10件目 / 約　127,000,000件
10. VisualBasic...で検索した結果　1〜10件目 / 約　121,000,000件
11. lisp...　　 　 　で検索した結果　1〜10件目 / 約.　 26,700,000件
12. fortran 　 　 で検索した結果　1〜10件目 / 約.　 21,300,000件
13. COBOL　 　 で検索した結果　1〜10件目 / 約.　 18,500,000件
14. HSP 　 　　　で検索した結果　1〜10件目 / 約.　 12,300,000件
15. FreeBasic..　で検索した結果　1〜10件目 / 約　　 6,320,000件
16. Tcl/Tk. 　 　 で検索した結果　1〜10件目 / 約　　 4,940,000件
17. QBasic 　 　 で検索した結果　1〜10件目 / 約　　 4,190,000件
18. VisualC....　　で検索した結果　1〜10件目 / 約　　 1,360,000件
19. DarkBASIC. で検索した結果　1〜10件目 / 約　　 1,320,000件
20. BasicStudio で検索した結果　1〜10件目 / 約　　　 304,000件
21. N88basic. 　 で検索した結果　1〜10件目 / 約　　　 215,000件
22. f-basic 　 　 で検索した結果　1〜10件目 / 約　　　 109,000件
23. ActiveBasic で検索した結果　1〜10件目 / 約. 　 　　89,800件
24. 99BASIC....　で検索した結果　1〜10件目 / 約. 　 　　11,500件

3Dprogramming で検索した結果　1〜10件目 / 約794,000件
2Dprogramming で検索した結果　1〜10件目 / 約. 57,400件

intel で検索した結果　1〜10件目 / 約729,000,000件
amd で検索した結果　1〜10件目 / 約355,000,000件

ちょっと前はこういうスレってHaskellって言う人であふれかえってたよね。
彼らはどうしたんだろう。
Haskellでアプリケーション作るのに飽きちゃったのかな？

習得しやすくて早いOcamlやLisp系に鞍替えしたとか

Haskellで何か作ってるのをほとんど見たことがない

今月中にReal World HaskellとProgramming in Haskellの翻訳が
出版されるから、また増えてくると予想。

Haskell関連株ってなんかないかねぇ

Haskellはアクション、モナドが面倒くさそうだからなぁ
ちょっとした使い捨てコードなんかも気軽に作れないし
ここらへん不純なLisp系やOcamlなんかは楽でいいな

不純は美しくないだろ？
美しいって言葉はschemeだけが受けることが出来る。

pureとかconsistentとか、それだけじゃダメなんだ
Remember Smalltalk!

Smalltalkの何を忘れてはいけないのかな。

>>35
Google Trendを使った方が正確なんじゃない？
tttp://www.google.co.jp/trends?q=PHP%2C+Java+%2C+Ruby%2C+Perl%2C+Python&ctab=0&geo=all&date=all&sort=1

>>41
schemeもLisp族、副作用のあるコードを書けるだろうに

それにしてもPugsはどうなったのやら

ちんこちゃん、ニュー速＋のRubyスレで暴れてたね

さすがは我らのちんこ！！
このスレの代表として暴れるてくれることを望む

>>43
Rememberは｢よろしく｣じゃないか？
出る単の最初の一ページ目を忘れているよw

>>40
ちょっとした使い捨てコードなら、
Haskell 含めてたいていの言語で気軽に作れる。
単に慣れの問題だ。

まぁちょっとした使い捨ての意味は人それぞれだから、
自分には無理と言われれば反論できんが。

奴のBlog見てみたが
何を悩んでいるのか全然理解できん
こいつは出来るのか出来ないのかどっちなんだ
普通の人間なら簡単に出来る事を難しく考えすぎてないか？

知能レベルはそれなりに高いのに、頭の使い方を知らないがために全く活かせてない輩なのだろう。
そういう意味では、無駄に賢い人口無能のようなもんだな。

s/人口無能/人工無能/

頭が固いつーか、経験が足りないつーか
まぁぶっちゃけ人の話も聞けない馬鹿だよな
部分部分ではいいところもあるのに、色々と惜しい

まぁ一応あれでも高学歴だからなｗ
学校の愚痴もかかないし上手くやってんだとおもう
けど奴の考えてる理論は、ふつうプログラムずっとやってれば感覚的に分かってるものだと思うんだよね
（奴がそれ以下だったっていうオチかも）
それさえも数年したら古くなっていくんだから
そんな躍起になって研究することじゃないんだよ･･･　時間とか学歴とか色々なものがもったいねえ
早いとこ何か１個くらい公開出来る作品つくれよ、と思う

Clojureはどうだろう

お前らどれだけ学歴コンプなんだよ。ただの基地外じゃねえか。

マジで天才だと思うよ。凡人の俺には理解できないけど。
そのうち、歴史に名前が残るようなすごい成果が出てくると思う。

感覚的に分かっている（と錯覚している）ことを
敢えて論理的に考え直して文章に起こすのは、
俺は好きだけどな。

気分で物言うなよｗ

>>57
Java,C#,D,Scalaを越えた凄いもの
美しきちんこ言語を作ったら認めざるを得ないな

まぁ今の調子じゃ無理だろうがｗ
天才を自称するならそのくらい軽くこなしてもらいたいものだな

おまえらほんとにちんこいじりが好きだなｗ

なんかちんこのblogみたけど死にかけてるな。

ちんこが死にたがってたり統失っぽい事書いてたりするのはいつものこと
気が付いたら立ち直ってるからな

ちんこマンセー！！
ちんこマンセー！！

ただのかまってちゃんなんだよ。

もうちんこスレ立ててそっちでやってくれ。
ここでは最も美しいプログラミング言語の話がしたい。

まぁ鬱の気が多いほうが技術者としては優秀
それに負けなければの話

>>55
実践的なscheme-likeな言語という位置づけ？
情報が少なすぎて現時点ではなんともいえない
本が出たらそれ読んで考える

>>66
そうは言っても、主観で美しい、汚い言い合ってるだけじゃん。

そろそろチンコ氏の鶴の一声が必要・・・・・

>>69
ちんこの話よりマシだ

>>69

それが楽しいんだよ。結論なんて求めちゃいない。

じゃあ俺は Haskell に一票

brainfuckはλ式のような美しさがある

美しさを測る尺度を示してほしい

美しさに尺なんてあると思うのか

お前らはプログラミングが難しいということが見えていないだけだ。
知能指数が低すぎるのだ。
だから、お前らには、おれの悩むポイントが一生理解出来ない。
だが、それは幸せなことだ。安心して欲しい。
バカだから、核心に気づかず、分かったと錯覚して幸福を手に入れることが出来る。
核心に迫りすぎて精神を病んでしまうより、人間の生き方としてはよほど優れている。
おれはもうダメだ。
頭が良すぎる。

金子勇はソースコードがうpしている。
はっきりいってひどい、0点だ。
だが、おれは彼を天才だと認めている。
そして、彼は自分の興味を、どう作るかではなくて、何が動くかに向けたため、幸せになった。
Linuxのカーネルもライナスが書いたコードはひどかったと聞く。
あまりに頭が良すぎる場合、「どう作るか」について考えるのは良くないのかも知れない。

おい
ちんこが死んだらお前らのせいだぞ
何だかんだ言ってちんこはこのスレで傷ついている

見た目の美しさと機能美の両方を持っているのはHaskell

プログラミングが難しい？当たり前の事だろ
柔軟な発想、幅広い視野を持てない時点で論外

>>81
お前はおれより優れているのか？

>>68
本なら1冊すでに発売されてるね。
ttp://www.amazon.co.jp/dp/1934356336/

この本の翻訳版もそのうち発売されるみたい。

金子勇
無罪判決
よかった・・・・・。

>>84
おれ、裁判は分からんけど、
大阪高裁で無罪になったら無罪確定ってこと？

最高裁まである。

clojureとかscalaとか、JVMに頼っているとマルチコアに対応できなくね？

練習問題：「マルチコア」の部分に、JVMが対応していない任意の機能を代入して、その影響を考察せよ

ということは、まだ無罪ではないんだろ？
ぬか喜びじゃん。
それとも、傾向として、高裁の判決はなかなか覆らないというのがあるのか？
絶対最後まで控訴しますということであれば、最初から最高裁でやりゃいいのに。

上告するかどうかは原告と社会情勢次第。

>>88

>>85 = >>86

自前にググって裁判の事調べてたんだろ

ちんこキャップ使って自作自演とは
ちんこ、役者だなーお前ｗｗｗ

おい、ちんこちゃん♪
なんか言えよカスｗ
聞いてんだよこっちは

>>90
実はこのスレにはお前とちんこしかいないんだ

>>92
そうだったのか・・・・＞＜

>>78
問題は、細かいことを後回しにできるかどうか。
完璧主義だから後回しにできないという面もあるかもしれないが
もしかすると短気なだけかもしれない。

最初に不完全なものを作り改良を繰り返し完成させるという手順は
気が短い人間には耐えられないだろ。

おれは神経質な男だ。そして完璧主義者だ。
だからソフトウェアには向かない。
今、おれは、「自分が心地よく開発出来る設計理論」を模索している。
そのためには、根本的に設計理論を理論して、それぞれの得失について考察する必要がある。
その上で、こういう方法であれば、常に合理的で悩むことなく開発出来るという方法が見つかればよい。
おれは実装能力が高いので、そういう流れに乗れば、さくさく開発が出来るだろう。

Haskell 98で書かれたプログラムは永遠です。
ソフトウェアのアイデアは、言語処理系の実装に関するものを除いてすべて、
Haskellモジュールとして保存されるべきです。

Haskellで何か実用的なプログラムを書こうと思ったら、
モナドを理解しないといけないんだぜ？
モナドを理解しなくても書けるかもしれないが、少なくとも
副作用の有無の概念と、副作用の扱いによる記法の使い分けは
学ばないといけない
そして、リストの内包表記と再帰についての概念、あと最低でも
高階関数の概念は必須だろう

これらはオプションじゃなくて必須
そんな言語が流行るわけがない
Scalaですら流行るかどうか怪しいと俺は思ってる

お前らスレタイ100回読み直せ

やっぱりお手軽なLispだな
Ocamlもいい感じな気がする

>>88
お前年間に何件裁判あると思ってんだよ

ちんこいじりはいいから言語の話をしようぜ

> おれは実装能力が高いので、
ん？

> おれは実装能力が高いので、
> おれは実装能力が高いので、
ん？

んん。何だか眠いか

>>95
そうだな、お前みたいな奴には向いてないよｗ
せいぜいチンカスの掃除でもしてな
そして二度とお前のその長文オナニーはチラシの裏にでも書いてろ
わかったらさっさと消えなさい


ｗ

この社会が全て正しいとは思わない。
でも、何か間違っているから全てを変える必要があるし
全てを変えなくてはダメなんだって思うなら
全てが変わるまで何一つ出来ない。
そしてそういうことを言う奴に限って何一つ変える力なんてない。
もちろん屁理屈言って自分を正当化するぐらいはできるだろうけど。

感覚的に、気楽に、誰でも、いろいろな視点で、
美しいと思った言語を言ってみるスレに
戻そうよ。

Cはきれいだと思う。
ガベージコレクタとか無くて、
全部自分でやんなきゃいけないから。
そういうシンプルなところがいい。

正規表現をサポートする言語は全部美しくない。

かりやざきしょうぞうに比べると全てのモノは美しくない

後付け感のあるオブジェクト指向言語も美しくない。そう考えてみると、
Erlang　は美しい。

実用的なものはCommon Lisp、JavaやC++、Perl、COBOLしかり
往々にして汚ないものなのだ

だからそれらは失格。

行末セミコロンみたいな不要なものを付けてる言語は美しくないよね

ちんこ起きたかー？

美しいって言っても曖昧すぎる
漠然と、「不要なものが無いから美しい」派と
「ソースコードの見た目が美しい」派がいるのは
なんとなくわかるけど

おれは池沼だ。もうダメだ。
お前らは立派な開発者になれよ。

ちんこって学生なん？
何才？

ム板は職業的な強固な主張が展開されることが多い。そんな中にあって
このスレのような審美性を拠り所とする曖昧さは誰にでも参加できる余地を残す。
そういう観点からは、前々スレ後半から前スレ、そしてここまでの展開では
その曖昧であるが故の余慶というものがない。

数学と違って工学はトレードオフとの戦いだからな
ちんこはソフトでなく数学の方にいったらいいんじゃね？
ラムダ計算とかコンビネータとか面白そうだぞ

もしこのスレにいたいならJavaとRuby以外の言語をマスターするか
美しいちんこ言語を完成させてこいｗ

C++　Lisp　Perl　Javascript　おｋ

>>97
流行るかどうかなんて、このスレ的には意味ないんじゃないか

関数型言語は綺麗に見えるが、Cのトリッキーな構文にも美的センスを感じる
Perlは記号だらけで、美しくはない。それ以外は好きだし、便利だとは思うが。
Pythonは空間の美学を体現している言語と言えるだろう。（ただしWhitespaceは考えない。）

pascal
smalltalk
haskell

実用性なんて飾りです。えらいひとには(ry

たとえば「数独を解くとはどういう事か」＝「こういう事だ」
というように思考と記述が近い美しさを Haskell は持っている。
これを一言で何て言えばいいのか、語彙がないので分からないが。

他の関数型言語については知らん。

思考と記述が近い？
あの副作用さえ許してくれない言語が？

思考の形式にも手続的と宣言的とがあるんだよ。

プログラミング言語の美しさと実用性の間に無視できない隔たりがあるということは
土台になるハードウェアアーキテクチャになにか問題があるのではないか？

美しさを紹介するだけ、実用性を紹介するだけならいいが、
それら間に隔たりがあるかどうか、あるならその原因は
土台になるハードウェアアーキテクチャにあるのかを語るには、
やはり美しさと実用性を定義しないと話が有意義な方向へは進まんと思う。

その定義は狭義の意味でもいいし、この話だけで通用するものでもいいが、
話を進めるにはとにかく何かしらの定義が必要だろ。

いま>>126が真実を言い放った

真面目な議論はもっと賢い人達に任せとけばいい

もっと賢い人・・・ちんこか

PostScript
異論は許さない

だからさ、PostScript の何が美しいのか言えって。
じゃないと、どこら辺がギャグなのか分からんだろうが。

>>127
つ言いだしっぺの法則

まさか誰かが定義を与えてくれるとか、自分の発言を機に
みんながディスカッションしてくれるとか思ってないよね？

The Cat Programming Language
スタック言語の最高峰
静的型付け、項書き換え
PostScriptなんか捨てたくなるほど美しい

>>133
その法則は日本人の芽を摘み取る為のものだからリアルで言ってると嫌われて孤立しますよ

>>133
逆だ。
ここでは俺も含めて誰も定義できないだろうから、
話は有意義な方向へは進まんだろう、
つまりディスカッションはできないのではないかと言いたかった。

>>135
わけのわからん理屈だな。

なごやかに雑談している最中に、いきなり正論を振りかざそうとするなら、
まず先に自分の持論を語れと言ってるだけだろ。
別に、その持論は正しくなくてもいい。単なる「叩き台」だ。
そんな叩き台ひとつ出せずにお子様モードで語るから、
>>133みたいな法則が必要になるんだヨ。

ハードウェアアーキテクチャが
美しくないから嫌いなの？嫌いだから美しくないの？

>>136 と思っていたが、>>137 も一理あるな。
自分の意見が正論であった自覚も、
お子様モードになっていた自覚は無かったが、
周りからはそう見えていたのか・・・

では、その「正しいかは分からんが叩き台としての定義」を言ってみる。
できるだけ、数値で比較できる定義を選んでみた。

(1) プログラム言語の美しさ
ある特定の振る舞いをさせるために必要な文字数の少なさ

(2) 実用性
IT関連会社が採用した言語の事例数、あるいは、
ある言語を習得したプログラマの募集人数

文字数の少なさで言えば、Short Codingという
文字数の少なさを競うプログラミングのスタイルが
あるのだが、そのShort Codingのソースコードは
とても美しいとは思えないほどぐちゃぐちゃなコードだ

LaTeX

Code Golfのランキングってどっかから見れなかったっけ？

>>140
いや、だからな、それはあなたが {コードの美しさ＝文字数} とは考えていないからだ。
文字数とは違う何か別のものに美しさを見出している。

>>139 では、「仮に」 {コードの美しさ＝文字数} と定義したとしたら、
>>126 はちゃんと議論できるんだろうか、と訊きたかったんだ。

>>126 ほど深く掘り下げた議題で議論するにはある程度定義しないとできない、
というのが俺の考えで、とのあえずその定義例を示してみたが、
この定義がダメなら別の定義を与えないと議論はやっぱり進まないと思う。

このスレでは感覚的に美しい、汚いと言い合うのが限界だと思う。

>>143
一レスで見切るって早すぎｗｗｗｗ
もう少し粘ろうよ

参考：conciseがnormalized source code sizeということらしい
この指標だとスクリプト系言語が強いね。意外とHaskellが弱い。

ttp://shootout.alioth.debian.org/u32q/shapes.php
ttp://shootout.alioth.debian.org/u64q/shapes.php
ttp://shootout.alioth.debian.org/u64/shapes.php
ttp://shootout.alioth.debian.org/u32/shapes.php

>>143
そりは「叩き台」という言葉の意味を取り違えていないかい？
叩き台ってのには、何らかの根拠があった上で
「だから自分は(>>143は)こう考える」という主張が前提になるよ。
その根拠は>>143の主観だから、別に正しくなくてもよいということ。
他の人が別の主観をぶつけることで反論が生まれ、叩き台として成立する。

最初から「仮に」なんていう「逃げ口」を用意しておくのは、大人の態度じゃないね。

>>145
わかった、わかった。
あの定義例にはそれなりの根拠はある。

Ａ「プログラミング言語の美しさと実用性の間に無視できない隔たりがある」ならば、
その原因はＢ「土台になるハードウェアアーキテクチャにある」のではないか、
というのが >>126 の問題提起だと思う。
逆に言えば Ｂ->Ａ だ。

これが正しいかどうかを議論するには、
ＡとＢに対して、議論する人同士の間に共通認識が必要だろ。
共通認識は議論する人がそれぞれ感覚で考えてたら生まれない。
なので、「できるだけ」感覚に頼らずに共通認識が生まれる定義が必要。
そこで、数値で表せて、かつ誰が考えてもほぼ同じ数値になるものなら
共通認識が生まれるのではないかと考えてみた結果が >>139 の定義だ。

正直、美しさ＝文字数というのは個人的には気持ち悪い定義だと思っているが、
>>126 を真面目に議論するには、今のところこの定義しか俺は思いつかない。

perlとC++があれば生きていける

>>146
それで、Ａ「プログラミング言語の美しさと実用性の間に無視できない隔たりがある」の真偽は
決定できるとして、命題Ｂ->Ａの真偽はどうやって決定するの？

ハードウェアアーキテクチャごとにAの真偽を決定する？
ハードウェアアーキテクチャってそもそも何？

LISPマシンアーキテクチャ上ではLispは最高に実用的で、他の言語はLispに劣ると
思うんだけど、美しさって全然関係なくない？

>>148
> 命題Ｂ->Ａの真偽はどうやって決定するの？
議論する人みんなが、ＢがＡの原因になっていると認めれば真だと思うが、
違うのか。

> ハードウェアアーキテクチャってそもそも何？
>>126 に訊いてみてくれ。

俺は、コンピュータ全般の設計思想において
特にハードウェアに関わるものと捕らえているが。
もう少し言えば、CPU が計算する仕組みとか。
データを格納する為の物理的な仕組みとか。

>>150
> 議論する人みんなが、ＢがＡの原因になっていると認めれば真だと思うが、
> 違うのか。
なんだその日本的和を以って貴しと為すメソッドｗ

プログラムの美しさはハードウェアに依存しない。実用性は依存する。
ハードウェアアーキテクチャに何らかの序列をつけて、その序列と
（美しさ（定数）と実用性（変数）の差の指標）の相関をみればいいだろう。

決めなきゃいけない事柄は>>139だけじゃ全然足りない

お前らの仕事って何？
研究者いる？

ソフトウェアの研究って凄く胡散臭そうだな。
このスレみたいに美しい言語とか考えてんのかな。
間違いなく給料泥棒だろう。

Scalaの開発者が研究者なわけだが。

>>151
> なんだその日本的和を以って貴しと為すメソッドｗ

だって、数学みたいに論理的に正しいかどうかを決めることはできないから、
みんながだいたいOKならOKで終えるしかないような気がする。

俺が定義が必要じゃないかと言ったのは、
議論をスタート地点から有意義に前に進めるためだから、
終えるのはだいたいOKでいいと思ってる。

>>153

ソフトウェアの研究というのは、おそらく「ソフトウェア工学」を意味してる。
それでは工学とは何か？だけど、土木/建築の分野では、数学を基礎とする理論に
基づいて設計が行われ、想定された状況下では絶対に崩壊しない設計値が算出できる。
それらは、いわゆる土木工学/建築工学と呼ばれている。

ではソフトウェアの分野ではどうか？現状は、未だに個人の能力に依存している。
言い換えると、プロジェクトの成功/失敗は、職人の「技能/技法」に頼っており、
とても「工学」と呼べる代物ではない。この問題を何とか打開しようとする試みが
ソフトウェアの研究(狭義のソフトウェア工学)である。

以下は、C.A.R. ホーアの論文「プログラミング - 魔術か科学か？」からの引用。
全文は以下の書籍(論文集)を参照。
・IEEE ソフトウェア '88, IEEEソフトウェア編集委員会編, 岩波書店

　職業としてプログラミング業務を行うためには、基礎となる数学理論に基づき、
　すでに確立された他の工学分野の先例にならわなければならない。
　これは教育を改善することによって実現することができる。

土木/建築工学の分野には様式(アーキテクチャ)という概念があり、その「美しさ」も
評価の観点の一部である。同様に、ソフトウェア工学の分野であっても、
プログラミング言語のアーキテクチャ(手続き型/関数型/論理型/代数型)を評価したり、
それらの「美しさ」を評価の観点として考えることは、決して間違いではないと考える。

>>156
てことは、美しさを客観的に測る指標を定義するアクションは当然行われている？

言語の美しさを判定するプログラムを作れば解決

こういうのを見ても、文字数＝美しさだと思う馬鹿なんているの？
http://www.4dm.org/ShortCoding/index.php?POJ1002

ShotCodingは読めるソースなら最高に綺麗に見えてくるよ

- 生産効率向上には何が必要なのですか。

体系的に簡素化された言語仕様、これに尽きますね。

- 人的負荷（ヒューマンオーバーヘッド（以下H.O.H.））の問題の解決にあたっては、言語仕様の簡素化や、APIを経由した複雑な
　 プログラミングの回避が必要になりますね。

30年前のパソコンブームの火付け役になったのがBASICですが、CPUやハードウェアの違いを乗り越えて爆発的な普及力を見せ
付けました。

BASICの学習に必要なのは、中学生程度の学力と、紙切れ1枚程度の簡単なマニュアルだけで覚えられると言う特徴があります。

- それらの背景には現行の開発システムには存在しないインタープリタ、フルスクリーンエディト、ダイレクト実行モードなど、小回
　 りの利く機能がありましたね。

現在の開発システムの周辺環境は大規模アプリケーション作成向けが主流であって、セルフフィードバックの効果の高いインター
プリタ、フルスクリーンエディト、ダイレクト実行モードなどの機能は置き去りにされています。

これは大学や企業の教育機関が、実際に機能している間は問題ありませんが、それらが機能しなくなると開発システムの根幹は
緩やかに崩壊していきます。

なぜなら、ユーザーである学生や研究開発要員が、セルフフィードバックの機会、つまりは自習の機会を失ってしまうからです。

- DarkBASICにはダイレクト実行モードはありませんね。

デバッグモードはありますが、ダイレクト実行モードはありません。

- セルフフィードバック（自己帰還）と、大学や企業の教育機関、どちらに信頼を置くべきですか。

どちらにも信頼を置くべきですが、生産効率だけではなく、将来への展望に備えた自己啓発が必要不可欠であると思います。

>>160
Shot

- 人によってはセルフフィードバックが自己嫌悪に陥る場合がありますね。

企業でよく見られるCプログラマがそれに相当します。
彼らはもうすぐリストラの対象になります。

文字数なんていう単純なもので美しさは図れないな
ShortCodingがちっとも美しくないのは当たり前として、
for文がf文だったら美しいのかというのもある

アメリカ人にとって英語は美しいかもしれないが
日本人にとっては英語は美しさ以前に読めないなんてパターンもある

>>157
たとえば法隆寺の五重塔は、美しさと耐震性を兼ね備えた建築様式だと思うけど、
その「様式美」を客観的に測る指標(尺度)ってあるかな？たぶん無いと思う。
美しさは愛でるものだから。

言い換えると、美しさの定量化は不可能だよ。でも、その美しさを批評したり、
議論したりすること自体は、建築でもソフトウェアであっても無駄なんかじゃない。

美しさの定量化

いろんな建築物の写真をたくさんの人に見せます
美しさを評価させます
結果を集計します

アルファベット使ってる時点でどうなの？って思うことはある。

>>166
> 美しさは愛でるものだから。

> 言い換えると、美しさの定量化は不可能だよ。でも、その美しさを批評したり、
> 議論したりすること自体は、建築でもソフトウェアであっても無駄なんかじゃない。

それじゃ建築工学もこのスレと同レベルじゃないか。

Bertrand Meyerの本が届いた。
お前らは彼女いたり、結婚してたりするのか？

>>169
もちろん「美しさ」については同レベルだろうね。
ただ「耐震性」については建築工学なら数学/物理学を基に定量的な強度を設計できる。
しかるにソフトウェアはというと....。

>>171
あー、なんかわかる気がする。評価関数が情緒的だよね

関数型のひとたちが型推論があるからコンパイルが通れば型エラー出ないよ、
とか言うけど、それがどれくらい嬉しいのか定量的な解釈はしてくれない

そこには型の矛盾を完全に消すまで全く実行することができない、という
トレードオフがあるはずなのに

建築はどっちかと言うとハードウェアだろ
ソフトは定量化できてもせいぜい、地価や株価のような変動する量になりそうだ

>>173
それならそれに適したアプローチが必要かな
手法的には工学よりむしろ経済学だね
それに統計学が必須のスキル

Haskellの期待値は無限大です

- 結果としてBASICが根幹にあるんですね。
　 どうしてでしょうか。

簡単で手軽、誰にでも学習の機会があることでしょうね。
CやHSPだとこうはいきません。

CやHSPだとAPIのノウハウが必要になりますし、それは大きな障壁となります。

>>170
彼女はいる。
けど、結婚の予定はなし。

最も美しいソフトウェアの書き方は直感主義論理に基づく数学だよ
将来実行できるようになるといいね

>>172
> そこには型の矛盾を完全に消すまで全く実行することができない、という
> トレードオフがあるはずなのに

それもよく聞くが、そもそも型が合わなくて
コンパイルが通らず悩みまくるという状況はほとんど無い。

C# や Java で型が合わずにコンパイラが通らず
悩みまくるという状況が無いのと、ほぼ同程度かちょっと悩むくらいだ。

しかも悩で理解できた後には、型推論があって良かったと思える。
だから、それがトレードオフだという認識すらない。

>>179
だから「ほとんど無い」とか「ほぼ同程度かちょっと悩む」とかを
定量的に論議しないと、単に誤解が広まっているのか
お前がものすごく頭がいいのか、周りには区別がつかないだろ

>>180
あぁ、そう言うことか。
勘違いしてた、ごめん。

議論の余地がないから定量的って言うんですよ

プログラムって、人間の思考を再現しているのではなくて
最早考える余地のないルーチンワークを再現してるんだよね

>>144
これって、全般的に速度を優先してるコードが多いし、
簡潔さをこれで測っても意味がないんじゃないかな
簡潔さを優先したら、ShortCodingみたいな
ソースコードになるはずだし
全然違った結果になるだろう

仕様はどうなってるのか、とか、バグがあるのかないのか、とか
知りたいことを知るためにグダグダ議論したり考えたりしないといけないプログラムは
醜い。
逆に言えば、簡潔なプログラムは美しい。

>>185
たとえば？

>>185
アセンブラとか Grass とかの極端な例を除けば、
たいていのプログラム言語は実用上十分に簡潔なプログラムは書けると思います。

それができない時、主な原因はプログラミング言語にあるのではなく、
それでプログラムしている人間、あるいはその人間を取り囲む環境の方に
あるのではないでしょうか。

つまり、>>185 の意味で言う美しさ（簡潔さ）というのは、
プログラム言語によって変わるものではないような気がします。

>>187
あ、敢えてプログラミング言語と言わずプログラムと言ったのは、
言語とは切り離して、プログラムする事について語っているからでしょうか。

- それはCやHSPでもAPIや外部のDLLを使えば簡単にできるでしょう？

確かにそのとおりです、しかしH.O.H.の問題は解決できません。

言語ごとの得手不得手、用意されているライブラリ、データの扱いなんかいろいろ違うし
同じ土俵で語って、あれがだめこれがいいとかばっかじゃないの

もまえらプログラマなのに、なぜ物事を量子化して考えない
美しい基準を決めてそれを数値として比較すれば良いではないか
アナログな美しいをデジタルな美しいに変えれば済むことではないか

量子化って何だよ

>>191
それが出来ればオリンピック競技に応用できそうだな。
体操の床とかフィギアスケートとかシンクロとか。

ミスコンはすぐ数値が出てしまうから廃止か？

それはそれでつまらんけどね。

よくこんなつまんねえ話で盛り上がれるな……
ほんとに日本人かおまえら
民度を疑う

>>194
もっと素直に「寄せて」って言えよ。

寄せて上げて寄せて上げて谷間くっきり♪

気持ち悪いスレだ
全員うつ病なんだろうな

ダッダーーーン　ボヨヨンボヨヨン　あぁあぁあああーー

プログラムで美しいとかいってんの頭悪い

かなりのレベルの奴がいってるならいんだけど
レベル低くてまともなものも創れないのに美しさなんてかたってるばあいじゃねえだろ
勉強してこい
それから語れ

いや、お前がなんと言おうと語るね。
たとえ<stdio.h>を<studio.h>って書き間違えるようなレベルでも語ってやる。

ｗ

それよくやったな。

何でコンパイルが通らないのか相当悩んだ。
危うく2chにソース載せて質問しそうだった事もあったっけ。

コンパイラ→コンパイル
インタプリタ→？
教えてください

interpret インタプリト

むしろ「実行」

>>204
あざーーーっす！！

宗教やら彼女が欲しいやら精神的にかなり参ってきてるようだね

天才にはよくある事らしいから、そっとしといてやれ

お前ら、バートランドメイヤーのオブジェクト指向入門は読んだか？

>>209
今更そんな本読まなくていいよ
オブジェクト指向に学ぶ点はない
読みたいなら止めはしないが

>>209
メイヤー本ならDbC押さえとけ。OOP以外でも役に立つから。

ちんこは英語読めるんだから中古で安く買えばいいのに

>>210
「今更」の意味が分からん。
あなたは、オブジェクト指向のすべてを知り尽くしているのですか？
神なのですか？

>>211
あなたはDesign by Contractの何を知ってるというのですか？

>>212
あなたにとっては、たかだか7000円の本が高いのですか？
あなたの人生はどれほど安いものなのでしょうか？

>>213
オブジェクト指向をなにやら深遠で難しくて有難いものだと思いたがる人々が居るのは知っている
あんたもその口かい？

>>214
別にオブジェクト指向が徳の高いものだとは思っていない。
ただ、原理的に、それほど簡単に理解出来るものだとは思っていない。
実際におれは、形上はオブジェクト指向で開発が出来るが、全く理解していないと思っている。
単に理解したという状態に対するしきい値の違いだとも考えられるが、あんたらはたぶん何も分かっていないのではないかと思っている。
それらの人は、ただ自分のテリトリーを主張したいだけで、実際は何も分かってないと思う。
おれは彼らとは違う。
おれはオブジェクト指向を真に追求したいだけだ。
それほどまでに、プログラミングはおれにとって不思議だらけなんだ。

http://web.archive.org/web/20061229213723/http://se.ethz.ch/~meyer/down/touch/TOUCH.pdf

>>216
ありがとうございます。
出版されたからドラフトが消されたみたいで、探してもなかったんですよね。
感謝します。
これはETHの教科書みたいですね。
バートランドとは一度、酒でも飲みながらOOについて語りたいです。

>>215
プログラミングを追及したい気持ちはわかる
まぁがんがれ
結論から言うと、オブジェクト指向なんてデータと手続きをまとめて第一級化してしまったがために
状態数を無駄に増やしてしまった筋の悪い方法論
頭の片隅に入れとくといいよ

>>218
なんであなたには結論が分かっているのですか？
あなたは神なのですか？

データと手続きをまとめて一級化したというのは、
「まとめてから一級化した」という意味なのか、「まとめたから一級化した」という意味ですか？
おれの第一級市民の理解は、変数名がつけれるかどうかです。
なので、データは最初から第一級です。
なので、後者の理解は間違ってると思っています。

さて、前者の理解だと、
「まとめてから第一級化したから悪い」ということになります。
ということは、「まとめずに第一級化したらよかった」となります。
データは最初から第一級なので、「関数を第一級にしたらよかった」ということになります。
しかしこれでは、ステイトレスな関数が増えただけであって、C言語のような言語から、状態は増えていません。
なぜならば、データの分だけしか状態がないので、データの数は同じだからです。

あなたは、関数型をベースにして話をしているのですか？
「増やしてしまった」の出発点が不明です。

こんな曖昧な文章を書く人間がオブジェクト指向を完璧に理解してるとは到底思えない。

>>219
「まとめて」の意味が理解できなかったか
暇なので少し教えてあげるよ
オブジェクト指向の出発点は複数のデータと複数の手続きを内包する変数（つまりオブジェクト）を作るともしかしたら便利なんじゃない？ってところ
これが「まとめて」の意味
# あっ、ちなみにメッセージが本質とかいってる奴らは無視すればいいよ
# 議論を発散させるからw

>>220
それは当たり前です。

「増やしてしまった」の出発点はどこですか？
何に比べて増えたんですか？

おれには増えてるようには見えません。

>>221
おや？理解したらしい
じゃぁ次のステップだよ
オブジェクトは「状態」を持っているね
しかも破壊的に変わる
すると、その「状態」はオブジェクトが内包している手続きの呼び出し全部に影響を与えてしまう
ほら、余計な心配が増えちゃった
つまり、考慮しなきゃいけない状態が増えちゃったってこと

>>218,220
抽象データ型の一言で済むものを、もったいぶって説明してるようにしか見えない

関数型は計算のレベルで抽象化するのに対し、オブジェクト指向は妄想のレベルで抽象化するからね。

それはOCaml(Objective Caml)がゲテモノであるという主張か？

Blogのソースはかなり大変なことになってるしな
自分と思うところまでやりゃーいいと思うよ

つうか、JAVA言語の限界きてる気がする
お前の才能はJAVAじゃない
オススメできる言語はないが、ソースコードが狭苦しそうに見える

>>225
まさかここにfunctional objectsを知っているマニアがいるとは思わなかったwww

オブジェクト指向が有利になる用途なんてシミュレーション以外に思いつかない。
オブジェクト指向はコンピュータの中に虚構を作り上げることだ。
実世界をシミュレーションすれば仮想現実だし、言語処理系を実装すれば仮想機械だ。

ノンノンノンノン
ＪＡＶＡ
→java

オブジェクト指向
って>>218,220,222で合ってるの？

だとしたら、ほんと学ぶ意味も無いっていうか･･
普通に適材適所で行う事だよね
オブジェクト指向ってそれより先に何かあるのか？

>>230
だからシミュレーションって言ってるだろ。
オブジェクト指向の先に何かあるのかという問いは、複雑系の先に何かあるのかという問いにほとんど等しい。

いや、おまえわけがわからない

>>230
まったくの嘘は言っていないけど、言い残していることも多い。

例えば、抽象データ型で粗い設計と細かい設計を分離すれば
*一度に*考慮しなきゃいけない状態は減るよね。
分離の仕方が上手ければ状態の総量は増えないから
結果として開発が楽になるかもしれない。

＞だとしたら、ほんと学ぶ意味も無いっていうか･･
＞普通に適材適所で行う事だよね
というのなら、他の人に設計を説明するくらいしか役に立たないかも。

グローバル変数とは違う形で、関数の外に変数があると便利じゃないか
それだけでも、無いよりまし

ちなみに、関数の外の変数のことをlet over lambdaと呼ぶ人もいる

>>227
なんだ、こんな質問にも答えられないのか。

>>228
オブジェクト指向が妄想/虚構であり、シミュレーションくらいにしか
有効に活用できない存在であると仮定する。
では、オブジェクト指向を取り入れず副作用の無い純粋な関数型言語
(たとえばCaml/FP/Haskell/Miranda/MLなど)で実装された
オペレーティングシステムとウィンドウシステムは存在するか？

ちなみに、命令を抽象化する手続き型がオブジェクト指向を取り入れ、
実用的なシステムが開発されているのは、だれでも知っているはず。
論理型言語でもオブジェクト指向を取り入れたシステムが試作され、
国内の一部機関(ICOTなど)で試験運用されたのを知ってる人も多いだろう。
上記の質問は「純粋な関数型言語はシステムプログラミングに役立つのか？」
という解釈でもかまわない。

この質問には答えられるかな？

>>230
心配事が増えるということ　＝　テスト項目が増えるという意味だろうが、
従来の手続き型／構造化プログラミングと、オブジェクト指向プログラミングではプログラムモジュールの粒度がまるで違う。
つまりオブジェクト指向は構造化プログラミングよりも細かい単位でのテストが可能ということ。
「この1000行のモジュール中にバグがあります」と言われるのと、
「この100行のモジュール中にバグがあります」と言われるのでは後者の方が修正が楽だと思わない？

>>236
オブジェクト指向がクソであったとしても、オブジェクト指向でないものがクソでないことを保証するものではないよ。

粒度が気になる人はレキシカルクロージャーを使おうね！

>>237
>従来の手続き型／構造化プログラミングと、オブジェクト指向プログラミングではプログラムモジュールの粒度がまるで違う。

意味不明な文。両者の用語は比較の対象として不適切だから。

オブジェクト志向って何ですか？

>>238
結局、>>225,236みたいな簡単な質問にも答えられないくせに、
長々と語っていたのか....。答えは両方とも NO だよ。

抽象データ型を知らず(>>218,220,222)、オブジェクト指向の抽象モデルが
何か知らず(>>224)、OCamlがマニア向けという認識で(>>227)、
純粋な関数型言語の問題も分からず(>>238)、最後には罵倒でしか返答できない。

とんだ「知ったかぶり坊や」だな。「ナゼナゼ坊や」かもしれないけど
自身が無知である事は自覚できている ちんこ氏のほうが、ずっとマトモだぜ。

マルチパラダイムな言語が流行りそうな予感がするけど、
美しさという観点だとマルチパラダイムな言語って微妙かもしれない
純粋さの対極にあるような混沌の美ってのはなかなか考えづらい

コテ外して自画自賛かよw

>>241
少し前に抽象データ型がオブジェクト指向の先祖と思わせる記述があるが、
抽象データ型が熟成する以前に、オブジェクト指向のアイディアは生まれて
いるので、この解釈は適切ではないように思われる。

実際OCamlのOの部分はゲテモノっていうのがOCaml使いの間でのメジャーな認識だと思うがな。

>>242
その中の一部は俺だが、残りは俺ではない。
全部同一人物に見えるお前は病気か？

>>236
Haskellで書かれたOSは存在する。
実験的なものに過ぎないが、存在するかという問いにはyesだ。
きみは嘘つきだ。

>>236
しかもML系の言語は純粋関数型ではない。

>>242のレスを見て、OOPの連中が妄想の塊であるという確信を私は強めた。

>>236
＞ウィンドウシステム

xmonadとかな。

>>251
xmonadはウィンドウマネージャであってウィンドウシステムではない。
ウィンドウシステムはたとえばX Window Systemだ。

>>252

＞純粋な関数型言語
＞(たとえばCaml/FP/Haskell/Miranda/MLなど)で実装された

とかの発言からあんまりウィンドウシステム/マネージャとかの言葉の定義には
あんまりこだわらない人かと思ったら違うのね。

OCamlの"O"はゲテモノだよ。
答えはYESね。

結局OOPがどんだけ素晴らしかろうとさ
何年もやってる奴ですら使いこなせないっていってんじゃ、ぜんぜん実用的とは思えないよ？
なんで簡単に説明すべきことをあえて難しいもののように語るかな
開発の場を無視して語ってるよね
確かに統べてはoopでやれる思うけど
それにはクラスに適切に変数や処理を入れていかなきゃならない
そんな完璧な設計をやる意味はあるか？

OOPは元々が扱いにくい
しいていうなら本当のベテランが設計やんないと紛れもなくカスになるだろ

クラス作ったはいいけどやっぱそれいらなかった
とか、この変数は別のクラスに移動、とか
頻繁に起こってたらコードかく側はやってらんないよ

つまり本来は設計が大変になる代わりにコーディングを楽にするものなんだと思うけど
OOPまともに設計出来る奴は滅多にいないから
どこも設計だけに負荷かけないでコーディングと痛み分けしてる感じだろ
OOP厨は時々、神にでもなったかのようなことたまに口走るから本当に信頼できない
成果と金を天秤にかけて語れないなら一生趣味の域をでることはないからね
妥協のないOOPは、設計力に依存しすぎて危ない

>>245
# アンカ(>>241)は間違いのように思うけど、とりあえずレスする。

抽象データ型のアイデアはSimulaで生まれCluで完成、その一方で
最初のオブジェクト指向言語であるSmalltalkはSimulaの影響を受けた、
というのが自分の認識。間違っている(あるいは不適切)かな？
まあ、この辺は歴史認識の差異だろうから、いくら議論しても皆が納得できる
結論は出せないとは思う。

>>246
そういう認識ならオケー。主観が入るから、YES/NOは決定できない。

>>248
ソースキボン。いや、マジで興味がある。
そのOSは普通のPCでブートできるの？サポートしてるデバイスにはどんな物がある？
Concurrent Haskellは聞いた事があったけど、OSまで実装されているとは知らなかった。

>>250
これは自分の誤りだ、ゴメン。リストからCamlとMLは削除する。

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

２ちゃんねるの有志の皆様へ

ただいまVIPのみんなで例のサイバーテロ集団の本拠地VANKに攻撃をしかける作戦を立てています。
今日の10時から楽しくぶっぱなしますので今すぐどうぞ♪
遊び半分の参加も最高ですのでどんどんどうぞ！

皆さんが集まればより強い攻撃が与えられるはずです。
さあ皆さん！今すぐ現行スレへ！

→【http://yutori7.2ch.net/test/read.cgi/news4vip/1255301899/】
まとめwiki(要編集)http://www20.atwiki.jp/vipvsvank/pages/1.html

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

osを勘違いしてない？
いっとくけどosて
osらしい処理はほとんどアセンブラで以外で書けないから
別に何の言語でも作れないし作れるようなもん
誰かがネタで作ったもんにつられるなよ

>>226
どう大変なのか指摘出来ない。
日本人らしいですね、分からないのをごまかして。

それと、君たち、
そんなことがオブジェクト指向だと思っていたのか？
レベルが低すぎる。
おれはすでにそんなところでOOやってないよ。

アセンブラで下地作った上にかく高級言語は普通のプログラムのソースと大差ない

>>251,253(両レスとも同一人物のカキコだよね？)
# >>252は自分(>>242)のカキコじゃありません。

システムプログラムということだから、汎用OS上のウィンドウシステムなら、
ツールキットがあればオケー。たとえばUNIXならXlibは前提ソフトとして位置付け、
その上で動くGTK+に相当するコンポーネント、WindowsならWin32 APIは前提ソフトで、
MFCに相当するコンポーネントがあれば、YES であると認めます。ただし、単なる
言語バインディング、たとえばHaskellであればgtk2hsやwxHaskellは除外します。

また、残念だけどxmonadのようなウィンドウマネージャはアプリケーションなので、
除外させて下さい。ライブラリ or フレームワークとして提供されている必要があります。

# ...と書いてきたけど、Haskellハカーならツールキットモナードとかを考案しかねない、
# と少しずつ心配になってきたゾw

>OCamlの"O"はゲテモノだよ。

基本的には、>>256内にある、>>246へのレスと同じです。
ただ、システムプログラムを開発するには、"O"が必要になるのではないかと考えました。
いわば必要悪であると認められているのではないかと思っています。

お前らは完全なる白痴。

どうしようもないな。
お前ら、IQ100あるか？

もっと学べよ！
学ぶ力がないから三流大学に行ってるということを考えると、学ぶこと自体不可能なんだろうけど。
勝手に納得して、勝手に理解したと勘違いして、それで生きている意味あるの？死ねば？

ほんとひどい。
何も理解してないのに偉そうに話す。
おれがもっとも嫌いなタイプだ。

>>261
http://wadler.blogspot.com/2008/09/caml-trading.html

Jane Streetでは"O"の部分はほとんど利用しないらしい。

では神オブジェクトさん
OOを学ぶと、OOを知らなかった頃と何が変わるんですか？

>>226
全然わからない
jsonとか聞きなれないものも最近登場しちゃってるし、
引数と戻り値にジェネリック使いまくりのソース
何に使うか分からないクラスばかり
こんなわけのわからない事をやる事によって、
他のプログラマーと『どういったスキルの』差を付けられるのか見せ付けて欲しいね　（ﾜﾛﾁ

それが分からないから、学んでいるのですが。

君は「学ぶ」という行為に対する意欲が低すぎる。
早急に死になさい。
これだから三流オブジェクトは。

おれが学んでいるのは、好奇心を満たすためです。
勉強しても勉強しても、おれには不思議なところがたくさん見えます。
時にはそれが何なのかも分からないことがあります。
だからこそ学ぶのです。
学ぶというのはそういうことです。
また、それ以外に学ぶ動機などありえません。

>>265
たぶんそれはあなたの頭が悪すぎるだけですよ。
学んでください。

>>266
好奇心を満たす為に学んでいるだけで、OOの何が素晴らしいかもわかずして
OOにあまり興味もなく理解してない人間を見下すのはどうかと思います
それは、ただ自分が他人が滅多にやらない範囲のエキスパートになっているだけで
天才とは程遠い存在「オタク」です

>>258,260

ブートローダや割り込みハンドラなどハードウェアと密接に関連する部分については、
組み込み関数やネイティブ関数ライブラリなどとしてアセンブラやC言語で記述されて
いてもかまいません。OSコード全体の1割程度までならセーフです。
でも、デバイスドライバ、カーネル、そしてシェルくらいは、純粋な関数型言語で
記述されている必要があります。マルチタスクや仮想記憶はオプションでかまいません。
ブートするとシェルが起動して、簡単なプログラム(Hello world)が実行できれば、
YES であると認めます。DOSのレベルでいいんです。ハードルはかなり低いと思います。

ということで、>>248からの情報ソースを期待して、しばらく待とうと思います。

# きっとデバドラモナードとかカーネルモナードとかあるんだろうな。ワクワクするなァ。

>>268
素晴らしさについては、
君たちが分かっている程度には分かってるつもりですが。
学ばざるものは死ね。

>>270
ぼくにはOOへの好奇心が無いからって死ねですか？
だってもっと他にやるべき事はいっぱいあるでしょう
あなたは金子氏のソースコードを小ばかにしていましたが、
ソースが汚かろうと物を作れたほうがよっぽどいいです
OOでいくらソースを綺麗に書いても何も作れないなら意味が無い
あなたは何も作れないゴミに、価値を見出す研究をしてる
誰もゴミ漁りなんて好んでやらないから、ゴミの構造を詳しく理解していないのは当たり前です

天才とオタクは紙一重

このスレみてたらちょっとOOやりたくなってきた

>>271
小馬鹿ではないです。爆笑です。
あのコードを書くというだけで有罪確定です。

大体、おれが何も作れない、作ってないと思ってるのですか？
ほんと、素晴らしくハッピーな考えをお持ちのようで、羨ましいです。

ちんこのブログってどこよ？

>>274
爆笑ですか、私は見ていませんが、たぶんjavaではないですよね
あの人だったらC++かな？　自分の使わない言語に爆笑するとはいい度胸だと思います

あなたが何も作れないかどうかはあまり関係ありません
あなたの考えてるそのOO++みたいな理論を使う事により、
開発効率がよくなるのか？
保守性が高まるのか？
バグが減るのか？
等、何らかのプラス効果が無ければ、　OOなどやっていく意味がないですよ

ちんこはオブジェクトの神でインタフェースの化身

あなたたちはなぜ、比較元を指定しないままに比較級の言葉を使うのですか？
白痴なのですか？
「よくなる」「高まる」「減る」
何に対して？バカなの？死ぬの？

おれの開発効率は高いですよ。バグはほとんど出ませんよ。
常に小さくて簡単なモジュールから作り上げていくからです。
あと、常に凝集度の高いコードを書くことでバグは減らせます。
適切な名前をつけることでもバグは減らせます。
ただ、これらはOOの性質というよりは一般的なコーディング作法やソフトウェア工学の話です。

OOという意味では、おれは、
ThoughtWorks Anthologyに書いてあるなんとかエクセサイズというのに感動しました。
プレファクタリングにも書いてあるようなものですし、すべて実践するものではないと思っていますが、
それでも、考え方としては学ぶことがあります。

ThoughtWorksに入りたい。マーチンファウラーはおれの中のヒーローだ。

>>269
俺は >>248 じゃないが
http://programatica.cs.pdx.edu/House/I/screendump-oct2005.png
http://programatica.cs.pdx.edu/House/I/screendump-icfp2005.png
http://programatica.cs.pdx.edu/House/I/screendump-hw2004.png
http://programatica.cs.pdx.edu/House/I/screendump.png

House is a small operating system coded almost entirely in
Haskell. It builds on the previous hOp project conducted by
S´ebastien Carlier and Jeremy Bobbio [4]. The system includes
device drivers, a simple window system, a network protocol
stack, and a command shell window in which a.out files can
be loaded (via TFTP) and executed in user-mode. To our knowledge,
this is the first functional-language operating system that
supports execution of arbitrary user binaries (not just programs
written in the functional language itself).

だそうだ。Common Lisp の Movitzみたいなの予想してたら結構すごい。

分かりました。
OOがどうとかいうよりは、Code Completeを読んだことがない人は今すぐ死んでください。
この本は非常に汎用性の高いことが書いてあり、すべての開発者が学ぶべきことです。
なので、それを学んでないのにコードを書いてる人は死んでください。
この本は一冊5000円くらいですが、おれが読んだ本の中でももっともコスパが高いです。
もうおれの本はボロボロですね、何度も何度も読んだので。

ちんこ氏のブログとかサイトとかってどこ？

>>278
一般人の理解してるOOよりも、あなたはかなり高い所まで理解しているんですよね？
確かに、OOに関してはそんな気配も少し見えます
比較しているのは、一般人のOOと、あなたの考えるOOです。

あなたの開発効率が高いのは、あなたが自分の作りやすいと思えるソフトウェアしか作らないからじゃないですか
本当に開発効率が他人と比べて高いと自信持ってるなら事業を起こすべきです
ちなみにwinny作るとしたらどの位の時間で作れますか？

ちんこさんってどんなソフトウェア開発してんの？

学校での研究テーマは何？
プログラミングと関係してるの？

あなたは発狂しかけています
それは高学歴だから他人より今まで優位に立ってきた
そんな自分がかなりの時間をかけて学んだ理論が素晴らしくないわけが無い
意地になっています
これはあなたの人生で最初の負けだと早く認めたほうが良いです
あなたはきっとOOを最初の1日で理解するくらい優秀な人間だった
だから理解したことが理解できず
さらに前に進んじゃって、ゴールの無いゴールを探し続けてる
有用だったのは最初の1日だけで、あとの数年間はあなたにとって無駄だったという事を
早く認めないと、どんどん多くの時間を無駄にしていきます

優秀な人間が大勢で時間かけて作った理論を、一人のハッカーが一世代で超えてしまう
ソフトウェアというのはそういう分野です

もしも明日、OOよりも格段に画期的な手法が発見されたとき、
自分の負けを認めてOOから乗り換える事が出来ますか？
まだ若い。　今のうちにたくさん負けておくべきだ。

私のCode Completeは中古(18$)なので元からボロボロでマーカー引きまくりです

Blogどこよ

Code Completeに対する専門家(の卵も含む)や、関数型言語畑、熟練C++ユーザからの評価は低い
ただ、網羅性は各所で評価されてるから、あれは全部読むよりも
知らない所だけ摘み読みするのがいいんだろうな
前書きにそういう用途に対しても考慮してあるとあるし

>>274
わろたｗｗ
書いたコードで有罪って
「被告人金子氏はwinnyの開発においてとても人的有害なソースコードを書きました。よって.....」こんな感じかｗ

何故、何のゆかりもない関西の大学に来たわけ？
東大や東工大に行けば良かったのでは？

高専とか馬鹿にしてたし東工大も工大(藁)って言って受ける気なかったんじゃね？
東大に関しては「逃げ」だろうな、そういう人多いし

>>279
期待していたのはコレですーーーーー！！
デモ版とはいえ、完璧にYESです。ええ、私は嘘つきでした。素直に認め、謝罪します。>>248

ご紹介、本当にありがとうございました。プロジェクトのHPは以下のURLですね。
　http://programatica.cs.pdx.edu/House/
Grub or TFTPでブートしたら、あとは(OSKitは使わずに)カーネル/デバドラ/
シェルはもちろんのこと、仮想メモリ/マルチタスク/マルチウィンドウ/ネットワーク
まで実装されています。TCPはまだ無いけど、追加は無理なく可能でしょうね。
HouseとP-logicの論文をダウンロードしたので、これからじっくり読ませてもらいます。
重ね重ねですが、本当にありがとうございました。感謝します。>>279

◆GbXlaaQNk. こいつはなんなの？
2chで意見を乞うてる時点でレベルが知れるんだよ
自分は天才だとか言ってるけど全然平均の枠を出てないよね
知能も精神面もまだまだガキだ
一度IRCにでも誘ってプライドぶっ潰してやりたい

(>>292への追記)

実は「関数型言語は手続き型言語よりも美しい」という主張を想定していました。
そして、それに対する反論として「いや、システムソフトウェアを記述できない関数型は、
汚い仕事を手続き型に投げて、自分は美しいと思い込んでいるだけじゃねーのか」という
結論を先に用意し、議論の流れを自分のペースに持ち込む事を狙っていたんです。

でも、完璧にひっくり返されちゃいましたねｗ。2chコミュニティ、そしてHaskell恐るべしです。
これで、関数型言語と手続き型言語との「美しさ」に関する議論について、
それらを同じ土俵の上で戦わせることができます。(調子良すぎカナ？)

>>293
実際まだ学生というガキなんだから見守ってやれよ

言ってる事にたいし
ここの書き込みややってる事が甘ちゃん過ぎてイラついてくるんだ

だいたい
242がお前なこともおれにはバレバレなわけで

>>288
＞Code Completeに対する専門家(の卵も含む)や、関数型言語畑、熟練C++ユーザからの評価は低い
待て、そいつらは初めからCode Completeの対象じゃない。
C系の手続型言語に関する既存の開発技術を効率よく習得する
というところが要なんだから。
初級者〜中級者向けの教科書だよ。

>>288
Code Completeって、継承とか例外にも懐疑的なくらいだから。
Windowsに例えると、「XPで十分だから新しいのは買わない」と言っているようなもの。
新しい分野の専門家にとっては死活問題だな。

>>296
生理が始まったの？

プログラミング言語の仕様はプログラマー性善説で作るべきだと思う。
分かりにくいコードを書ける可能性があるくらいの自由度があるほうが
拡張性も高くなってよいと思う。
分かりにくいコードを使うかどうかの選択は使用者に委ねればよいと思う。
分かりやすいコードなのに書けないということがないように配慮するべきだろう。
人間の言語でも矛盾した論理を文章にできるくらい自由度が高いが、
問題はあまり起きない。

Steve McConnell より Steve Maguire の方が好きだ。

＞分かりにくいコードを書ける可能性があるくらいの自由度があるほうが
＞拡張性も高くなってよいと思う。
その評価基準だとHaskellはあまりよくないね。Pythonはもっと悪い。lispが最高かな？

Haskellはかなり自由な方だと思うけど

その基準だとアセンブリ言語はどうなの？

耐タンパー化テクニックを駆使して非常に分かりにくいコードを書くことはできるけど
自由度は全くないよねww

Haskellは構文が不自由だと思う。

アセンブリは、CPUができることなら何でもできる、
自由度極大の言語だと思うけど。

ちんこってプログラミングにしても日本語にしても。
現実が教科書に書いてある通りにならないといちいちキレるんだね。

>>305
構文が自由な言語ってたとえば？
Haskellは演算子とかも細かく自分で定義できて中々いいと思うけど。
インデントに依存するところは微妙だけど。
lispは自由だけどS式から脱出できないし。

>>306
でも構文的な自由度はほとんどないけどね。マクロ使ってもあんま変わんないし。

>>299
かもしれない
すげーイラついてる

Haskellが不自由だといったのは、インデントが意味をもつから。
見るだけならいいけど、ソフトウェア的に処理するのが面倒。
中括弧のほうが簡単に実装できる。

＞ソフトウェア的に処理するのが面倒。

一般的に、ソフトウェア的に処理するのが面倒なほうが自由度は高いっていうんじゃないのか？
いろんな場合が考えられるって事だから。

Haskellは別に { ; ; }みたいに書いてもいいわけだし結構自由なほうだと思うけどな。

エジソンが言っていたよね。
1%のひらめきがない人間は努力をしても意味がないと。

＞一般的に、ソフトウェア的に処理するのが面倒なほうが自由度は高いっていうんじゃないのか？
なるほど、そう考える方がよいかもしれませんね。

>>308
横だけど、マクロが強い言語は構文が自由だよ。
Common Lispは非S式のマクロも使えるし、
Forthもかなり無茶ができる。
今のところの最上位はOMetaかも。

ttp://d.hatena.ne.jp/kami_object/20091012/1255322189#c1255323701

> 315=ちんこ
お前が来なけりゃ良いんだよ

>>263

アプリケーションといっても、おそらく複数のフレームワークを階層的に構成させる、巨大な
金融処理プログラムだと思いますから、システムソフトウェアに近い技術が要求されるはずです。
そして、関数型言語への移行目的は、副作用が無い透明なコードによるプログラムの信頼性(reliability)
確保にありますから、たとえシステムソフトウェアであっても(副作用を前提とする)"O"を排除するという
考え方には、一理あるなと感じました。

他にも「ほとんど(almost)」とありますが、標準的な関数プログラミング技法では実現できなかった
という、"O"が残ってしまった設計箇所がどこだったのか？が、興味をそそられますね。

また、スレ違いな独り言になりますが、実は、OCamlについては概要くらいしか知らないので
(だから>>256みたいな誤りを犯す)、OCamlの"O"でも副作用の無い関数プログラミングが
可能であると勘違いして時期がありました。それは、東大の米澤研では、過去に、状態変更操作を伴う
オブジェクト指向を備えた、MLベースの純粋な関数型言語(の理論?)を研究していたらしく、
書籍を入手して読みかけていたので、きっとOCamlも同じなんだろうと(自分勝手に)想像していた為です。

型推論を理解しようとすればML系の言語を避けて通れない事は分かってはいたのですが、
ゲテモノというOCamlの"O"の「曖昧さ(obscure)」とは具体的には何であり、それは米澤研の理論と
何が違うのかを知る為にも、やはり(Haskellだけでなく)OCamlにも手を出す必要性がありそうです。
# Perlのオブジェクト指向があまりにゲテモノなので、Rubyへ乗り換えた過去はあるんですけどね....。

>>279のOS実装を含め、何か霧が徐々に晴れてきて、大きな山の裾野の一部が見えてきたような
感覚を覚えます。遅くなりましたが、レスありがとうございました。ただ、今の自分の技術レベルだと、
その頂きは、遥かな遥かな遠くに霞んでしか見ることができません....orz。先の長い道程です。

マクロ使っていいならC++で十分

>>318
それが正しいと思う
出来るんであれば、どの言語を使ってもいいし
他人が見る機会があるソースも現場レベルで規約に則って書いてあるんだったら問題ない

というか、ここでいう美しいという定義があまりに曖昧すぎる
手続き型・関数型・オブジェクト指向とか
インタプリタ・コンパイラとでまたまったく違ってくるだろう

そんな中で杓子定規で考えようとすることはまったくのナンセンスだと言わざるを得ない

OCamlはC++の代替として有望視されていたんですけどね。
パフォーマンスが遜色なくしかもsecureな代替として。

結局OCamlがティッピングポイントを乗り越えることはできず、JVM上の言語が主流になりつつあるようです。
OCamlのようなマイナー言語を産業に適用しようとすれば、プログラマを探すことが難しく、
もし見つけられても高くつくことは覚悟しなければいけません。

びじゅあるべいしっくどっとねっと

Camlを使いたいならF#.net

F# は今はまだ色々ゴテゴテしすぎてる感じがする。

このスレはコテコテしすぎてる

DSPやFPGAが台頭してきたときにチューリングマシンありきの今の言語じゃおのずと限界がくるので、
てきとーにハイブリッドな言語ほすぃ

＞DSPやFPGAが台頭してきたときにチューリングマシンありきの今の言語じゃおのずと限界がくるので、
＞てきとーにハイブリッドな言語ほすぃ
フォンノイマンの間違いか？
意味論が適当な仮想機械で定義されている言語は問題ないだろう。
インタプリタ言語はダメだな。

意味がわかりません＞＜

>>317
OCamlなんて参照しなくても型理論の本を読めば？

>>328
??

>>263
そのページが公開された時に、
OCamlでオブジェクトを普通は使わない理由を
わかりやすく説明してくれた人がいました。

without objects!?
http://d.hatena.ne.jp/osiire/20080906
オブジェクトは OCaml の鬼子
http://d.hatena.ne.jp/camlspotter/20080906/1220723583
オブジェクトは OCaml の鬼子 #2
http://d.hatena.ne.jp/camlspotter/20080908/1220846961

なにやらOCamlな流れ

OCamlは速い言語

VB

今のこのスレなにげレベル高い奴多そう

XMLで書くプログラムってエディタを工夫すれば美しくなるんじゃないかな？

<program>
<main>
<func plus retrun=ret, arg1=a, arg2=b>
ret=a+b;
</func plus>
</main>
</program>

xmlはいわばS式の腐ったようなもの

>>335
わざわざタグ使わなくても、カッコで十分だろ。LisperならS式でもいいし。

program(
　main(
　　func plus(retrun=ret, arg1=a, arg2=b) (
　　　ret=a+b;
　　)
　)
)

インデントだけでオケー

program
　main
　　func plus(retrun=ret, arg1=a, arg2=b)
　　　ret=a+b

それなんてHaskell？

module Main where
plus a b = a+b

>>335
中途半端すぎる。ここまでやれ

<program xmlns="http://www.example.com/xml-program"
xmlns:std="http://www.example.com/xml-program/std"
entry="#main">
  <function name="main">
    <arg><defvar name="arg" type="int[]"/></arg>
    <funcall name="std:puts"><funcall name="add"/></funcall>
  </function>
  <function name="add" type="int" return="ret">
    <arg>
      <defvar name="ret" type="int"/>
      <defvar name="a" type="int"/>
      <defvar name="b" type="int"/>
    </arg>
    <subst>
      <lvalue><defvar name="ret" type="int"/></lvalue>
      <funcall name="add"><var name="a"/><var name="b"/></funcall>
    </subst>
  </function>
</program>

書くのめんどくせ。

YAMLやJSONで書いてトランスレート

OCamlはクラス使うと遅くなるから使わないほうがいいらしいね

マイナーなのは何かとカスすぎる

function plus(a, b) { return a + b; }

xmlを持ち出したのは
プログラムという単なる単語群において、あえて構造に注意をむけるため。
構造をパターンやアーキテクチャ
として見られるかに革新へ向かうヒントがある。
そしてツリーのより根に
近いところでのみプログラミングすることが
抽象化であるし、
より根に近いところだけで
プログラミングできるプログラミング言語は美しい。

＞そしてツリーのより根に
＞近いところでのみプログラミングすることが
＞抽象化であるし、
本当ですか？

>>346
いいたいことがよくわからないな
非終端記号でプログラミングするという超画期的試み？
それともただのメタプログラミングの話？

たとえば、パラメータ化、といえば、パラメータに具体的な値を入れると具現化する、
という様子がわかりやすいわけだが、それに比べて、抽象化、という名前は酷い。
酷すぎる。ネーミングセンスが無さすぎる。

抽象化って濫用される言葉ですよね。
本来は、ラムダ計算で変数の入ったラムダ式みたいな意味だったと思うんですけど。

λ抽象と一般的な抽象は別だろ…

>>350の後半はλ抽象ですらないし…

一般的な抽象っていうのがよくわかりません。
クラスを定義するのは抽象化なんですか？

葉があるから根があるわけで。

>そしてツリーのより根に
>近いところでのみプログラミングすることが
>抽象化であるし、
もしかしてCalculus of constructions(=higher-order typed lambda calculus)を生で書こうとか言う試み？
そりゃλ式だからツリーっぽく書けるけどさ
素直にCoq使っとけ

>>278
> 常に小さくて簡単なモジュールから作り上げていくからです。

ちんこ氏はトップダウンではなくて、ボトムアップで作る人ですか？

閑話休題

２ちゃんねる
ひろゆき杯プログラミングコンテスト
ttp://pc12.2ch.net/test/read.cgi/tech/1255420019/

が開かれます。人工知能に興味のある人は是非参加してください。

なぜこのスレで言語ではなく人工知能？

>>356
見ればわかる

ちとスレ違いだけど…。

>>355
> 常に小さくて簡単なモジュールから作り上げていくからです。

俺もこの方法使うけど、おすすめだよ。こまかい話はどうでもいいけど
・テストが書きやすいこと
・低レイヤの仕様と実装をきちんと把握できること
から、バグが少なくなる。と俺は思う。

ボトムアップな開発手法のほうが品質が保証できるから好まれるでしょうね。

だからボトムアップな開発手法を恒常的に使う人は好まれるでしょう。
彼の残す成果は信頼できるからです。

>>360
接続詞の使い方がおかしい

>>358
つうかトップダウン方式で作る人のほうが全然少ないと思うんだが。

開発手法のトップダウンorボトムアップを左右するのは、人ではなく組織では？

SICPのトップダウン式の記述には慣れるまで苦労した

ちんこが紹介しているNHKのニコ動画を見たけど、GUI-OSってアップルが独自で開発したのかと
思ってたけど、アラン・ケイが作ったのをパクってたんだね。

まさか、今あるOSの元祖はアラン・ケイが作っていたとは。

Alay Kayって妄想しただけじゃないの？
開発したのはゼロックスじゃなかった？

小さなクラスというのは、
メンバが１つか２つのクラスです。
考えてみてください。
このルールに従ってクラスがコンポジットされていくと、実際に中に入っている変数は2^nに比例して増えていきます。
これは、一時的に5個や6個のメンバを持つ、理解不能なクラスを作る理由を粉砕します。
それと、クラスはなるべく不変にします。
演算結果のキャッシュが書きやすいからです。

クラスが小さいことの良い理由は上に述べられてるとおりです。
小さいクラスはテストが少なくなりますし、コードを見てバグがないことを確かめるのが容易です。
それと、クラスの凝集度が高くなる傾向があります。
それは、仕様の理解を助けますし、再利用性を高めます。

変数が10個も20個もあるクラスを「クラスだ」と言い張る人は、単なる気狂いです。

アランケイは天才。
だが、好きではない。

Altoも知らない奴がいたとは…

お前らさ、おれがライブラリ作ったら使いたい？
可視化ライブラリなんだけど。
Google Codeにうpったら、ソースコードレビューしてくれる？

>>370
嫌だよ
お前のインキンタムシが感染るｗ

どういう育ちの人間ならば、嫌だという理由を述べるのにインキンタムシという言葉が出てくるのか分からんね。
大阪人？それなら納得です。

まず「ちんこ」コテハンが頭の悪さを証明してますよね？

あなたはコテハンでその人の本質の何を見るのですか？
能ある鷹は爪を隠します。
おれもちんこというコテハンによって、あなたたちに「こいつはバカだ」と思わせることに成功しています。
つまり、自分の実力を、本質をカモフラージュしているのです。

上からざっと読み返しても、実力が出さてないんで
本質もバカなのかと思っただけなんです(笑)
すみません。もう寝ます・・・・。

脳ある鷹？誰が？
このスレにくるからにはJavaだけでなくほかの言語をマスターするか
あるいは自分で言語作ってから来なさい
天才なら３日もあれば作れるよな？

インキンタムシもカモフラージュの言葉かもしれないだろｗ

頼むからちんこ
一生ＲＯＭっててくれorz

動きゃいいんだろうとばかりに醜いコード組む奴は糞だが
口先ばっかりでコード完成させない奴も糞

Butler W. Lampson は好きですか？
http://research.microsoft.com/en-us/um/people/blampson/70-softwarecomponents/70-SoftwareComponents.doc

>>379
目的に応じて最も良い選択をすりゃいいんだよ
exeをみて貰いたいのかソースをみて貰いたいのか始めに決める
どっち付かずにやってるとパフォーマンスが悪い
綺麗なソースっていうのは
”ふつうのプログラマ”にとって理解しやすいものだよ
一線越えてでも開発効率あげてくと酷いソースといわれるようになる

主に、その言語には元々備わってない機能を使いたくなった時に、
どうしようかって無理やりなコードをかくと、カオスになってる事が多い
綺麗好きな奴（？）はそういう場面でも無理やりなコードを書かずに冗長した処理をいっぱいはさむんだけど
それは絶対バカ

>>381
具体的な例をあげないと、何を言ってるか分けわかめ

そこのクソコテは本当にJavaしかできなくて
ロクにソフトウェアも作った事ないのにこんなでかい口たたいてんの？
脳ある鷹は爪を隠すって表現はこっちの世界の場合
「脳ある鷹は爪を出してるフリをする」が正しいよ
誰でも長年やってりゃ非公開にしておきたいソースくらいあるからね
お前はそのフリさえ出来る技術がなくて矮小な技術をごそう大事に隠して
自分の小ささ見極められるのが嫌なだけだろ低脳が
今すぐそのゴミみたいなライブラリとやらを晒してみろよ
＜＜一度もソフトウェアをつくったことないぼくがつくったらいぶらり（笑）＞＞
一体どんなものにお前が自信持っちゃってんのかキョーミがあるよｗｗｗ
何も出来ないコテハンは目障りなだけなんで二度とこのスレに来ないでください

>>383
いったい、誰と戦ってるの？

>>382
分からないなら別に良い　無視してくれ
コード晒しても否定意見のほうが多いの目に見えてるから
意見書き込んどいて悪いが、面倒くさい

教科書に載ってるのは綺麗なソースだけど
実際の開発じゃあんな風に書かないだろって話じゃね

コテハンが総じてゴミなのは2chの常識
今更きれることもなかろうに

>>384
明日の自分

大抵の教科書にはゴミみたいなソースコードが載ってるんだが

>>389
カーニハン著の「プログラミング作法」は教科書として最適だと思う。
実用的で美しい(と思える)コードがいっぱい載ってる。
（実際のUNIXのコードは知らんけどねw）

漏れのはRatforで書かれた旧版らしいけど、疑似コードっぽく読めるから、
C言語への移植(写経?)で、すごく勉強になった記憶がある。

>>390
で、勉強したあとのあなたはどんなコードを書いてるの？
見せてよ。

うわ
ちんこがきたから今日はお開きということで。

歌丸「ではまた来週」
チャラララララーチャラララララーチャン♪

>>390
しょせんパスカル野郎

疑似コード(笑)

エアーセックス

擬似コードをバカにするやつはレベルが低い。

コテハン「ちんこ」にするやつはレベルが低い。

ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

消えろといったのにまだ来るかこいつ

>>391
プログラミング作法を読んで勉強していたのは、ずっと昔の話だよ。今は、こんなコードを書いている。
あるデータベースの検索結果を、XML(DocBook)へ変換するツールの一部。
プログラミング作法には、テキスト加工処理がいっぱい載っているから、潜在的には役立っているはず。

(続く)

(>>401の続き)

% get_importer_attr/3

get_importer_attr(MdAttrName, AttrStruct, Id) :-
　　!,
　　map_list(
　　　　[
　　　　　　'type',
　　　　　　'default',
　　　　　　'multivalued',
　　　　　　'nosearch'
　　　　],
　　　　get_importer_attr_char(Id, MdAttrName),
　　　　CharDict
　　),

　　get_langs(Langs),
　　map_list(
　　　　Langs,
　　　　get_importer_lang_str_dict(MdAttrName),
　　　　LangStrDict
　　),
　　reject_nil_list(LangStrDict, LangStrDict1),

　　get_importer_attr_use_importers(MdAttrName, UseImporters),

　　AttrStruct = attr(MdAttrName, CharDict, LangStrDict1, UseImporters).

(まだ続く)

(>>402の続き、これで終わり)

XSLTで加工した最終的な出力結果は、ここで公開している。海外向け文書なので、英語版のみ。
・http://www.h6.dion.ne.jp/~machan/
最終結果(公開文書)が重要であって、コードは手段でしかないから、ツール自身は(現時点では)公開予定無し。
このスレでコテハン張っているちんこ氏なら、Prologくらいは批評できるでそ。評価ヨロ。

イミフ

---
391 ：ちんこ ◆GbXlaaQNk. ：2009/10/14(水) 19:36:51
>>390
で、勉強したあとのあなたはどんなコードを書いてるの？
見せてよ。

404 ：ちんこ ◆GbXlaaQNk. ：2009/10/14(水) 20:41:53
イミフ

----
なんだこれは。　流石に。　態度悪すぎ。
お前自分より出来る奴を認めない傾向に走ってないか？

知らんよ。

これじゃ評価のしようがない。

評価できないんだろw

最初に Java か Scala でお願いしますと言っておくべきでした、すいません。

くらい言って謝ればいいのに、せっかく提示してくれた人に対してイミフって。
本当に大人か？

ちんこはスレ荒らしに来てるのかよ

Javaしか出来ない無能は来るなよ

Javaを最初の言語に選んでる時点でセンスないのでは

お前ら、DIPくらい理解しろよ。
おれは、javaしか読まない、評価してほしければjavaでよこせ。

>>411
（大学の授業を除いて）最初にやったのはRuby。

Cだったら嫁んの？

大学の授業ではCです。
Javaは3回の冬休みからです。
2回の後期からプログラミングやって、1年くらいはRubyやってました。
研究室入ってから、いくつか言語を勉強しようと思って本はざっと読みましたが、どれもjavaよりクソでした。
Scalaはおれの人生を変えるほどの力を持っていると思いますが、IDEがヘボすぎて使い物になりません。

ちなみに、ブログに、お前への問いかけを書いた。
出来れば、返答をいただきたいのだ。コメにでも。

>>408
せっかく提示したのに、一度や二度スルーされた位で諦めちゃだめだぜ
もっと頑張れば、きっと分かってくれるさ

レジスタ

最初にRubyやJavaやるのはやっぱ問題だな
OOP厨になっちまう

>>417
別人です。
相手に迷惑をかけるので、冗談でも遊びでも、
そのようなことは止めていただけないでしょうか。

言い忘れました。
このレスと >>408 と >>420 が同一人物です。

IDEがヘボいからとか自分がヘボってことじゃんw
少なくともCのプログラマはそんなことは言わないし。
それにアラン・ケイは嫌いだとかほざけな

IDEがないと何も出来ません。

159:デフォルトの名無しさん 2006/06/21(水) 15:45:53
>格差社会は、IT 業界も例外ではありません。Java/Eclipse や C#/VisualStudio の生産性の低さには
>居た堪れず、先祖返りを見せられる思いがします。これらの開発環境を見ていると、南極物語と同じ年に
>公開された Smalltalk-80 には遠く及ばず、その格差には愕然とする思いです。本来の統合開発環境は、
>このような際物ではなかったはずです。

>Eclipse/VisualStudio などは統合開発環境〔IDE〕とされていますが、本来の IDE は、このような際物では
>なかったはずです。これらが「あまり早く開発されては困る」とさえ言いたげに見えてしまうのは、
>Smalltalk-80/Interlisp-D など真の IDE を知っているからかもしれません。

>環境などにはさらに進化がみられない。1970年代後半の Smalltalk 環境などは私の今までつかった経験の
>なかで、最も快適で最もクリーンで最も高速で最もスムーズなプログラミング環境なのである。たとえ、
>CodeWarrior が C++ による開発においてそれ相応によくできた製品であったとしても、私がほとんど
>20年前に使っていた Smalltalk システムと、ひいき目に見ても比較の対象にはならないのだ

Emacsユーザなら自分でIDEを実装してしまうだろう

>>423
それはお前が無能なだけ
昔はIDEなんて無くてもやってたんだがな
8bit時代のBASICはどうやって作られたか知ってるのか？

James Goslingは、Emacsの時代は終わったと言っている。

で、これからはNetBeansを使うべきだwwwwwwwwww


だが断る。

紙の上でコーディングして、それ以上できないとこまで煮詰まったらおもむろに打ち込む！！
ってスタイルだな、何しろコンパイラが遅すぎるし
このスタイルでやってた人は脳内コーディングができるんで、環境とか殆んど関係なくなる
もちろん、欠点も沢山あるけど

糞遅くて、バギーだったGosling EmacsをRMSが刷新したものが現在のGNU Emacs

emacs lispが糞なのは認める
Yiに期待

自分でIDE作ってみろよ
天才ならそのくらい簡単に出来るだろ？
その上で他の色んな言語やってみろよ
関数型、論理型、スタック型、いっぱいやってみれ
OOPだってJava以外にもSmalltalkやJavaScriptみたいなのもあるだろうが

いい加減コテハン恥ずかしくないんだろうかｗｗｗｗｗｗｗｗ

Yiは最近元気無いよね(´・ω・`)
ghc-6.12のUnicode I/O対応で息を吹替えしてくれればいいのだけれど

>>429
たまに複雑な処理で、解くのに時間かかりそうなときそれやるけど
やたら疲れるよ
目にソースが見えないし
おれはやっぱ、ある程度脳内で作ったらコード書いて
また次をかんがえるって感じがいいわ
（字を書くのが好きじゃないｗ）

そういやリリカルLispの人も京大じゃなかったっけ

>>ちんこ氏

ちんこ氏ならPrologくらいはサラッと読めると思っていたので、残念です。

実は、Prplogのコードについては、人に見せるのは初めてだったので、
どんな辛口の批評が飛び出すのか、ワクワクドキドキしていました。
コードの意味は理解しなくても、その「美しさ(あるいは汚さ)」に関してならば、
何かしら評価してもらえるのではないかと期待していました。

では、Rubyなら読める(>>415)という事ですので、Rubyのコードをコピペしましょうか？

実は、このツールのデータベース作成処理については、Rubyで書いてあります。
誤解されないようにことわっておきますが、先にPrologを提示したのには２つの理由があります。

・ここはプログラム言語比較論のスレであるはずなのに、いくらマイナーで、日頃から変態と後ろ指さされて
　いるとはいえ、Prologが一度も登場していないのは、あまりにも寂しすぎると感じていました。
　自分は、Prologでも「美しい」コードは書けると考えている一人ですから。

・Rubyコードは、トップレベルを除くと、関数型言語の発想を取り入れた「副作用のないクラス定義」で
　構成しています。ですから、普通のRubyプログラマ(OOPプログラマ)にとっては、
　(OCamlの"O"の部分とは逆の意味で)「ゲテモノ」に見えてしまう可能性があると考えました。
　人に見せる予定は無かったコードですから、自分の趣味(好奇心の対象)を徹底的に追及したコーディングに
　なっています。(実は、>>402のコード内にあるmap_list/3述語も関数型的な発想を基にしています。)

どうされますか？。もし要望があればコピペしますよ。>> ちんこ氏

# ところで、ちんこ氏のブログってどこにありますか？
# 自分は、このスレ#から入った新参者なので、知らないんです。

ちんこの単語を入力するのも恥ずかしいよねこっちはｗ
ね？みんな？

つttp://d.hatena.ne.jp/kami_object/

私も最近は元気がありません。

>>424
EclipseでJava GUIを実装したいけどインストールが面倒そうでやってない
Delphiでさえあんなに簡単だったのに

ちんこブログを見たが
こういう文体の奴に精神疾患を患ってる患者が多い傾向がある

>>442
どういう文体？

普通の人は気にせずに楽しく暮らせるところを
ちんこは常に観念に捉われ過ぎて苦しんでしまう
哀れな奴だ・・・。

いずれにせよ
ちんこの価値観は世間の価値観からかなり遠ざかっているため
世間から敬遠疎遠で幼少期から親友は皆無に等しかっただろう
類は友を呼ぶ
類に属さないちんこは友が近づかなかった・・・・

>>445
価値観がどうとか
プログラマに言われたらおしまいだｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
しかもこんなスレをみてる人間
一般人からしたら気持ち悪がられるわ

>>437
あんたが出来る人間だというのはコードを見れば分かる。
文芸的なコードを意識出来る人間だということは分かる。
だが、Prologは分からない。
なので評価のしようがないし、「評価」というのがあやふやなので何をしようもない。
これではアルバイトで、「働いて」と言われてるのと同じだ。

おれはRubyが嫌いなので、Rubyのコードなど貼らないでください。
そして、山に帰ってください。二度と人里には降りてこないでください。

404:ちんこ ◆GbXlaaQNk. 2009/10/14(水) 20:41:53 [sage]
イミフ

ちんこ神はなんでrubyが嫌いなんですか？
使ってみて、あるいは調べてみてこれは駄目だということがあったら語ってみてくださいな

型がなくて可読性が低い。
自分では分かってるつもりかも知れないけど、他人が読んだ時の不愉快さが異常。
コードは他人に読ませるために書くものなので、型がない時点で論外。
人類に残された選択肢はJavaかScalaしかない。

あと、世界的にユーザが少ないこともデメリットだ。
Python VS Rubyはよく言われることだが、
おれの中ではPythonが存在するのにRubyが存在するメリットがよく分からない。

今、javaのエスケープ解析なるものを使ってみた。
射精した。なんだこれ。
エスケープ解析考えたやつは世界に千人くらい子供残せ。
おれが許す。

まつもとゆきひろに謝れ

おれはJavaが嫌いなので、Javaのコードなど貼らないでください。
そして、山に帰ってください。二度と人里には降りてこないでください。

まぁ冗談はともかくJavaなんて仕事でもなければあんな醜いもん使いたくねーよ
Rubyが糞なのは同意だがMatzもお前には言われたくないだろうな

>>447
>(前略).... なので評価のしようがないし、「評価」というのがあやふやなので何をしようもない。

了解しました。

>おれはRubyが嫌いなので、Rubyのコードなど貼らないでください。

こちらも了解。コピペは取り止めます。

コンパイラをキッチリと理解していないチンコに明日はない

上の書き込みとは関係ないけど
美しさではPrologが一番。
この言語が一番フラットに書ける。

フラットとは？
シンプルでなくてフラット？

リスト以外に構造体を使わない

>>450
>型がなくて可読性が低い。

これはJava vs. Rubyを指していると思うんだけど、だとしたら同感だね。
Rubyでのプログラミングは楽しいけど、人の作ったRubyスクリプトの多くは読みたくネエ。

>>451
>あと、世界的にユーザが少ないこともデメリットだ。

Webアプリの世界ではPHP/Ruby(Rails)がメジャーで、Phyton(Zope)は超マイナーな存在じゃないかな。
つまり、一概にはユーザが多い/少ないは言えないのではないかと。

>Python VS Rubyはよく言われることだが、
>おれの中ではPythonが存在するのにRubyが存在するメリットがよく分からない。

両者は設計思想がまるで違うよ。
Phytonは教育用途も意識し、簡潔な言語体系(simple is best)を目標に設計された。
だから、コードは冗長だけど、可読性が高いという利点がある。
Rubyは、なんかPerl/Smalltalk/Clu/Lispの良いところを、もうこれでもかと積極的に取り入れた。
だから、プログラミングは楽しいけど、可読性は低いという欠点がある。

プログラマが目的に応じて使い分ければいいんじゃないかな。
業務で開発するとして、両者からの選択権がもらえたなら、漏れは、まず間違いなくPhytonを選ぶけどね。

>>458
引数に構造体がこないという意味だと思うけれど、
本体に現れる副目標は構造体そのものだけどねw
制御構造としては確かにフラットでPythonのインデントを嘲笑いたくなるね。

>>459
ふぃとん？

[訂正] X: Phyton --> O:Python

指摘アリガト >>461

制御構造？構文ではなくて？
制御構造がフラットというと逐次とジャンプしかないasmみたいなものを連想するのだが

>>458

>>390だけど、漏れも意味がよく分からんw
もう少し具体的に書いておくれ

少なくとも、>>402のコードの最終行では「リスト以外に構造体(attr/4)を使っている」ヨ。

私は>>458ではないけど、
AttrStruct = attr(MdAttrName, CharDict, LangStrDict1, UseImporters).
のようなコードは私も避けるね。

RDBではないけれど可能な限りフラットなデータベースを構築して、
appendの積み重ねで記述していくのがPrologだよね。データこそすべて。
appendが3個出てくるとaaaという述語名が与えられ、これが5個になると
cccという述語になる。そんな感じでしょう。

>>463
>制御構造がフラットというと逐次とジャンプしかないasmみたいなものを連想するのだが

その連想で正しいと思うよ。

純Prologにある制御構造は、パターンマッチ(単一化)と書き換え(推論)しかない。
いわばアセンブリ言語に近いと言える。(どちらかというと純Lispかな？)
ifやforといった述語は用意されているけど、それらは副作用(カット)を前提としているから、
「美しさ」の基準からは外れると思われ。

>>465

Prologプログラミングで、関係(データベース)という概念でコード化されるのは、全体の1割くらい。
他の9割(たとえば>>402)は、関係という概念は用いない。単なるリスト処理の塊。
(ただし、一般的なデータ加工処理の場合。時には、関係の比率が5割を越えることもある。)
少なくとも、>>402のコードは、以下のようなRubyコードに書き換えできるヨ。
コードの意味は理解しなくてもいいけど、ほぼ一対一に対応付けられることは分かるんじゃないかな。

def get_importer_attr(md_attr_name, id)
　　char_dict = [
　　　　　　'type',
　　　　　　'default',
　　　　　　'multivalued',
　　　　　　'nosearch'
　　].map { |char_name|
　　　　get_importer_attr_char(char_name, id, md_attr_name),
　　}

　　lang_str_dict = get_langs().map { |lang|
　　　　get_importer_lang_str_dict(lang, md_attr_name),
　　}.select { |lang_str|
　　　　lang_str
　　}
　　use_importers = get_importer_attr_use_importers(md_attr_name)

　　Attr.new(md_attr_name, char_dict, lang_str_dict, use_importers)
end

# ゴメン、Rubyのコードを書いちゃった >>ちんこ氏

(>>468の補足)

>>468の冒頭で書いたのは「自分(>>390)のPrologプログラミング技法の場合に限定」させて
ください。他のPrologプログラマであれば、また別のプログラミング技法があると思う。
Prologはアセンブリ言語みたいな単純な構造だから、人によって様々が技法が存在する。
おそらく(間違いなく?)自分の技法は、マイナー(あるいはマニアック)じゃないかと想像してる。

>>469 「まったり」スレでmapの形にして処理すると書かれていた方かな？
リスト処理の塊、には賛成。ただし単位節にリストの形で定義することはなく、
findall/3でまずリスト化してから仕事をする。findallが遅延評価できるといいのだが。
以前はRDBとインターフェイスをとったり、ファイルにデータを保持したりしたが、
最近はほとんど単位節をassert(reconsult)してオンメモリデータベースとして使っている。
したがって、95%以上の節が単位節。まあ私は相当に異端だと思うけど。

>>470
>>>469 「まったり」スレでmapの形にして処理すると書かれていた方かな？

ええ、そうです。

>ただし単位節にリストの形で定義することはなく、
>findall/3でまずリスト化してから仕事をする。

このツール(>>401-403)のデータベースとはassertしたPrologの単位節であり、
その検索処理では、findallを使用して検索結果をリスト化しています。
そして、その(findallを使った)検索処理がコード全体の1割ほどで(>>468)、
残り9割は(mapを使った)リスト処理の塊である、という意味でした。
自分の説明が分かりにくかったかもしれません。

>以前はRDBとインターフェイスをとったり、ファイルにデータを保持したりしたが、....(後略)

まったりスレは以前からROMしていたので、オンメモリPrologデータベースの話題は
知っていましたヨ。最近のPCでは数GBメモリ搭載なんて当たり前な世界ですから、
ワークグループ規模であれば、リーズナブルなシステムが組めるのではないかと思っていました。

>したがって、95%以上の節が単位節。

自分のツールも95%以上は単位節ですね。ただし、そういった単位節は
(コードではなく)データの一部として考え、全体のコード数を計測しています。

390は他人に読みやすい文章の書き方考えたほうが良い
おれがProlog知らないせいもあるけど全然なにいってるかわからない

あえて変な文体で書いているんだろ。

実行できないコードは、説明してもわからないね
脳内で実行してもらいたいなら尚更わかりやすさを要求されるわけで

文章の要素を無理に省略したり逆に飾ったりしないことだ。

型がないのがそんなに可読性低いか？
とりあえず、具体例を出してみてくれ
俺はそんなに可読性が低いとは思えないので

動的言語に型がないというのはやめてくれ。型が実行時（動的）にしかわからないだけで型はある。
型宣言がないだけだ。

ここでいう型がないとは、変数に型がないということだから、
そういう風に解釈してくれ
ちんこもそういう意味で言ってるし

変数に型がないというのは意味が分からない。
識別子とストアは別。

変数に型がないの意味がわからないという意味がわからない
変数に型がないというのは、そのままの意味だけど

ドラゴンブックによれば、名前と識別子と変数は別、らしい
変数はストアと同じ意味で使われている

ドラゴンブックによらなくても、言語の仕様書に書いてあるだろ
変数には型がありますよとか
そう書いてる言語がCやJavaであり、
そう書いてない言語がRubyやPythonだ
ていうか、意味ぐらいわかるだろ
汲み取れよ

sigilは型に入りますか？

Haskell ＞＞＞＞＞＞＞ Prolog

Smalltalk >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> C++

>>479 大分上の方に、
_出荷日　+　_商品番号　+　_数量　:-　売上入力検査(_出荷日,_商品番号,_数量,_診断),　...　.
というようなデータ入力の述語定義を示し、本当はPrologで
出荷日 A　+　商品番号　B　+　数量　C　:-　売上入力検査(A,B,C,_診断), ... .
のように型記述ができればいいのだがね、というようなことを書いた。
この場合、A,B,Cはそれぞれ、出荷日型,商品番号型,数量型,であると考えてはいけないの？
?-　20091016+200+36.4.
というような入力をしたいのだが。

>>477の言っていることはよくわかる。
型を使うとき、変数は用途のひとつに過ぎない。

ちんこってソフトウェアがどうやって金になるのか解っているのか？
コードそのものが付加価値を産み出していると思っているのか？

すばらしい意見。感動した。勘違いしちゃいけないとこ・・

箱に入れるものを厳密に制限するか、中身に「お前は何型だ？」と問いかけるか。
前者が絶対的に正しいという論理がわからん。

向上心や学習欲は大事だよね
Java以外のものもしっかり学ばないと解らないものもあるのにさ
まぁJavaのライブラリにすがってる馬鹿にはわからないだろうな

>>486
>大分上の方に、

とあるけど、それはどのレス番号ですか？。おそらくオンメモリPrologデータベースの話題(>>470)の
ことだと予想しますが、他のスレ住人には、何の事か分からないと思われます。

それはともかく、なんとなく述語定義の引数形式、述語の評価技法、そしてデータ型機能の三者が
ごっちゃになっていると推測します。まずは、それらを解きほぐしてから、Prologとデータ型との
関係について、このスレで議論されたほうがよいのではないかと、個人的には考えます。

もし「Prologでまったり」スレに同じカキコをしてもらえば、そちらで、もう少し具体的なレスが返せます。

昔は型宣言のある言語じゃないと不安だったけど
型なんてなくてもいいさ。と逆に考えたら平気になった

多相型とか依存型とか
きりがないよ

>>492
2-3週くらい前だと思ったが、だとすると前スレか。
変数表記にどれだけ情報を与えるかという話題の流れに書き込んだように思う。
違うスレかもしれない『推薦図書...』とか。どこであるとしてもdat落ちしている
ようです。すみません。

◆宣伝、広告◆
腕に自信のあるプログラマは、以下のコンピュータ大富豪大会に参加しましょう。

ひろゆき杯コンピュータ大富豪大会
http://uecda.nishino-lab.jp/2009/


○What's UECda?

大貧民（または大富豪）は、我が国で最もポピュラーなトランプ・ゲームのひとつでしょう。
このゲームは、1960年頃に日本で生まれたと言われており、海外では、ほとんどプレイされていないようです。
本大会は、その日本固有の人気トランプ・ゲームである大貧民を、人が直接プレイするのではなく、
プレイするコンピュータ・プログラムを作成して持ち寄り、対戦させる大会です。

主催

電気通信大学

プログラミングって
数学と捉えた方がいいのか
国語と捉えた方がいいのか
どっちなんですかね？

国語

>>497
書かれたプログラムを読むのはコンピュータ

>>497
そういう質問に真面目に答えるかどうか決めるのが国語
答えると決めた後の作業が数学

>>495
もしかして>>470の方とは別人だったのでしょうか？

どちらにしても、>>486へのレスは書きかけていました。
ただ、生々しい質問内容に沿ったレスを意図したので、
レス内容が、あまりにProlog固有の話になっていました。
そんなレスをカキコしても、おそらくこのスレの住人さん達には
スレ違いと思われそうでしたので、
(カキコを控え、)Prologスレへ誘導したつもりでした。

もし自分のレスがウザイと感じられなければ、お相手しますから、
遠慮なくPrologスレへカキコしてください。
他の方(Prolog有知識者さん達)からも、レスがあると思いますよ。

>>501
470も495も私です。仕様に含まれる情報をどこまで生の形で、
しかも濃厚にプログラムに含ませられるかというテーマと
フラットにという姿勢は時として衝突することがあります。
それが 出荷日 A + の部分に現れています。情報を型として
与えれば、必然的に構造になってしまう。
それでは、この後は「Prologでまったり　Part4」で楽しみましょう。

蛇足というのはもとは立派だったのだから違いますね、なんというのでしょう。
_出荷日 + _商品番号 + _数量　:-
はフラットどころか
(+)/2 という述語の引数に(+)/2の関数が現れています。お粗末でした。

Prolog野郎のおかげでスレが止まったな。

ちんこ、英検1級を受験か。
受かるといいね。

数学が出来ない人がプログラムを書く、
国語が出来ない人がプログラムを書く、
英語が出来ない人がプログラムを書く。

それが日本の現状。
旧帝国大学卒以外の人間がプログラムを書くことは許さない。

>>506
それでもいいけど、んじゃ今動いている日本のシステムはお前がメンテナンスしてくれるのか？
お前バカだろ

えっ？今の日本のシステムは数学も国語も英語もできない無能集団がメンテしてるって意味？（学歴は別にして）

おれがメンテナンスしてやるからソースコード公開しろよ。

メンテナンスだけじゃないよね？
仕様追加もあるのに

それは話がずれてる

>>506
学閥/学歴は確立の問題なんじゃねえか？
旧帝大卒でも中には屁理屈ばかりで使えない奴はいるし、
専卒/高卒でも中には実戦で使える(戦力として計算できる)奴もいる。

確率ね。

学歴ほど人間という資産の信頼性を保証するものはない。
プログラミングには高いIQが必要なので、低学歴はしょうもないコードを書きつづける。
それが結果として、他人の時間を奪い、時には殺す。
だから、質をしっかり確保することが重要なんだ。
日本では、人海戦術というのが平気で使われているようだけど、人員が増えればそれだけ効率が落ちるということが分かっている。
少数精鋭で望んだ方が結果としてコストも質も何もかも良くなる。
バカは雇うべきではないということは経済的な面から主張出来る。

たしかにJavaとIDEはIT土方のためにあるようなもんだよな
とりあえず動くコードを大量生産させるためにな
で、そのJavaとIDEの上でいきがってる人はいったい何をしたいのかな？
自分でJavaを越える言語を作ってみたら？
ScalaにはIDEがないから使えないとかいってたけど
それなら自分でIDEを作ってみたらいいんじゃね

言語の問題じゃない。

少数精鋭。いい言葉だ。一面の真実だと思う。

ただな、マジな大規模開発プロジェクトだと、少数精鋭じゃ解決できないんだ。
ちんこはブログでコードの断片を公開しているようだけど、
何か完成した、一定規模のソフトウェアを公開しているか？
コードの断片レベルをいじくって分かる理屈が、現実世界では通用しないなんてのは、ままある事だよ。
ちんこは学生さんだけど、ちんこなら何かソフトウェアを作って公開できるはずだとおもうぜ。
そんな実践経験から現実の一面を学ぶ事は、ちんこの将来にもきっと役立つと思う。

また、コスト(開発費)という課題もある。
もちろん優秀である確立の高い、高学歴な人間ばかりを雇えば、プロジェクトの成功確立は高くなる。
でもそんな人間は絶対数が少ないし、雇うにも高いコストが必要になる。
企業はボランディアじゃない。これも、ちんこが社会に出れば、分かるようになることだと思う。

ボランティアじゃないから、優秀な人間のみ雇えと言ってるのだ。
低学歴のクソみたいなやつらを雇うのはボランティアとどう違うのだ？
社会奉仕みたいなもんだろ。
Googleのエンジニアの平均年収は1400万だそうです。
それにプラスして企業内のサービスなどもあるでしょうから2000万レベルの待遇といえるでしょう。
一方、一般的なエンジニアが年収500万として、Googleのエンジニアの1/4の仕事が出来ますか？
おれには1000分の1すら危ないと思えるのですが。

ちんこもPaulGrahamみたいにLispで起業したらどうよ？
Lispなら少数精鋭も夢じゃないだろ

あ、Java厨のちんこの頭じゃ関数型言語は理解できなかったかｗ

>>517
Googleのように、高学歴/高レベルの人材だけを集め、高度なソフトウェアを開発している組織は存在する。
で、ちんこがGoogleのような企業を志望しているなら、その道に進めばいい。
>>517のカキコは、まったくそのとおりだと考えるから。(1000分の1は言い過ぎだがなw)

ただし、その他の企業が、どのような人材を選別するかという判断は、その企業に委ねられる。
それに対して不満があるなら、ちんこは起業家の道を選び、少数精鋭集団の企業を立ち上げるべきだ。

あるいは、そんな日本におけるIT業界の惨状を、ちんこが真面目に憂いているのなら、
ちんこは教育者、あるいは政治家の道を選べばいい。

>>506
プログラミングと英語なんて関係ないだろ。
学生の質と英語力は関係が深いが、それは言語というものが深いと
いうことにすぎない。国語をよくし難しい書物を読みこなす人間は
英語も習得しやすいというだけ。

美しい言語を求め理想を語る学者もこの世には必要な存在だろ。
食っていけるかはわからんが。

>>517
共産主義こそ理想です。

>>520
>プログラミングと英語なんて関係ないだろ。

プログラミングという行為そのものには関係ないと思う。
でも、その前提となる知識を得るには、英語(最低でもリーディング)が必要。
日本語だけだと、書籍/論文/ネットの情報は限られているし、良書も少ないから、
どうしても人の後追い仕事しかもらえなくなってしまう。(今のVB房がそれ)
もっとも、いわゆる底辺プログラマで一生食べているつもりなら、英語できなくてもかまわん。

>>523
規格書が読めればいいのでは。
ORACLEがなぜ生き残ったか。外部に公開された規格書のみで、あれだけのものを
作ったから。そのことを知っている人に尊敬されていたから。

しかし、ちんこみたいにコーディング技術如きで底辺だの神だの言ってる奴は馬鹿なんじゃないのか。

おそらく、ライブラリの集合を、コーディング技術で包むと、フレームワークができる

いや、それはおかしい

>それにプラスして企業内のサービスなどもあるでしょうから2000万レベルの待遇といえるでしょう。
>一方、一般的なエンジニアが年収500万として、Googleのエンジニアの1/4の仕事が出来ますか？
>おれには1000分の1すら危ないと思えるのですが。

なんだこれは？頭が悪すぎるｗｗｗｗｗｗ
そのGoogleのエンジニアが一般的なエンジニアと同じ会社に勤めてたら500万しか貰えねえよｗｗ
どんなコード書いていようが500万だｗｗ
Googleのエンジニアの給料が高いのはGoogleが富豪だからに決まってんだろｗｗｗｗ

>>528
おれは、Googleのエンジニアの給料が高いなんて一言も言ってない。
むしろ低いくらいだと思ってるよ。
スポーツ選手たちは億単位での契約をしているのに、プログラマは給料が低すぎる。
あなたたちは500万でも高いくらいだが、
Googleのエンジニアなら億レベルでの契約をしてもいいくらい。

俺は俺の給料が一億万円ぐらいあればいいなと思ってる
年110万では少なすぎる

＞それにプラスして企業内のサービスなどもあるでしょうから2000万レベルの待遇といえるでしょう。
＞一方、一般的なエンジニアが年収500万として、Googleのエンジニアの1/4の仕事が出来ますか？
なぜかGoogleに関してだけ給料にコストが加算されてるけど、一般的な企業でもいろいろなコストはかかってるよ。
たとえば新卒の給料は300万くらいだけど、実際にはその倍くらいかかっているらしい。

俺の年収においては日本の国家予算ぐらいでも安すぎると思ってる

その人がどんな事情で進学できなかったかもしれないし
（親の借金・父親の酒代等）教育機関だけでその人の本質は決して解からない
ただ、コテハンに「ちんこ」をつけると、その人の本質は馬鹿ということしかハッキリしていない








ｗ

かかってこいよチンカス

学歴なんて、経営側が労働対価を値切るための指標にしか過ぎないだろ

ちんこは使えそうにないから月10万払うのももったいないんだが。

一日フルタイムで働けばどんな○○でも月に12万ぐらい稼げるんだから日本人は幸せだよなーと思ってる
○○には俺含む

そういやどっかで宗教に入信するのは高学歴が多いって話を聞いた
日本には仏教っていうとても素晴らしいものがあるのに
何故か新興宗教へいっちゃうやつが多いって。

高学歴は今までたくさん勉強をしてきたからね。
それで下の奴に負けるのは悔しいってか、心が保てないよ
だから強がったり、低学歴バカにしたりするのも分からなくはない

でもプログラミングの世界はね
100の仕事の知識持ってるけど、今回の仕事は初めてだっていう人と
1の知識しか持ってないけど今回の仕事はやった事があるって人がいたとき、
後者のほうが誰が見てもスキルは低いのに、仕事速かったりするんだよ？
コンピュータは膨大すぎるから、　誰も全部を把握できないから、
こうやって、立場がすぐコロコロ逆転したゆんだよ
下の奴に負けたくないなら、低学歴が絶対入ってこない仕事につくしかないよ
そもそも京大なんかいってるなら
自分から低学歴に関わろうとしない限り、　これから一生きみは関わらなくていいはずだよぬ
なのになぜ降りてくるんだろう？

あなたは知ってることしか出来ない人ですか？

過去にやったことから類推して、新しいものに迅速に適応出来ない人ですか？

おれは出来る人です。設計と、一つの言語についてよく知ってるので、
どんなフレームワークでもライブラリでも言語でも一瞬で理解出来ます。

最後の2行はダウト

そんなに自信があるならtopcoderとかSRMとかで世界の競合を相手に勝負やってればいいじゃん
下々のことなんて意識しなくてもいいよ

オレハデキルヒトデスゥセッケイトヒトツノゲンゴニツイテヨクシッテイルノデー
ドンナふれーむわーくデモらいぶらりデモゲンゴデモイッシュンデリカイデスマスー

ねーよｗｗ
そんな知能持ってるならそれこそバスを待ってる時間でLispでも覚えりゃいい

まぁがんばれや

お前が社会人になってもその考えのままいけるか見ものだな
天才天才ほざいてると、その言葉に連れられて色々な人が集まってくるみたいだから
レスはちゃんと読み返したほうがいいよ

＞どんなフレームワークでもライブラリでも言語でも一瞬で理解出来ます。

で、Prologは読めないんだっけw

とりあえず学生のうちはLisp漬けの生活を送っていきたいと思う。
LLとかは後でどうとでもなるでしょという考えに基づいて。

プログラムなんて、仕事の自動化を補助するもんだろう
仕事についての知識が無い奴がプログラムを組んでも絶対に良い物にはならない

素晴らしいコーディングだの、美しい言語だの、扱いやすいフレームワークだの
そんなものに、大した意味はありはしないよ

＿＿　＿＿＿＿＿＿＿__
　　　　　　r | |――┐　 r――　　ヽ
　　　　　　L.! !_∧＿∧　Li＿＿　　　＼
　　 　 　 .＿| |（　　ﾟ∀ﾟ） ||＿＿__　　 　＼＿　　　　　　　 　　　　　 （~ヽ　　　　　　　.. .
　　　　　（＿| |/　　　／つ⌒ヽ　 i　　　　　＼）　　　　　　　　 ／⌒ヾ .＼＼＿　　　:・:∵:
　　　　　　　　＼￣￣￣￣￣￣￣￣￣￣￣"''' - ..,,　　人　／⌒ヾ　／ ＼＼￣ヽ∴:　ｹﾞﾊｧｯ
　　　　　　＿　　＼＿／⌒ヽ＿＿＿＿＿＿＿＿／⌒ヽ　 て　　　／　ノﾃ-ヽ（　｡Д｡）二二つ　　←ちんこ ◆GbXlaaQNk.
　　　　　　　 ヽ　　　　　 ＿ﾉ r―――─―――┐　＿ﾉ　ドカッ／ ／　/　　　∨￣∨
　　　　　　 　　|　　＿＿＿＿| 三三三三三三三.|＿＿l__　　　 /　/　|　|
　　　　　　| .＿|--[＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿]　／　__)　ﾉ　)
　　　　　ﾉ.|　　|　　　　===========[＿＿＿]======='　　 ー'　　　 し'
　　　ヽ＿ﾉ＿ノ　　　　　　　　　　　　　　　ヽ__ﾉ＿ノ

コードの価値を認識出来ない開発者はレベルが低い。

一流の開発者は良いコードを書くことに命をかける。

君たちって、開発者でもないんだろ。

何なの？

ちんこは人を貶すことにだけ命をかける

プログラミング言語などよりもはるかに美しい、イケメンです。

コードの価値なんてものは、与えられた仕事をきちんと自動化できたかどうかだ
美しい必要も、素晴らしい必要も無い

それが美しさというものですよ
実際美しくないものとされているソフトウェアはすんなりと成功は導かれてない

美しさというかデザインですね。
近年ではユーザビリティとかいう概念が流行ったこともありました。

確かにもっくんはカッコイイと思う

またJavaしか出来ないちんこ君来たのか
とっとと美しいちんこ言語作りなよ、スレタイ読める？

あと天才なら簡単なLispぐらいなら1日で作れるだろ
それぐらい朝飯前だよな？

まあ、実際就職してみればわかるんじゃね？
どれほど美しいコードを書いても誉められもしない現実を味わってみればいい。

>>556
美しいコード書いたことないから褒められたことがないのは当たり前では？

評価する人が美しいコードに興味なければ美しいコードは評価されないだろうね。
相手の評価に不満を抱くのではなく、客観的な評価という幻想を打ち砕くことだ。

釣りにしちゃ手が込んでると思っていたが、天然なのか。

そもそもこのスレ自体ネタだろ？

>>558
当麻乙

美しいコードって何ですか？

何だろうな？>>556に聞いてくれ

日本では、「協調性」 ばかりが重視され、「個性」 ・ 「主体性」 は軽視されています。
協調性ばかりが重視される社会においては、個人の自由が尊重されず、
また、各個人が自分を見失ってしまって 「楽しく生きる」 ことができません。
そして、個人の自由が保障されていない社会は、最終的には破滅への道を歩むのです。
確かに協調性、チーム・ワークといったものは必要ですが、
それらは強烈な個性と個性が集合し、
互いに火花を散らして激しくぶつかり合うような集団に初めて必要になってくる高度な理念です。
ところが、日本の教育では、子どもたちに個性を持たせるステップを省略して、協調性だけを教育するのです。
これでは 「協調性」 の教育もおかしなことになってしまいます。
個性を持たせずに行う 「協調性」 の教育は、
「協調性」ではなく 「均一性」 の教育で しかありません。
日本には 「協調性」 を 「均一性」 のことだと勘違いしている人が多いのです。
均一性に重きを置く教育というのは、多種多様な考え方を認めない非民主的なものであるばかりか、
多数派がすべてを支配してしまう 「全体主義」 を許してしまう危険性をはらんでいるのです。
協調性というのはみんなが同じ考えをすることもなければ、集団の中で個人が犠牲になることでもありません。
各個人が尊重され、また多種多様な考え方が共存するというのが真の協調性です。
今日までの日本において 「みんなが同じであるのが望ましい」 という教育方針は、
教育をする側にとって大変都合のよいことでした。
画一的な教育をして、子どもたちを型にはめこみ、均一化してしまいさえすればそれでよかったのですから。
つまり、今日までの日本の教育は教師本位のものであって、子ども本位のものではありませんでした。
みんな仲良しというのは所詮ありえない幻想、世の中には色んな人がいて、
気が合わない人、分かり合えない人がいて当然で、その中でうまくやっていく事や集団への同調ではなく、
互いに個性を尊重することを考えれる人を育てることが日本の空気の支配を弱めるには必要だと思う。

そうです。

個性というのは優秀な人間にしか認められません。
実際、優秀な進学校というのは自由な校風を導入しています。
おれの母校の麻布も自由であり、個性的な学生を育てています。

おれのような人間がソフトウェア界を引っ張るべきなのですが、
あなたたちがヘボすぎるので絶望しているのです。

個性って何ですか？
そんなもんいちいち見てはくれませんよ。
気にしているのは納期に間に合うかだけだ。

ちんこの個性って周りをカス扱いすることか。

ちんこなんか所詮Java専門のIT土方が関の山だろ
Googleなんかでもこんなのは使わないだろ

てかいい加減別スレ建てるかOOPのスレに引っ越してくれないかな
美しい言語スレの筈なのに出てくるのはちんこ流コード理論の話ばかり
しかもこいつはちょこっとクラス設計してるだけで
実際にコード１本完成させたことないんだろ
なんでこんなでかい顔してここにいるんだ？

そういやScalaは神とか言ってたけど実際には使ってないのか
やっぱりそんなレベルなんだろな

リアルでは誰にも相手にされないけれど、このスレでは煽っていれば
相手してもらえるから、嬉しくて嬉しくて仕方ないんだよ、ちんこは。

そろそろ並列処理について学んでみたいんだけど、
綺麗にそういう処理が書ける言語のオススメとかない？

Erlang

c

>>564-565
コテハン・名無し自演乙ｗｗｗ
お前の同意意見は自演だということぐらい見抜けない馬鹿はいないｗ

>>571
言語じゃないけど美しい計算モデルであればホーアの考案したCSP、
簡潔さであれば(CSPを基にした)Occam言語がある。
Occamの語源はもちろん「オッカムの剃刀」の数学者オッカム。
ErlangもCSPの流れをくむ。
CSPは旧版であればホーアが書いた教科書の訳本あり。
新版(英語)はネットでダウンロード可。
個々の単語が不明であればWikipediaで調べてね。

蒼井そら

>>571
intel c++コンパイラ

>>575
なんか、漸く出てきたって感じだな。

>>574
このスレとkami_objectのブログを見れば分かる通り、
ちんこは自分と他人の意見が違うのは他人がバカだからだと
くり返し公言する典型的な中二病患者です。
>>564の主張はちんこの普段の主張とはあきらかに異なります。
もし>>564がちんこが匿名で書いたレスならば、
ちんこは実は自分を特別視しない客観的な見方もできる人であり、
ブログの中二病患者ぶりは演技だと言うことになります。

私は>>564はちんこ以外の人の書き込みで、
ちんこは>>565のように自分は特別な選ばれた存在であるという
妄念から一歩も離れられない状況にあり、
>>574は自演認定厨の妄想にすぎないと判断します。

you make feel good!!
セクシャルぅバイオレットぉ
セクシャルぅバイオレットぉ
セクシャルぅバイオレットぉ　ナンバぁーワぁーーン
情熱の赤ぁ　哀愁の青ぉ　今混ぜながらぁ（ｒｙ

>>564は単なるコピペだしな

ここまでforthの話なし

Jedi乙

>>582
今更Forthか？って感じだな
ファームウェア開発くらいにしか用途は無いし、
ましてや「美しさ」を語るレベルには、ほど遠い存在

まぁちんこでもまんこでもなんでもいいんだけど、一言だけ
スレチ

いやいやforthは美しい

スレの議論の対象は「言語の美しさ」だろ
なんで有用性を語る奴が出てくるのさ

584だが、たしかに有用性は余計だったかもしれん

ソフトウェアについて悟りを開いた。
アジャイル以外の選択肢なんて存在しない。
言語？関係ない。OOによるアジャイルが最強。

言語が関係ないって、今更言うことじゃない

今頃解ったのか
さらに言うならOOもそんなにいいものではない
関数型もOOPも両方使えるマルチパラダイムのがいい

言葉足らずだな、すまん
言語が関係ないってのは今更言うほどのものじゃない
開発手法のどれが最強ってのは置いておいてだが、
その考えに至ることが出来るか出来ないかで、実際の開発時にかなりの差が出てくるものと思われる

たぶん、君が至っている領域とは違う領域にいる。

神の領域に至ってしまった。
スーパープログラマになってしまうと思う。

>>593
領域って何？realm?

絶対領域

領域…ねぇ……
範囲外の領域だったりして

言語どうこう語れるのは
ＣＰＵが０と１しか判断できない障害者であるため

OO（笑）
アジャイル（笑）

画期的な概念は最初に滑稽だと思われるものだ。

バートランド本を読んでないやつがOOとか言ってると、本当に理解してるのかよと思う。

でも、OOって最初に言い出したのはアラン・ケイなんだよね
そして、その後概念を捻じ曲げたのはストラウストラップ
いわば、メイヤーなんてOOの立場からすれば完全に部外者

お前、バートランド本を読んだことはあるのか？
おれは感動しまくってる。
素晴らしすぎるよ。ETHに行きたかった。

ずっと昔に、第一版を読んだことがあるよ
でも、部外者の言ってることは信用しないほうがいい
信用したからいろんな概念が入り混じったあいまいな
概念となってしまってるのだろうが

POSAやPEAAを読んでない奴がMVCとか言ってると、本当に理解してるのかよと思う。

>>604
じゃあ、MVCってなんですか？
おれはMVCの神だよ。
プログラミングを始めた時からMVCの必要性に気づいていた。
そして半年ほど前に解決した。

確かにバートランドは、継承について語りすぎていると思う。
継承が危ないことはよく知られているし、継承は再利用のための非常にまれな手段でしかすぎない。
多くはオブジェクトコンポジションによって達成される再利用だ。

78 名前：デフォルトの名無しさん [sage]： 2009/10/21(水) 21:04:59
もうさ、MVCが基本とかいう幻想は早く捨て去ろうよ
あんなもの、単にオブザーバーパターン使ってみましたってだけじゃん
GUIのGの字も語ってない
それよりも、FRP（Functional Reactive Programming）とか参考にした方がまだまし


80 名前：デフォルトの名無しさん [sage]： 2009/10/21(水) 21:20:27
そういう様式論って殆ど実りが無いんだよな…
マーケティングのバズワードとかハイプとかと同じ匂いがする


81 名前：デフォルトの名無しさん [sage]： 2009/10/21(水) 21:22:40
様式論のバズワードの筆頭がデザパタ

またHaskell厨か。
もうね、Haskell厨はうんざりなんすよ。
OO最強、OOとアジャイルのコンビネーションが異常。
いってみれば、あんぱんと牛乳のようなもの。

OOSC第2版が出たのは2000年
JavaWorldに「Compositon vs Inheritance」がポストされたのは1998年

>>609
さんくる。
JavaWorldというのは知らないが、
その記事には興味がある。あとで読むことにする。
http://www.artima.com/designtechniques/compoinh.html
これだよね？
すでに議論されていたのか。
議論したり考察した内容はきちんとした形でまとめておく必要がある。
それが出来ない企業には入りたくない。
煩雑とした文章でまとめることには意味がない。
テクニカルライティングの技術がない人間は雇われるべきではない。
彼は害悪的文章をまき散らすだけだ。

ちんこはGoF本読んだか？
デザパタを学ばぬうちは、OOPをしゃぶりつくせてない。

>>608
ちんこに訊きたいのですが、
Haskell を使っている一部の人間に嫌気がさしているのでしょうか。
それとも、Haskell という一プログラミング言語に嫌気がさしているのでしょうか。

また、その理由は何でしょうか。

デザインパターンｗｗｗ

むしろちんこをしゃぶりつくしたい

ちんこはJavaかOOスレにとっとと行きなよ

Objective-Cの作者は単一継承すらいらなかったって言っている

>>611
当たり前だ。
未だに学ぶことがある名著だ。
デザインパターンはそれをソフトウェア開発に活かす再利用方法もあるが、
もう１つの再利用方法は、ディベロパ同士のプロトコルとして使うことだ。
おれはむしろ後者の方が恩恵が大きいと思っている。
前者は、デザインパターン中毒を生みやすい。
とりわけ低レベルなディベロパはデザインパターンがいつも有効だと思う傾向にある。
シンプルであることがもっともアジャイル的だということを忘れて。
これはケンパークのプレファクタリングにも書かれていることだ。

>>612
おれのブログにHaskell厨がよく来る。
彼はよく知っているが、「すべて関数だ」しか言わない。
Haskellは厨を生みやすい。
また、Haskellという言語そのものの役目は終わった。
関数型ならScalaオンリーだ。

>>615
お前らはおれが嫌いなのか？

>>616
それはやりすぎだ。
おれはフックや骨格実装を実装させる、設計された継承ならば許されると思う。
例えば、JComponentのpaintComponentだ。
何も描画しないという、いわゆるヌル描画は振る舞いを重視するOOにおいて必須だと思う。
単一継承は絶対に必要。

>>617
＞お前らはおれが嫌いなのか？


　　　　→はい。

バートランド・ラッセル

>>617
> Haskellは厨を生みやすい。
何故でしょうか。
また、Scala は Haskell ほどの厨は生まないのでしょうか（何故？）。

> Haskellという言語そのものの役目は終わった。
ちんこが考える Haskell の「言語そのものの役目」とは何でしょうか。

ScalaとHaskellのソースを比べると、やっぱりScalaの方が冗長な記述が
目立つような気がする
あと、ポリシーが違う
Haskellは数学的な純粋さがポリシーで、Scalaは多様な概念の融合がポリシー
Haskellは極端で、Scalaはどっちつかず

そこでCommonLispをだな
OOをやりたいならCLOSもあるし
型宣言で効率も追求できる

動けば良い
ただそれだけを追求したBASICよりも美しい言語は無いと思われる

VB Script万歳!!!

>>623
言語ではなく言語を使う人が美しい一例だな

Haskellは「なんかよくわからんが、圏論という数学の難しい理論を使ってるらしい。
インテリ風でカッコよくね？」みたいな感じで信者を生み出す。

>>625
それはあなた。

私はCleanをやりたかったんだけど、Cleanがプロパライエティで使えないからHaskellに流れてきたんです。

>>626
俺は信者じゃないよ

.NET対応
ＶＢ，ＶＣ＃，ＶＣ＋＋、こ

美しくなくていいから最強の言語がほしい。

アセンブラ

>>631はやっ

>>628
ならばあなたの憶測。

いろいろな言語に手を出す人が多いのは達人プログラマの影響が大きいだろうな。

わたしは器用貧乏だねってよく言われる(´・ω・｀)

目的に適した言語を選んで使うのが大切なのではないかと
速度、あるいはハードべったりなプログラミングに限定すれば、アセンブリ言語は最強かもw

関数型言語からCPUアーキテクチャに最適化されたネイティブバイナリを
吐き出すコンパイラを書けるプログラマが最強だろ

minCaml？

Haskellとは特定言語ではなく、むしろ言語にとらわれない態度のことだ。

神の領域とか言っているやつも厨と変わらんよな

というよりモロに厨だし

>>29
そうなんだ。大月の読んでみようかな。
俺理系なんだけど呉智英の講義で興味持っちゃってさ。

誤爆w

LispはEmacsを弄ろうと勉強しようと思ったけど
James Goslingの発言を受けて止めたのはいい思い出

GoslingはRMSと犬猿の仲らしいな

でも確かに「Haskellは厨を産みやすい」

っていうのは真実だよな。
この板のどこでもHaskellが話題になる時期があったけど、
そいつら全員が本当にHaskellで実際何か作ってたかと言われると非常に疑わしかったし。
「モナドを使うには圏論の理解が必須」とか大嘘こいてた奴も多かったし。

Scalaは確かにあんま厨を見ないな。



単 に 知 名 度 の 問 題
J V M （笑）

俺が書いたHaskellアプリケーション
xmonad.hs

>>646
同感だね

俺は代数みたいな難しい数学を知ってるんだゼー、お前ら知らねえダローって自慢したいだけ
新しいオモチャを買ってもらって、それを友達に見せびらかしている、
小さな子供達の会話にしか、自分には見えなかった

Haskellの処理系を「作る」場合には圏論の知識が前提になるかもしれないけど、
Haskellの処理系を「使って」プログラミングする場合には、そんな知識は必須じゃ無い

インテリってのは子供っぽいもんだ

>>624
書式が決まってそれ以外の書き方が極端に少ないから、汚く書くには、逆に考えないと無理だろうwwww

>>648
Haskellでプログラミングするのに圏論の一部は必要だが、全部は必要ない

ついでにいうとHaskellプログラミングに必要な圏論は
Haskellの教科書に書かれているので、別途やらなくてもコードは書ける

そしてお前らのいう「知ってる」「理解してる」
っていうのは大抵の場合、
上っ面を舐めただけのことなんだけどね。
底辺の人間って大抵そうなんだよ。だからしょぼい。

そしてちんこのブログは用語が独特で誰にも理解できない

それはお前がしょぼいだけ。
何も考えてないから、自分の持っている概念からおれの概念にマッピング出来ない。
何かに一生懸命取り組めば、他のこともその類似性から何となく分かったりする。
世の中にある多くのことには一般的な類似が見られる。

お前らは常に浅いところで理解したと錯覚するから、一生そういう経験を得られない。

低学歴の人間って大抵そう。

まぁ言葉は正しく使うようにきをつけたほうがいいよ

とりあえずちんこは邪魔

>>656
正しい言葉なんて誰が決めたんだよ。
その言葉は英語ですか？ポルトガル語ですか？
この世に正しいプロトコルなんて存在しない。
存在するのは、「おれと話したいならおれのプロトコルを使え」というDIP原則だけだ。
おれは他の誰とも会話せず、本と独学でOO技術を勉強するから、他のやつが定義したしょぼい言葉なんて使う気になれない。

ならお前のブログから出てくるなよ。

>>659
本気でも釣りでも構って損するような
バカはほかっとこうぜ！

ならまずは論文の１本でも仕上げてみなよ
ちゃんとみんなが理解出来て認められる内容でな
お前のはただの独りよがりだろ

はぁ？
誰にも理解されなくていいし。
お前らを含む他人に、おれが理解して欲しいと思えるだけの価値がある人間はいない。

そういや
ちんこはubuntuしか知らないのでWindowsやubuntu以外のLinuxは消えろとか言ってたが
そうなったらJavaの存在意義が無くなりますね。

ちんこは >>620 の質問に答えて頂けないのでしょうか。

>>664
Haskellを知っているみたいだけど、単に質問するだけじゃなくて、

・.....だから、Haskellは厨を生みやすくないと考えるが、どうか？
・.....だから、Haskellという言語の役目は終わったとは考えられないが、どうか？

というカキコでないと、「フェアじゃない」と思われ。
もしも単純にHaskellについて知りたいだけなら、Haskellスレで質問するのがいいと思うよ。
横レス、スマソ

言語の総合比較のスレを作って
そっちでやってもらえば？

もしくは、自分で作ってそっちに移るわ

>>661は日本国内だけでとは書いてないだろ
まぁこいつは海外の研究者にも認められないだろうがな

と言うかいい加減このスレから消えろよ、スレ違いだろ
JavaかOO、関数型言語のスレに行って思う存分語ってこいや
大体ここでおまえは何をしてた？
「俺の考えた理論は神、それを理解出来ない奴は池沼、氏ね
ちんこ様を崇め奉れ」
それしか言ってないだろうが

>>667
かまうのは思うつぼ

無視すればいいと思うよ
そしておまえは言語の美しさについて話題を提供しなさい
（あいつが作る話題しかないことも、また事実だからな
最初のころは勉強になると思ってたが、図にのりすぎている）

>>665
私は Haskell が厨を生みやすくないと考えているわけではないです。
そもそも Haskell が厨を生みやすいのかどうかが分からない。
（どちらの側に付くにしても、その根拠となる材料が私にはない）
ちんこは生みやすいと言っているので、その考えをもっと聞きたかった。

Haskell という言語の役目は終わってない、という考えが私には無いです。
そもそも Haskell の役目というものを考えたことすらないですし、
ネットで少し調べてみましたが、役目について意見を述べている方が見あたりません。
なので、ちんこの考える Haskell の言語としての役目が何なのか取りたかった。

べつに対等に議論したいわけではないです。
考えが聞きたかっただけです。

教えたくないのでしたらそれで構わないのですが、
そうなのか、単にスレを見逃しただけなのか分からなかったので、
催促してみました。

>>669
> ちんこの考える Haskell の言語としての役目が何なのか取りたかった。

知りたかった。

>>658
> おれは他の誰とも会話せず、本と独学でOO技術を勉強するから、他のやつが定義したしょぼい言葉なんて使う気になれない。
本に書いてあることもOO技術もそれ全てちんこじゃない人間が定義した言葉だけどな

早く言語の美しさの話にもどろうぜ。
かまってチャンの面倒見るのもこれくらいで良いだろ。

そもそもこいつは今の日本のIT業界を啓蒙したいと言っておきながら
誰にも理解されなくていいって言う奴だしな

>>672
と言ってもネタが無いな

なにか美しさの目安が作れれば面白いな
コードの長さ、識別子の数、ループや条件判断のネスティングの数
ここらへんでスコア作ってみるとか？

>>675
似たような言語なら比較できるけど、
全く別の種類の言語では比較の仕様がない

全ての言語の中からってのはいきなりやるにはハードだと思うから、関数型とか手続き型とかの型とかで区分けをしてから
その中で1番ってのを決めてみるのがいいんじゃなかろうか？
そうすれば、それぞれの区分け内で1番になった言語のどれがもっとも美しいかってのも評価しやすくなると思う

>>671
乗りたいフレームワークと乗りたくないフレームワークがあります。
それだけの話です。
デザインパターンの用語を独自に開発するのはよくありません。
なぜならば、おれは、デザインパターンを使って他のディベロパと会話がしたいからです。
おれが会話したくないと思う人たちの言葉は覚える必要がありません。
例えば、あなたがアメリカ人の彼女が欲しいと思えば英語を勉強するしかありません。

例えば、工学では、分野によって言葉の定義が違ったり、符号が逆だったりすることがあります。
この時、あなたがその分野にいたいと思えば、その分野の流儀に従う方がいいです。
そしてこの時、他の分野の知識を使おうとすると、変換コストを覚悟するしかありません。

あなたはめちゃくちゃなソフトウェアを書きそうです。
気持ち悪いので、これから一切コードを書かないでください。
おれには、悪いコードを書く人間は犯罪者だという意識があります。

>>663
Javaの意義がWORAのみだと思っている池沼ですか？
おめでとうございます。
あなたもこの瞬間からコードを書く権利を失いました。

ある言語を知らない人が、その言語を知ったときに美しいと思う確率で定義しようぜ。

>>679
それは難解だなｗ

美しさの定義についての話題でも、なんかすがすがしいよ。
かまってちゃんの相手より。
このスレは結論をだすスレじゃないんだよね。延々と議論するスレなんだよ。

このまま、かまってちゃんは華麗にスルーの方向で。

Javaなんて、VB Scriptよりも劣るものをよく賛美できるなぁ...

Javaしか理解出来ないんでそれを賛美するしかないんだよ

Javaにジェネリクスなんぞ要らなかったよ。
foreachの構文はよかった。

ほほー
ttp://d.hatena.ne.jp/kwatch/20080305/1204743236

俺は変態だがPerlが美しいと思う。
100万のゴミの中から1行の輝くコードを発見した時の喜びが忘れられない。

>>687
この変態！

>>687
どう美しかったのか(輝いていたのか)書こうよね。

ゲッターセッター問題はRubyのやりかたがいいと思う。
簡潔にアクセスさせつつも、オーバーライドもそのままさせられるという。

ただ、クラスにゲッターとセッターが目立つようなら、
そもそもクラス設計がミスってると考えるべきだね。

>>689
忘れた。

if(cond1){
if(calcCond2()){
doIfTrue2();
}
return;
}
でいいんでないの？
余計な一時変数は省けよ。
コレのほうがよっぽど見やすいだろ。

どの言語で書いても俺のコードは美しい

>>693
具体的になんで美しいのか書いてくれよ。ぎろんできないじゃん。

美しさは複合的な要因で成り立っているものだ

美しいものはシンプルでわかりやすいものだ

美しさはIDEに現れる

small is beautiful, simple is beautiful

>>698
OH......I don't think so................

>>699
why?

Smalltalk is beautiful.

>>700
Yeah.......
Maybe........

Fine thank you ...ando you?

Oh, I'm fine thank you !!

Good luck!!

by Kein Kosugi in New York

E = mc^2

これが美しいというのは誰もが認めるところである。

>>291
東工大が志望だったみたいだね

>>704
Why?
Did you know its reason ?

and...... What's toukoudai ?

>>705
Didでいいのか?

>>706
Hahahahahahaha

I'm sorry..........mistake!!!

Hahaha.....

またへんなのが沸いてきたな
ユーモアにしても面白くないし、こういうセンスしかないやつは美を語れない

シンプルな美しさと言えばLispやForthだな

この中のオセロの局面という述語なんかはどう評価する？
http://nojiriko.asia/prolog/t844.html

>>717
評価の観点はいろいろあるよね
まずは日本語を使うのは美しいかかな？

さてｋｓｋするか

http://coreblog.org/ats/turtle-python-standard-module
ここでPythonのturtleというものが紹介されています。
上記ページにある、turtleを使ったコードは簡潔でわかりやすく、エレガントで、
このようなコードが作れるPythonは美しいと思いました。

>>713
指示性があっていい書き込みだね。

>>703
別に、そいつが美しいわけじゃない。

1.4.2までのJava。マルチパラダイムに色気を出してからJavaはおかしくなった。

>713
むかしNﾍﾞｰｼｯｸ用のﾀｰﾄﾙがあったなあ。

kコンパイラとか

>>685
Javaでコンパイル時に型の安全性を保ちつつ、foreachするにはGenericsを使わざるをえなかったとおもうのだが・・・Generics全否定というわけではなく、JavaのGenericsがあまりにも中途半端・貧弱ってこと？

a

>>720
> a

ちんこちゃんのblog意外に読み応えあったよ
暗黒面に落ちた新山さんて感じでｗ

書き込めない。

>>722
新山って誰？すごいの？

tabesugi.netの人
python弄ってるとき遭遇してると思うけどなあ・・・

>>725
Python？何のこと？
すごいのかどうか聞いてる。
OpenSSHの本とか形態素解析の本とか書いてるらしいけど、
有名な人なの？

なんだまた生きてたのか
スレ違いなんだからここから消えろよ
天才だってんならとっとと起業でもしたら？
大学生でも起業する人だっているんだし

暗黒面に失礼だ

つーか、呼ぶようなこと書くな＆相手をするな。馬鹿？

OOって、ほんとに重要なのか？その辺に、自分の足を撃つ要素が増えるだけだろ
ガチガチのオブジェクト指向で設計されたシステムは、後々で変化できんってリーナスが言ってるぞ。
tclの開発者だって、たしかOO嫌いで、言語仕様に取り込みたがらなかった。
ポールグレアムだって、arcはとりたててオブジェクト指向じゃないことに何か随筆書いていたし

よく考えられたインタフェースベースのシステムならそうでもない。
アダプタパターンとかで比較的簡単に付け替えができる。

ただ全くの別物に変化させるのは難しいだろうね。
後方互換のために大量のコードが残る可能性がある。

ということで、おれは、
「アダプタによって互換可能でないアルゴリズムは使い物にならない」
ということを主張している。
USBメモリは可変な抽象を開くことによってCPUからデータの書き込みが出来る。
再利用性が高いのは、インターフェイスがシンプルであるのと、アダプタブルであるからだ。
もちろん、アダプタブルでないシステムも再利用性はある。
自分システム (( 自分定義のインターフェイス (( そのシステム
という形でバリアを張ればいいからだ。だが、再利用性はやっぱり劣る。少なくともコピーが入るからだ。

中途半端なOO技術を適用すると、ゴミのようなシステムを作ることになる。
多くの人間はOOを単純にとらえすぎているが、実際はそうでもないのだ。
ちゃんと勉強しないとダメだ。
特に、タグによって階層を表現するシステムを見ると泣きたくなる。
どうやら、古い時代には、認識コードによって種類を特定するという考えが蔓延していたらしく、古いライブラリにはそういう設計が時々見られて腹立たしくなる。

机上レベルでシステムなんか作ったことないだろうデザパタオタクの学者の卵が何かしら宣ってらしゃる

コードを見て腹が立つって致命的欠陥だな。
糞コードにムカついてるよりもどんなコードもストレス無く読めるほうが利点が遥かに多いだろ。
難読化されたコードを解析するとかこれからの時代はありそうだしさ。

互換のないインターフェイスをアダプタパターンで再利用可能にする
というのが本来の筋だろ

インターフェイスにおいて十分に気をつけないといけないのは、可変のインターフェイスです。
例えば、何かを提供してくれる人であれば、提供してもらったものを自分空間でラップすればいいので簡単に整合がとれます。
何かを突っ込んで、別のものが返ってくる場合（問い合わせなど）も、突っ込むものを生成するフェイズは自分のライブラリとはほとんど何も関係ないので問題がなく、突っ込んだ後は上のパターンに帰着します。
問題は、何かを突っ込んで、それ自体が変化する場合です。
例えば、USBメモリを考えましょう。USBメモリは突っ込むと、PCからそのメモリにデータを突っ込めます。つまり、可変です。
実際に、書き込む前と書き込むあとではUSBの中の磁気情報には変化があります。
さて、ここで、USBに書き込むというではなく、書き込み口の方が独自に決めた具象のブツに書き込む仕様だったとしましょう。
とれる方策は２つです。
外の世界もそのブツに依存すること。そして、そのブツを自分の世界にコピーすることです。後者は、前のパターンに帰着します。
このどちらも使いにくくてしょうがありません。うんこです。
なので、おれは、可変のインターフェイスについては、常に抽象化することをオススメしています。
そうすることでコンポーネントをくっつけるがごとく再利用が出来るのです。

3行でよろしく

PCI規格の拡張カードは、PCIの拡張スロットに挿すことが可能
それが、ビデオカードだろうと、サウンドカードだろうと、キャプチャーカードだろうと関係はない
そういったハードウェア的機能をソフトウェアに求めたのがオブジェクト指向だ

と、3行にまとめてみた
重要なのは、1つのソフトウェア上では、1つ思想で通すことだと思うよ
うーん、なんか上手く表現できんけどな

>>738
それは違うな。
これは以前にブログに書いたら、ソフトウェアとハードウェアの大きな違いは、
アダプタが作ることへのコストなんだ。
ハードウェアでは、アダプタのコストはそれ自体が非常に高い。
だから、実際問題として、自分でインターフェイスを定義することは出来ず、すでに定義されたインターフェイスに依存することが求められる。
どんなデバイスを作るにしても、そうしなければ再利用性がなくなる。
ソフトウェアは、インターフェイスを抽象化しておけば、安価なアダプタによっていくらでもつなぐことが出来る。
ここが大きく違う。

ちんこってやつは、人にわからせる説明をする能力はないな

>>739
そんなことは無い
ハードウェアにしても、インターフェースはわりと色々な物が存在する
コンピューター製品しか見たことが無いから、ハードウェア製品のインターフェイスコストが高いと思うだけだと思うよ

制御盤なんかは、規格はあっても、インターフェースそのものは出鱈目だから
図面を確認しない限り端子盤に電線を接続することなんて出来ないし

>>741
ではあなたは自分でインターフェイスを定義出来ますか？
それは出来ません。
あなたは与えられたいくつかの変換可能なインターフェイスのうち、自分に良さそうなものを選んでいるだけです。

>>742
貴方はそんな簡単な事も出来ないんですか?
ソフトばかりに目を向けず電子工作位はした方がいいですよ

まあハードというか、脳外の事象についてはあんま強くないみたいだな・・・
ＵＳＢメモリの磁気情報ってｗ

Pythonの作者が語るScala
http://blog.shibu.jp/article/28455302.html
けちょんけちょんに扱き下ろしてます

辺に抽象化せんで間にラッパーのようなもの入れるんじゃだめなのか？
ソフトって新しいインターフェースを作るのにハードほどコストかからんだろし

Haskellだけは褒めてるのな
さすがPythonの作者は見る目があるな

>>746
それは前提です。
再利用するものが、こちら側を書き換えるようなものだった場合に困るということを言っています。
対処療法としては、まずこちらでバリアを作って、それからあちらでの演算結果をコピーします。
それで様子を見て、もしボトルネックならばその部分を自分で書き換えるということをします。

>>744
USBメモリは強磁性体というものが使われていたと思います。

>>743
電気電子工学科卒のおれに向かって何言ってんだ？

Scalaの型システムが複雑すぎるとダメだしした上で、
代わりに持ち上げたのがHaskell？？
Haskellの型システムだってよく複雑怪奇だと言われてるのに

>>746
抽象化自体はした方が良いと思うよ
制御盤に機器を取り付けるにしても、じかにネジ穴を開けて取り付けるよりも、レールマウントのほうが楽だし
場合によるっちゃよるけどねぇ(大電流用の遮断機をレールマウントにするとか馬鹿かって話になるからねぇ)

>>748
電気電子工学科を出てて、インターフェースの自作は無理とか言ってちゃ両親が泣いちゃうでしょう...

>>751
それ、インターフェイスの概念を間違ってるよ。
電子工作でのインターフェイスは、すでに存在するインターフェイスの合成物がせいぜいでしょ。
ソフトウェアにおいては完全に独自のものを定義出来て、それが有用だからハードとは違う。

>>750
あなたは分かってるな。
抽象化すべきところを抽象化しないでリリースしてるソフトウェアを見るとイライラする。

Scalaは知らんが、Haskellの型システムの何が複雑に見えるのか、が分からん。

class, instance, data, typeといろんな予約語があるし
多相型とか型クラスとか普通にややこしい

>>752
すまんねぇ、>>750も>>751も同一人物なんだよね...

>>754
それは、関数型言語を知らない人から見たらそれらが複雑に見えるのか、
それとも他の関数型言語に慣れている人から見てもHaskellのは複雑に見えるのか、
どっちなんだ？

Javaでいいや。優れたIDEを持った言語が優れた言語ってことでｗ

>>757
あなたは賢い選択をした。
javaが最強なのです。他の言語など、IDEがカスだから使い物にならんのです。

>>758
IDEがカスかどうかは何を基準に判断してるんだ？

電電出身だとemacsも使えねーのかよ

javaのIDEはeclipse、netbeans、ideaが3強って感じ？
やっぱeclipseがいいのかな

>>756
慣れてるけど複雑に見えるよ

>>758
Scalaが最強じゃなかったの？

>>760
4回生になるまでは、emacsを使っていました。
IDEというものの存在を知りませんでした。
しかし、Eclipseを知ってから、文章作成やスクリプト以上のことはEclipseでするようになりました。
texを書くのですらEclipseです。emacsなどもう、使ってられません。

言語オタクの俺が認定するIDEが優れてる言語
Java + Eclipse
Java + Netbeans
JavaScript + Eclipse + Aptana
Flash + Flex Builder
Flash + Flash Development
Python + Pyscripter
Python + Eclipse + PyDev
Ruby + NetBeans
C# + Visual Studio
C++ + Visual Studio
C++ + Vim
Lisp + SLIME + Emacs
Elisp + Emacs Lisp
PLT Scheme

IDEが優れたの最強っつーんだったら、VSによって使える言語も十分優れているよ
言語はC++、C#、VBだったっけ？

TeXに関しては正直言って野鳥の方がまだEclipseより便利かなあ
emacs侮れないね

pyscripterってwin専用だろ？
javascript + aptanaっていいのか・・・。aptana重くない？

>>763
Scalaは言語単体なら最強。
だけどトータルではJava、これは揺らがない。
ScalaのIDEがJava並に発達すれば、Python始め、すべての言語は不必要になるレベル。

>>768
なんだおまえは、使ってもないのにカスかどうかを判定してたのか？

>>768
VSとかもWin専用だけど、そういうことは判定基準に入れていない
使いやすさ重視

>>769
あなたはナイフで足を刺してみないと、ナイフで足を刺すと痛いということが分からないのですか？

>>765
PLT Schemeは未来的だよな
他のは言っちゃえば想定の範疇だけど、PLT Schemeは意表を突かれた

Pythonを実際に使いこんでたら「型がない言語は不安だ」なんて
言わなくなるって

すべての言語不要って、せいぜいシステム開発かアプリ開発の上でだろ
組み込みや数値計算の分野では、今後とも、CなりFortranが使われるし、
簡単なバッチ処理がしたいときに関数型とかいらん

>>772
確かに
そういう意味ではかなりヤバイな
未来的というか独創的

>>771
喩えがおかしい。

ナイフで足を刺すのが危険かどうかの判断は刺してからでは遅い。
しかしIDEがカスかどうかの判断は十分使ってからでも遅くない。

むしろカスなんてレッテルを貼るのが妥当かどうかは、
十分吟味してからの方がいいと思うが。

Java”しか”使えない無能な人はお引取りください
真面目な話JavaかOOスレ、関数型言語のスレに行ったほうが有用な議論が出来ると思われ

>>773
かも知れない。
というのも、おれはjavaの前は1年くらいずっとRubyのみを使っていた。
今ほど大きなソフトウェアや難しいものは書いていなかったが、それでも自分なりにコードは書いていた。
その時は、型がないことが不安だとは思っていなかった。
しかし、これはおれのウェブサイトに書いたが、おれは型あり言語で設計の修行をするためにJavaの世界に乗り込んだのだが、
型ありのソフトウェア手法を学んでいけばいくほど、型なしが怖くなってきた。
型が当然の世界で、型によってすべてが記述される世界に生きると、インターフェイスがないも同然の世界なんて怖くてしょうがないのだ。

>>774
数値計算でも、JavaはFortran並の速度を出すという結果が出ていたと思います。
Javaの問題はメモリだけです。

自分で強力なScalaのIDE作れよ
どこが天才なのやら

JavaはFortran並みとかLispはCより速いとか、C#はC++より速いとか
OCamlやCleanはC並に速いとか、、、
確かにそういう類の言葉は頻繁に聞くけども、
本当にそうだった試しがない
有利な状況だったり、限定的な状況だったり、なんらかの条件付だったりして、
トータルでは結局遅いんだよね〜
結局宣伝文句に使われてるだけ
同じような宣伝文句に、Scalaのソースコードは控えめに見てもJavaの1/2になるとか
そういうのがあるw

前からずっとちんこ氏に聞きたかったのですが、
反論するレスと無視するレスとでは何が違うのでしょうか。

丁寧に質問している方に対してはちゃんと論理的に反論し、
失礼な質問をしてくる人に対しては無視してるのでしょうか。

Haskell厨の自慢するクイックソートがPythonやRubyであっさり書けるらしい
と知って俺の中でPythonやRubyに対する評価は上がったな
def qsort(list):
if list == []: return []
else:
p = list.pop(0)
return qsort([x for x in list if x < p]) + \
[p] + \
qsort([x for x in list if x >= p])

ここまで読んでみて、うちの情報科は潰した方がいいなと思った

>>783
どうして？

Haskellみたいにクイックソートがかけても、結局Haskellの
クイックソートが一番美しい件
特にScalaの例はまだ汚い

>>782
みんななぜか短く書けるところだけ見て他の言語でもできるとか言うが、
Haskell のクイックソート（に限らんが）は、短く書けるところより、
遅延評価と絡めたところを注目した方がいいと思うんだけどな。
、

>>784
たぶんだけれど、ちんこの学生時代にすら満たないのが9割
卒業したら地元に戻って公務員専門学校にでも行こう

>>786
遅延評価だとどうなるの？

そう。Haskellの真髄は遅延評価＋短くかけるということ
Haskellに対抗したいなら、「無限に続く」フィボナッチ数列をもってこい。

fib　= 1:1:zipWith (+) fibonacci (tail fib)

で、Haskellのクイックソートは他の同様に短く書いたクイックソートと何が違うんですか？

例えば10000個のものからベスト100を取り出すのに、
遅延評価だと少なくとも後ろ5000個はソート処理されない。

これに比べたら、記述の短さなんかそれほど自慢にならん。

東大京大以外のやつはカス
プログラムやる資格なし
特に宮廷などと言って東大の仲間面してる大学のやつらはカス

>>791
おっと、すまん。

これは単純なクイックソートではないな

>>791,793
少なくともというのは間違ってた、平均だ。

take 100 (qsort list)
みたいなコードを書いたときに後ろ5000個がソートされないのか？
マジで？

>>795
ごめん、平均の話だ。
「上手くばらけた」ソースなら、
平均で 5000 + 2500 + 1250 + ... 個はソート処理されないと言える。

偏ってると、ほとんど全ソートするのと変わらなかったりする場合もある。

逆にマージソートだと大半をソートしてしまったりする。
遅延評価だと全ソートして結果を取り出すのと
部分ソートだけで取り出すのと区別しないで済むんだよね。

色々な要素が絡んでくるから、Haskell が最も美しいとは言わんが、
デフォルトが正格評価の他の言語と比べた場合の Haskell の美しさは、
この遅延評価のおかげで「区別しないで済む」ところにあると思う。
この区別しないで済むというのがソート以外にも様々なところで役立つ。

コードが短くなるのは、区別しないで済む事によって
場合分けが不要になる結果だと思う。
だから、ある程度まとまった処理の関数らを繋げるところで、
他の言語に比べてコードが短くなる（可能性が大きい）。

クイックソート自体のコードは最適化を考慮すれば、
良く例示されるコードほど短くはないし、もう少し複雑だ。

>>765
言語オタク的にはSmalltalk IDEはどこが駄目でしたか？

Haskellのソースコードが短くなるのは、徹底した型推論とインデントや略記を
利用した構文にあると思うよ
短くなる原因は遅延評価じゃない

>>800
クイックソートの例からの流れで遅延評価の話だけになったが、
徹底した型推論も大きなポイントですね。
では言い方を変えます。

プログラムの「構造がシンプル」になるのは遅延評価「も」その一因だと思う。

日曜日にちょろっとするぐらいの完全な趣味プログラマーだけど、Haskell勉強してみようかな。
日本語の本も出たみたいだし。

しかし、コンピューターですら1と0から様々な情報を扱うと言うのに
ちんこときたら...敵と味方でしか人を認識できないって...

入門レベルの書籍を購入って、銭を溝に捨てるようなもんだと思うんだ

俺が考えた最も美しいプログラム

x = y - 1
y = 2*x - 1
main = print x

http://codepad.org/CUcRMMwy

>>802
>日本語の本も出たみたいだし。

せっかくだから、11日に出る「プログラミングHaskell」で学んでみては？
良い入門書だと評判です。
http://www.amazon.co.jp/dp/4274067815/

原書の方では練習問題の（模範）解答も公式サイトで公開されているようですし。
http://www.cs.nott.ac.uk/~gmh/book.html

>>806
初心者にはそっちのほうがいいのか。
�d

初心者っていうか、rwhはpracticalなアプリケーションをHaskellで書くことにフォーカスしているからだろ

　______
　| 　|.| ∧∧
=====(,,ﾟДﾟ)∩=
　|＿|.⊂　　ノ
　　　　/ 　０
　　　　し´

＼ えっ…と、糞ｽﾚはここかな…、と ／
　 ￣￣￣￣￣Ｖ￣￣￣￣￣￣￣￣￣
　　　　　∧∧　∧∧　_＿._
　　　　∩ﾟДﾟ,≡,ﾟДﾟ) 　 |.|
　　　　 ｀ヽ　 　 |）＝＝＝=
　　　　　　 | _　|〜　.|＿_|.|
　　　　　 　U U

　　　　　∧∧　　ミ 　＿　ドスッ
　　　　 (　 　,,)┌─┴┴─┐
　　　　/　　　つ　糸冬 了　.|
　　〜′　/´　└─┬┬─┘
　　　∪ ∪　　　　　││　_ε３
　　　　　　　　　　　 ゛゛'゛'゛

>>805
main ってなんのことですか？

>>810
C言語のmainと同じ。
Cのmainもわからないのなら死ね

x, y が遅延評価の爆弾みたいなもので
爆発するかどうかまで推論できないと、コンパイル時にエラーにできないんだな

>>811
はぁー。それらしい気はしていましたが、
なんで main と print x ば = なのですか?

http://pc12.2ch.net/test/read.cgi/tech/1105689128/

>>813
君って、よく例え話が理解できない人でしょ？
物事の奥底にある共通事項を見抜こうとしない人だね

名前だけよく目にするせいで、python、haskellやschemeが特に珍しいものと思えなくなってきた。
どこかの言語オタクが、pike、clipse、rexx,spl、S-Langとか、Synapticの片隅にのっとる言語を
片っ端からやさしく説明してくんねーかしら
こうやって見ると、rubyがとんでもなくメジャーに見えてくるから不思議

>>814
いるよね
目の前にあるものしか見えないひと

>>815
昔、C MAGAZINE で似たようなコーナーあったよね。

>>815
その辺はマイナーだから話題にならないのではなくて、
美しくないから話題にならないのだろう

マイナーながらも何からしらの機能美があると信じたい。でないと、中の人が不憫

ここにいる人はコードレビュー出来る？

皆さん、ヤバいですよ
ノイマンの開発したプログラム記憶方式のＣＰＵから
プログラミング作業を必要としない次世代ＣＰＵができたら
一発日雇い派遣で倉庫作業ですよ・・・。

>>814
最も美しい言語スレで醜い部分の指摘を受けるのは当然だろ。

>>822
同意。

醜いといえば、無限リストをreverseしたら醜いだろうなあ
でもHaskellは有限と無限をあえて「区別しない」ことを選んだ
有限のリストに許されるreverseを、無限リストにも許してしまうんだ

>>824
区別しないんじゃないんだよ、区別できないんだ。
あるリストが無限リストなのか有限リストなのか、
Haskell ではそれを構文解析時に調べる術がない。

だから許してしまうというのはちょっと違う。
いや、結果的に許しているように見えてしまうかもしれないが、
意図的に許しているわけではないんだ。

>>825
いや、違うな・・・

Haskell では式を評価している時にそれを調べる術がない、の方が正しいな。

関数型とか、無限リストだとか、触ったことも無いからなんともいえないが...
有限ってのは、無限の一側面でしかないから、どうとかこうとか言うことじゃないの?
高校時代、眠くなりそうな授業をする数学の先生が、そんなことを言ってたような言わないような...

Java屋だが、イミュータブル至上主義で内部で泥臭い事をするのが好きだ。
CPUパワーの恩恵もあるが、もうセッターなんてDTOでしか使ってない。

>>828
で？

イミュータブルは言語の美しさの基準のひとつだ。機能美的に。

アセンブリ言語でできること以外はすべて汚いだろ。

と書いてみる。

上司や教授の言うことは間違いだ！ってことですね。わかります

>>813
なぜ「＝」なのかと言えば、同値関係を定義したいからです。

Haskell では「＝」は代入ではなく同値を表します。
つまり main と print x は同値です（参照透過性が保たれていると言う）。
なので、同じ文脈の中で main 変数を評価する部分を print x と書き換えても、
逆に print x と書かれた部分を main と書き換えても、
その文脈は全く同じ処理をします。

ちなみに、print x は x の値を表示する関数ではなく、
x の値を表示するという処理を返す関数です。

質問の意図を履き違えていたらすいません。

>>822-823
醜い部分の指摘のつもりだったの？
むしろ美しい部分だと思うけど

ロドラスカル言語

>>773

「型のない言語」というのは実際にはないのだし。

go hiromi

>>836
たとえばTCLは、すべての値が文字列ですが、こういったものは「型のない言語」になると思いますか？

マシン語（アセンブリ言語）の場合、すべての変数には数値が入りますが、16bit、32bit、64bitなど、異なるビット数を単位として扱えます。
マシン語はすべて数値なので「型のない言語」でしょうか？
それともビット数の単位を異なる型とみなし、「型がある言語」と考えるべきでしょうか？

>>838
彼はおそらく、変数に型のない言語はない、と言いたかったのではないかと
勝手に推測する。

変数というのはデータに名前を結びつけるものだ。
マシン語やアセンブリ言語におけるメモリ番地やレジスタ名は、
データではなくデータを入れる入れ物の方の名前だ。
マシン語やアセンブリ言語では変数と呼べる仕組みがそもそも無い。
したがって、変数に型のない言語という文脈では語れない。

TCL は使ったことがないから知らない。

>>838

コンピュータ側からみれば、コンピュータ上の全ての情報は二進数の数値だ。人間がどの言語を使ってもこれは変わらない。

型について語ることに意義があるのは、もちろん、その型が人間にとっての型である場合に限られる。

>>839
変数というのはデータに名前を結びつけるだけのものではないでしょう。
変数には型がある場合があります。
たとえば、Cで
int a;
と書けば、int型の変数aを宣言したことになります。
このような場合、一般的には、変数に型があるといいます。

>>841
変数に型があることと、変数というのはデータに名前を結びつけることとは、
相反することでも排他的なことでもなく、両立できると思いますが。

要するに int型の変数とint型の（とも解釈できる）データを結びつけているのでしょう？
その後に a = 8 とやれば、別のint型の（とも解釈できる）データと結び直している。

私が言ったことと何も変わらないと思うが、何かおかしいでしょうか？

>>842
別に相反することでも排他的なことであるとも言ってないよ
ただ、あなたが、変数には型がないと主張しているように見えただけ
そうではなかったのならすいません

>>841
あぁ、相反するとは言ってないよね、すまん。
>>842 の上２行はこちらの勘違いだ、無視してくれ。

私は、a = 1 の意味はaという名前と1というデータを結びつけることで、
型というのは結びつけるもの同士に制約を課すもの、と認識している。
何でも結びつけられると、人間が解釈し難い場合もあるからね。

>>843
ごめん、レスする前のリロード確認を忘れてた。

>>844
たとえばその解釈であっても、「変数」というものに「型がある」という
定義となんら相反しないよね
ただそれが言いたかっただけです

Cは変数に型があり、Pythonは変数に型がないよ。
その言い方で通じるし、それが一般的だと思う

>>846
うん、分かってる、というか気づいた。

>>839
TCLについてざっと調べてみたところ、
プログラマから見た場合 TCL の変数には型がないと言えると思う。
パーサーが読み取る時、出力する時に自動的に型変換が行われるらしいが、
プログラマにはそれが見えない。

ただし、プログラマが型変換を使うことはないけど、
パーサーが行う自動の型変換を意識して、
可能な限り（内部処理における）余計な型変換が起きないように
スクリプトを書くことはできるみたいだ。

でも、そうであつても、型がないとは言えると思う。

結論すると、文脈に応じて使い分けてね

まったく異なる視点かもしれないが、プログラミング言語の縦をそろえて見やすくするってことに私はかなり気になっていた。
まわりでだれもそんなこと考えるやつはいないが、わたくしは気になる。
↓下記の文章を読むと、日本人だけの特質なのかもしれないと思えたりする。日本人がプログラミング言語を設計していたら
　縦をそろえて見やすくできるような表計算的な表現方法になったのではないかと。
　そういえば漢詩や５７５７７っていうのも　ある意味テキスト上の表記のたてよこをあわせる東洋的な美しさを表したものではないか？
　以上は、たぶんだれも発想していないユニークな視点だと思うので有益じゃないかもしれないがここに示した。　

http://journal.mycom.co.jp/articles/2009/11/04/form2/index.html
米国では、レポートが主な文書形式であり、そこに罫線を引くケースはあまり見られない。
特に「上下方向の罫線は滅多に使用しない」(八巻氏)という。
それに対し、日本人はあちらこちらに罫線を引いて境界を作るのを好む。
その結果、表計算ソフトのExcelをイレギュラーなかたちで応用するまでになったようだ。

>>850
なかなかおもしろい
まあ言語というより、いまだにexcel方眼紙作ってるキチガイF通向けにexcel代替アプリ作ってくれ・・・

仕様書作成ツールにして
コード自動生成まで持っていければ
Excelから離脱出来るし
無理に離脱しなくても
Excelからコードを吐ければ
F通方式でも問題ないと思われ

>>851
そういう人は代替アプリは使わなそうだ。
彼らの大半にとってはExcelで「済ませられる」ことに意味がある。

>>852
なんか2000年代初頭って感じだな
糞みたいなソース吐きだして二重管理になって・・・
なんもいいことないぞそんなの

excelでソース生成するツール作りましたって結構どこでもあるよな
なんかなるべく使わないでくれって雰囲気で持ってくることが多いようなｗ

>>851
下請けって大変だな

Excelでソース生成は、スキーマ定義ならやるかな。

そのときの状況に合わせて自分で生成ツールを作れば問題ない

実際Excel方眼って、どういう利点があるんだろ？

縦の区切りが自由になるってことじゃないかと
だからドキュメントエディタとしてExcelを使う場合に便利なのでは
もし、方眼じゃなければ列幅が固定になる
それでドキュメントをレイアウトするのは困難だ

「レイアウト」なんだよな
なんか設計資料を定型の帳票みたいに考えてるおかしな癖がある
そこがアホ

レイアウトかあ…だったら方眼にせずに
全部オブジェクト（…正確な表現が判らんけど）にしちゃえば良いんでないの？

奇麗に整列させたいんじゃないの。
座標で管理するといつの間にかズレてたりするけど、
行と列で管理すれば絶対にズレないから。
代わりにグリッド線を使えば良さそうなもんだけど、
空間認識上の何かがあるのかもしれない。

糞スレ

言語オタクが選ぶ最も美しい言語アンケートNo1は、簡潔に
かけてインデントですっきりしていてソースコードの見た目が美しく、
関数型スタイルもあっさり書けるPythonだろう

おれはロジックの複雑度や規模の増加に対して実装量の増加が少ないってことも
美しい言語の指標になると思う。見た目の美しさというよりも機能美の話になると思うが。

たとえば、JavaとC++を比較した場合、規模が小さい場合はどちらも対して変わらないが
規模が大きくなるほど、C++のほうがコード量の増加を減らすための工夫をする余地が多い。
そういう観点から見るとJavaよりもC++のほうが美しいと感じる。

なので、おれはSchemeを一押しにしておく。

個人的には、宣言的なプログラミングが可能な
関数型ナデシコがほしい。

>>865
結局、バカが書いたコードはどんなに取り繕うがクソだよ。

そりゃそうだ

>>835
このスレに書き込んでいるのはどう見ても言語オタクだけど、
一向にPythonが一番という結論にはならないけどね。

>>869
というか、このスレで、他所ではこうに違いないなんてニュアンスで書き込むことが自体がナンセンス

だが Python は美しい

>>870
独断と偏見のスレか

それでもpythonは美しい

>>865
インデントを強制され、
論理型スタイルをうまく書けず・・・

PASCALはきれいだとおもう。

教育向けとして作られたから、確かに一定の美しさがあるが、
教育向けであるための限界や、時代による限界があって、
今となっては、ちょっとどうかなと思う

■たくさんこのスレを荒らして下さい！■お願いします■迷惑が分からないやつは迷惑を教えればよし■カキコミ放題！■荒らせ！荒らせ！■祭りだ-----！■■■
■■■■■■■■　プライバシーは犯罪！　福島県いわき市・秋山隆浩さん(25)を救え！　　　■■■■■

ヤフオクで車両仕様や走行距離等を偽装した不正出品を指摘した善意の第三者に対して
罵詈雑言を浴びせた上に、暴力団の存在をちらつかせて脅迫するという事件が発生しました。
この事件の首謀者はいまだに検挙されていませんが、福島県いわき市四倉町梅ケ丘在住の秋山通商
秋山隆浩さんが根拠もなく犯人と決め付けられ、卒業文集やアルバムをネット上に晒される被害に遭われています。
秋山隆浩さんの潔白を証明し、いち早く騒ぎの沈静化を図るためにも真犯人の発見にご協力ください。

【プライバシーは犯罪】福島いわき市のDQN秋山通商★71【ボンクラ】　　http://gimpo.2ch.net/test/read.cgi/news2/1252767131/l50
【ボンクラ】三年間の思い出のガイドライン　　http://society6.2ch.net
※※荒らし大歓迎です※※
いつもカキコされてイライラ… コイツは何がしたいのか？
荒らすしかないい！

Pythonは現代のCOBOL。
シンプルでコーディングスタイルのばらつきを抑えられる言語仕様のためビジネスで使われていくが、
やがて負の遺産となるだろう。

漏れはRubyにそれを感じる

どれも時代の流れだろ
未来は関数型。後々に残るのはCとアセンブラだけ

>>880
> 未来は関数型
には、同意。
だが、手続き型の言語に関数型をうまく取り込んだものが普及すると思う。

>>881
つ [Scala]

関数型は絶対に必要になる。
将来的に残るのはScala, Java, C, Go, Python, Javascriptだよ。
未来からやってきたおれがいうんだから間違いない。

くだらねぇｗ Goとかｗ

時代ははfunction-level programming

俺の周りだけ。


>>883
だが、go-routineのネーミングセンスにはちょっと吹いた。

>>882
将来的っていつの話？

純粋関数型の Haskell は残ると思うな。

手続き型は32コアくらいまではいけると思う。
1000コアなんて代物を普通のPGが扱うのは20年先だろ。

>>886
いや、無理と思う。

「いける」というのがどれほどを意味してるのか分からないけど、
手続き型は並列処理をすべきではない。

>>885
言語の淘汰は20年後。
関数型じゃないと全くダメだと言い出すのが5年後。
Java開発者がScalaに本気で移りだすのが3年後。
ムーアの法則は止まったけど、また別の方向で進んできた。
ややこしやー。

言語は残るけど淘汰はされる。
ユーザが増えないなら、話にならない。

>>887
> 言語は残るけど淘汰はされる。
> ユーザが増えないなら、話にならない

ユーザーが増えない根拠は？

宣伝活動を活発に続けていれば、
純粋関数型を学ぶ価値に気づくものは増える。
あとは GUI ライブラリがWYSIWYGツールと共に生まれれば、
ユーザーは確実に増えると私は思ってる。

今は GUI ライブラリが単品で研究されている段階だから、
WYSIWYGツールとセットで出るのはまだ先だとは思うが。

tclやprologが根拠がダメかしら

>>888
およそ20年前、熱心な研究者や開発者は、よいソフトウェアを作るために、C言語でOOをすることにしました。
それは内部構造を隠蔽出来るという点でべたべたなCコードより格段に優れたものになりました。
例え、それが完全なOOでもなければデザインパターンなどを駆使したテクニカルなものではなくても。

現在、熱心な開発者（おれも含む）は、OO言語に関数型言語を取り入れることを目指しています。
そして、それを言語仕様レベルで取り入れたものがScalaです。
Apache-Collections, Google-Collectionsはラッパーを使うことでこれを実現していますが、明らかに無駄があり、限界があります。

さて、ソフトウェアは工学です。そして、工学には要求があります。
要求のない言語はいくら優れていても普及しません。
C++はCにデフォルトでOOを組み込むことに成功した、今でいえば、Scalaのような言語でした。
ポインタがダメでしたのと言語仕様がクソだったのでJavaが開発されて今ではリーディングになりました。

今、Javaはマルチコアへの対応がダメというのと、言語仕様が複雑すぎる、型が鬱陶しすぎるなどの問題があります。
それに直に対応したのがScalaです。
Pythonは、シンプルな仕様、可読性の高いコードという点から問題にアタックしました。
JavaScriptはウェブ時代における基幹技術になっています。
Goは、Googleが気合で普及させてくるでしょう。おそらくGoのAPIしか提供しないサービスなどを作ってきます。
C言語は組み込みで生き残ります。

Haskellには理由がありません。
それがHaskellが淘汰される理由ですが、理解されましたか？

どこのドカタが書いてるのやらｗ
作文は三行にまとめろよ

５つのパラグラフに分かれています。
問題があって、それに対処するために開発者は工夫をし、
その要求を満たすために言語が開発され、開発者はそこに流れる
という繰り返しが20年前と同様にまた起こるということを言っています。
形は違いますが、時代というのは同じようなことが繰り返されるものなのです。

ところで民主党のせいで、研究費が軒並み潰されて、ポートランド潰されたらやばいんだけど、どうにかなりませんか？

>>891
土方でなくて学者の卵様だろ。プログラムが書けない方のコンピュータ科学者と同じ臭いがする

>>893
残念ながらおれはプログラムが書けます。
もう少ししたら、可視化用のライブラリもうp出来ます。

>>890
もし現在の Haskell に「要求がない」原因が、
Haskell がいったいどのようなもので、何がどのようにできるのかが
分かっていない事にあるとしたら、
その原因を払拭することで要求が増える可能性はあるのではないか？

そのような形で遅れて普及した技術や製品は無いのか？

>>895
言い忘れました。

ちんこ氏が言うHaskellが淘汰される理由は理解しました。
もっともなことであり、一理あります。

ですが、他の可能性もあるのではないか、と言いたかった。

>>895
頑張ってください。

あなたはこの世にどれだけの人間がいて、
自分以外の人間は全員、自分ではないということを理解すべきです。

今、仮にあなたがHaskellについて知り尽くしていて、
かつ、他の言語の問題やHaskellとの差異について知り尽くしているといます。
おれがあなたに100時間の時間を与えて、おれをHaskellに口説き落とすようにさせたとしても、おれは絶対に落ちません。
一人の人間すら口説き落とせないのに、何千人というユーザをどうやって獲得する気ですか？

また、言語の学習コストは非常に高く、人々という群はそれほどドラスティックには動きません。
せいぜい、明らかな問題があり、明らかに優れている言語がある場合にのみ、ゆらゆらと動く程度です。
Haskellは50年後に評価される言語かも知れませんが、今必要な言語ではありません。

極一部で普及しているだろうソフトウェアには、xmonad、Yi、pugs
Haskellの要求はラピッドプロトタイプか？
そのあたりは、Ocamlでも、Scalaでもいいか。
Scalaだと、JVMの上でしか動かないし、バイナリを吐かんし。
そもそも、Javaって一企業の製品だし

>>873
美は乱調にあり、なんだよねぇ。

関数型に移行していくのだろうけど、現時点でいうとあまりフェアな感じが
しなくて気に食わない。関数表記を自然で理解しやすいと感じるまでには
初等教育から4桁の時限の教育を受けてきている。それに引き換え、たとえば、
BASICはほとんどゼロ。しかし、幼稚園の学芸会の「プログラム」をほとんどの
園児が理解することを考えると、教育コストゼロでもそこそこ書ける可能性が
ある。BASICをCOBOLを子供のころから1000時限も教育されたらどんなことが
起こるのか。それはそれで、美しい世界があるに違いない。

JavaScriptとGoは「オブジェクト指向」の定義を別の定義に移行させるだろう。
同様に「関数型」の定義も時代とともに変わるだろう。

「参照透明」の意味がコロコロ変わったりしたら笑える

ちんこ氏ってHaskellやったら「Haskell以外は糞」って言いそうだよなw

>>897
おう、がんばるぞ。
私独りではとうてい不可能だけど、同じ想いの者は世界にもいる。

> 一人の人間すら口説き落とせないのに、何千人というユーザをどうやって獲得する気ですか？
あなたは、自分は神で自分以外はバカだと言ってたのに、
今度はみんなが自分と同じ思考だと思い込んでる。

あなたの言う20年の間には Haskell を普及させてみせるよ。

ちんこって人工無能か何かだろ

ちんこちゃんは極論から入るけど、手動かした後はオーソドックスなとこに着地する

意固地な特定の一人を説得するよりも
不特定多数から一万人を説得する方が簡単なのは明らか。

>>905
一瞬、人工無職に見えた。

> 一人の人間すら口説き落とせないのに、何千人というユーザをどうやって獲得する気ですか？

早まった一般化

ちんこは図星を指されると絶対に反応してこない、無視する。

> Goは、Googleが気合で普及させてくるでしょう。おそらくGoのAPIしか提供しないサービスなどを作ってきます。
Googleのブラウザも大して成功しなかった

chromeは中途半端なβ版ですらないものをリリースしてしまった
っていうかgoogleのプロジェクトってそんなんばっかりだし

機能が足りないのを
シンプルで高速ｗとか宣伝するからなｗ
株価吊り上げるのだけはうまい

Google Chromeを気に入って常用している俺が通りますよ。
Pascalラブな俺にとって、GoはCに以下のPascal風味を入れた感じで好感持てます。
・セミコロンは文と文の「間」につく
・変数宣言はvarで始まる
・変数や関数の型は後につく
・関数はfuncで始まる

日本のソフトウェア業界は、バグが絶対になくて完璧なものしかリリースしない。
だから遅れる。
ベータだろうがなんだろうが、リリースしてフィードバックを受けて修正する方がアジャイル的。
これからはアジャイルじゃない企業は全部淘汰される。
アジァイルのための言語 = Scala, Python

mixi β

アジャイル以外はカス。

な、決して反応しないだろ。
別の話を持ってきて、話題を変えようとする。

バグがない業務システムなんて見たことがない

>>919
当たり前です。
絶対にバグの出ないソフトウェアを作れるわけがありません。

日本企業は、バグがあることに対して必要以上に恐れる傾向があります。
それは、
日本という社会が減点方式であるということ、
日本人が必要以上に生真面目だということ、
リスク管理を学んでいないのでリスクを必要以上に恐れる傾向があること
などが影響しているものと考えられます。

ハードウェアの世界では、その判断は妥当かも知れません。
リリースしたあとにバグがありましたというのは、修正コストが高すぎますし、電気機器であれば火事になったりもします。
実際に、ノートパソコンの電源が火を吹きましたという事故が耐えません。
車のブレーキが突然効かなくなったら人が死ぬかも知れません。

しかし、ソフトウェアでは、医療や宇宙事業では致命的な場合もあると思いますが、
多くのソフトウェアではバグがそれほど致命的ではありません。
バグがあるのは当たり前、フィードバックをもらえるなら直すよ、
というアジャイルな態度が適切なのです。これは適当なのではありません。アジャイルなのです。
そして、ハードウェア的な慎重さを持つことは、形勢を損なう原因となります。
スピード、スピード、スピードなのです。
これは楽天における合言葉のようなものですが、楽天がいかにアジャイルな企業かということを物語っています。
楽天はアジャイルだから成功しているのです。

アジャイルを理解しない老害は排除されるべきなのです。

日本語で勉強しなおしたほうがいいぞｗｗｗｗｗｗｗｗｗ

ところでアジャイルってなんですか？

>日本のソフトウェア業界は、バグが絶対になくて完璧なものしかリリースしない。

>絶対にバグの出ないソフトウェアを作れるわけがありません。
??

俺はアジャイルの前にGTDを学ぶべき…

俺が会社の社長だったらちんこみたいな夢あふれるやつを雇うよ
でも、一介の社員の立場だと、うちの会社にはイラネ
来ると不幸になる

>>925
能力のある人間を受け入れることの出来ない職場ははきだめ以下です。

>>922
優れた開発者にしか使えない上級魔法です。

>>923
颯爽と矛盾を指摘ｗ　ちんこ沈黙ｗ

口先だけの詐欺師はいらんな
完成したコードなり論文なりのちゃんとした成果を見せてもらえなければ取らないよ

人のコードなんて読む気しない

女の心が読みたいんだけど、読めないんだ・・・どうしたらいい・・・・

お嬢ちゃん、随分元気いいねぇ〜。何かいいことでもあったのかい？

>>930
Don't think, feeeeeeeeel.

考えないで。感じちゃうじやない

女の子が書いたら女の子らしく、
なんかまるっこくなる言語ってないの？

なでしこ

うそ言うなよ、あれ誰が書いても同じじゃん

Adaとか。

名前の語源が女の子ってだけじゃん （ん？　・・・子じゃないか）

こういう女の子の文章の書き方を巧く取り入れたら、
素敵なプログラミング言語が出来上がるような気がちょっとする。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1026512185?fr=shopping_search

あるいは、こういう今考えていることをそのままの順でプログラムできたら、
本番前のプロトタイプを作る為の言語としては良さそうだ。

プロトタイプを作るための言語というところが気に入らない。

>>932
あざーーす