[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 10:27 / Filesize : 244 KB / Number-of Response : 901
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【数学者】Haskellはクソ言語【オナニー】



1 名前:デフォルトの名無しさん mailto:sage [2005/09/30(金) 01:34:05 ]
C/C++>>>>(越えられない壁)>>>Haskell

231 名前:デフォルトの名無しさん mailto:sage [2006/06/30(金) 09:46:16 ]
>>230
誤解を招く言い方だったが、俺が指摘したかったのはそこじゃない。
>何より IORefを扱うモナド IOモナドは「副作用」を扱うモナドじゃないか。
違う。「入出力」を「副作用なしで」扱うモナドだ。
ここで言う「入出力」にはIORefの操作なんかも含める。

なんでこの区別にこだわるかというと、
>>210は「Haskellに副作用が無い」という前提で話している。
 だから少なくともこの文脈ではHaskellのIOを副作用と呼ぶのは不適切。
・unsafePerformIOなどによって導入される本物の副作用との区別ができたほうが良い。
という理由から。

232 名前:デフォルトの名無しさん mailto:sage [2006/06/30(金) 12:27:10 ]
ああ、言いたいことは分かったよ。

IOモナドは副作用を陽に扱わない。
Haskellは、副作用を表現するIOモナドを純粋関数的に「繋いで」、mainとして定義するスタイル。
繋いだアクションが逐次実行されることで、実行形式は副作用を伴うプログラムとして動作する。
一方、unsafePerformIO はIOモナドとは違い、Haskellの遅延評価のステップの途中で
本当に「副作用的に」評価される(純粋関数の枠を壊している)。
それを言いたいのは分かった。

>・>>210は「Haskellに副作用が無い」という前提で話している。
> だから少なくともこの文脈ではHaskellのIOを副作用と呼ぶのは不適切。
どうしてその前提が読み取れるのか分からんけど。
というか明らかに IOモナドを副作用を扱うモナドでそ。unsafePerformIOと区別したいのは分かったが。
Haskellで副作用を表現できることはもはや常識なわけで、
「Haskellは副作用を(表面上)追い出した為にIOモナドというややこしい形でしか扱えない。しかし副作用は効率的なプログラムを扱う上で必要悪だよな。もっと簡単にならんのか?」
という風に読んだ。


233 名前:とおりすがり mailto:sage [2006/06/30(金) 22:38:41 ]
・形式的にはHaskellのソースコードの中に副作用を伴う要素は無いものとみなせる。

・副作用をいわば「ランタイム側に追い出す」ための仕組みがIOモナド。
 そういう意味でIOは副作用を扱っているといえる。

(・でも本当に副作用を持つ禁断の関数も実はある。)

ってことでFA?

状態機械の仕様をフローチャート的にではなく構成的に
定義できるのってキモチイイな
do構文使ってると普通の逐次処理言語とあまり変わらないけど。
まあ気分の問題で。

234 名前:デフォルトの名無しさん mailto:sage [2006/06/30(金) 23:03:53 ]
>do構文使ってると普通の逐次処理言語とあまり変わらないけど。
そう。というかlet文も考えようによっては逐次型っぽい。

for文やwhile文がなくて、オブジェクトのアップデートができない事を除けば、
手続き型言語も関数型言語もそんなに変わらない。
更にHaskellは純粋関数的なので順序を気にしなくていいんだけどね。


235 名前:とおりすがり1 mailto:sage [2006/06/30(金) 23:52:32 ]
fib = 1:1:zipWith (+) fib (tail fib)
= 1:1:2:3:5:8:12 ....

これはおなじみHaskell版フィボナッチ数列
遅延評価の例として一度はお目にかかるという。

これはリストのある要素の値を
遅延評価を利用して
同じリストの手前の要素から構成しているのがミソ。

#解説は「フィボナッチ Haskell」 でググるといっぱいでてくるので略

236 名前:とおりすがり2 mailto:sage [2006/06/30(金) 23:55:06 ]
で話かわってmain関数の値の話。

これって要するに最終的には

main = (IO a) >>= (IO b) >>= (IO c) >>= (IO d) ......

というふうに(IO x)を>>=でつないだ数珠繋がりに簡約されるわけで。

(IO x)中にはキー入力とか、画面出力とか、メモリの上書きとか
逐次処理言語の命令コードやサブルーチンのようなものが詰まってる。

>>232とかで言ってるアクションてやつ
ちなみに(return x)で作った(IO x)はNOP(何もしない)が入ってるとみなす。


237 名前:とおりすがり3 mailto:sage [2006/06/30(金) 23:59:14 ]
>>236のミソは
ループや分岐に相当する(IO x)は無いってこと。

なぜそれでこまらないのかというと、

フィボナッチ数列のときに
ある要素を決定するのにそれより前の要素の値を利用したように

条件分岐で次の処理として(IO y)を繋げようか(IO z)を繋げようか決めるのに
それより前の(IO x)の値をみて決める事ができるから。
あるいはそこで打ち切ってプログラムを終了してもいい。

つまり、Haskellで副作用のあるプログラムを書くってことは

フィボナッチ数列を定義するように
コマンド列を定義しているようなもの

238 名前:とおりすがり4 mailto:sage [2006/07/01(土) 00:03:08 ]
とまあ
そういう風にオイラは理解したわけです。

239 名前:デフォルトの名無しさん mailto:sage [2006/07/01(土) 06:11:52 ]
合ってると思うっす。



240 名前:デフォルトの名無しさん mailto:sage [2006/07/01(土) 06:30:18 ]
>>232
>どうしてその前提が読み取れるのか分からんけど。

>「Haskellは副作用を(表面上)追い出した為にIOモナドというややこしい形でしか扱えない。しかし副作用は効率的なプログラムを扱う上で必要悪だよな。もっと簡単にならんのか?」
>という風に読んだ。

そう読めるのに気付かなかった。

入出力のことを副作用と呼んでるようだが、副作用とは式の簡約の過程で入出力を行うことであって、
入出力そのもののことではないだろ。
それとも、「副作用」という言葉をそういう意味で使うことを支持する典拠があったりするのか?

多くの言語では、入出力を扱う唯一の方法が副作用なわけで、入出力と副作用を混同してもさして問題はないだろうが、
そうでない言語(たとえばHaskellやClean)の話をするときはちゃんと区別して話したほうが良いと思う。

>というか明らかに IOモナドを副作用を扱うモナドでそ。
>>231に書いたように「副作用なしで」IOを扱うためのモナド、とするのが普通だと思う。
How to declare an imperativeから引用
>This section relates the monad approach to input-output to four other widely used
>approaches: synchronised streams, as used in earlier versions of Haskell; continua-
>tions, as used in Hope; linear types, as used in Clean; and side effects, as used in
>SML.

241 名前:デフォルトの名無しさん mailto:sage [2006/07/01(土) 08:52:27 ]
手続き型言語の代入でも、裏で全メモリの値を渡してると考えれば副作用ではないな

242 名前:デフォルトの名無しさん mailto:sage [2006/07/02(日) 00:07:46 ]
>そうでない言語(たとえばHaskellやClean)の話をするときはちゃんと区別して話したほうが良いと思う。
なるほど、完全に同意しましたです。すまない。

更に How to declare an imperative の文がとてもわかりやすい。ありがとう。
入出力、といえば副作用と思っていたけど、同期ストリームもそうだよな。
自分ではhGetContentsくらいしか使わないけど。
linear typeで入出力ができるのもCleanのマニュアルの序章で分かる(world as value)。
しかし。。。continuationでどうやって入出力するのか??


>それとも、「副作用」という言葉をそういう意味で使うことを支持する典拠があったりするのか?
あなたが言うように、副作用と入出力を混同していた。典拠はない。


243 名前:242 mailto:sage [2006/07/02(日) 00:15:21 ]
誤解を招くと悪いので少し書くと、hGetContents自体の型は Handle -> IO StringなのでIOモナド。

ただ、hGetContentsから得たStringは遅延評価の度にファイルやネットワークデバイスから読み出される。
(データがなければブロックする)
この「遅延読みString」を処理する部分は旧来のストリーム・プログラミングっぽい(よね?


244 名前:デフォルトの名無しさん mailto:sage [2006/07/06(木) 22:15:48 ]
C言語だと言語仕様として再帰は32回までしか保証しない(だっけ)とかだから、
再帰による33回目の関数呼び出しとそうでない呼び出しで意味が大きく変わってくる。

245 名前:デフォルトの名無しさん [2006/07/06(木) 23:06:29 ]
>>244
うそつけ。Cの仕様書にそんなこと書いてないぞ。

246 名前:デフォルトの名無しさん mailto:sage [2006/07/07(金) 04:38:43 ]
何かそういう類いのあった気がするよ。
for のネストの回数とか意外なものに、
最低保証回数が仕様として決められている。

247 名前:デフォルトの名無しさん mailto:sage [2006/07/07(金) 06:46:28 ]
つ[5.2.4 Environmental limits]
だが、再帰回数はない。

248 名前:デフォルトの名無しさん mailto:sage [2006/07/07(金) 08:25:32 ]
そうなのか。

249 名前:デフォルトの名無しさん mailto:sage [2006/07/07(金) 08:32:38 ]
>>244
少し考えれば、再帰を32回まで完全保証する事が不可能だって分かるだろ。



250 名前:デフォルトの名無しさん mailto:sage [2006/07/08(土) 09:19:47 ]
へ?不可能なの?スタックさえ確保しておけばいいんじゃねーの?

251 名前:デフォルトの名無しさん mailto:sage [2006/07/08(土) 09:22:30 ]
>>249
ああ、確かにそうだな。

252 名前:デフォルトの名無しさん mailto:sage [2006/07/09(日) 01:07:02 ]
>>250
ローカル変数がスタックに取得される仕様だと
消費されるスタックの量が予測できないだろ。

ローカル変数と配列の最大数×配列サイズの制限?から再帰の
最大数を決めてもあまり意味があるとも思えない。

ローカル変数をスタックに取らないといけない決まりも無いけど
ほとんどの実装で受け入れられないモノを標準仕様を
するわけにはいかなかったんだろう。

ってスレ違いごめん

253 名前:デフォルトの名無しさん mailto:sage [2006/07/09(日) 20:45:30 ]
ローカル変数のスタック上のサイズは固定でしょ。言語にもよるけどCやC++ならそう。
そんなことも分からんやつしか居ないの?


254 名前:デフォルトの名無しさん mailto:sage [2006/07/09(日) 21:39:50 ]
もっと優しく言ってくれ

255 名前:デフォルトの名無しさん mailto:sage [2006/07/09(日) 21:49:20 ]
おれにはツンデレでお願い

256 名前:デフォルトの名無しさん mailto:sage [2006/07/09(日) 22:30:35 ]
し、Cの言語仕様にスタックなんて概念は規定されてないんだからねっ!

257 名前:デフォルトの名無しさん mailto:sage [2006/07/09(日) 22:34:52 ]
>>244-256
スレ違いの議論はこの辺で終了して下さい

258 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 00:31:31 ]
>>253
だからその固定の変数を最大いくつ宣言できるか判らないでしょ

259 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 02:01:36 ]
さらにC99だとスタック上の配列のサイズは実行時に決定できる。
すれ違いなのでこの辺までにしとこう。



260 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 06:35:50 ]
>>259
>>256

261 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 12:53:18 ]
>>259
偉そうに大嘘で締めないように。無能はしゃしゃり出ちゃいやん。

ま、スレ違いだからやめとくか。

262 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 13:38:02 ]
ここは一応 Haskell 本スレじゃないから、
少々脱線した所でどうでもいい気もするけどね。

263 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 13:52:49 ]
少々なら良いけど3日も続くとね…。
面白い話でもないしw

264 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 22:01:26 ]
>>260
細かいな。記憶クラスが auto の配列って言えばいいのか?

>>261
C99のマニュアル読んでね。

265 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 22:17:04 ]
げ。知らなかった。
int a[hoge()];
なんてやっても動くじゃん。
いままで関数内で捨てちゃう配列にmalloc使っていたのは無駄だったのか。

HaskellとRubyばっかり使っていたせいで、Cはメモリ管理がめんどくさい言語
だとばかり思っててちゃんと調べてなかった。

266 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 22:31:16 ]
C99 じゃないと無理だけどな。

267 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 22:34:35 ]
Cは99なのにHaskellはまだ98なのかー

268 名前:デフォルトの名無しさん mailto:sage [2006/07/10(月) 22:46:53 ]
>>264
しかしそう言い直した途端にスタックの話じゃなくなる罠。

いつまでもひきずってもつまらんので、Haskellの豆知識でも。

GHCでコンパイルされたプログラムがスタックをどのように使うかはわかりにくい。
再帰呼び出しでスタックが深くなっているようにも見えないのにオーバーフローを起こしたりする。
これは、スタックの消費が、呼び出しの深さではなく正格な関数の適用のネストの深さに比例するためだ。
例えばg x = x + 1 - 1 + 1 - ..たくさん.. - 1という関数を定義すると、呼び出しの深さは一であるにも関わらず
スタックを大量に消費する。正格な関数である(+)と(-)の適用が深くネストされているからである。

269 名前:デフォルトの名無しさん mailto:sage [2006/07/11(火) 09:42:39 ]
スタックが足りなくなったら適当に評価を行って遅延してるのを減らすとか
できないの?




270 名前:デフォルトの名無しさん mailto:sage [2006/07/11(火) 11:27:31 ]
>>264
嘘を拡大するためだけに前言撤回で復活しなくてよろしい。

271 名前:デフォルトの名無しさん mailto:sage [2006/07/11(火) 19:11:00 ]
>>269
未評価の式はヒープに保存されているので、それ自身はスタックを消費しない。
スタックが溢れるのは式を評価しようとしたとき。

272 名前:デフォルトの名無しさん mailto:sage [2006/07/14(金) 00:15:50 ]
>>271 スタックあふれた時はヒープ上にスタックを移動して計算したりできないの?

273 名前:デフォルトの名無しさん mailto:sage [2006/07/14(金) 01:15:45 ]
>>272
なんで俺らがそこまでしなきゃいけないわけ?お前何か勘違いしてない?

274 名前:デフォルトの名無しさん mailto:sage [2006/07/14(金) 01:28:55 ]
スタックが溢れそうなのにヒープに余裕があるなどと思ってる素人はモノ喋んな。

275 名前:デフォルトの名無しさん mailto:sage [2006/07/14(金) 03:16:34 ]
・・・

276 名前:デフォルトの名無しさん mailto:sage [2006/07/14(金) 11:25:17 ]
頭が良くない人ほどすぐ怒る

277 名前:デフォルトの名無しさん mailto:sage [2006/07/14(金) 17:56:55 ]
>274は50年前の世界からやってきた時空の旅人

278 名前:デフォルトの名無しさん mailto:sage [2006/07/15(土) 19:52:26 ]
>>277
♪ぼくらは たびびと
 ときの たびびと♪

279 名前:デフォルトの名無しさん mailto:sage [2006/07/16(日) 04:35:58 ]
Haskellは、お利口さんに見られたいけど誰もそう見てくれない
哀れな人たちの嫉妬を一身に買って出てるよね。



280 名前:デフォルトの名無しさん mailto:sage [2006/07/16(日) 14:04:58 ]
嫉妬というか、そういう奴らがすがるための言語。
知的な奴は、そういうことを考えずに自己拡張しまくりのLispを使う。

281 名前:デフォルトの名無しさん [2006/07/18(火) 13:14:51 ]
諸君議論しているかね?

282 名前:デフォルトの名無しさん [2006/07/19(水) 01:50:46 ]
Haskell 面白そうなので調べていたら、Clean にたどり着いた。
両方とも、ちょっとしか解ってないが、現時点ではClean の方が良さげに思える。
でも、一般的にはHaskell の方が流行ってるみたい…。
なぜなんでしょう?

Haskell の方が良い!という人の意見が聞きたいです。

283 名前:デフォルトの名無しさん mailto:sage [2006/07/19(水) 02:56:48 ]
ttp://groups.google.com.au/group/comp.lang.functional/msg/c09cb40a66558a19
個人的にはCleanって閉鎖的な印象を受けるからHaskellに流れてるだけ。
どっちも元はMirandaだからCommon LispとSchemeくらいにしか違わないんじゃないの?と
ろくすっぽCleanを知らないで書いてみる。

284 名前:デフォルトの名無しさん mailto:sage [2006/07/19(水) 03:02:04 ]
ま、素人はそう考えるわな。

285 名前:デフォルトの名無しさん [2006/07/19(水) 03:58:51 ]
最新ニュース 【教育】国際数学オリンピック 中国が全員金メダルで3年連続世界1位 2位ロシア、3位韓国 日本は7位も過去最高成績
1 :ネットナンパ師φ ★ :2006/07/19(水) 02:23:23 ID:???0
news.searchina.ne.jp/disp.cgi?y=2006&d=0718&f=national_0718_002.shtml
imo2006.dmfa.si/results.html によると、順位は 1中国 2ロシア 3韓国
4ドイツ 5アメリカ 6ルーマニア 7日本 8イラン 9モルドバ 10台湾 11ポーランド 12イタリア
13ベトナム 14香港 15カナダ 16タイ 17ハンガリー 18スロバキア 19トルコ 20イギリス
【ニュー速+】news19.2ch.net/test/read.cgi/newsplus/1153243403/

(以下参考情報)
インド人は、あんだけ人間いて夏季オリンピックで銅1個しか取れない劣等民族。
自慢の理系でも数学オリンピックは毎年中国が優勝。アメリカが2位。この2国が指定席で、インドなんてランク外。
ja.wikipedia.org/wiki/%E5%9B%BD%E9%9A%9B%E6%95%B0%E5%AD%A6%E3%82%AA%E3%83%AA%E3%83%B3%E3%83%94%E3%83%83%E3%82%AF
数学オリンピックの日本の輝かしい成績
1995年:1位-中国、2位-ルーマニア、3位-ロシア、4位−ベトナム、5位-ハンガリー
1996年:1位-ルーマニア、2位-アメリカ、3位-ハンガリー、4位-ロシア、5位-イギリス
1997年:1位-中国、2位-ハンガリー、3位-イラン、4位-ロシア、アメリカ
1998年:1位-イラン、2位-ブルガリア、3位-アメリカ、ハンガリー、5位-台湾
1999年:1位-中国・ロシア、3位-ベトナム、4位-ルーマニア、5位-ブルガリア
2000年:1位-中国、2位-ロシア、3位-アメリカ、4位-韓国、5位-ブルガリア、ベトナム
2001年:1位-中国、2位-アメリカ、ロシア、4位-ブルガリア、韓国
2002年:1位-中国、2位-ロシア、3位-アメリカ、4位-ブルガリア、5位-ベトナム
2003年:1位-ブルガリア、2位-中国、3位-アメリカ、4位-ベトナム、5位-ロシア
2004年:1位-中国、2位-アメリカ、3位-ロシア、4位-ベトナム、5位-ブルガリア
2005年:1位-中国、2位-アメリカ、3位-ロシア、4位-イラン、5位-韓国

なお参加資格は高校生までです。今すぐではなく次世代、次次世代に効いて来るものです。
それが教育の深さ、恐ろしさ。

286 名前:デフォルトの名無しさん [2006/07/19(水) 05:09:41 ]
みなさんやっぱり頭がいいんですね。

287 名前:デフォルトの名無しさん mailto:sage [2006/07/19(水) 05:20:57 ]
>>285
数学オリンピックでは中国とか凄いんだけどねえ。
なぜか欧米の方が偉大な数学者は多いよね。
インドだってラマヌジャンっていう大天才がいたし。



288 名前:デフォルトの名無しさん [2006/07/19(水) 10:28:12 ]
だって数学オリンピックって数時間で処理できるような、簡単な問題を
いかに処理しきるかっていう官僚的作業だろ?
それでも俺には逆立しても解けないが。

ノーベル賞フィールズ賞取る様な何年もかけて倒す仕事とはスケールが違い過ぎるから

1kmレースを3速ギアでトップで駆け抜けたからといって
そのマシンが300kmレースを6・7速ギアでトップでゴールできるわけじゃない。

289 名前:デフォルトの名無しさん mailto:sage [2006/07/19(水) 10:57:38 ]
>> 284
非素人の見解披露希望。



290 名前:282 [2006/07/20(木) 02:58:24 ]
>>283
英語、苦手でして…。
単語を拾い読みしてみましたが、Haskell は研究用で Clean は実用言語という所でしょうか?

>>284
ぜひ、具体的意見をお聞かせ下さい。

291 名前:デフォルトの名無しさん mailto:sage [2006/07/20(木) 20:36:18 ]
Cleanは実行速度速いよ
メモリも食わない
Haskellは遅い

292 名前:デフォルトの名無しさん [2006/07/21(金) 00:42:59 ]
Cleanで
echo 'main = readFile "b.txt" >>= putStr . show . (\x->x*x*x) . read'> c.hs && echo 4 > b.txt && runghc.exe c.hs
これと同じことやってみ。

293 名前:デフォルトの名無しさん [2006/07/21(金) 09:36:40 ]
>>288
は、数学オリンピックについて何も知らない。

294 名前:デフォルトの名無しさん [2006/07/21(金) 09:39:46 ]
Microsoftが開発中の新しいシェル「Windows PowerShell」は、RC1版以前は
「Microsoft Command Shell(開発コード名:Monad)」という名称が付けられていた。

295 名前:デフォルトの名無しさん mailto:sage [2006/07/21(金) 09:48:28 ]
英語が苦手だとHaskellやCleanの新しい機能をすぐに使えないので楽しさ半減だろうと思う。
nobsunみたいに和訳してくれる人は普通とても少ないし。

296 名前:282 [2006/07/22(土) 03:36:21 ]
>>292
なる程、Haskell の利点としては
@スクリプト言語的な使い方ができる
AIOモナドだと簡潔に書ける
といった所でしょうか。

@の使い方は面白いかもしれませんね。

Aはどうなんでしょう?
エラー処理とかを考慮したプログラムも簡潔に書けるのでしょうか?

297 名前:282 mailto:sage [2006/07/22(土) 03:38:17 ]
>>295
今の所、基本的な事を覚えるだけで、アップアップですw

298 名前:デフォルトの名無しさん mailto:sage [2006/07/22(土) 05:01:32 ]
Haskell
 関数型言語のスタンダードという役割を担うために作られた言語。
 だから、関わっている人が多いし、ライブラリも多い。

Clean
 関わっている人が少なく、ライブラリも少ない。
 異端であるがゆえに、最新の話題がCleanから出てくることはほとんどない。

という違いもある。
勉強目的ならHaskellだな。

Haskellといえばモナドだけど、Cleanでも同じようなロジックで書ける。
両者の違いは構文糖衣的な違いで、中身は似たようなもの。
Cleanで書くと、たらい回す変数を山のように書いて、文字数が2倍ぐらいになる。
Haskellはプログラムが美しい、Cleanは実行速度が速い、と言える。

299 名前:デフォルトの名無しさん [2006/07/23(日) 00:13:15 ]
もっと最適化しろよハスクル



300 名前:デフォルトの名無しさん [2006/07/23(日) 00:15:44 ]
カレー食いたくなった

301 名前:デフォルトの名無しさん mailto:sage [2006/07/23(日) 00:52:36 ]
コンパイル時間をもっと短くしろよハスクル

302 名前:デフォルトの名無しさん mailto:sage [2006/07/23(日) 01:34:55 ]
あらいぐまハスクル

303 名前:282 mailto:sage [2006/07/23(日) 02:53:12 ]
>>298
なるほど…。
なぜ、Haskell の方が一般的なのか、解ったような気がします。
ありがとうございました。

304 名前:デフォルトの名無しさん mailto:sage [2006/07/30(日) 10:30:01 ]
ヒアドキュメント無いんだったらクソ認定

305 名前:デフォルトの名無しさん mailto:sage [2006/07/30(日) 10:58:56 ]
確かに欠陥だ。
次版で入らんかな。

306 名前:デフォルトの名無しさん [2006/07/31(月) 18:40:18 ]
自己記述してるからコンパイラが低速なんだろ?

307 名前:デフォルトの名無しさん [2006/08/02(水) 17:42:50 ]
諸君議論したまえ

308 名前:デフォルトの名無しさん [2006/08/03(木) 20:24:15 ]
諸君怠けてはいないか?

309 名前:デフォルトの名無しさん [2006/08/04(金) 16:48:43 ]
諸君夏休みかね



310 名前:デフォルトの名無しさん mailto:sage [2006/08/05(土) 13:39:27 ]
本物のプログラマはHaskellを使う
itpro.nikkeibp.co.jp/article/COLUMN/20060801/244812/

記事のタイトル、センス無い

311 名前:デフォルトの名無しさん mailto:sage [2006/08/05(土) 15:42:44 ]
> 最後にこの連載のタイトルの由来を紹介しておきましょう。
> 「本物のプログラマはHaskellを使う」というタイトルは
> 「本物のプログラマはFORTRANを使う」や「本物のプログラマはPascalを使わない」
> といった有名なフレーズをもじったものです。

って書いてあるじゃんか。自分が知らない読んでない理解できないからって
不当に他人を卑しめるのは止めような。

312 名前:デフォルトの名無しさん mailto:sage [2006/08/05(土) 16:30:56 ]
そういうもじりが安直だって言ってんじゃないの?

313 名前:デフォルトの名無しさん mailto:sage [2006/08/05(土) 16:53:19 ]
そんなに悪いとは思わないけどな…
「本物のプログラマはHaskellを使わない」のほうがしっくりくると言われればそうかもしれないが。

314 名前:デフォルトの名無しさん mailto:sage [2006/08/05(土) 17:45:17 ]
「本物のプログラマはPascalを使わない」で語られる本物は、
決してHaskellなどという"軟弱な"言語なぞ使わんと思うんだが?

315 名前:デフォルトの名無しさん mailto:sage [2006/08/05(土) 20:09:59 ]
310のリンク先の情報処理学会のページ、おもろいな
まだ少ししか読めてないけど

316 名前:デフォルトの名無しさん mailto:sage [2006/08/05(土) 20:33:27 ]
本物のプログラマはPASCALを使わない

参考
ja.wikipedia.org/wiki/%E6%9C%AC%E7%89%A9%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC%E3%81%AF%E3%83%91%E3%82%B9%E3%82%AB%E3%83%AB%E3%82%92%E4%BD%BF%E3%82%8F%E3%81%AA%E3%81%84
www.genpaku.org/realprogrammerj.html

317 名前:デフォルトの名無しさん mailto:sage [2006/08/06(日) 00:46:32 ]
この人のサイトが痛いのは本人の趣味嗜好の問題だから放っておくとして、
一昔前のgauche-devel-jpでのshiroタンとのやりとりを見る限りコンピュータの
アーキテクチャの根本が理解できていない人としか思えなかったんだが。
まぁHaskellと戯れているうちはデータがメモリ上でどう表現されているかなんて
知らなくても生きていけるってことかな。

318 名前:デフォルトの名無しさん mailto:sage [2006/08/06(日) 01:08:00 ]
ハードに近いことは良くわかってないけど何となくプログラミングできている、ってのは文系出プログラマの得意技。

319 名前:デフォルトの名無しさん mailto:sage [2006/08/06(日) 09:28:30 ]
Haskellの美しさにあてられら未熟な若者だ。
優しく見守ってやれ。




320 名前:デフォルトの名無しさん mailto:sage [2006/08/06(日) 16:03:48 ]
>>317
似た名前だと思っていたら、あれと同一人物なのかよ……。


321 名前:デフォルトの名無しさん mailto:sage [2006/08/07(月) 00:56:53 ]
同一人物、なんだろうねぇ…。
偶然一致するようなハンドル名なのかどうか判断できないから確証はないけど。
未踏にも顔出してたと思ったけど、どんな成果だったのかな。

322 名前:デフォルトの名無しさん mailto:sage [2006/08/09(水) 18:27:04 ]
何これ? あわててブラウザを閉じたぜ。
ttp://page.freett.com/shelarcy/

323 名前:デフォルトの名無しさん [2006/08/10(木) 09:03:14 ]
だれかヒアドキュメントの機能をcommitしてきてください。

324 名前:デフォルトの名無しさん [2006/08/10(木) 18:39:34 ]
グラスゴウスケールって医療用語であるけど
グラスゴウハスケルと似てるね

325 名前:デフォルトの名無しさん mailto:sage [2006/08/11(金) 01:41:09 ]
>>324
うわぁっ、すごぉっ、すげぇー!って、日常用語にあるけど、
グラスゴウスケールと似てるね。



326 名前:デフォルトの名無しさん [2006/08/11(金) 07:51:06 ]
ということは
うわぁっ、すごぉっ、すげぇー!

グラスゴウハスケルは似てるわけか

327 名前:デフォルトの名無しさん mailto:sage [2006/08/16(水) 20:04:53 ]
問1

「うわぁっ、すごぉっ、すげぇー!」を使って
長文を作りなさい

328 名前:デフォルトの名無しさん mailto:sage [2006/08/17(木) 05:51:34 ]
それを見て、あるいは、変なものだ。うわぁっ、すごぉっ、すげぇー!
むやが及ん、すべてが、と思った。うわぁっ、すごぉっ、すげぇー!
不要なら、それが、それを出してきたところでもないのなのだ。うわぁっ、すごぉっ、すげぇー!
まだ比べできて、この本にもある。うわぁっ、すごぉっ、すげぇー!
すでに、人を手をするのを出している、バカな気が、この本のせいと、一歩だと思うんだ。うわぁっ、すごぉっ、すげぇー!
0001200-ROM人は、もう一つの問題になるので、ついにこれには、ホントには、下の時代にはその時のせいをつくるなものを読んでいるのも、それはそれを92020202/1創作連中所持とかの時代にもある。うわぁっ、すごぉっ、すげぇー!
あるいは物語もあった。うわぁっ、すごぉっ、すげぇー!
なお、その号のこともずっとさておきけれど、感じ。うわぁっ、すごぉっ、すげぇー!
プロットをすると、という感じ。うわぁっ、すごぉっ、すげぇー!
で、すでにシャープに、ほとんど無節操ないのかな。うわぁっ、すごぉっ、すげぇー!
短距離では、その戦時のお解釈年前の大解決冷や汗指標はほとんど開かかとかを手をもらった芸ばかり。うわぁっ、すごぉっ、すげぇー!


329 名前:デフォルトの名無しさん mailto:sage [2006/08/17(木) 10:12:37 ]
ちょwww



330 名前:デフォルトの名無しさん mailto:sage [2006/08/17(木) 22:03:17 ]
>>328
日本語による近代美術だ

331 名前:デフォルトの名無しさん mailto:sage [2006/08/18(金) 17:06:46 ]
解読できたらごほうびをあげるわ






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<244KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef