1 :
デフォルトの名無しさん :
2010/01/06(水) 01:08:14
このスレッドは天才チンパンジー「アイちゃん」が 言語訓練のために立てたものです。 アイと研究員とのやり取りに利用するスレッドなので、 関係者以外は書きこまないで下さい。 京都大学霊長類研究所
Brainfuck
>>1 乙
>>2 続いてるスレなんだから、一々アイちゃんコピペを書くな
>>3 お前がそう思っているならそれで良いが、俺はそうは思わない
アセンブリ
シンプルなLispが好きなんだが最近Forthなんかも面白そうに思える
前スレの続きCの美って話だけど、それらをサッカーにあてはめると Haskell ->オランダ 機能美 Lisp ->ブラジル 自由自在の美 C ->ドイツ 質実剛健美
GHC モジュール表現が今ひとつだが、並列(平行)処理をこれくらい 単純化できればたいしたもの。
pythonと言ってみるテスト
Haskellがドイツな気がする。
11 :
デフォルトの名無しさん :2010/01/06(水) 21:24:25
perlでないことは確か。
アイちゃん認定されてるのに(
>>2 )まだやるんすか?
14 :
デフォルトの名無しさん :2010/01/06(水) 22:38:33
Haskellに一票
15 :
デフォルトの名無しさん :2010/01/06(水) 22:39:22
C++最強
>>13 え?
だからアイちゃんがやってるんだろ?
>>12 あなごるに LMNtal 入っているんだけど、標準出力の問題ぐらいしか
わからない。誰かくわしい人、やってみて。
Perlが成功したのは、まだ単純なウェブプログラミングだけで有名になれる(?)時代だったからだろうね UNIXとテキスト処理という低レベルな処理に薄いゴミ集めレイヤーをかぶせただけだろ 今ではもっと抽象レベルの高い言語でないと使えない
ならPerlで抽象度の高いライブラリを作ればいいじゃない というかすでに沢山ありすぎて困ってる状態
>>19 ライブラリじゃなくて言語の問題だよ
汎用グルーとして言語自体に優れた表現力が必要だ
逆に最も汚いプログラミング言語は ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
C言語 いろんな部分が中途半端 C++はCで悪かった部分の大部分が改善されてるからだいぶ美しいけどな。
C++ 改悪とは何か身をもって教えてくれる言語。 C 改悪とは何だったかを学んだ者に与えられる美しい言語。
C++の罠についてはBest Software Writingに書かれているね ユーザはbetter Cとして使い始めたのに、やがては負の遺産に囲まれて途方に暮れるという
c++はガラクタ言語の典型じゃないの? 基本的な文法を拡張して、無理矢理 マルチパラダイムにしただけの話だからね。
Scalaも同じ道を辿るのか
>>18 Perlは元々単なるテキスト処理言語でWeb用の言語じゃない
たまたまWebとテキスト処理が相性よくて、既にそれなりの実績もあったから使われてただけだろ
最近じゃ、かつて隅に追いやられたawkの方が魅力的に見える。
C++はソースが縦長になる傾向があるのでやだ 処理がメソッド単位で、内部変数使うから引数が少ないからだな それにprivate変数ごとにGetSetとか馬鹿みたい JAVAはクラス宣言のせいでデフォルトでTabネストが一段関数にくっつくので見辛くなって邪魔くさい 宣言部と実装部は分けるべきだ
関数型言語が美しいな C言語だと mainの中が中心ですべての関数はmainの外部だけど main(){ //いっぱい hoge(); } hoge{ //処理内容 } こういう感じだとhogeいくたびにずっと下みなきゃいけないとかバカみたいだし。
>こういう感じだとhogeいくたびにずっと下みなきゃいけないとかバカみたいだし。 それは関数型言語でも同じだろうw
ctagsとか使ったら?
Cと関数型言語比べて、意味あるか?
>>30 集合と要素を比較することの無意味さを理解しる。たとえば、
・関数型言語と手続き型言語を比較すると....
・HaskellとCを比較すると....
に書き直してから再提出だ。
>>30 の知性のカケラも見れないカキコには、真面目にレスする価値がない。
最近、Cは必要十分な文法が揃っていて美しいと思えてきた
どのレベル(レイヤー)でプログラムを書きたいのかにもよる
>>35 俺も。
OOPLはJava -> C++ -> Rubyと渡ってきて、
OOPとはなんぞや、デザパタとは何ぞやの道を通ってきた。
べつにCでOOPが出来る!などと大層なことを言い出すつもりはない。
ただ、適切に構造体なりを使えば、
結局Cでもそんなにおもったよりは不自由はしないとおもうようになった。
Cは素晴らしい。構造化プログラミングの原点にして至高の完成品。 でも標準ライブラリがボロボロだ。 でもC++の std::cout << "Hello, world!\n"; みたいな標準もありえない。気持ち悪い。 標準ライブラリはやはり関数にして欲しい。
型があると、文字列処理が気持ち悪いな
41 :
デフォルトの名無しさん :2010/01/08(金) 19:25:52
C++はいいよ。 自分の作ったクラスに operator + とかoperator -とかを作れば C1 a,b,c; a + b - c とか出来るんだよ。 これは美しいと思う。
>>41 初めてコード見た人が混乱しない?
operator+の実装を確認するために継承ツリーを逆に辿るはめになりそう
>>42 混乱しない。
というかさせない。
混乱するようなら、
インターフェイス設計の失敗ってだけ。
oop?いらん。あれはスパゲティを作るためのもの。
と、まともにOOPを使いこなせない無能がほざいてます。
>>44 それ10年ぐらい前のOOPじゃね?
継承を多用して実装の共有部をくくり出すやり方には
問題があることが分かり、最近はできるだけ実装に依存しない
抽象を抽出しようとする方法論が主流
closやRのようなoopならよいけどね。
>>46 ジェネリックなところは別にしないとね。
演算子の動作を定義するというのは、わかりやすくなるかは微妙な感じだな。
>>48 うん。よけいなことをコテコテやってるだけにしかみえないよ。
おれがきめてやる。 アセンブラ、FORTRAN ←ごみ、理由なんてない、きたない LISP ← くず、静的な型検査がない、きたない C ← なまごみ、型検査がやわい、ごみポインタ、シンタクティックな高階関数がない、きたない perl,python ←普通に汚らしい、型検査がほとんどない、イラつく Java ← 粗大ごみ、コード量多すぎ、代数的データ構造がない、ペアすらない、イラつく Ruby,groovy ← かみくず、静的な型検査がない、動的言語ってなに?わらえるんですけどww、ダックタイプとかふつうに汚い SML ← 取り扱い不可能ごみ、つかえねー、ライブラリがごみなのに互換性がわるすぎ GHC、LMNtal ← 使えないの一言、人工的な感じで別にきれいじゃない、箱にはみたいなもの C++ ← もうごちゃごちゃ、きえていいよw prolog ← 過去の汚い遺物 CAML,OCAML ← 埃、結局使えない、かといって別にきれいじゃないw、中途半端
つづき Haskell ← ごみすぎなうえにつかえない、これがきれいとかいってるやつ、自分の美的感覚をうたがえよw Scala ← ごみのいいところをいくらあつめまくってもごみにしかならないことにいい加減きずきなさい 英語 ← ごみ、よめても、普通に通じないし通じさせれない、使えないのでごみ 他の外国語 ← 空気、もはや認識不能、パターンすら見えないのできれいじゃない 日本語 ← 別にきれいじゃない、というか、よく通じないことがある チューリングマシン ← ハエみたいなもの、ごちゃごちゃうるさいが、結局使えない上にきれいじゃない、そもそも構造がないw λ計算 ← つかえない、型がないのでイラつく、というか構造がなさすぎ、イラつく雨みたいなもの 型付きλ計算 ← 汚くはないが、つかえない、ポカリスエットみたいなもん π計算 ← λ以上に使えないし、より汚い コーヒー牛乳みたいなもの R ← 静的型検査がない、汚い、イラつく、というより、マジイラつく Maxima ← 静的型検査がない、数学ができる人ほどやりたいことができなくて幻滅する SQL ← もっとまともなシンタックスにできないの?消えていいよw、汚すぎ Mathmatica ← 高い、というか、高すぎ、ぼったくり SPSS ← 高いけどごみ、コンサル契約つけないと結局使えない。 正則表現 ← 使える場面でしか使えない、使えない場面が多すぎ、汚くはないけど別にきれいじゃない金魚なみ 文脈自由文法 ← 文脈がフリーすぎて意味が不明=きれいじゃない 文脈制限文法 ← よりフリーなのに制限とかまじいらつく PASCAL ← 別にそんなにきれいじゃないけど、まあまあ、思い出みたいなもの eclipse ← それなりにつかえる、ごちゃごちゃだけど、その割にはそんなに汚くはない、女子の部屋みたいなもん
COBOLがないから、コボラーとみたw
Brain Fucker "ブレインファカー" とみた。
>>50-51 GHCとHaskellが別なのは何故?
俺の好きなSmalltalkが入ってないけど美しいということでOK?
>CAML,OCAML ← 埃、結局使えない、かといって別にきれいじゃないw、中途半端 これは同意するわ。 OCamlの敗因はOの部分が蛇足以外の何者でもないこと。
>>55 >GHCとHaskellが別なのは何故?
ニヤニヤ(w
GHCも知らないのに言語を語る
>>55 って....
こう考えてみよう、以下のリスト
GHC
GHC
GHC
GHC
このうち並列論理型言語に対応しないものだけを消去せよ
できる奴だけが、
>>55 に石を投げろ
つ○
つ --==○
つ ----===== ○ガツン☆
>>55
λ計算が入ってる時点でそんな区別考慮されてないわなw
ghcは言語というよりも計算モデルな希ガス
>>64 このスレだったかな。前に、エジンバラ大ならGHCとは名付けなかった、という
ジョーク?があったが、そういうことではないのかな。
Guarded Horn ClausesでなくGHCとした時点で少し意地悪な気持ちを含んでいる。
67 :
デフォルトの名無しさん :2010/01/09(土) 08:31:49
ALGOLもねw
>>65 オチがエジンバラだとEHCだ、というやつね。そのこころは
「ICOTに対する尊敬を欠いたグラスゴーの破廉恥な奴等」
ただ、その誹謗への答えが
>>62 であり、
>>64 なのではないかな。
BASIC入ってないなw
シグナル駆動っぽく書ける C/C++用プリプロセッサってなんか無い?
72 :
デフォルトの名無しさん :2010/01/10(日) 07:08:18
DSPに任せたら?
>>68 残念ながら、
>>62 や
>>64 は答えになっていない。
GHCはれっきとしたプログラミング言語であり、単なる計算モデルではない。
今時の若者が知らないのは無理も無いと思うが、1980年代の日本で
第五世代コンピュータを開発するという野心的なプロジェクトが開始された。
その技術の中核に据えられたのがPrologに代表される論理型言語。
プロジェクトの第一段階として、逐次型Prologへのオブジェクト指向拡張が行われた。
そのコードネームがKL0(ケー・エル・ゼロ)であり、開発された論理型言語は、
一般的には ESP(Extended Self-Contained PROLOG) と呼ばれることになる。
続いて第二段階として並列型Prologの開発が行われ、そのコードネームが
KL1(ケー・エル・ワン)である。開発に当たっては、先行していたPARALOGや
Concurrent Prologを参考にして、新しい並列論理型言語が考案された。
それがGHC(Guarded Horn Clause)であり、開発の中心人物が現早大の上田氏。
GHCの初出は1985年。当然、関数型言語Haskellの誕生以前の時代であり、
その時点でグラスゴー大のHaskell処理系は影も形も存在していない。
大学講義じゃ、Prolog,ML,schemeのどれが扱われること多いんだろ
たぶん、Prologは論理型言語として、関数型言語とは別枠で教えられる。 関数型言語はLisp系、ML系、Haskellで食い合ってるんじゃないかなぁ。
デバイスドライバ書けない言語は不要
78 :
デフォルトの名無しさん :2010/01/10(日) 21:49:40
関数型言語はひとつ覚えておきたいな
>>76 デバイスドライバが書けない言語が不要、存在価値が無いとは思わない。
書ける言語としてはC/C++/アセンブリ言語などがあるけど、
それらでアプリケーションを含むあらゆるプログラムを作るのは、あまりにしんどい。
言語なんて道具なんだから、用途に応じて使い分ければいいと考える。
>>77 最新のHaskellコンパイラというのは、gccに匹敵する性能のコードを吐くまで
最適化技術が進化しているのかな?OCamlがgccの数倍程度までの性能を
叩き出せる事は知っているが、Haskellがそこまで進化してるとは初耳だ。
また、当然リアルタイムGCはサポートしているよね?カーネルモジュールだから、
処理途中でGCが始まってドライバの動作が止まるようでは困る。
アプリケーションやトイプログラムならいざしらず、これらの事柄を満足できずに
「カーネルモジュールが書ける」と主張しているとしたら、
その主張は誤解をまねく誇大な表現であると言わざるをえないが、どうなんだろ?
私は
>>77 ではないが、向こうの記事のレスでは、
今のところそのような心配をしてる人は見あたらないな。
ただ、まだメモリリークのバグがあるそうだが。
(比較的簡単につぶせるだろうとも言ってるが)
気になるのなら、向こうにレスを投げかけてみてはどうだろう。
最も美しいプログラミング言語・・・ それはm4
結局、x86の言うパフォーマンスチューンはついて回るのか。
>>80 あれをメモリリークと言うのはちょっと語弊がある。
直感的にはもう使用していないように思える領域が、
実はまだ必要なので解放されずに残っているという状態。
バックグラウンドで自動で文書を読んでくれだり絵を閲覧してくれたりできる言語って、ありますか 見た結果だけ知りたいです 動画も見てくれたらもっといいです
>>87 日本語を使って誰か雇うといいよ
文書を読んだり絵を閲覧したり動画も見てもらって、結果を教えてもらう
>>87 その前に、文章を清書してもらう言語とか、
雑多な考えをまとめてくれる言語とか、
そもそも言語とは何かを教えてくれる言語が必要な気がするが
>>73 オサーンの昔話乙
第五世代は完全な失敗プロジェクトとでしょwww
Eclipseは言語じゃないだろw ま、言語そのものの機能より、開発環境とかライブラリとかの成熟度のほうが重要だとは思うけどね
>>91 公表できない秘密の結果が出たかもしれないぞ
人間クローン開発成功とか
>>91 過ちは現代でも繰り返されるのだよ
情報大後悔プロジェクトというのが最近あってだな…
>>83 Haskellがやっているのはコンパイラの最適化ではなくベンチマークプログラムの最適化。
>>91 ICOTの評価についてはわからないが、
このスレ的には、Guarded Horn Clauses は全然過去のものではない。
GHCは過去のものですw
98 :
デフォルトの名無しさん :2010/01/12(火) 16:45:58
このスレでは、ある言語を過去の物として、考察の対象から外すことは、するべきじゃないし、していない
GHC(Guarded Horn Clauses)はそれを乗り越えたものがないのだから、 過去のものになりようがないよ。
100get
GHCはまったく使えなかったというその一点で世間様においては過去のもの
102 :
デフォルトの名無しさん :2010/01/13(水) 01:22:28
BLISSは? ねぇDECのBLISSは?
>>104 世間でないとこなんてないよw
自分は世間ズレしているという点にへんな優越感を持ってる馬鹿がまだいるのかよw
>>105 GHC,Guarded Horn Clauses,KL1,KLIC の四つを同一のものを指しているとすれば
このスレではすでに10票近く入っているよ。
Whitespaceが上位にくるのだから、世間からは相当ズレたスレだよw
世間ずれの「ずれ」は「擦れっ枯らし」の「擦れ」だ。
気持ち悪い人たちが寄り添いあって作っている気持ち悪いコミュニティのなかだけでぎろんしているのですねw
>>107 あれは外見がちょっとヘンテコなだけで
中身はごく正統的だったような
>>110 チューリングマシン自体が見た目ヘンテコだからな
もうeclipseでよくねw
トップシェア以外はゴミ扱いする池田信夫脳のバカは死ねよ
じゃ、結論はMS-DOSのバッチファイルということで。
それを言ったらトップシェアはx86のマシン語だろ
116 :
デフォルトの名無しさん :2010/01/13(水) 20:47:25
>>111 へんてこというのはunusualということだからね。
現実には存在しないのに具体的だから変だと思うんだよ
マイナー言語持ち出して悦に浸ってる馬鹿が最初に死ぬことでしょうw なんだかんだ言っても結局のところ何もできない病人みたいなもんだろw
118 :
デフォルトの名無しさん :2010/01/14(木) 08:16:39
トップシェア以外をごみ扱いしてるんじゃなくて、
ごみをごみとして扱ってるだけだということに築かない馬鹿
>>113 引きこもりだな。死んでいいよ、で、地獄に落ちろ世w
>>118 このスレ、○○こ君が登場するまでは、圧倒的に見た目派優勢で、
C++やJavaなんて話題にも上らなかったんだが。
デサントの「速いものは必ず美しい」というコピーはデサントという社名と 「滑降」がダブっているからおもしろい。シェアの高い言語と美しさの 関係を説明してくれない限り、シェア云々はこのスレ的には無意味だよ。
美しさの定義による 言語がプログラムの設計のためにあるのならJavaは美しいと言えるし シェアの高いものも同じだ。C++は全然美しくないけど マイナー言語よりは設計者の環境が整っているという事実はある
>>119 > このスレ、○○こ君が登場するまでは、圧倒的に見た目派優勢で、
それは単に参加者が入れ替わっただけなのでは。雑談スレだし。
自分の詳しくないものを否定するところが○○こ君とその取り巻きに見えるな 前のアセンブラが老害云々もこいつらだろ
>>122 そうだと思うけど。それで数千スレ浪費した。
取り巻きっていうかちんこ一人だけだろ
126 :
デフォルトの名無しさん :2010/01/14(木) 22:25:37
>>自分に詳しくないもの(ry ばかかこいつ
127 :
デフォルトの名無しさん :2010/01/14(木) 22:27:41
例えばHaskellとJavaと比べたら、完成度に違いがありすぎだろ。 Javaの方がすごい
128 :
デフォルトの名無しさん :2010/01/14(木) 22:29:10
MLとかHaskellとかでぎゃーぎゃーいってるやつのほうがよほど世間しらずなんだよwww いのなかのかわずっていうやつだね
>>127 完成度と美しさの関係を述べてください。
130 :
デフォルトの名無しさん :2010/01/14(木) 22:37:23
完成度が低くて美しい<<<<完成度が高くて美しい です
わかりやすいやつだなw 君はJavaだけやってればいいよw
実際Javaが一番いいだろ、その次Python。マイナー言語はオナニーみたいなのばっか
Javaは所詮は土方言語
>>132 いいからhaskellや他の関数型言語の勉強を再開しろよ
話はそれからだ
Javaでオナニーしている変人がいると聞いて
たしかにJavaは広く普及してるね IDEのおかげで馬鹿でもチョンでもコードを書けるし でもただそれだけ 美しい言語とはいえないな
>>121 俺もみんなに言語の美しさの定義を聞きたい。
美しい言語の十分条件って何なんだ?
>>138 シンプルで可愛げがあること。
標準ライブラリの設計のありかたも含む。
シンプルかつ可愛げの例はたとえば、
Rubyの配列でカンタンに和集合積集合を扱えることとか。
>>138 それが定義できないから
こんなスレがPart5なんだよ
美しさの基準が計測しにくいから難しい。 ところで数値化できる美しさの基準に「黄金比」がある。 これを使ってプログラミング言語の美しさを計測するのはどうだろう? つまり、その言語で典型的なプログラムを書いて、 それぞらの行に占める予約語とそれ以外の語がどれだけ黄金比に近いかとか ソースコードに占めるimportやincludeの行の比率とかを調べる。
前にも出てたけどソースの中の識別子の数やネスティングレベルとかで何らかの指標を作ってみたいな
お前らがpart5作る以前、何十年も前からソフトウェアメトリックスと いう研究が行われているけど、成果は何も出ていない。
>>143 成果の大きさをどうやって計測したんだ?
>>138 必要最小限の抽象化
最大限の可能性
まあ、Cのことだけどね
間違いなくC、それで物足りなかったらJava、それでもダメならPytonになるわけだが
>>144 それはソフトウェアメトリックスメトリックスで計測するに決まっているだろ。
メタ-ソフトウェアメトリックスメトリックス
C言語 メモリを直接操れる言語 そのためうまくプログラム組めばほかの言語(JavaとかC#とかVBとか)より メモリ消費量が少なくして同じことができる。 メモリの容量が少ない組み込み系で活躍。 オブジェクト指向を取り入れたC++は インスタンスの作成でどうしてもメモリの無駄遣いが生じてしまう。 C言語にくらべメモリの管理がはるかに難しい。 ガーベージコレクションをとりいれたJavaやC#はメモリの無駄遣いは比較的生じにくくなったが ガーベージコレクションの動作自体にかなりの負荷がかかっちゃう点がマイナス。
ソースコードの形象の美しさが第一。
それからアルファベットに対して記号が少ないこと。
>>141 の観点は面白いが、やはり予約語は少なければ少ないほどいい。
上記からはPrologが思い浮かぶが、
"いろんな言語で宿題スレ"の故意に冗長に書いたコードなどを読むと、
重っ苦しくてとても美しいとは言えず、Prologだから常に美しいもの
でもないことがわかる。やはり言語ではなく書き方ではかなとも思う。
そんな数学の証明問題みたいな方法による美しさじゃなくてさ… それって言語に依らないアルゴリズムとかコーディングの問題でしょ
152 :
デフォルトの名無しさん :2010/01/16(土) 00:32:00
だからさ− Java賀一番きれいなプログラミング言語 ⇒ シェアーのみで判断してる っていう思考回路がそもそもおかしいと思わないの? Java ⇒ どかた っていう思考回路もそう けっきょくML,とか,Haskellとかしか知らないんじゃないの? けっきょくのところまともなプログラムを書いたこともないんじゃないの? Haskellとかが美しいとかいってるやつはそもそも物を知らなさ杉。 というか馬鹿がHaskellにたまたまであって目覚めちゃったwwってかんじじゃねーの? けっきょくばか
Javaしか出来ない人が言っても説得力ありませんよ まずCでLisp作ってからにしようね
154 :
デフォルトの名無しさん :2010/01/16(土) 00:38:17
おいおいJava言語も知らない人がいってもせっとくりょくないですよw さらに、CでLisp作るくらいのことでぎゃーぎゃーいってる人がいってもせっとくりょくないですよw
CでLisp作ったような奴がらことごとく汚い言語を量産してんだろ おまけに人に強要するしな。まるで説得力ねえよ
156 :
デフォルトの名無しさん :2010/01/16(土) 00:39:54
そもそもどかた根性まるだしだからHaskellごときですげーとかいえちゃうんだということに まだきずかないんですかねーーーwwww
157 :
デフォルトの名無しさん :2010/01/16(土) 00:41:13
汚い言語=Scala,Haskell,....ww
Javaみたいに一般に普及してる物を否定したい=中二病
Scalaはごちゃごちゃしてる。GroovyとかClojureのほうが美しい
こんな人までMLやHaskellの名前を知ってる時代になったんだな 普及したもんだ Scalaも一応言語だという事は知ってるみたいだし ところでOCamlは知ってますか?
>>160 ほら来た。お前みたいな奴だよ、諸悪の根源はさ
それらが美しいとでも思ってんの?
162 :
デフォルトの名無しさん :2010/01/16(土) 01:01:56
ML以上にきたないくそげんごだろw
名無しになった途端に草はやしまくるんだな 君は無理しないでJavaでアプリだけ作ってればいいよ でも決して基幹ライブラリとかやるなよ はっきりいって迷惑だ
164 :
デフォルトの名無しさん :2010/01/16(土) 01:03:43
SMLのまちがい
165 :
デフォルトの名無しさん :2010/01/16(土) 01:04:46
無理しないでHaskellあぷりでもつくってろよのまちがいでしょwwwwww ま、Haskellでまともにかけるのはくそアプリぐらいだけどねw
すごい、SMLまで知ってる
167 :
デフォルトの名無しさん :2010/01/16(土) 01:06:26
どうかんがえても Java>>>>>>>>>>>>>>>>>>>>>>ML>>>>CAML
>>163 ねえ俺はJavaが絶対なんて言ってないんだけど、
どうしようもない言語を美しいと言えばカッコイイとでも思ってんの?
それならCの方が遥かにマシだと言えるね
マイナー言語を寄せ集めて、それでどうこうなる問題じゃない
単なるJava厨かと思いきや ものすごく意外に言語の名前は知っているね 見直したわ では、Javaが>>>>な理由はなに?
本当に頭の中はお前が言うところの老害と同じなんだな まだ25なのに
で、CでLispを作った結果、どの言語がどう美しいのか言ってみろよw
172 :
デフォルトの名無しさん :2010/01/16(土) 01:18:45
ML,camlにあってJavaにないものと、 JavaにあってMLにないものと ひかくすれば Java>>>>>>>>>ml haskell,haskellとかいってるのは、小学生が小学校の先生にあこがれるようなものwwwwww
ところで漢字変換がおかしいようだがUbuntuが壊れたか?
>>172 SMLやOCamlにあってJavaにないものというと、
型推論、クロージャー、バリアント、ファンクター...
他にもあると思うけど
JavaにあってSMLやOCamlにないものというと、
null...
あれ?他に思い付かないや
でも、これではJava>>>の理由にならなそうだ
それとも決定的な何かを忘れてる?
型推論、クロージャー、バリアント、ファンクター...が美しい条件なの?
>>174 みたいな奴が糞言語を量産しているんだろうな
そもそも美しさが重要なのかという疑問はありますね。 このスレの参加者は美しさが重要であるというテーゼに合意していることが前提なのかもしれませんが、 私には信じられません。
いくらでも多機能に、そしていくらでも汚くできますからね。
>>175 ああ、そうか
なんとなく機能を比較しちゃったけど、美しさを比べなきゃいかんね
コードをエレガントに書ける機能なんだから美しさの評価基準とみていいだろ。
C++が最たる例だよ 言うなれば球体のCに棒やら四角やら三角を突っ込んだ歪極まりな言語
Javaもそうだな サブタイプポリモーフィズムだったのに、パラメトリックポリモーフィズムも後付けした
183 :
デフォルトの名無しさん :2010/01/16(土) 01:41:27
型推論: あれば便利という程度、Javaにはきちんとした型体系がある、アノテーションで十分 クロージャー: Javaでも結構簡単に模倣できるし、そろそろ加わるんじゃないの? バリアント? サブクラス、インターフェースで簡単に模倣できる ファンクター? トイプログラム以外で使う馬鹿はいないだろw
184 :
デフォルトの名無しさん :2010/01/16(土) 01:43:00
これだけ色々あるのにまだまとまりを保っているJavaこそ美しいといえるんだよ
185 :
デフォルトの名無しさん :2010/01/16(土) 01:45:24
MLの型推論<<<<Java-Eclipseのリアルタイムいろいろチェック
MLもかじったのか マスターできたのか? それともパダワン未満か?
うわー、意外とよく知ってる 本当に意外だ あまり正確ではないけど
>>187 自分はもっと知ってるみたいな言い方ですけど
煽りしかやってませんねw
>>188 お前が敬語を使う理由は何だ?
そいつはたぶんお前より年下だぞ
年功序列の日本で何をしているんだ
俺20歳ですが
191 :
デフォルトの名無しさん :2010/01/16(土) 01:53:18
MLの型推論 vs JavaのEclipseリアルタイムチェック ⇒ Javaの勝ち MLのバリアント vs Javaのサブクラス・インターフェース ⇒ Javaの勝ち MLのクロージャー vs Javaのオブジェクト ⇒ 10000ポ譲ってイーブン MLのファンクター ⇒ ごみw
あーはいはいJavaはすごいねー Javaの勝ちと一人で勝手に思ってな
このスレってJavaが良いというレスとそれを馬鹿にするレスしかないんだけども?
面白いのは、言語の機能と、言語を使った実装方法を比較しているということだ Javaは粘土的、lisp的であるといえるかもしれない
195 :
デフォルトの名無しさん :2010/01/16(土) 02:04:08
まあそうだけど、 例えば型推論なんか言語自体に組み込む必要はないんだよっていうスタンスがJava言語なんだよ (ただし型体系はきちんと持っておく) で、そういうのがほしければ記述環境でやってねと(型はあるので余裕で可能) つまりJavaの方が簡素できれいなんだよw
そうですね、明らかに誤っている点を挙げると >クロージャー: Javaでも結構簡単に模倣できるし、そろそろ加わるんじゃないの? Java7にクロージャーが加わる話の事だと思うけど、残念ながらあれは断念されました >バリアント? サブクラス、インターフェースで簡単に模倣できる 模倣できても型安全でもないし、exhaustiveness checkもできません >ファンクター? トイプログラム以外で使う馬鹿はいないだろw ファンクターはトイプログラムではないUnisonというOCaml製の同期ソフトでも活躍しています グラフ構造を扱うライブラリでもファンクターが上手に利用されています
197 :
デフォルトの名無しさん :2010/01/16(土) 02:06:45
どんな抽象的な構造をもってきても、それを使える領域なんていくらでも作り出せるw たんに、へんちくりんなものをもっているねwwwってだけww
お前もようやく中学受験レベルのパズルゲームを超えたということだな
199 :
デフォルトの名無しさん :2010/01/16(土) 02:11:16
HaskellやMLにこだわっている=パズルゲームのレベルということにきずいたほうがいいよww
200 :
デフォルトの名無しさん :2010/01/16(土) 02:13:09
トイプログラムじゃないプログラムにunisonくらいしかあげられんのかwwwwwwww
Whitespaceってきれいだよな 真っ白だもんな
そもそも例って網羅するもんじゃないしな
unisonはぎりぎり
Javaしかできない人が関数型言語を勉強したけど 判らなかったから逆ギレしているような気がする。
別にファンクターがすごく優れてるとは言いませんよ そういう意味でもよく知ってるなと感心しました でも逆にそこまで知っててJavaを褒める心境がいまいち不明 型体系は必要とか言ってるのは、もしかしてFeatherweight Javaのファンかな?
ところで、関数型言語を分かった気になってる人が優越感に浸って何やってんの? スレタイ読んだ方がいいね。いろんな言語の前に日本語読めないかな
207 :
デフォルトの名無しさん :2010/01/16(土) 02:23:20
逆だろw 関数型言語でへなちょこプログラムしか書いたことない人が 自分の狭い世界の中だけで意固地になってるだけw
強い静的型付けにこだわっている理由がよくわからない。
209 :
デフォルトの名無しさん :2010/01/16(土) 02:32:09
あった方が綺麗だし、生産性高いだろ? へなちょこtoyアプリならべつだけどww
toyでもいいやって割り切って書いたときの生産性の高さは異常
抽象化機能はでかいプログラムをなんとかコンパクトにまとめる工夫だから、 ちょっと何か書く分には役に立たない
型はバグを減らす工夫だから、設計とかには役に立たないと思うんだが。
設計で言ったらJavaが一番便利だね
>>196 断念されたけどまた復活したって話をこの前どこかで見たんだけど、それも断念されたのか?
前につけていたトリップつけよう 話はそれからだ
>>215 好ききらいの話じゃないよ。異論があるならどう醜いか論理的に説明することだな
そして何が美しいかも
>>218 はいはい。じゃあお前の美しいと思う言語とその理由だけで結構
>>215 の言い回しからしてOO設計に否定的なのかと思ったがな
Javaは記述の粒度が細かすぎて設計に向かない。
野党みたいな奴だな
やっぱり姿形が一番大事。 ずばり、Shakespeareでしょう。
Javaは工業的なプログラム生産に向いた言語だと思う。 工業的というのは、一定レベルの品質のものを大量に生産できるということ。 WebフレームワークやBeanを見るとそう思う。 Eclipseなどの開発環境も素晴らしい。ライブラリも充実しているし、実行環境も整っている。 これらをまとめて「美しい」と表現することはできると思う。 一方、関数型言語もまた、別の方向の美しさを持っていると思う。 たとえば自分はHaskellの遅延評価に美しさを感じる。
○○こがこのスレに居る間だけJava最高ってことにしとこうぜ まともな議論は奴が消えてからだ
オブジェクト指向は美しくない。
>>224 頭の悪い小学生みたいな理屈しかないから
まともな理論で論破できないんだよ
Javaが本当に美しいのがその原因の一つかもしれないがな
>>225 見た目派からいうと、オブジェクト指向など論外。
まだ2月じゃないけど暇になったんだな Cでコンパイラ作る話はどうなった? x86氏の宿題のクイックソートのコードはどうなった? まず見識を広げろ、話はそれからだ haskellで挫折して逆ギレしてる暇なんてないぞ
隔離スレでやれ
このスレって隔離スレじゃなかったのかw
JavaやC++を美しいと思える人の頭の中を覗いて見たいわ
>>232 そういう煽りしか出来ないという事実が明確な証拠になってるねw
>>232 はたぶんJavaとC++は似てるという表面的な情報とC++は汚いという事実から
Javaも汚いと勘違いしてるんだろうね、やれやれ
235 :
デフォルトの名無しさん :2010/01/16(土) 13:04:13
Javaで挫折して、Haskellに逃げた人の溜まり場ですねここはw
Javaで挫折した低脳も逃げ込めるなら、良い言語じゃん。
>>232 OOもどきで美しいとは言えないが、実用性とうまく妥協している。
1 実用的かつ美しい 2 実用的でないが美しい 3 実用的だが美しくない 4 実用的でなく美しくない
やりたいことによるが C言語しっておくと一番いいよ。 C言語は得意なことはないけど不得意なこともない。 C言語以外は得意なことはあるけど不得意なこともある。
>>239 1. Python, Java, C, F#
2. Haskell, OCaml, Scheme, Pascal, Standard ML, Prolog
3. C++, Common LISP, Perl
4. ?
>>223 industrial(産業)用途ということですね。
manufacturingではない。
>>241 F# が 1 に入ると君が思う根拠は?
.NET Framework が簡単に利用できるから実用的というのは分かるが、
美しさを感じるのは何処?
244 :
241 :2010/01/16(土) 17:42:50
245 :
241 :2010/01/16(土) 17:44:24
自演かよ
自演君は恥ずかしくなってもうお休みかな?
どうしたんだろうな 平和でいいことだ
ピ、平和…。
めんたんぴん
一通
>>223 Railsに代表される、今では無数にあるウェブフレームワークやRDBMSは、
典型的なケースを処理するには生産性が高いけど、YahooやAmazonみたいな超大規模なシステムでは
使えないよ。ソフトウェア開発は製造業ではないから、大量生産=短時間で開発できるのとスケーラビリティは
別の品質要求だと考える必要がある。
>>252 YahooやAmazonではフレームワーク使ってないの?
次にスレ立てるときはID付きにしようぜ
Javaは検査例外とgetter/setterと匿名クラスが美しくない。 と思いませんか。
Javaは、パッケージの仕組みが美しくないと思う。
C# switch caseにbreakがほぼ必須で美しくない。 数学のsinとかcos使うのすらMathとか必須で美しくない。 double x=Math.Sin(0.5*Math.Pi);←汚い double sin(double x){ return Math.sin(x); } とかやればMath省略できるけどどっちにしろ汚い。
既存のフレームワークでは多量のリクエストを処理しきれない。特にトップページはやばい。 Googleだってファイルシステムの研究までしてるだろ?
>>258 アマゾンはCが主な言語だったし、YahooストアはYahooのほんの一部だろ?
Webフレームワークを使うのが主流になったのって、AmazonやYahooが有名になった後だろ? 昔のAmazonやYahooが使ってないのは当たり前だよ 今も使ってないことを示すか、もしくはもっと新しい会社の例を出さないと
島根県庁 とかでいいのかな
MySQLの方が実はBigtableやhdoopより性能がいいみたいな 記事なかったっけ?
その比較はおかしい。 GAEよりWebLogicのほうが速いみたいな意味不明な比較。 っていうかスレ違いか。
C++のいやなとこ。 ・デフォルト引数 小賢しい、不要。記述がヘッダ側のみというのも混乱する。 ・virtualキーワード(?) OOPLとして消極的。記述がヘッダ側のみというのも混乱する。 ・constメソッドのconst ケツにピロッと追記するのがイライラする。 ・リファレンス不要 演算子オーバーロードでオブジェクトへ多次元配列っぽくアクセスさせたい時しか必要性を感じなかった。 ・クラス変数と、その初期化 どこに書けばいいのか悩んでしまう。
C++への不満を挙げていったらキリがない もともとこのスレ的には論外だろうし
レーザーなんかより死んでる武器はたくさんある。 SMGとか
>>268 そうかな? C++は汚い、とは誰もが言うが、
具体的な例はあまり見たことが無い。
汚い言語の何が汚いか、はこのスレにきっと役立つはず。
誤爆
>>270 C++は他の言語と違って、もともとオブジェクト指向言語でないCを無理矢理改悪したからだろ
美しさは文字通り、必要かつ十分な機能ってこと。
ごちゃごちゃしてなくて、やりたい事はストレスなく実現できるような
Java、C# と比べて、C++ がどう汚いかを述べてくれ。
型安全、メモリ管理、実装依存
C#も嫌だ。 ・delegate不要 OOPLならオブジェクトだけで完結してていいはず。 ・eventが不要 「リスナオブジェクトの追加」方式で十分。+=なんざそこまでして使いたくもない。 ・パスカル命名記法がクソ ・それにつられてプロパティが嫌な感じになっていく String String {get; set;} Foo Foo {get; set;} 変数名に型情報をつけるどころか、そのものになっちゃってる。 意味から離れて、型になっちゃってる。それをよく見かける。 ただしこれは、プロパティ自体が悪いのではないけど。 プロパティが悪いのは、インタフェース設計を間違った方向へ導きかねないこと。 ゲッターとセッターなんぞ、OOPにおいて必須でもなんでもねえし、 そこから設計をスタートさせるなんぞもってのほか。
プロパティが嫌なのは、 setPosition(int x, int y) setPosition(Point p) setPosition(Vector2 v) などの美しいオーバーロードに対して、 Vector2 Position {get; set;} で型をモロに晒しておきながら、 オーバーロードしたけりゃ void SetPosition(int x, int y) void SetPosition(Point p) などをあらためて準備しなきゃならんとこ。 ならば、最初っからプロパティなんざ無くてよかった。
.NET Framework のプロパティは、 その役割のほとんどが IDE のためだからな。 プログラマにとっては構文糖衣でしかない。 だったら初めから、プロパティという属性をメソッドに与える方式で良かった。
どうでもいいけど >setPosition(int x, int y) >setPosition(Point p) >setPosition(Vector2 v) >などの美しいオーバーロードに 美しいか?w
C++、デフォルトがvirtualでないってのがな…
>>279 不要かもしれないコストがかかる選択肢は
デフォルトであってはならないって哲学だっけ?
パスカル命名記法ってクソなん?
日本語は美しいですか、英語は美しくないですか、フランス語はどうですか。
ラクダが嫌いだからといってハングル表記記法なオブジェクトが許されるかと云えば 否
Javaもうんざりだ Integer.toString()なんて使ってられるか
へぇ? それ超便利じゃん
書く手間に較べて、できることがしょぼすぎる 5000行のコードを書いて、おれ天才ハカーじゃねと思って 実行して自信喪失の繰り返し 見た目まともな動きさせようと思ったら、ソースがぐしゃぐしゃになるか 直感的でないサブルーチンの羅列になる 理想の言語は、やりたいことを書くだけで実行時実現するような言語
>>283 その中だとフランス語が一番美しいとされてるよね。
普通の言語だとエスペラント語が一番になるのかなー
いや フランス語は美しくないだろ 特に数字の読みが節操無い
>>287 それなんてPASIC(Pictured All purpose Symbolic Instruction Code)?
フランソ語が美しいとか言っちゃうのは日本人だけw
美しいのは英語じゃね? アルファベットも26個だけだし、 数を数えるにしても素直だし。
11, 12 は不規則だし、13 と 30 の違いも微妙だし、100 越えたら音節が多いし、 どこが「素直」なんだ?
つフランス語
至高の言語はヒエログリフ
ほとんどのプログラミング言語が英単語を使用しているにも関わらず、近年に普及したプログラミング言語の多くが、英語を母国語としない人によって初期の設計、実装がなされたことは注目すべき。
英米人は既存ので満足してたのに余計なムダ知識増やしやがってってとこじゃないの
でも既存の知識以外を検閲するほどの自信はないんだろ もしかしてムダじゃないかもって思ってるだろ
コンピューターは英語圏で生まれたから ・まず英語圏の人が作ったものが普及する ・次に非英語圏の人が作ったものが普及する ←いまここ
フランスの小学校には落第がある 数学でつまずく子供も多いらしい フランス語の数字の解釈は独特だが 歴史的に優秀なフランスの数学者は多い 数の概念の捉え方の難しさが脳を刺激し 発展に繋がったのだろう
日本では文字コードが発展したんですねわかります
>>301 フランス語の数字は難しくないよ
ただの20進数だ
英語より単純
フランス語の数字は60進数もあるぞ。
もう何進数とかやめてさ、 数字1つずつに固有の名前をつけたほうがいいんじゃないかな。 その数字の固有名詞がわからなかったら足し算で表現するとか。
100年後には素数で表現されてると思う 10 = p(1,3) みたいに
27を書いてくれ
>>287 その昔、ASCIIというマイコン雑誌があった。
以下は、その1984年10月号に掲載された連載記事からの引用。(二十数年前だね)
"TBN: ダートマスからの脱出 - Scene#4 動くプログラムを作る方法"
みんなは今までにソフトウェアというものをどれだけ作ろうとしてきたのかナ?
そして、そのうちいくつが完成したんだろうか?机の奥には、作りかけのソフトウェアが
溢れているなんてことはないだろうネ。
....(中略)....
それらのほとんどは、作っている途中でプログラムがスパゲッティーになってしまった
ものばかりではないのかナ?さて、これは何が悪かったのだろうか。
ちょっと、みんながプログラムを作るときのことを考えてみようヨ。たいていの人は、
「こんなプログラムを作ろう」と思いつくと、すぐにパーソナルコンピュータに向かって
プログラムを書き始めているのではないかナ。計算機に向かってさっそうとプログラムを
書く姿は意外とカッコイイと思っているかもしれないけれど、実はここに作っている途中で
放り出してしまった原因が潜んでいるのではないだろうか? .....(以下、省略)
TinyBasicNewsletterか、懐かしいな
持ち主の意に沿わない形で願いを叶える
lーgg
Forthは美しい というかもうinfix記法はプログラミングでは 「ほとんど使わない」と気づけボケども だがFactorは複雑すぎて理解不能
繰り返すけど、もうinfix記法はプログラミングでは 「まず使わない」と気づけボケナスども
>>313 複雑なものを理解できないのはおまえの頭が悪いから。
316 :
デフォルトの名無しさん :2010/01/21(木) 17:21:04
>>313 あなたの脳内のことは他人には理解できません
鳩の頭といっしょ >宇宙ができて137億年、地球は人間だけのものじゃない
ウヨの脳内も理解できないなw
烈士様なにやってるんですか
クニがなんだよ!
国は重要だぞ お前の負けが確定しているのも日本の政治がカスだからだ
こんなところにまで汚い金を綺麗に使う名人、小沢先生の応援者の方が。 応援お疲れさまです。小沢を総理大臣にしましょう!
caseにbreakが必須というのがCなどの汚さの一つとされてきたが、 そうでもない例がある。 switch(num) { case x: case y: case z: foo(); break; case a: case k: bar(); break; case b: case c: baz(); break; } break無しだとかえって冗長になるはず。
switch(num) { case x: case y: case z: foo(); case a: case k: bar(); case b: case c: baz(); } 別にこれでいいじゃん。
>>323 C#とかはそうなってるみたいだね。
> C#では、1つ以上のステートメントが書かれたcaseラベルから
> 次のcaseラベルにフォールスルーすることは許されない。
> ただし、ステートメントのないcaseラベルにおいてはこの限りではない。
fall throughしうる=break書く必要がある だと思い込んでた。
break書かなくても「1つ以上のステートメントが書かれ」たか否かで区別できるとはたいしたもんだ。
323 のような例は case x, y, z: とか書けたほうが美しいだろ。 case a: foo(); case b: bar(); break; a のときは foo(); bar(); 、b のときは bar(); という、こういう処理が書きたい、という ごく珍しい場合に、C の仕様は有利。
>>325 将来、赤の他人がメンテすることになったときにバグの温床になりそうな気がする
>>326 そういうとき、普通は /*FALLTHROUGH*/ を書きます。
>>325 のような書き方には美しさを感じるな
switch(num){
case x: aho();
case y: baka();
case z: hoge(); break;
case w: foo();
}
見たいな奴とか好きだ。
あくまで個人的な意見だけどさ
breakなんて付け足すあたりが薄汚いな
switch-caseなんてなくなってしまえばいいのに。
このスレに英語もどきのオペレータを書き込んで美しさを比べる神経が。
>>325 switch-caseは単純な振り分けには有効だけど、処理順序の制御とかは絶対にしたくないなあ。
順序変更とかに弱いし。いや永久に不変ですっていう状況がありえるならいいんだけど
結論から言うとやっぱbreak不要で分岐終了して欲しい。
>>332 に同意
将来の修正で
>>328 のyの時だけbar()を呼ぶ処理を追加するとかになったら大変そう
>>325 Rubyがそれだね
CやC#よりもRubyのほうが直感的で簡潔に記述できる
以下は
>>322 ,323をRubyで書いてみたもの
case num
when x, y, z
foo()
when a, k
bar()
when b, c
baz()
else # No case
raise RuntimeError
end
個人的にはRubyは一番美しいと思うよ。 map, to_a, to_s, inspect, inject, sizeなどどれもステキすぎる。
switch(num) { case x: case y: case z: foo(); break; case a: case k: bar(); break; case b: case c: baz(); break; default: raise RuntimeError } そんな違わないけど ruby は case じゃなくて when の方にも色々条件書けるのが良いと思う c だと switch にしか条件書けなくて case の方はただの数字でないとだめだから
全てのプログラム言語はどれも美しいものばかりじゃないか 記述されたコードが醜いのは、コードを書いた奴の醜さが、コード現れているだけだろ 美しいプログラム言語を探すより、エレガントなコードを書ける人になろうぜ
どんなに頑張っても綺麗に書けない言語がある そのうちのひとつが Perl と PHP だ
>>336 Cの場合は特に、
switchは低コストな実装に最適化されることをプログラマ側は期待する
テーブルジャンプだったり、二分木であったり
だから、caseに書けるものが制限される合理性はあると思う
お前ら、C の switch-case でなにが出来るようになって欲しいんだ?
ローカルスコープの定義かな 回避方法はあるけど
>>338 非常に残念だが、君のその机の上を見たら、君に綺麗なコードを書く能力が無いとしか思えない...
Perlは普通に手続き的な処理を書くなら、素直なコーディングは可能だと思う。 でも、Perlのオブジェクト指向のゲテモノさに辟易した。だからRubyを知って飛びついた。 PHPは詳しく知らないが、構文としてはPerlの難解なOOPをシンプルにした良い言語に見えるよ。
OOPは初心者に教えるべきではないから、ゲテモノくらいが丁度良い Perlもそうだし、Cならポインタを十分に理解した後で良い
>>333 それはC#のswitchでも同じことだろ
美観は損ねるが、ifをはさめば済むことだし
switchを2並べてもいい
そもそもswitch文に柔軟性を求めることが間違っていると思う
> それはC#のswitchでも同じことだろ 全然違う
>>345 C#は、禁止されてる。(goto使えば出来るけど)
そもそも、breakがないというところに美観は感じられない。
ごめん、食べログちがうwww クックパッドでした
機械語は綺麗な言語 それ以外カス
それは人間にとって、か?
構造化アセンブラ用のプリプロセッサを作ればレジスタの役目も分かり易いしマクロも強力だからOK
>>352 文字列やループ、条件分岐を書きやすく拡張していくとC言語になるわけですね。わかります。
>>353 本当にそれだけか?ポインタやメモリ割り当ては?
int21h
>>354 メモリ割り当ては、C言語そのものにはないな。
ポインタは、EBX,ESI,EDI,メモリ割り当ては4kB単位のページ。 凄いですね、x86は。
自分はEBPもポインタに使いますが。 68000なんて、もっと凄いですよ。スタック除いてポインタが7個もありますね。 自分はESPすらもポインタとして使っているプログラマを知っていますが。
286までのセグメントは批判の嵐だったけどねw
Cはアセンブラとか言われるが、キャリフラグ等をイジれないから面倒くさい。
x86もキャリーフラグとUVパイプのことはしつこく言ってたよな。 しかしJAVAがCより速いとか言ってる馬鹿はどうにかならんのか。
Cとアセンブラの併用
JavaがCより早いのは物理的にありえない話だ ガーベージコレクションしてる以上、その分余計なCPU使うし
>>365 Cのポインタは効率が悪いからJavaのほうが速い場合があるとかいう文献をどこかで読んだことがある
パフォーマンスはプログラマの技量に左右されるから、Cで下手に書くよりもJavaが速くなる可能性はありそうだ
まあJavaにはループが遅いという欠点があるから、ほとんどのケースでC/C++の勝利だろうけど
何よりもJavaはメモリ食いすぎ。
組み込みでもやるのか?
Javaの方が制限が多い分だけ最適化しやすいのもあるね。 数値・ポインタ間のキャストがないとか、配列の部分重なりを気にしないで済むとか。
>>365 実行時情報が得られるので、
JITがうまく効けば静的にコンパイルされたコードより高速になる可能性はある
GCも最近のやつは効率が良い
JITの中間言語コンパイル時間は実行時時間にいれないのはずるいよ。 極めればアセンブラだけど、C/C++はJAVAより遅いなんて無い。 MSのライブラリを見てもUVパイプを使ってpenに最適化している
プログラマ次第だからバグが多そう
ユーザの視点で見ると、Javaで書かれたプログラムは反応時間が変動するので変な感じがする。 それは美しくない。 やはり機械と一体化しているネイティブバイナリはユーザにとって美しい。 開発者よりもユーザを尊重するユーザビリティ原則に基づけば美しいのはC/C++だろう。
>>371 つまり凡人はJavaを使うべきですね。
CとC++を一緒くたにするなよ
>>370 費用対効果で割に合わない部分には、そもそもJITをかけない
VM上で動作することを逆に利用すれば、
Cとまでは言わずとも、かなりのパフォーマンスは出せるし
場合によってはCより速いケースもあり得るってだけの話
場合によってはな。熟練したCのプログラマが熟練したasmの プログラマを超えられないように、javaのプログラマもライブラリで補ってるだけだろ?
>>377 しかしCのパフォーマンス上の優位は確率的なもので、100%ではない。
asmはどうよ。100%だぜ? キャリーだってあるし。 javaの全て符号付きより100倍マシ
javaより無難な言語は無い
>>380 全てが中途半端なのを無難というのか?
パフォーマンスが重要な状況でパフォーマンスに上限があるのは難ありだし、
ソフトウェア開発者としての資質を見極めるのにも使えないのも教育言語として難ありだろう。
javaで作ってれば問題ないから。
パフォ厨うぜー
あんなライブラリ依存の言語をか。
asmはキャリーが使えて実行時スピードが凄い。 javaはライブラリが豊富。しかしライブラリにないことをすると困難。 Cが一番なんじゃない?クリティカルパスはasmにまかせてさ。
>>383 資源は有限だ。パフォーマンスも重視してどこが悪い。
構造化アセンブラならマクロも強力だから、言語としても綺麗だし。
生産性を考えればメインはPythonだろ。 クリティカルパスはCにまかせて。 そのまたクリティカルパスはasmにまかせて。 Haskellは意外とランタイムが信頼できないからサーバには使わないほうがいい。
388 :
デフォルトの名無しさん :2010/01/25(月) 02:04:53
>>387 asm至上主義の自分から見ても正解に近いな。
GCは中々コントロールできない。
asmは読める程度にして、組むのはマエストロに任せればいい。コメントは忘れては困るが。
PythonとRubyが醜いユーザーの競合をしてるところが頂けない
C、asmは安全でないという、場合によっては致命的な短所がある。
タコプログラマならだろ?
>>391 自分だけはタコじゃないというやつが一番のタコなんだけどな
393 :
デフォルトの名無しさん :2010/01/25(月) 06:35:34
うん、SEGVに気を遣って書くよりはその集中力を他に向けた方がいいコードが書けるのは事実
末端処理をしっかりやればCやasmでは最強だ。 ライブラリが貧弱なのは認めるが、 今のライブラリは何だ。何でもやってくれる物ばかりじゃないか。 これでPGなんてよく言えるよ。
しかし、このスレでアセンブラのエキスパートはいないのかoptasmに狂喜乱舞したやつとか、
dos-extenddrでメモリを大量に使ええられるようになったと。
>>393 セグメントはメモリ制限のためのものではなかったんだよ坊や。
8080をみて64kb以上を保護するために作ったんだよ。
それが間違いと認めて286/386ではMMUと共に強化されたけど
GDIで3d表示用のブレゼンハムのasmプログラムを晒そうか?UVちゃんと考えてるぞ。
>>395 残念ながらMS-DOSではバッチファイルプログラミング(?)しかしたことがない。
バッチファイルでゲームを作ったりした。
シェルスクリプトであるバッチファイルを、COMにコンパイルするプログラムなんてのがあったので、それを使って遊んだ記憶がある。
CONFIG.SYSは書いたことがある。
ところで、さすがにバッチファイルは美しい言語に挙げられていないな。実際美しくないが。 そもそもDOSコマンドが美しくない。大文字だしな。
しかし、一般ユーザーがatomに退化してるのによく速いプログラムは必要ないなんて言ってるよな。
話が抽象的すぎるから何とも言えないが 例えば、速いC++コンパイラが必要だ、と言われたらどうするんだ
DOS は IF ERRORLEVEL n が n 以上で真という変わった仕様があったな。 PowerShell だっけ? FizzBuzz が case n % 3 == 0 print "Fizz" case n % 5 == 0 print "Buzz" else print n みたいに書ける(複数条件が順番にひっかかるcaseと、「どれでもなければ」のelse) というのは。
DOSのErrorlevelの仕様のどこがへんだ?
errorleve 1,2,3...と使い分けたい時に直感的に書けない、とか? いや使った事ないから知らんけど
405 :
デフォルトの名無しさん :2010/01/25(月) 22:32:29
おすすめのスプリクト言語は何?
zsh
js
>>401 どっちかっちゅーと switch (1..100) { ... } とか switch ($a,$b,$c) { ... } とできることの方が特徴的だと思うよ>PowerShell
awk sed をその他のツールと組み合わせて使うのが最強
411 :
デフォルトの名無しさん :2010/01/26(火) 19:13:00
>>412 指摘された通りだと思うが、
KL0は、PSIのマイクロコードに対する一種のマクロアセンブラ的な位置付けの
Prologであると思います。
414 :
413 :2010/01/27(水) 14:36:41
>>413 「マクロアセンブラ的」 ではなくて 「アセンブラ」 としなくてはいけないか。
415 :
デフォルトの名無しさん :2010/01/27(水) 16:57:58
JAVA は JAVA、JAVA いにしえの、この海に癒される、 JAVA JAVA とこしえの、この空に癒される、 とかいう歌を思い出すね。
ちんこは、スピードとメモリは時間が解決すると言っているが、 洗濯機にJAVAなんに可笑しくないか?
やっぱり言語仕様というよりはライブラリが美しさの明暗を分けると思うな。 ライブラリが最も美しいプログラミング言語は何?
じゃあTkは何のライブラリなのだ TclのライブラリかCのライブラリか
Tkはツールキット ライブラリではにあ
tclもgtkと浮気するような時代 ライブラリは、Cでかかれてりゃそれでいい
>>415 JAVA JAVA言われても、バブルスターしか思い浮かばん
まるで詐欺に会っているようだ
Cで書かれていれば大抵の言語にはバインドすることができるしなあ
服を洗うのに風呂釜用洗剤使うのは変だよねってこと
エアコンにx86を使うようなものだというほうがよくないか?
もうこの際だから名前で決めようぜ
それならFORTHだな
Cじゃね? 視力検査にも使える名前で優れもの。
C力検査なんてな
JAVAでジャバジャバ洗濯
432 :
デフォルトの名無しさん :2010/01/30(土) 06:37:30
スパゲティプログラミングができる言語がエレガント
>>429 【審議中】
∧,,∧ ∧,,∧
∧ (´・ω・) (・ω・`) ∧∧
( ´・ω) U) ( つと ノ(ω・` )
| U ( ´・) (・` ) と ノ
u-u (l ) ( ノu-u
`u-u'. `u-u'
>>431 【審議拒否】
∧,,∧ ∧,,∧
∧∧ (・` ) ( ´・) ∧∧
(ω・` ) U ) ( Uノ( ´・ω)
| U u-u u-u (U ノ
u-u ∧,,∧ ∧,,∧ u-u
(・ω・`) (´・ω・)
(l U) (U ノ
`u-u'. `u-u'
Cが美しいという奴がいたのでちょっと使ってみたら、酷すぎw 名前空間すらないから関数名がカオスすぐるwwwwww
僕は馬鹿ですって自己紹介されてもリアクションに困る
サッカーなら? java 戦略眼のない無駄走りもおおいし、つまらない規約に人をはめてる ようなものだから 日本代表だな。 c++ ぐちゃぐちゃしてるからな。つぼにハマれば強力なんだけど、 どっかわからんわ。
C++はアメリカだな。 力はあるけどエレガントさを気にしない。
プログラムの事全くわからない無知だけど 全てのプログラム言語はLispに向かってるんじゃないの?
Haskellなんかは、Lispの「なんでもあり性」には背を向けている、と思う。
閉じ括弧サクッと省略処理できればLISPも小奇麗なんだけど 機械向けにマ側から歩み寄ってる部分が美しくないんだよね
あれだ、いっそ、改行と;で区切るとか
Lispは動的な言語。型システムが動的だし、リフレクションもできるので、プログラミングスタイル全体も動的。
Haskellは静的な言語。参照透明な記述は信頼できるが、運用の柔軟性がないので実用的でないといわれる。
Lispは古典的なラムダ計算がベースで、Haskellのように現代数学の成果が取り込まれていないのが不満。
>>441 それをやるとマクロの強力さが失われるというのがlisperたちの言い分だろ。
インデントで構造を示すなんていうのもありがちだが、それは書きにくい。
Pythonのほうがいい。
>>442 マクロのないlispなんか
クリープのないコーヒーみたいなものだ。
年寄り向けコメントな。
ところで今gtkプログラミングをしているんだが、非常に面倒だ。 やはりUIはlispに限る。
>>444 比較対象がバラバラだな。
それとも行間を読みまくれってことか。
>>445 UIとしてのS式は素晴らしい。
XMLは制限されたlispだ。
GUIライブラリはlispでかかれるべきだろう。
447 :
デフォルトの名無しさん :2010/01/31(日) 01:39:52
ちんこがついにコンパイラ作りに着手したもよう。
実装する前にもっと基礎知識が必要だと思うけどなぁ
なんだかコンセプトがよくわからないな 遅延評価で関数の評価のとこだけS式なのが売り? まぁどんなもんが出来るか待っててやるか
451 :
デフォルトの名無しさん :2010/02/02(火) 21:26:10
JAVA Tea と書いてジャワティですから。JAVAラーには常識かもしれんが。
ちんこってForth知らなかったんだな
最も美しいプログラミング言語でも日本のIT奴隷技術者にかかれば汚いコードが出来上がる
泥十年働いた日本のゴミプログラマーは インド人プログラマーに置き換えるよ
デスマーチの下ウンココードを大量生産 負の悪循環 美しいプログラミング言語以前の問題
俺はいまジャバとフラッシュ勉強してる。後者は予定。 ジャバはやっと6章のfor文終えて、明日から7章のwhile文へ入る。 サイト系ビジネスで一旗上げてやるぜ。 作りたいネタは5つはあるぞ。
勉強してから自力で開発も良いけど、出来る奴あつめてサッサと実装した方が良いんじゃね? アイデア5つあるなら1,2つ形にしといた方が、勉強にも勢いがつくぜ
javaやってるのでjavaでよろしくね
それはこのスレでやるような話じゃない
>>456 >俺はいまジャバとフラッシュ勉強してる。後者は予定。
まず日本語な
半年ROMってこい
>>456 みたいなゆとりネタは、たまに本気かと思うから怖いわ
プログラム言語の構造単体に美しさがあるのではなく、 それをいかにエレガントに書くか、プログラマーの美的センスがあるのみだ。 たとえば私が書けば、いまウブ声をあげたばかりの言語を駆っても、 最高の作品が生みだされるであろう。
エレガントな方法は、実行速度その他の効率が悪いことも多い。美しく書けることを自慢しているうちは中級。
>>466 >>465 では無いが、これは俺には無理だ。orz
ソースと、そこから生成された実行コードとの関連性が自分には理解不能…。orz
>>467 個人的な意見としては、実行速度その他の効率よりも、
美しく書かれたソースのほうが重要だと思う。
ただしビジネス用に書かれたソースならという前提での話だが…。
実効速度その他の効率を追求してメンテナンス性に劣るコードを書く奴はプロとは言えん。 それが必要でない限りにおいて。
美しいコードを書けない人は、効率的なコードは書けない。 あくまで通過点。
コードの品質なんてどうでもいいとしか思わない それよりも社会を何とかする必要がある
どうでもいいとか言って論点をずらすな 社会の話の方がどうでもいいわ つまりpython使っとけって話だろ
ブラックボックスに依存して 箱の中はどうでもいいと思っていたら 箱を何とかしたいと思ったときにはもうお手上げ
計算モデルのレベルからどうにかしたい
>>467 実行速度その他の効率が悪いのはエレガントな方法とはいえない。
両立するのがエレガントな方法。
いくらエレガントな方法で書かれても、実用性がないプログラムはもうおなか一杯だ。
LispやSchemeでフィボナッチ数列書いてる場合じゃないw
C最強ってことだろう?いい加減Cに変わる最強が出てこないのかね
そこでGoですよ
>>477 つまり、haskell で GUI バリバリ書けて、ビジネスアプリ作りまくれて、
GIMP や OpenOffice や Blender みたいなのをたくさん作れれば
最強ってことだよね。
>>480 haskellでCインタプリタを作っても意味ないだろうな
ハードウェアや計算モデルには特にこれといった欠陥はない
どう考えてもOSとかミドルウェアとかが怪しいのになぁ
>>481 つまりUNIX-likeでないOSが必要だと?
>>484 UNIXの全部が悪いとは思わない
でもUNIXの色んな機能を一括りにするしかないのが現状なら、
もっと分割できればいいのにと思う
勉強に時間がかかるんじゃ何のための抽象化だよって感じだな OSのせいで逆に学ぶべきことが増えるのでは意味がない
抽象化は人間の思考の志向性
美しさにこだわるやつは無能の法則
自称有能な奴は醜いの法則
自分を定義するのは愚かだ
たしかに自分は神だなんだと言ってる奴にろくなのはいないな
何言ってんだ。 さすがにそこまで傲慢なヤツいるわけないだろ。 自分が神だなんて。
493 :
デフォルトの名無しさん :2010/02/13(土) 13:25:55
わたしが神だ
| ノ {{|iiiiiiilll;ノ,,,,,ヽ;liiiiiiii||}} ゝヾ | .ミ >='^◎≫,i'^'i,≪◎'=、< ミヘ ,ヘ ミ ~こ二ヲ i i; .'ミ二こ、 ミ }
僕は新世界の神となる
自称情強にろくな奴いない
私は再発明する前に調査する
私は理解したいから再発明する
理解したくても理解できないのは残念だな
自分のことを神とか、社長とかいうやつにはろくなやつがいない
Only human
>>500 後者は実際に社長だったらそう言うしかないだろw
二人称が目上の人には「社長」、目下には「貴様」の奴にろくなのはいない
結論:C++で正しく美しく書ければいい
不可能が存在するという実例が示されたな
Cが好きならC++のCの部分だけを使えばいいのに
俺は地面に落ちた食べ物は汚いから食べない
だから、地面に面してない部分だけをだな
C++はCの部分と違うしなぁ ポインタとか。 いちいち(int)とかつけないとmallocできなくなっててうざいわ
C++になれるとCには戻れないからJavaに落ち着くんだよね
>>509 void*のキャストをうざいということは、Cの警告も切ってるね。
とっとと引退しろ。
JAVAは言語としては好きだが環境がウザい アップデートのたびに別バージョンのエントリがわらわらインストールされる
JAVAは動作がもっさりしているからどうにも好きになれない。
いつの話だよ
Javaの仕事とかしたこと無いけど わけわからんフレームワークがいっぱいあるよね。 しかも全部Web系だし、泡沫的な技術ばかりなにおいがする。
わけわからん人は使わなければいいだけ 万人のために用意されてるわけじゃないだろ それはJavaに限った話じゃないしな
>>509 ぶっちゃけ、c++ で malloc 使う時点で負け決定なんだが…
# malloc が必要な場合c++ を選択しない
Cで書きたいけどOSの都合で部分的にC++機能が必要な場合 Cとの互換性で使う場合もあるだろうに
ホビープログラミングのレベルなら、Java選んどけば間違いない。 圧倒的汎用性である。 ちなみに大学授業での採用率も、CとJavaがトップ(ソースは無いが)
>>517 別に勝負なんかしてないから負けも勝ちもない
malloc最強
××が最強
prologでしょ
化石言語は糞だから化石になった。再評価の価値はない
汎用性と言語としての美しさは別
美しい言語 [beautiful]
>>520 日曜グラマがJavaを選ぶ理由がわからない
ホビーなら、lispとかOCamlつかう
グラウンドアップで作るなら Lisp が良いけど、あり物のライブラリを使って 素早く作りたいなら Java も良いんじゃない。
>>528 LispもOCamlも使いこなせない奴が言いそうな台詞w
>>1 すっきりした美しさを買って、Prologだね。
日本人ならプロログだよ。 国家プロジェクトだったし。
誰か、AAでプログラム作れるの作ってないのか?
for (´;ω;`) { }
>>534 Haskell の変数で C# みたいにユニコードが認められれば、
けっこう面白いことができそうだが。
思いっきり文系プログラマですが、HaskellかOCamlのどちらかを 趣味でやろうと思います。 現段階で、できる言語はCとRubyです。 どちらの方がおすすめですか?色々な角度からのご意見お待ち しております。
両方やるとさらに理解が深まるよ
OCamlって、スピードなりなんなり、関数型の癖にそれなりにいい性能だ みたいなの記事は見た。 F#が出るかもしれないとか、実用面で考えたらOCamlとか言ってみる どっちも触ったことすらない
最近PYTHON使い出した。美しい言語かといわれるとよくわからんけど 思想と記述のしやすさはとても好きだ。
if (゚∀゚) ━━━━━━ !!!!! else (´・ω・`)ショボーン
>>539 逆でしょ。ocamlだとライブラリが足りなくて大変だよ。マルチスレッドもダメダメだったはず
>>537 私も詳しくないからアドバイスなんてできないけど、ML系には
「最新コンパイラ構成技法」という魅力的な本がある。それで
私が勉強するならOCamlの方。
OCamlは全くやる意味なし。 HaskellやればOCamlは普通にわかる。 OCamlやってもHaskellはわからない。 OCamlのOのオブジェクト指向の部分はOCaml使いの間では使わないのがセオリー。 普通に「失敗」と言われている。 別に両方やれば「そういう物か、ふーん」ってなるけど、片方やるなら絶対Haskell。
OCamlとHaskellじゃ言語がどうの以前にライブラリの充実度が違うから 何かやろうと思えば必然的にHaskellを使うことになる
というか、ゴチャゴチャ色んな言語があること自体が美しくない 一長一短適材適所あるだろうけど、それでも多すぎだろ。文法や利用用途が似てるのも多いし
Oの部分を使わないってMLでいいんじゃないか? とか言ってみる Haskellの方がライブラリ多かったりするん?教えてママン
OCamlの方がCの関数呼びやすいから結局何でもできるよ。
>Cの関数呼びやすいから じゃあ始めからCでやりゃあいいやんwww
OCamlのほうが何でもあり。
生産性の話をするなら美しさに拘る必要もないな
基本はOCamlで必要なところはCで書く これでいいだろ
554 :
デフォルトの名無しさん :2010/02/18(木) 22:34:06
コテハンちんこはいなくなったのか?
名無しになって潜伏してると思われ
言語の数学的側面はまあいろいろある 関数型だあ手続き型だあオブジェクトだあ そういうのを比較して美しさを論じるのもいいだろう けれど一番重要なのは、そういう構造をどう表現しているかだ GetProfile()なのか get_Profile()なのか GET_PROFILEなのか (get-profile)なのか そもそも関数名にgetなんて単語をつけるのは美しくないとか usingなのかimportなのかはっきりせいとか そんな人間の習慣や主観のせいで言語体系の美しさが損なわれている
構造なんて似たり寄ったり。 ラベルに何と書き込むかがすべて。
最も変数値の交換が美しい言語Ruby x,y = y,x
>>559 それPythonもいっしょ。
Perl は ($x, $y) = ($y, $x); か?
カンマはどういう意味なの?
タプル
交換ならswapやpush, popの関数があれば同じように書ける。
便乗質問スマソ ウェブアプリ(つーか簡単なCGIの掲示板とかチャットルーム)を 安いレンタルサーバーで運用する前提で、関数型プログラミング 言語で作ってみたいんだけど、 HaskellとOcamlとどっちがお勧め? おいらは趣味グラマでCommon Lispはそこそこ使えます。 ちなみにErlangは数年前に挫折済
>>564 そもそもそのサーバではghcやocamlでコンパイルできるのか。
>>566 レンタルサーバーも紹介してくれ、という意味なんじゃないの?
>>564 そういう時はVPSだろ。Linode安いしオススメ。
GAEでClojureとか?
570 :
デフォルトの名無しさん :2010/02/27(土) 03:45:02
Common Lispが使えるならGoogle App Engine + Clojureで決まりだろう。 ClojureはJavaへのフルアクセスが用意されてるLispなので、Javaでできることはなんでもできるし関数型でも書ける
同じ人工知能用言語でありながら、lispと対照的に、あまり出てこないProlog 見た目はPrologの方が良いと思う
シーゲンゴとか美しさは皆無だ
そうか? シンプルで美しいと思うぞ。
美しいだろ。ソフトウェア設計においては少し劣るけど
>>572 「シーゲンゴ == C言語」 の事だったら、確に、あれほど、不細工なアセンブラはないな
それって C は高級アセンブラだという話を聞いたのかな?
>>576 聞いたんじゃなくって、初版の K&R を読んだ時から、そうだと信じてるんだけど…
K&R の初版って日本でも売ってたんだ…
不細工なアセンブラでも他の言語より美しいのは事実だからな
>>578 「第2版日本語版へのまえがき」にこうあるぞ。(うちのは2版訳書訂正版)
本書の第1版の日本語版が1982年に出版されたとき、<snip>
根拠もなく美しいとか語るプログラマな人って…
583 :
デフォルトの名無しさん :2010/02/28(日) 03:23:09
プログラミング言語ってなんで英語なの? なんでそんなややこしいの?
「なでしこ」でも使ってろ
英語だからややこしいと思ったことはないなぁ。 オブジェクト指向だからややこしいと思ったことはあるけど。 クラスのメソッドがプロテクテッドでこれがプライベートで セルフがこれを参照してて、パブリックだとこれこれで、 継承するとこうなって、ここからこれは参照できるけど あれは参照できなくって・・・ 「こんなもんわかるか!」って終いにはブチ切れる。
まあ所々言葉で説明するだろうけど数学でもなんでも学術的なもんは英語の方が圧倒的に有利だな 後置修飾の方が分かりやすいし簡潔になる
そんなに後置修飾がいいのなら、 英語ベースのプログラミング言語なんかより フランス語ベースのプログラミング言語にすればいい。
フランス語が世界標準になったらね フランス人の永遠の夢だね
なら前置修飾で我慢するんだな。
はあ?
非現実的な無理難題や極論で、どうして論破したつもりになれるんだろうね 英語の後置修飾が良いって意見の、どこが癪に障ったんだ?
日本語はかな漢字変換が必要だから英語より効率が悪い。少なくとも今主流の技術では。
普通に考えれば、英語では後置修飾よりも前置修飾のほうが多いからじゃないのか? そんなこともわからないなんて、生きていても仕方のない馬鹿なんじゃね? おまえ、死にたいと思ったことあるか? もし今後、死にたいと思ったりしたら、自分の気持ちに素直になったほうがいいぞ。
最近普及し始めたげん語の設計者は英語ネイティブではない人が多いな。Eiffel, C++, Python, Ruby, C#ほかになにかあったかな。 アメリカ人が設計したものは、記号を多用していたり、場当たり的な機能が多いように感じる。
記号が多いのはシェルやawkからの流れだろ 意味は似通っているから、覚えるのは楽 Eiffelって、はやってんのか?
>>583 Prologを使えばいい。
もともと、遅いのは覚悟の上だから、
read,write,assertといった組み込み述語は
全部日本語で再定義してしまえばよい。
どうしても残るのは(),.くらいのもの。
プログラミング言語が英語に見えるか? 英語由来のキーワードを使っているから英語というわけではないだろうに。 日本人から見たぴゅう太の日本語ベーシックなみに英語ネイティブからみたらプログラミング言語はキモいと思うのだが。
キーワード的なものや記号がどのくらい残ってしまうかということかな。
英語に見えるように努力してるプログラミング言語っつったら COBOL 系ぐらいだろ
>>598 英語ネイティブには、普通のプログラミング言語が日本語ベーシックみたいに見えてるんだよ。
われわれとは、違って見えていると考えていい。
それが、英語ネイティブが記号を使用したがる原因だと思う。
それから、美しさの評価では 思いつき的な記法がどれだけ排除されているかも大事なポイント。
RubyアンチかPerlアンチかPython信奉者かw
>>598 Haskellとかでwhereをネストさせて書いてる時、
思考感覚としては英語(または類似言語)の修飾節に近いものがあると感じる
まず本題を述べてから、それが何か、どんな条件かをツリー状に補足してくイメージ
Perl/Rubyの後置ifにも同じものを感じる
と、Pythonにも後置if式があることを知らないブタがほざいていますw
>>604 whereの用法は、英語うんぬんじゃなくて、数学の流儀なんだけど。
語単位ならまだしも、節単位での説明単位がトップダウンかボトムアップかなんて、
言語の違いではなくて論理構成の違いなんだけど。
Haskellのような宣言的言語がトップダウンな構成になっているのは
英語うんぬん以前の当然の帰結だと思うんだけど。
>>600 英語感覚の言語ならAppleScriptを超えるものはないだろ、常識的に考えて
>>606 人間の思考と、人間が操る言語は分離できないって説があるでしょ?
英語はトップダウンな思考を誘導するのではないかと思ってる
もしそうだとすれば、Haskellなどと英語が似ている(と感じている)事が説明できる
>>608 じゃあバイリンガルは多重人格か?
どんな言語でもトップダウンな論理構成も取れるし、ボトムアップもできる。
where節の用法は英語特有のものではなく、論理学や数学のものだと気付け。
どうしてもそれを英語由来のものだと主張したければ、
Haskell風のwhereの用法が、英語でのwhereの用法の主用法であることを示せ。
>>609 >じゃあバイリンガルは多重人格か?
?
>どんな言語でもトップダウンな論理構成も取れるし、ボトムアップもできる。
これは否定していない。むしろ肯定したい
>where節の用法は英語特有のもの
そう主張はしていない。ただ「誘導する」と述べた
>>608 今時サピア・ウォーフ仮説とか流行んないよ。
自然言語でもそこから表現される言葉、文章で美しさを感じることはあっても言語で美しさを感じることは無いなあ。 プログラム言語の美しさの定義って何?
自然言語と違って文法ルールは数が限られていて、ルールの適用も厳密。語彙数も限定的。 比較するなら iambic pentameter の美しさはどこから生まれるかとか、もう少し限定的な 対象が適当だと思われ。
614 :
609 :2010/02/28(日) 16:35:10
>>610 > >where節の用法は英語特有のもの
> そう主張はしていない。ただ「誘導する」と述べた
俺もそんな文面で書いていない。
引用したふりして勝手に俺の書き込みを捏造するな。
数学の公理系とかに近いかなぁ
日本語のトークンでプログラミングするのがいいとは思わない。 プログラミング言語がどの自然言語に似ているかという言語構造の問題ではなく、文字セットの問題だ。 私たちは文字をキーボード経由で入力しているので、日本語を入力するにはかな漢字変換が必要だ。アルファベットを入力するよりも間接化のレイヤーが増えるので手間が増える。 やはりアルファベットを直接入力する方がいくらか楽だ。 プログラミング言語なんてどうせ記号の集まりなのだから、記号を直接入力する方が楽だろう。
>>616 そういうレベルなら、プログラムは仕様書と対だろう。
仕様書の方で漢字変換はしているよ。
>>604 > Haskellとかでwhereをネストさせて書いてる時、
数学で言うところの「ここで…」のネストとしか思えないのはおかしいんですか?
> 思考感覚としては英語(または類似言語)の修飾節に近いものがあると感じる
英語関係ない
>>594 >普通に考えれば、英語では後置修飾よりも前置修飾のほうが多いからじゃないのか?
形容詞の後置修飾じゃなくて、関係詞節や分詞構文のことだろJK
英語を日本語に翻訳したら、だらだら続く形容詞節は前に持ってくるか、
複数に分けるしかないからな。それで学術的な記事では記述のしやすさにおいて
英語が日本語に比べて圧倒的に有利ってなだけの話なのに
それよりも、どうしてそんなことで悪意に満ちた文章を書けるのか分からないな
一晩寝た後見返して赤面するタイプだな
>>619 はあ?いつ論文の文章の格調高さを競う話になったんだ?
>>587 は英語のほうがプログラミング言語のベースに適している根拠として
後置修飾を挙げているのだから、ならば英語の文章は前置修飾よりも
後置修飾のほうが多いのか?という疑問が出るのは当然だろう。
>>588 が言うように、英語を推す理由が後置修飾がいいというだけならば、
英語よりも後置修飾を多用する言語はいっぱいあるし。
おまえ、顔真っ赤にするのもいいが、もうちょい冷静になったほうがいいぞ。
>>620 数学の話を受けて学術論文の話をしただけで
プログラミングに前置も後置もないだろ
フランス語とか論外にも程がある
342 仕様書無しさん [sage] 2010/02/27(土) 21:34:04 ID: Be: >学歴主義、権威主義であり自分の理解できないもの、新しいものには強い拒否反応を示す。 これこそが生き残る術だよな。さすが、ちんこはよくわかってるよな
一理ある
>>621 > フランス語とか論外にも程がある
理由を書け。
数字、単語の性
>英語のほうがプログラミング言語のベースに適している根拠 やっぱ必要な文字の種類が少なくてすむことかな 漢字の多様さを、欧米語は単語単位で持っているけどな・・・ 後区切り文字がはっきりあることかな・・・日本語解析はムダばかりだ とりあえず英語ができなきゃ、プログラミング能力はかなり伸び悩むだろうな 変数名ひとつ思いつかなけりゃ単純なロジックで混乱するだろうし それでなくとも他人のソース見て綴り間違いだらけだったりしても引く
コンピュータ自体が20世紀にアメリカを中心として発達した産業
IBMもマイクロソフトもGoogleもアメリカの会社
Pascal + Haskell => Paskell
Pascal + Haskell => Phasckel
問題文が英語のプログラミングコンテスト、結構なことだね
Pascal + C = Go
プログラムに英語が必要なのはプログラミング言語のキーワードが英語ベースなのだからじゃなくて、 マトモな資料が英語で書かれたものしかないからじゃないかね。
634 :
デフォルトの名無しさん :2010/03/04(木) 01:59:52
頼むからバグらないようにちゃんとテストしろ糞が ん〜〜どうにもこうにもまこっちゃん! @26歳 汎用系ネットワークエンジニア
テストしてもバグが残るんだろ それとも、テストしないような職場で働いてるのか?
きっとテストがバグってんだよ
テスト環境で出なかったバグが本番で出ることはよくあること 本番環境でテストするべきなんだが稼働中だとそういう訳にもいかない
Smalltalkなら本番環境で動いてるオブジェクトをコピーしてその場でテストできるね。 プロトタイプベースの言語なら動的にテストメソッドを追加したりできる。
640 :
デフォルトの名無しさん :2010/03/04(木) 11:05:46
おまえらは一体何のシステム開発してるの? この中で銀行のATMシステムに携わってる奴いる?
みかんを選別する機械のソフトウェア
642 :
デフォルトの名無しさん :2010/03/04(木) 12:00:31
いいねー 愛媛の農家の人の役に立ててるんですね、わかります
刺身にタンポポを乗せるプログラム
組み込みだからレベル高いな
645 :
デフォルトの名無しさん :2010/03/04(木) 12:17:42
世の女性をモテない男子を好きにさせるシステムとか開発できないんですか?
646 :
デフォルトの名無しさん :2010/03/04(木) 12:22:22
>>645 この1行のソースコードを女にプログラミングさせること
”俺には何の取り柄もないけどお前を好きっていう気持ちは誰にも負けない”
いわゆる愛の言語
647 :
デフォルトの名無しさん :2010/03/04(木) 12:23:49
w
truncate life myself
>>640 ATMなんて基本的にはただのインターフェースだから
ソフトウェア的にはそんなにたいしたことしてないぞ
勘定系のことを言ってるなら今もほとんどの環境が
メインフレームでCOBOLだ
652 :
デフォルトの名無しさん :2010/03/05(金) 09:58:25
やっぱCOBOLか
信号もATMもVB.NETで動いてます。
この先10年も20年も残る言語っていったら、やっぱりCOBOLしかないんじゃないのか?
微妙
COBOLの代替がないからなぁ 以前、一部Javaで置き換えとかあったが、逆に遅くなったからな。
>>656 COBOLが走るマシンがなくなってる可能性があるような
古いNTで動いているのを最近のマシンに仮想マシンで動かしたりとか、 PC-98のソフトをエミュレータで、とか以前からたまに聞くんだけど メインフレームとかってVMで動かせないのかな。そしたらマシンとかいくらでも代替きくよね。 メインフレームどういうのかよくわかってないから適当なこと言ってみたがw
662 :
デフォルトの名無しさん :2010/03/06(土) 01:04:34
サーバーとメインフレームって同じようなものと考えていいんですか? 汎用機系とかオープン系とかいまいちよくわからないんですが 初心者の僕に誰か解説して下さい
ググレカス
>654 yieldを使えない人ハヶ━m9( ゚д゚)っ━ン!!
yieldないなら、ブロックを明示的に引数で受取って(&block)、 block.callになるかな。
ああ、そういうことか。Rubyみたいなやつね
遅延評価
>>668 遅延評価ってのはHaskellとかMirandaみたいのを言うんだよ。
いらん
遅延評価: 死後に評価される天才の悲しさ
評価されると生き返ってしばらく動いて再び停止する けど必ず停止する保証はない 本当の悲しさはそこにある
>>672 ん?
遅延評価なしで終了するものは、遅延評価でも必ず終了することが、
数学的に証明されているが?
遅延評価は参照透明性と関係が深い。 副作用がなく、いつ評価しても値が変わらないなら、 本当に必要になるまで評価を遅らせることができる。
>>673 前提条件がついてるのに「必ず」と言うのはすごい違和感があるなあ
>>675 物事を論理的に考えることが苦手なタイプ?
「前提が証明できれば、結論も証明できる」ってのは楽観的だよな 悲観的に考えると 「前提が証明できないとき、結論をどうやって証明しますか?」ってなる
さあつまらない議論の始まりだ
やはり論理的思考が苦手な人のようだ。
前提が正しいと仮定しなければ議論できない 前提が偽とわかっているのならただ議論は無駄なだけだ
>>680 いや、無駄とは限らん
生かせる場合もある
その前に、前提が偽とわかっていてることと、前提が正しいと仮定することは 同時に起こり得る事象だ。
ともかく前提は仮定するものであって、証明しなければならないものではない。
>>680 おまえ、かなり馬鹿だな。
IF文は無意味か?
if statementのsemanticsはどこで定義されているんだ?
if(IsDoIt()){ DoIt(); }else{ DoIt(); }
ifでもelseでもDoIt()なんだから、そのif statementはDoIt()に書き換えられるな。 で、ifのsemanticsはどこで定義されているんだ?
んまあ前提の下での証明は一抹の気持ち悪さはあるわな 未証明のものはその性質がよくわかっていないわけでその前提の性質を使用して証明するのは気持ち悪い 前提の性質が明快なものは肯定的証明がなされることが多い気はする 遅延評価は内部状態遷移を持ってはいけないと思うが、持っている関数を遅延評価したら止まらないかもしれない しかしそれはバグだ
>>673 遅延評価なしで終了すると仮定すると、もちろん無限リストは使えないよな
どういう前提で遅延評価なしで終了するかという前提が必要だな 更にそれはどういう前提でと以下無限ループ トレードオフだなw
>>690 > んまあ前提の下での証明は一抹の気持ち悪さはあるわな
むしろ前提を明らかにしない証明のほうが気持ち悪いのだが。
>>690 ユークリッド幾何の公理に、
2本の直線が平行ならば、その2本の直線は交わらない
というものがあるが、君の感性だとこの公理も気持ち悪いし、
「2本の直線は平行である」という証明がなければ無意味
ということになるわけだが、正気か?
>2本の直線が平行ならば、その2本の直線は交わらない >というものがあるが、君の感性だとこの公理も気持ち悪いし、 先人もそう思ったから証明しようとしたんだろ 結果非ユークリッド幾何になっちまったが
>>695 > 先人もそう思ったから証明しようとしたんだろ
はあ?公理を証明??
おまえ、終わったな。
スレタイ嫁
>>696 公理ってのは定義で証明すべきもんではないだろ?
むしろ証明できなかったから公理にされたってのが正解だ
論理的に証明できないなら実験するのが普通だ プログラムはテストするのが普通だ
いい加減この板ID必須にしようぜ
このスレは荒れて然るべきだけど、この板には 意味不明な主張するキチガイが湧いて荒れてるスレが確かに多い 言語とか、特定の言語の作法についての暴論があって つっこまずにはいられないんだけど、つっこんだら最後、ずっと荒れるし
>>699 平行線の公理が他の公理より回りくどい表現だったせいで他の公理から導けるのではないか?
という疑いが大昔にあってだな…以下略
>>704 当たり前だがユークリッドは只者ではない
ユークリッドの小売は 5つくらいある。 で、平行線の小売(5つめの小売)は 1〜4つめの小売から導けるのではないか?という疑問があった。 で、証明しようとしたが誰もも導けない。 じゃあ1〜4つの小売は正しくて、平行線の小売だけ成り立たないような幾何学もできるよね?ってエロイ数学者が考えて 実際にできてしまった。 じゃあこれは定理じゃなくて小売だね。 こんな感じだよね。
すべての公理が互いに直交している必要があるのか?
必要はないが、直交しない公理を使って体系を作る意味もない
直行してないなら、どれかが定理になるな。
俺が、定理だ
>>709 どれかの公理の一部分が定理になるだけかもしれない
直交しない公理Aと公理Bがあり、体系が作られているとします しかし、実は直交した公理Cと公理Dと公理Eによって同じ体系を作る(先の体系と命題の真・偽・不明が一致する)ことも できるとします 前者の公理Aは後者においては公理Cと公理Dから導かれる定理であり、 公理Bは後者においては公理CとEから導かれる定理であるとします すると、前者の体系においては、公理Aと公理Bの一部である公理Cが 前者の体系における定理として導かれます。
線形代数で言ってくれ
(1 0 0)と(0 1 0)と(1 1 1)は直交してないが、どれか2本だけでは足りない
BLASとLAPACKはどっちが美しいんだろうな
BLAS
>>703 内容はデタラメでも、テーマの選び方は法則性があるな。
机上の空論になりがちな話題を狙ってくる。
>>718 最悪の場合矛盾してたりとか、
そこまではいかなくても、他の公理から定理として導ける公理があったりとか、
そういう公理系を「直交してない」っていうんでない?
まさか、幾何的な意味での直交だと思われたのではないだろうな。
>>721 そういう意味で「直交」という用語を使われることはない。
少なくとも正しい数学用語では絶対にない。
きっと素人がネットとかで検索して、埋め合わせの知識で使ってるだけだろ。
直交とかorthogonalとかアカデミックな場なら「独立している」という意で普通に使うだろ。
>>723 数学では言わないかもしれないが、情報科学の分野では互いに独立しているの意味で直交という言葉を使う。
ベクトルからのアナロジーで考えても別に変じゃないし
独立なら独立と言えばいいだけ。 無い席を求めてゼロになりはしない。
独立と直交は意味が違う。
用語は普通なのが一番いい 独立が通用しているなら独立、直交なら直交 オリジナリティは不要
連投ご苦労! だから「公理」が「直交」とは絶対に言わないの。 「公理」という数学用語を持ち出してるんだから、 「直交」も数学用語として正しく使えということだよ。 「独立」という意味なら「独立」と書けばいいだけだろ。 何が理由で「直交」に拘るの?どうして間違った用語に拘るの???? ただの馬鹿なの?
直交なんて教養のある人間なら普通に使う一般用語だろ。 別に何もおかしくない。数学の文脈でも普通に使われる。 直交がおかしいと言うのは、投げてないから「連投」じゃない、と言うのと同程度のくだらない言いがかり。
直交はいい言葉だと思うよ。直線の直交じゃないよ。 公理がからみあって定理がたくさんできるのを直交と表現したんでしょ。
俺は某有名大学の工学部の数学科出身だけど、それも実は大学院だったりするけど、 公理も直交というよ。ちなみにユークリッドの場合は並行ね。 もうぎろんしなくいいよ。公理は直交するんだよ。
>>731 >>732 だから、そういう言い方はしないの。しない物はしないんだよ。
君らは「独立」の意味で使ってるんだから「独立」でいいだろ。
なんなの?
>>733 なんだよ、工学部の数学科って?
理学部の間違いだろww
これが教養のある奴の言うことか???
「『公理を直交』と絶対に言わない
>>730 が属するコミュニティー」 と 「『公理が直交』というその他の普通のコミュニティー」 が独立に存在してるんだろ。
話が直行してかみ合わないのはある意味当然。
>>734 「独立」でいいよ。
でも「直交」でもいい。
どちらでもいい。
学部と大学院は別の組織だろ。スレ違い終了。
公理 『
>>734 の世界では、「独立していること」を「直交」とは言わない』
以上
ぐぐった結果 "公理の直交" : 0件 "公理の独立" : 27,200件 "直交した公理" : 1件 (このスレwwwww) "独立した公理" : 531件
公理が独立ってのも微妙だが、公理が直交ってのは明らかにおかしいだろ
>>736 君が思う「その他の普通のコミュニティー」ってのは空集合ということだろ
あ、君が一人いるから、空ではないかw
直交にこだわってる奴って、大学落ちて、 コンピューターの専門学校にしか行けなかった悲しい奴な気がする。
>>743 てっきりソフトウェアと関係ない職業のやつが趣味で書き込んでいるのかと俺は思った
コーシー=シュワルツの不等式でどうのこうのしたことのないやつのタワごと>公理の直交
文系だろうな
「Hになればなるほど固くなるものちーんぽ?(・ω・)」 「えんぴ…はっ?!Σ(゚д゚ )」 「…(・ω・)」 「… (゚д゚;)」 「ちーんぽ?(・ω・)」 「(えぇー…)0o(;゚д゚)」
数学にはデスマがない そんな風に考えていた時期が俺にもありました
公理の直交だと意味はとれなくもないけど 「定理AとBは直交する」だとよく分からない
まあ俺は英語の論文を読むことの方が多いから、 別に直交でも独立でもよいのさ。英語とフランス語では直交という感じなんだよ。 馬鹿なおまえらに合わせるために今度から独立と言ってやるがね。 あと人の学歴とかにケチを付けるのはみすぼらしいことだよ。
>>750 あ、これは俺も同感。
たしかに英語と直交だわ。俺の大学は数学の先生が英語だし、よく聞くわ。
恥の上塗り・・・
>>744 俺も。むしろコンピュータとかには全く興味無い人なんだろうなって思ってた
どっかの数学の本でかじった知識を披露してるんだろうって
直交という言葉はコンピュータの世界で使うけどな。
情報処理で使う直交というのは、 二つの事象とかのパラメータを格子状(行と列からなる表)に並べて、 その交点ごとの値を算出する場合の直交でしょ。 要するに演算方法の説明みたいなもで、これは数学でもありだよ。 直交と用語があるかないではなくて、(というかあるからこそ) 公理の直交というその使い方がおかしいということだよ。
>>753 プログラムと無縁な奴がこんなスレは覗かないかと。
むしろプログラムだけはできる(つもり)で他のところでつまづいてる奴な気が。
仕様です、仕様です!を連発して、すぐに絶対不可能です!って言う奴。
けど他の人がやればあっさりできたりすることが多い。
>>755 そんな場合に直交なんて言葉は使わないだろ。
使うよ。
とりあえず、数学で直交といえば、二つの物が垂直に交わるということであり、 ベクトルなら内積が0になる状態のこと、それ以外の意味で使われることはない。 これは情報処理でも同じだと思うけどね。 表に関して行と列は直交するともいう。垂直だからねw。直交表という言葉も存在する。 この辺から勘違いが発生してる気がするけど。 あと、工学系の情報処理なら、 離散フーリエ変換やアダマール変換とかの直交変換という用語も出てくるけど、 この場合の直交もまさに元の意味の直交でしかないから。直交行列もそうだし。
数学でつかう直交と、情報科学で使う直交は同じだろ。幾何学でいう直交と同じように。
数学板で質問してきた。
どんな質問にもマジレスするスレ(弐)
http://science6.2ch.net/test/read.cgi/math/1262693441/755 755 名前:132人目の素数さん[sage] 投稿日:2010/03/08(月) 14:11:19
>公理が直交しているという言い方は正しいか間違っているか
公理が直交っていう表現は初めて聞いたけど、意味が通じるから良いんじゃないの?
知らないけど。
「直交する概念だ」なんて言い方もあるし。
>・前提は仮定するものであって、証明しなければならないものではない
「P→Q」を示すためにPを証明する必要があるかってこと?
そういう意味なら、その必要は無い。
「P:数学板の利用者は全員ロリコンだ」っていう前提の元では「Q:君も僕もロリコンだ」が成り立つ
つまり「P→Q」は真
実際の数学でも、証明されていない定理を仮定して利用してる論文は沢山ある。
というわけで、これ以上やるなら数学板へ移動ヨロ
>>750 > 英語とフランス語では直交
はたして交差するような概念かい?w
物事の関係が綺麗に直角をなすなどと、
そんなもん探す方が難しい
ベクトルと言えば矢印しか思い浮かばないタイプだな 「割り込みベクトル」じゃない、「割り込みベクター」だ、って必死になったりとかw
「綺麗」というのは美しさを示す尺度であって、「直角をなす」を修飾する言葉としてはふさわしくないとかw
数学体系全体をベクトル空間として捉えた場合の言い方だね→直交 俺以外にもそういう言い方してる奴いたと知って驚いた
発想としてはありがちなんじゃね 考え方を指向性としてベクトルと表現するのは文系でも使うほど結構一般的だし ま、直交は聞かんけどね。理系ジョークっぽい印象を受ける
これ以上続けるなら数学板へ移動しる!
物事の道筋を文じゃなくても「文脈」と言ったりするだろ。 それと同じように幾何学の文脈じゃなくても互いに独立していることを普通に「直交」と言う。 何も特別な使い方じゃない。普通の使い方。
普通普通と連呼してみて宿る説得力などない。
普通じゃない普通じゃないという連呼もな
公理に対して直交という用語を使うのが普通だというのなら、 使ってる事例を出せば? 上でググった結果によると0件だろ? 数学板でも見たことがないと回答されてるし。 言わばこのスレが史上初ななんだろ。これのどこが普通なんだ?????
数学科の奴ってどんなプログラム書くだろ
取り敢えず、バンピーに不適切な言葉を覚えさせてしまった
>>707 ,708は猛省しろ。
自己レスだけど、「バ」ンピーとかアホか俺
数学無知が「公理」なんて単語を使うのがまちがい
779 :
778 :2010/03/08(月) 20:03:30
まちがえました。すいませんm(_ _)m
独立にこだわってたやつも反省しろ。
ちっ、うっせーな
じゃあ本題に戻るか 遅延評価が止まらない場合、どのようにデバッグするのか
質問スレへどうぞ
公理に対して直交という用語を使うのが普通だというのなら、 使ってる事例を出せば?
物理世界をモデリングするプログラミング言語ってないかな。
>>786 シミュレータや3Dゲームのデータはそれに当たらね?
直交とは内積が0であること 内積が定義できれば数学的には同型だから直交の概念も使える
ベクトルの内積なんて高校数学でやるんだから、それがわからないのは文系だとしか思えない やっぱり趣味プログラマだろうな
ベクトルの内積ぐらい文系でもやるだろ。 ところで、OO言語で数値計算するメリットあるのかいな uBLASやらTNTやら、何かと遅くなるだけじゃないのかと
MATLABでオブジェクト指向的に書いてみたら超低速になった
オーバーヘッドがつもりに積もって山になるからな。
やはりCやFortranか 速い言語は美しい
仮想関数の呼び出しの実装方とかみたら、C++でも遅いと感じるよな
機械語 0と1だけ 美しいだろ
796 :
デフォルトの名無しさん :2010/03/09(火) 11:00:25
機械語もCPU内部ではマイクロコードだったりするから、0と1だけというのは単に符号化(見た目)の話かもしれない。 そしたらCとかのプログラムに出てくる文字をアスキーコードの2進数表記にしたら美しくなるのかという話になる。
0と1だけだと余計汚くなると思うんだが
日本語より英語の方が美しいという発想だろうけど、 高級言語で簡潔に表現されている物を 0と1に翻訳したら飛んでもなく長くなって見れたものではない。 美しさの欠片もない。
799 :
デフォルトの名無しさん :2010/03/09(火) 11:20:57
>>798 お前が低能なだけだろ
ハードウェアからやったほうがいいね、君にはソフトは早すぎる
>>799 何が言いたいのかまったくわからんのだが。。。
機械語で直にコーデイングできるようになっていから言え、という意味か?
その次は、紙にパンチで穴を空けるんだ
歴史の勉強かよ
抽象化されているところに美しさを見るのが普通だと思ったが、もっとも抽象度が低いところに美しさを見いだす人もいるようだ。
リンゴを「リンゴ」としてじゃなく、 原子が結合したものが複数集まったの塊として見る。
しかし原子が結合したものが複数集まった塊がリンゴとは限らない
コードやデータを01の組み合わせとして見る。
アセンブリ最強伝説
リンゴis-aスイーツ
まあ、プログラム板でリンゴを例にあげるということは、つまりそんなやつなんだよな
アセンブリならわかる、他の言語との比較もできるし、その書き方で美しさも全然違う。
機械語を美しいと言う奴は、FAXのピーガーという音を聞いて、 いい音色だって言うんだぞ。
笛で電話の無料掛けする世代だな
あの菓子は良く売れたもんだ
パルスコードの電話器のフックを10ppsで叩いてダイアルしたりな
自分でやってみて、あっさり 117 にかかった時は感動したよ
816 :
デフォルトの名無しさん :2010/03/09(火) 16:41:12
メインフレームなんかはCOBOLで書いてるんでしょ?
>>790 整数、有理数、複素数などがシームレスに使える。
>>817 普通の言語が複素数を扱えないから、
OOがカウンターになってるだけ。
C99は普通の言語じゃないか...
820 :
デフォルトの名無しさん :2010/03/10(水) 09:01:35
always @(posedge clk) if(reset) OO <= 8'h0; else OO <= OO+1;
数値計算でパフォーマンスを気にしなければいけないのであれば、 必要なのは並列処理の機能だろう。これが簡単に書けない言語は使えない。 昔は知らんが。
>>821 数値計算では、並列化はコンパイラやライブラリ任せにするから、そんなに必要ないな。
HPF 以外はクソ、か。 それもそれでひとつの見解ではあるな。
>>822 >並列化はコンパイラやライブラリ任せ
何か勘違いしてると思われ
Dは普通の言語じゃ…ないな
>>821 つまりはFORTRAN最強ってことだね
やはり筆算が最強である。
そろばん最強説。
計算尺には及ばんよ
指でいいんじゃね?
そのあたりは言語じゃないのでスレ違い。
exp(πi) = -1 これの美しさを説明してください
美しさを定義しろよ馬鹿
ガウス平面の座標 1 に exp(πi) という変換を施す(かける)と 半回転(πi)して座標 -1 に移る、これはそういう意味の式だ という解説を受けた時、その式よりも解説の仕方に美しさを感じた。
>>832 自然対数の底と円周率という二つの重要な超越数を結びつける唯一の等式。
浮動小数じゃ超越数を表現できないでしょ
>>832 対数の無限多価性を示す一例。835なんて些末なこと。
>>832 は
e^(iθ) = cosθ + isinθ
だったかの特殊なケース
ln(-1) = πi じゃいかんのけ
大学1年の時テイラー展開から求めたでしょ?
テイラー展開による説明が自明でないから美しくない
マクローリン展開で見ると美しい
log10や360度では美しくない理由を発見しなさい。 eを底にする理由とラジアンを単位にする理由はどのように結びつくか。
スレチにもほどがある
美しさの定義
テーラー展開による、なんとなく正しそうで厳密でないな説明 sinxはテーラー展開でx+x^3/3!+・・・ cosxもテーら展開してみましょう ついでにe^xも! で、e^xのxをixとおいてみると なんかcos+isinにならね? みたいな漢字だっけ
まー、テイラー展開教わったら、言われなくてもやってみるよな。
オイラーの頃にはテイラー展開とかマクローリン展開とかは既にあったの?
何の話に脱線してるねん、はよ関数電卓の話に戻さんかい!!
複素数を扱える関数電卓はありますか?
無い訳が無い。
関数電卓といえば逆ポーランド
二度と普通の電卓が使えない体にしてやるから覚悟しろ!
尻P自重w
π**π や π + e のような単純な定数が無理数であるかどうかも分かっていない。
今日はπの日だとグーグルを見て気付いたろ?
はい
でもなんでπの日かわかりません
そこは分かれよ…
いついかなるときも美しくなければいけない。
ホワイトデーだけどお前らには関係ないよな
先月チョコもらったので 明日の件誘ったら断られた そんなつもりじゃないって
┌─┐ │●│ └─┤ _ ∩ ( ゚∀゚)彡 ┌─┬⊂彡 │●│ おっぱい!おっぱい! └─┘ おっぱい!おっぱい!
>865 お前もだよな!
書かれたコードが読みやすい、書かれている処理内容が理解しやすいプログラミング言語は何だろう?
>>869 実行できる擬似コードって頻繁に言われるのはPythonだな。
PerlやRubyに比べると魔法が少ない為に若干コードは長めになるけど。
コードが長くなる時点で、読みにくいコードってことだけどね
>>871 長くなると言っても、Javaみたいにダラダラ長くなるんじゃないよ?
しかも、魔法が要らない単純な操作なら逆にPythonの方が短くなることもある。
たとえば、正規表現なら、専用の構文が用意されていない分長くなるけど、
普通の関数呼び出しのシンタックスだけ理解できればコードを読める。
if ($s =~ /foo/) { #perl
if "foo" in s: #Python
if ($s =~ /fo+/) { #perl
import re
if re.search(s, "fo+"): #Python
>>872 特定言語の話でなく一般論だろ。
簡潔なコードの方が読み易いということも理解できないの?
>>873 「単純な操作なら」とあるけど、
「複雑な操作で」如何に簡潔に書けるかが大事でしょ。
簡潔なコードすなわち分かりやすいコードではない
しかし、使う変数の数や変数名をケチったりなど、 そういうことをしない限りは、簡潔なコードのほうが読みやすく、 変更に強く、バグが少ないとおもわれ。
短い と 簡潔 が同じであるとは限らない。 ソースコードをzlibで圧縮したら短くなっても簡潔では無くなる。 文字当たりの情報量を増やすことが必ずしも簡潔とは限らない。
【審議中】 ∧,,∧ ∧,,∧ ∧ (´・ω・) (・ω・`) ∧∧ ( ´・ω) U) ( つと ノ(ω・` ) | U ( ´・) (・` ) と ノ u-u (l ) ( ノu-u `u-u'. `u-u'
コードの短さより分り易さを優先するなんて普通にあるでしょ
Cの++演算子は、簡潔なコードを書く助けになっているが、分かりにくいコードを生み出す原因にもなる
とりあえずJavaは糞
Javaは良い
>>878 "いろんな言語で宿題"の前スレでそういうテーマを徹底的にやっていた。
極限まで短いJと故意に冗長に説明的に書いたPrologの対照。
>>878 >ソースコードをzlibで圧縮したら短くなっても簡潔では無くなる。
俺にとってperlは圧縮入っちゃってる印象。
短く書けるけど暗合っぽくなる。
>885 それが、たまらなく好きな奴はperlキチガイだよなw perlは他人が書いたソースが時に全く読めない(しかし動作している)のが玉に傷だな。 perlは言語としては好きだけど、美しいとは思わない
rubyは好きだし美しいとさえ思うけど、 ああいうラクに書ける言語は、 ラクに楽しく書いてしまうがゆえに、 後から見るとやや見難いと思う。 どうだろうか。
一理ある
自分が好きな言語の欠点を必死に擁護しているとしか思えん。 欠点は欠点と認めて長所をアピールしなよ。女々しいんだよ。
擁護してるってことは欠点と認識してるでしょ。事後処理なだけ
ここまでのみなさんの意見を総括すると、 C#が一番バランスが取れており、最も美しい言語ということですね。 やっぱりそうですか。。。
windowsオンリーのC#信者が現れたか
へー、美しいプログラミング言語というのは、 Unix 系で走ることが必須なんですね。 汎用性がないと美しくないないと。へーへーへー
当たり前だろ。馬鹿かコイツ
>>893 Windows でもいい、問題がそのコードが美しいかどうかだから。
ばかは、
>>894 だが、Monoもあるし、MSもBSDで動くCLRを一応は出している。
Linuxで動いてフリーでない物は認めないよ それ以外は醜い言語に決まってるだろ 前スレにはそういう条件が書いてあったよ 今後はC#禁止な
ということでC#は醜い言語として認定ですね。
C#はLinuxでもMac OSでもiPhoneのOSでもいけるが。
C#自体はMSの囲い込み失敗言語だろJK
>>900 フリーじゃない物は認めません。
あとMacはシェア殆どないから、関係ないでしょ。
フリーでオープンソースのコンパイラもあるが。
object-Cは割と囲い込み成功言語
>>903 ひつこいな、細かいことはいいんだよ。
MSに金が入ることは間違いないんだろ。
その時点でC#はアウトだよ。
このスレをC#で抽出したら汚いという結論が出た
バカはほっとくけど、 C#がC++を進化させた物でよりエレガントはコードが書けることは認めるよ。 けどその進化の方向(ベクトル)が他の言語と違うから、他の言語と比較が難しいわな。
>>907 それじゃ、俺もお前の言う事は無視するからwwww
フリーのC#コンパイラを使うとMSに金が流れると思うとは、知恵遅れなのか妄想癖が甚だしいやつなのか
開発環境ありきのC#が何言ってんだよ
ただのバカだった。
C#信者が湧いたら終わりだよ 別の質問スレもレス番100台でC#が湧いて、C#最高!で荒らされて結局潰されたからな
C++最高!
F#最高!
>>913 私にはアンチC#が荒らしてるように見えますが。。。
読みやすさでいったら、 VB6で日本語使うと激しく読みやすいよ。 例: Sub 初期化 フォームを開く 提出日に今日の日付をセットする 明細行が20行になるように追加する End Sub
>>870 魔法っていうか、ただの構文糖衣じゃないか
>>919 「邪道」という意味で「魔法」と言ってるんだよ。
Python 信者なんだから。相手にしてもしょうがない。
劣ってることを認めたくないだけだよ。
Pythonはメソッドチェーンをあんま使わないから長くなるってのもある気がする メソッドチェーンは魔法でも何でもないよな? 読みやすさで言っても map(f, filter(pred, xs)) より xs.filter(pred).map(f) のほうが左からそのまま読めて格段に読みやすい Python推奨の [f(x) for x in xs if pred] もやはり評価順とは一致していないし、段数が多くなると 結局メソッドチェーンよりずっと可読性が劣るのが分かる
内包表記で適度に記述を分割するように プログラマを誘導したいんでないの?
Lisperの俺にはメソッドチェインは気持ち悪いな
関数リテラルの地位も低い
静的型付けのScalaですら
xs.map((x) => x * 2)
あるいはもっと短く
xs.map(_ * 2)
とさえ書けるのに、Pythonでは
map(lambda x: x * 2, xs)
こうなる
つまり冗長
>>923 というか、抽象度の低い、泥臭いやりかたに誘導しているのだと思う
早い話がforを使えってこと
どうでもいいけど schemeの (map (lambda (x y z) (+ x y z)) '(1 2 3) '(4 5 6) '(7 8 9))や pythonの map(lambda x,y,z:x+y+z,[1,2,3],[4,5,6],[7,8,9]) はrubyだとどんな風に書けるの? 1行じゃ無理?
三行半
[ [1, 2, 3], [4, 5, 6], [7, 8, 9] ].transpose.map {|x,y,z| x + y + z} でいいのかしら。
[[1,2,3],[4,5,6],[7,8,9]].map{|x| x.inject(&:+)}
>>929 injectはいいとして、君は元のコードの結果を確認すべき。
>>926 どうでもいいけどSchemeのその例は冗長だな
(map + '(1 2 3) '(4 5 6) '(7 8 9))
でいい
Pythonのoperator.addではダメだけど
PythonでSchemeの真似をしたければ map(lambda *args: sum(args), .....) と書かなければならない つまりPythonは冗長
functionalな方向でやりたいのなら、部分適用と関数合成によって メソッドチェーン風に完結でフラットな記述が可能になる筈なんだが、 Pythonの部分適用は陽にfunctools.partial()を呼び出す必要があり 関数合成も compose = lambda f, g: lambda x: f(g(x)) のようなものを自分で定義する必要がある どっちも関数なので、冗長で汚い上にカッコの入れ子構造が残ってしまう つまりPythonはHaskellの真似もできない
まーHaskellじゃないんだし真似してもしゃーない
ま、その通り 趣旨は、Pythonは簡潔でもなければ、その冗長性が見通しのよさにつながっているとも 考えにくい、ということね (map + '(1 2 3) '(4 5 6) '(7 8 9)) map(lambda *xs: sum(xs), [1, 2, 3], [4, 5, 6], [7, 8, 9]) どう考えても下のコードのほうが冗長なだけでなく、読みにくいだろう
なんでこんなに粘着アンチは毎日ネガキャンに必死なんだろうな 周囲の環境を否定することでしか自我を保てない哀れな野郎だ
貶められるのが嫌なら、こんな批評スレに来なきゃ良いのに
最近のPythonだと lambda/filter/mapはdeprecated、代わりに内包表記を使え、 という流れだから意味がない。 比較するなら内包表記でしょ。 (sum(xs) for xs in ((1, 2, 3), (4, 5, 6), (7, 8, 9))) [sum(xs) for xs in ((1, 2, 3), (4, 5, 6), (7, 8, 9))] #まあ、xsなんて名前を付けている点は冗長。
>>935 プログラミング初心者にとってはどちらも、
何のことかわからないよ。
>>938 内包表記では所詮map()とfilter()相当のことしかできないし
多段チェーンさせた場合に可読性がメソッドチェーンより加速度的に落ちる
[ f(x) | x <- xs, pred ]
を
[ f(x) for x in xs if pred ]
と書かせる時点で冗長なことには変わりは無いしな
メソッドチェーンなら
xs.filter(pred).map(f)
で済み、しかも構造がフラットだからいくら繋げても可読性が落ちない
Pythonが内包表記を導入しただけでなくそれを推奨しているのは、
Pythonの作者が抽象度の高い方向性を嫌っているのと、
Pythonのlambda式が中途半端で貧弱だからだろうと思う
メソッドチェーンを導入したところでPythonでは
xs.map(_ * 2)
とは書けないわけだしね
>>> [(x, y) for x in range(3) for y in range(x, 3)] [(0, 0), (0, 1), (0, 2), (1, 1), (1, 2), (2, 2)] とかはメソッドチェーンではどう書くの?
>>941 Ruby1.9にはそのものズバリのArray#product()があるんでなかったかな
つまり
[0,1,2].product([0,1,2])
と書けるんだろう
↓はScalaだけど、もっと綺麗に書けそう
(0 to 2).flatMap((x) => (0 to 2).map((x, _)))
だからメソッドチェーンの嫌いな人に押し付けするのは止めれ
書き方がたくさんある時点で、遠慮させていただきます。
>>943 まあ、
>>870 ぐらいからの議論について、実例を上げて考えていただけなので、
そろそろやめるよw
デカルト積に関しては内包表記は良いと思うよ俺も
>>943 この時点で、言語の客観的な評価なんてできないよね。
君が嫌いだとしても、参考になる人もいるんだよ。
というか自分に取って都合の悪い部分を論理的には反論できず、
嫌いという言葉で誤魔化しているようにしか見えないよ。
>>944 色んな書き方が「できない」言語なんてあるのだろうか
F#ではpipeline operatorを定義していて、関数合成とは別の形で メソッドチェーン風の記述を可能しているね let (|>) x f = x f ぐらいの超簡単な定義だったと思うが、これを使うと xs |> filter f |> map g のように書ける
949 :
948 :2010/03/18(木) 15:17:05
ありゃ - let (|>) x f = x f + let (|>) x f = f x だよなどう見ても
>>942 は答えとして正しくないと思うんだけどな
(0 to 2).flatMap((x) => (x to 2).map((x, _)))
for (x <- List.range(0, 3); y <- List.range(x, 3)) yield (x, y)
内包表記のほうが読みやすいし,(x, y, z)に拡張するのもやりやすいよね
>>950 ああ、題意を間違えてたみたいだね
最後の行については、俺もその通りだと思う
ちなみに
>>935 の実行結果:
(map + '(1 2 3) '(4 5 6) '(7 8 9))
→ (12 15 18)
map(lambda *xs: sum(xs), [1, 2, 3], [4, 5, 6], [7, 8, 9])
→ [12 15 18]
>>938 の実行結果:
[sum(xs) for xs in ((1, 2, 3), (4, 5, 6), (7, 8, 9))]
→ [6 15 24]
なので、話の発端から間違っていると思われる。
>>938 は特に別に発端ではないと思うし、スルーでいいんじゃね
ちなみに
map(lambda *xs: sum(xs), [1, 2, 3], [4, 5, 6], [7, 8, 9])
はまだsum()が使えるからマシな例だな
(map * '(1 2 3) '(4 5 6) '(7 8 9))
と同じものを書きたければ、
map(lambda *xs: reduce(lambda x, y: x * y, xs, 1), [1, 2, 3],....)
こうなるのだから
まあ lambda x, y: x * yは operator.mul で置き換えられるんだが、それでもまだ長い
長い長いって、全部2文字くらいなら満足なのかよ
冗長性が可読性や何かに貢献しているのならいいが、このケースは
単に冗長なだけだろう?
>>878 あたりが言っていることは一般には真だが、
このような例ではPythonコードは単に冗長なだけで、Schemeのほうが簡潔だ
皆さんいかがお過ごしでしょうか。 ストレス解消に煽りに来ている方、十分な睡眠を取って煽ってくださるようお願い申し上げます。 風邪を引く前の予防が肝心です。日々の鍛錬を怠らないようにして下さい。 暇つぶしに来ている方、時間を決めて一時間ごとに十五分から二十分くらいの休息を取られた方が良いと思います。 時間は限られています。あなたの人生はあなたの物ですが、一日中インターネットに没頭している、これはいかがな物でしょうか。 インターネットはあなた様の健康に悪影響を及ぼす可能性があります。 マルチしている方、人を忘れないでください、すべてはたくさんの人の多大な努力と膨大な時間を費やして出来た物でありますが故に、 そのような行為は非人道的行為にあたります。なお九十割はスクリプトで出来ているので、気軽に質問してください。マルチはいけません。 さて、私がこのような事をなぜ申し上げますかというと、この度Goのビルドに成功したが故に存じ上げる次第でございます。 よくよく冷静に考えると、このような開発段階にあり、現段階では実用に適していない「ぼくのかんがえたさいきょうのげんご」は プログラミング言語の学習に適さないと判断させていただきました。今後ますますのご健康とご活躍をお祈り申し上げます。
Pythonの人はlambdaなんて使わないんじゃないかな L = [(1, 2, 3), (4, 5, 6), (7, 8, 9)] map(sum, zip(*L)) def product(L): return functools.reduce(operator.mul, L) map(product, zip(*L))
>lambdaなんて lambdaたんが泣いているぞw
>>959 なるほど、そう書けば十分簡潔だね
もっとも、元の
>>926 の意図的には「これメソッドチェーンでできるの?」
だったと思われるので、
メソッドチェーン向きで無い可変引数mapではなく、単一リストとして与えたほうが
Pythonでも簡潔に書けるというのは皮肉な結果だな
九十割w
>>926 これを見ると、Scheme(LISP)のmapって、
単に高階関数を順番に引数に摘要するだけじゃなく、
引数が複数あるときは(そして高階関数が複数の引数をとるときは)
串刺しのような演算ができるんだね。知らなかった。
Pythonのmapでもできるんだ。
残念ながらRubyのmapはそんなに高性能じゃなくて、
単に高階関数を順番に引数に摘要するだけだと思う。
摘要
結局メソッドチェーンを取るか関数を取るかの違いくらいだよな 俺はダラダラとして見づらいメソッドチェーンより関数を取るぜ
[[1,2,3],[4,5,6],7,8,9].map{|x,y,z|x+10}なんてやってみたら [11,14,17,18,19]が返ってきたんだけど エラーにならないなんて随分恐ろしい仕様だな
何をしたい処理か分からん俺には、PHPが偉大だと思ふ
俺はすべての人口言語と、その発明考案者に拍手を送りたいと思う。
照れるニダ
現時点でもっとも洗練されているのはscalaでしょ
clojure
コードが短く書けることよりも、後から読んでわかりやすい方がいいと思う。 他人が読んでもコードに書かれている内容を理解しやすいのは、どの言語だろう?
Python Haskell
Pythonかな 括弧に苦手意識が無ければLispも読みやすいと思う
Cで中括弧出まくってるんだからLisp丸括弧そんなに多いとは思わないなあ。 人の噂なんて当てにならないや。 でも最後に)))))ってやるの嫌い。美しくない。
例えば最後だけ目を瞑ればどうだろうか
俺はちゃんと全部ネストでそろえてるよ。
Lisp分かりやすい読みやすいってマジ? 型ないし超ダイナミックだしマクロで構文木弄りまくれるし インデントが変なだけでまず読めないし 他人の書いたLispコードどうにかしろとか言われても困る PythonはLispよりはマシだけど、メタクラスだの色々あるし どのみち静的型ほどは読みやすくないなあ
大概はemacs使うだろからインデントは崩れんだろ
F♯だろ
エクセルだと思う。これでテトリスも作れるし。
まぁ実際COBOLなんかではExcelのフローチャートからソース起こせるしな
COBOLだけじゃないけどな
>>983 言語としてはVBAということだよね?
ExcelはGUIに相当するから。
まあVBAも良いんじゃね。特別なにか凄いわけでもないけどな
どの言語で書かれたコードが読みやすいかは、慣れによるものが大きいのかな? 慣れを排除して比較することはできないだろうか。
perlは読みづらい
だれが書いても同じようなものになるのは、読みやすいと一部でいわれている。 COBOLが長寿になれた理由のひとつ。 斬新で巧妙なコードを書くことが困難というのも、利点になることがある。
それがパイソンでつか? で、その試みは成功しまつたか?
大成功
PythonはCOBOLやJavaほど「誰が書いても同じように」はならないと思う
>>990 それじゃ、なんでCOBOLで書かれたものをJavaで書き直そうなんてことがあったんだ
生産性が低いから それでも資産性や実行速度の観点で結局捨てきれないんだけどな
OOPは、ドキュメントがいい加減だったり、設計が不味かったりすると、訳の分からないものが出来上がる。
>>994 SI屋が金儲けがしたいから、いまどきはオープン系の時代ですよJavaですよ
COBOLなんて時代遅れですよと売り込んだからじゃないの
COBOL時代の人はソースが何をしているのかさえ仕様として残さなかったのだろう ソースを読んで何をしてるかわかるなんてのは幻想
このスレは非常に盛り上がったな
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。