訃報: Haskell設計者Paul Hudak氏 45
ストーリー by headless
訃報 部門より
訃報 部門より
純粋関数型プログラミング言語 Haskellの主要な設計者の一人として知られる米イェール大学教授のPaul Hudak氏が4月29日、白血病のため62歳で死去した(Yale Daily Newsの記事、
イェール大学の発表、
本家/.)。
Hudak氏は2009年12月に白血病と診断され、2010年には幹細胞移植を受けていた。2013年1月までの闘病の様子は、The Yale Haskell GroupのHudak氏の個人ページに記載されている。6年近い闘病生活を続ける間もセイブルック・カレッジの寮長を務め、キャンパスでの活動にも積極的に参加していたそうだ。亡くなる数週間前にも、学生がHudak氏のために開催したアートイベントに参加しようとしていたという。
Hudak氏は2009年12月に白血病と診断され、2010年には幹細胞移植を受けていた。2013年1月までの闘病の様子は、The Yale Haskell GroupのHudak氏の個人ページに記載されている。6年近い闘病生活を続ける間もセイブルック・カレッジの寮長を務め、キャンパスでの活動にも積極的に参加していたそうだ。亡くなる数週間前にも、学生がHudak氏のために開催したアートイベントに参加しようとしていたという。
Haskell 使ってみて (スコア:1)
Haskell 5年ぐらい趣味でこつこつ使っているが、いまだに使えているレベルに達していない。
遅延評価、純関数型言語、カリー化とかかっこいいとおもってはじめたけど、なんか実際書いたりすると、自分の頭のレジスタが足りなくて、全然エレガントにプログラムを書けない。
といか、Haskell使っていると自分がばかなのがわかってがっかりする。
頭いい人にはいい言語なのかもしれない。
Re:Haskell 使ってみて (スコア:1)
同志がいた。
頭にかかる負荷が高すぎて、完成させるのも精一杯です。
もっと自然に抽象化できる人でないと使いこなせないのかな。
# プログラムは余裕をもって作れ。
# 全力で作ってしまったら、誰がそれをデバッグするんだ?
Re: (スコア:0)
言語に依らずその現場での流儀にのっとったプログラムを書くのは特に難しい話ではないと思っている。ある程度の基礎知識は必要だけど。
周りに現実的なサンプルがない状況とそれがある状況って結構ちがうよね。実際課題が与えられて、書かざるを得ない状況で書いてみれば意外と書ける。
参考書は理想しか教えてくれないし。
求められているレベルかどうかとかその後正しく消化してちゃんと書けるようになるかはその先の話。
現場のコードが理解できないなら勉強不足。
でもどの程度の知識が妥当かわからないから一人で勉強してても自信につながらないだよね。そのあたりは真面目な人ほどできるのに門を叩けないというのはあるかも。
# なんちゃってSEは無駄に自信だけあるので「いや、それ書けてるって言わないよ？」ってレベルでも自信もっちゃったり。
割とオフトピックだが (スコア:0)
これを機にHaskellに触れてみようと思う。
# 関数型言語はLispとPythonしか触れなかった
Re: (スコア:0)
以下、Pythonが関数型言語かどうかの議論
Re:割とオフトピックだが (スコア:2)
クラウド時代に習得すべき言語10選 [zdnet.com]
4. 「Clojure」数学言語
リアルタイムでデータストリームを処理する「Apache Storm」は、Clojureで記述されている。関数型言語は手続き型言語と違って、セミコロンが不要だ。このClojureスクリプトでは、セミコロンはコメントにしか使われていない。
＞関数型言語は手続き型言語と違って、セミコロンが不要だ。
Re:割とオフトピックだが (スコア:1)
FORTHは一応関数型言語だけど, 関数定義の末尾がセミコロンですけどね.
セミコロンの有無が関数型かどうかを示す指標になるのは, ALGOL系統の言語の特徴じゃないですかね.
Re: (スコア:0)
>セミコロンはコメントにしか使われていない。
これを言いたかっただけにしか見えない
Re:割とオフトピックだが (スコア:1)
確かに、セミコロンを連呼しているし、そう主張しているようにしか見えない。
Nick Hardiman氏の原文 [techrepublic.com]からそうなのか。面白いこという人ですねぇ。
とはいえ、言語はともかく、クラスを使った時点で関数型じゃないなくなると思います。
メンバー変数を使った時点で内部状態を持つことになるし、
class的なもの多用せざる得ない言語は、関数型言語とは言えないでしょう。
Re: (スコア:0)
おっとOCamlの悪口はそこまでだ
Re: (スコア:0)
BASICが関数型言語だったとは、初めて知った。
Re: (スコア:0)
セミコロンがないと、改行してしまいますよ
Re: (スコア:0)
おわり
Re: (スコア:0)
Haskell は面白い言語ですよ。
私は、C++ や Java がメインな人だったのですが、Haskell の学習は、
いろいろカルチャーショックを味わえてエキサイティングな体験でした。
木構造のアルゴリズムから攻めると分かりやすいと思います。
でも、未だにモナドはよく分からないんですけどね…orz
Re:割とオフトピックだが (スコア:1)
これ [adit.io]をみて、やっとこさモナドとアプリカティブとファンクタがセットで分かった低能の俺様がとおりますよ。
Re:割とオフトピックだが (スコア:2)
しかし Haskell の Set は Functor ですらないという悲しい現実。
Re: (スコア:0)
モナドの分かりにくさは、うまい例がないところにある気がする
実際のところ、処理がつながっているものはみんなモナドなのだが
Re:割とオフトピックだが (スコア:1)
うまい例がないどころか、モナドの例はあらゆるプログラミングのなかに溢れかえっている
だってリストはモナドなんだよ。
こんな単純で身近な例があるのに「うまい例がない」という人は、モナドを理解していないとしか思えない
Re:割とオフトピックだが (スコア:2)
僕の場合、 Haskell を使っていても、リストがモナドだと意識してコードを書くことなんてあまりないんだけど。リストはモナドの例ではあってもモナドの「うまい例」ではないと思う。
Re:割とオフトピックだが (スコア:1)
他人に説明するための例えなんだから、「リストはモナド」で伝わらないなら、たとえあなたにとって自明でも例えとしては意味がないのでは？
Re: (スコア:0)
基数と順序数と実数が「ぜんぶ数」だと言ってもうまい喩えがないようなものですな
ちなみに「リスト」はモナドではない
Re:割とオフトピックだが (スコア:1)
ちなみに「リスト」はモナドではない
俺が「リストはモナド」と言っているのはこのことを指しているんだけど
http://www.sampou.org/haskell/a-a-monads/html/listmonad.html [sampou.org]
君が「リストはモナドではない」というのは何の事を言っているの？
Re: (スコア:0)
それは「HaskellのListモナド」
HaskellではListを用いて非決定性をもつ計算の連鎖を実現しているとうこと
一般的にリストはモナドではないし(そもそも意味をなさない)、モナドの理解のためにHaskell特有の事情を例に挙げるのも相応しくない
Re: (スコア:0)
一般的にリストはモナドではないし(そもそも意味をなさない)
ある特定の言語でリストモナドの実装が標準ライブラリに存在しないことを指して「一般にはモナドはリストではない」と君が言いたいなら、君の中ではそうなんだろうけど、
それこそ、特定の言語、特定の実装を指さずに「一般のリスト」「一般のモナド」「一般の言語」についていう場合は、
「一般には」リストはモナドだというのは正しい。
モナドの理解のためにHaskell特有の事情を例に挙げるのも相応しくない
いや、これHaskell特有でも何でもないけど。例えばScalaの例。
http://eed3si9n.com/learning-scalaz/ja/List-Monad.html [eed3si9n.com]
標準ライブラリにモナドのフレームワークがある言語は稀だ
Re: (スコア:0)
やはり、悪い例から始まるといつまでたっても理解ができないようです
「リストのモナド」ってさあ、自分で言ってて意味が通らないと思わないの？
なんでモナドの性質を書くべきところに「リスト」なんて実装がくるわけ？
HaskellでList(これは、Haskellの型のListのことです)がモナドなのはモナド則を満たすようにしているからで、それ以外の理由はない
Listを直接Monadのインスタンスにせず、ListをnewtypeしてそっちをMonadのインスタンスにすることは可能だし、その場合Listはモナドではなくなる(もちろん独自にモナドにする場合は別)
> モナドというのは抽象的なフレームワークであって、
およそモナド則を満たすものがモナドであって、それ以外の一般論はないし、フレームワークでもない
Re: (スコア:0)
なんでモナドの性質を書くべきところに「リスト」なんて実装がくるわけ？
モナドを説明するときには、まず性質を説明すべきで、その後で具体例を説明すべき。
それは元コメもわかっていて、だからモナドを理解するためには「良い例が欲しい」しかし「良い例がない」と言っているわけだ。
話を戻すが、ここでの論点は「リストのモナドのインスタンスを実装して、モナドを説明するのは説明として適切かどうか」。
俺は「関数型を知らない人でもデータ構造としてのリストはよく知っているし、モナドのインスタンスを実装して見せるのも簡単だから、説明に適している。リストを実装して見せるのは「良い例」だ」といっている。
それなのに「リストモナドが標準ライブラリにない言語もある。リストのモナドインスタンスには他の実装もある。だから「一般には」リストはモナドではない」というズレた指摘をし始めたから、話がズレてるんだけど。
およそモナド則を満たすものがモナドであって、それ以外の一般
Re: (スコア:0)
さらに言えば、あなたの言ってる「「一般的に」リストはモナドではない」というのも、俺は意味を理解している。
Javaの標準ライブラリにはListクラスがあるが、標準ライブラリにはそのListのモナドのインスタンスはない。
だから、一般に「あるソフトウェアでソースコードにリストが定義されていれば、そのモナドインスタンスもソースコードに定義されている」は正しくないし、
その意味で「「一般的に」リストはモナドではない」というのも意味は通る。
ただし、我々の論点は「リストのモナドを実装して見せることは、説明に適しているか」であって、
俺の言っている「リストはモ
Re: (スコア:0)
なんども言うようだが、「非決定性中略モナド」というのはあるけど、「リストのモナド」というものはない
非決定性モナドをリストで実装するのは遅延評価のhaskellだからうまくいくけど、ほかの言語だとeagerなリストよりlazyなEnumerableとか使うんじゃないの
余談だが、「リストの各要素を並列処理するモナド」というのもありそうだが実はない
なぜないのか説明するのかは実はけっこう難しい
Re:割とオフトピックだが (スコア:1)
#2808317 [srad.jp] は三行でまとめようとして失敗した、まで読んだ。
Re: (スコア:0)
私はHaskellは軽くかじった程度でモナドに対する知識は乏しいのだけど、
> 俺は「関数型を知らない人でもデータ構造としてのリストはよく知っているし、モナドのインスタンスを実装して見せるのも簡単だから、説明に適している。リストを実装して見せるのは「良い例」だ」
ということで「リストはモナド」というのは（リストというものが各種言語で一般的すぎるがゆえに）まず間違いなく誤解を生むので、せめて「Haskellのリストはモナド（則を備える？）」と言うべきかと思う。
私なんかは普段使うC#とかpythonとかCの双方向リストで考えてしまうので。
（と、聞いて「それらのリストとHaskellのリストは違うから、Haskellの話だから」と思うのであれば、なおさら「Haskellのリストは」と前置きしてほしい。それらのリストでもやはりモナドなのならあなたの書き方がふさわしいと思う。）
Re: (スコア:0)
リストや配列の各要素を並列処理する場合にはコモナドというのを使うといいらしい
コモナドはモナドのreturnとbindのかわりに
class Comonad c where
extract :: c a → a
extend :: (c a → b) → c a → c b
となっていて、
http://www.cl.cam.ac.uk/~dao29/drafts/codo-notation-orchard12.pdf [cam.ac.uk]
> Comonads are the dual structure to monads, where a comonadic data type
C has operations for the composition of functions with structured input, of type
C a → b. Whilst monads capture impure output behaviour (side effects), comonads
capture
Re: (スコア:0)
あなたQiitaから追い出された人でしょ
Re: (スコア:0)
「モナドにはうまい例がない。なぜなら、例えお前は理解できても、俺に理解できないならそれは悪い例でしかないからだ」というのは、
例えば「この寿司屋には食い物がない、なぜなら、例えお前は寿司が好きでも、俺は寿司が嫌いで食べられないからだ」と言ってるも同然。
確かに、「俺が理解できない例は意味が無い。俺はどれも理解できない。だから俺が悪いのではなくて例が悪い。「良い例」がない」と主観的に決めつけて放り出す相手には意味が無いな。
でも、一見理解しにくそうな例でも、「俺が理解できないのは俺の勉強が足りないせいだ。他の例とも合わせて理解を深めよう」という
謙虚な姿勢で望む人間には意味がある。
「例が理解できないのは例が悪いんじゃなくて、そいつの理解力が足りないんじゃね？」と漏らしてしまいそうだけど、
まあそんな事言ったらそいつが怒りだしそうだ。
Re: (スコア:0)
きみ、マックブックを持ってカフェに出かけて開発してる雰囲気がしますね。
Re: (スコア:0)
すげえな、これだけの文章からそんなことまでわかるのかよ。お前マジでエスパーだな
あと俺はマックブック持っていないし、カフェでコードを書いたこともない。
だからそのコメント見て俺どんな顔したらいいかわからん
Re: (スコア:0)
こういう、初学者が興奮めいて語るような極論って
相手をおいてきぼりにしてナンボなところがありますからね。
ムキになって食い下がらず徹底的に突き放すべきでしたね。
Re: (スコア:0)
モナドというのが、虎を出してくれたらなんとかすると待ち構えている
一休さんだからではないでしょうか？
屏風から出す方が圧倒的に大変だしそれは一休さんだって分かって
いるはずです。
話が将軍さまの冗談話に頓知で答えるのならともかく、それをするのが
大変です困っている場面での頓知だと、和尚さんに本気で怒られる場面
だとおもいます。
部分計算ならそれはそれで、ワークテーブルを使うとか手が有るはずで、
モナドとか、なにか冗談話にしか聞こえないんですよね。
Re: (スコア:0)
例を示せば理解できるというものではない、のがモナド。
関数も取りうる値の列挙に対する可能性の計算としてのリストモナドインスタンス、失敗する可能性のある計算としてのMaybe,Eather,Option,Optional,、将来の計算としてのFuture,Promise,Taskなど、これらの実例をそれぞれプログラムの動作として完璧に理解したとして、またそれはたいして難しいことではないが、それらすべてを包括する抽象的な共通概念モナドを体得するためのもう一段のギャップがある。
そういう意味で「うまい例」はない、と言ってるとしたら同意。
あるいは抽象概念としてのモナドは意識せず、させず、個別の実例だけ理解しておけばいいと言うのは一つのあり得る、ある意味現実的な立場でもある。Scalaは、あるいはhaskellとScalaz以外はほとんどその立場。
しかしそれでは、モナドの真の力、合成などの力を得ることはできない、とモヒカン族は思うのだ。モナドトランスフォーマーが使えないのはクソだと。、
Re: (スコア:0)
> それらすべてを包括する抽象的な共通概念モナドを体得するためのもう一段のギャップがある。
いっそコンピュータから離れて、自然言語も料理も人間のあらゆる意味ある行為にはモナドを見いだせるというところから始めた方がいいかもとは思う
Re: (スコア:0)
ここでの長々とした解説合戦を読めば読むほど
モナドはモナドであることがわかってきました。
要はtanashinnやキムタクと同じことなんですね！
Re: (スコア:0)
オフトピックどころか、非常にHaskellらしいツリーが出来上がりましたね。
Re: (スコア:0)
訃報の記事を見るといつも、この程度のやつが死んだからっていちいち記事にするなよ
とおもってたけど、ここまで知らない人だとむしろどういうとだったのか興味がわく。
Re: (スコア:0)
記事投稿は13時32分、この1getは19時39分。
6時間もの間、何の書き込みもなし。
これぞスラドニッポン。
やっぱり最終的には金を稼げる奴 の み が偉い。
根底を支えてる人間なんか興味ないよな。