  |
はてなキーワード: FORTRANとは
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 80 | 14223 | 177.8 | 48.5 |
| 01 | 78 | 6595 | 84.6 | 47.5 |
| 02 | 29 | 5712 | 197.0 | 46 |
| 03 | 26 | 1939 | 74.6 | 44.5 |
| 04 | 9 | 558 | 62.0 | 55 |
| 05 | 35 | 2225 | 63.6 | 29 |
| 06 | 29 | 2715 | 93.6 | 49 |
| 07 | 40 | 2290 | 57.3 | 27 |
| 08 | 76 | 5077 | 66.8 | 32.5 |
| 09 | 79 | 7893 | 99.9 | 46 |
| 10 | 90 | 7336 | 81.5 | 44 |
| 11 | 42 | 3779 | 90.0 | 38.5 |
| 12 | 63 | 8268 | 131.2 | 35 |
| 13 | 94 | 9035 | 96.1 | 33 |
| 14 | 82 | 11118 | 135.6 | 46.5 |
| 15 | 110 | 10424 | 94.8 | 35 |
| 16 | 95 | 7515 | 79.1 | 46 |
| 17 | 81 | 7994 | 98.7 | 44 |
| 18 | 61 | 7997 | 131.1 | 39 |
| 19 | 95 | 5841 | 61.5 | 32 |
| 20 | 69 | 6908 | 100.1 | 46 |
| 21 | 101 | 7978 | 79.0 | 41 |
| 22 | 124 | 8646 | 69.7 | 27.5 |
| 23 | 109 | 11659 | 107.0 | 34 |
| 1日 | 1697 | 163725 | 96.5 | 39 |
人(163), 自分(127), 今(79), 話(71), 増田(58), 仕事(57), 感じ(52), 問題(51), 好き(45), 普通(44), 前(43), ー(42), 必要(42), 人間(42), 日本(41), 女(41), 金(41), 会社(41), 今日(41), ワイ(37), 子供(36), 親(35), 場合(35), あと(35), 気(33), 関係(32), 理解(32), 意味(31), 言葉(30), 結婚(28), しない(28), 漫画(27), 最初(27), 最近(27), 他(27), じゃなくて(26), 昔(26), 人生(26), ゴミ(25), 生活(25), バカ(24), 相手(24), 結果(24), 目(24), 嫌(23), ネット(23), 理由(23), 女性(23), 時代(23), ただ(23), 時間(23), 意見(22), 無理(22), 人たち(22), 頭(22), 逆(22), 一番(22), 時点(22), 子(21), 誰か(21), 心(21), 世界(21), 気持ち(21), 大人(20), 別(20), 作品(20), しよう(20), 他人(20), 馬鹿(19), 映画(19), 社会(19), 絶対(19), イメージ(19), 男(19), 興味(19), 可能性(18), 存在(18), いや(18), 前提(18), 否定(18), 音楽(18), 全部(18), 結局(17), レベル(17), ダメ(17), 状態(17), 体(17), お金(16), 説明(16), バイト(16), 大学(16), とこ(16), 場所(16), 評価(16), 動画(15), アニメ(15), 内容(15), わからん(15), 一人(15), 趣味(15), 車(15), 宣伝(15)
増田(58), 日本(41), ワイ(37), じゃなくて(26), 可能性(18), わからん(15), アメリカ(14), なのか(12), 社会的(11), バズ(10), 明石(10), Twitter(10), KKO(10), マジで(10), 上念(9), 元増田(8), バツイチ(8), 個人的(8), 基本的(8), O(8), バイトテロ(8), IT(8), ツイート(7), バカッター(7), 労働者(7), 安倍政権(7), ツイッター(7), 被害者(7), SNS(7), togetter(7), ガチ(7), OK(7), バズる(6), スマホ(6), 普通に(6), にも(6), キモ(6), いない(6), フェミ(6), くら寿司(6), …。(6), 東京(6), いいんじゃない(6), ブコメ(6), 金(6), 中国(6), 窓ガラス(6), hatena(6), 2人(6), 竹中(5), 難易度(5), アレ(5), 1年(5), 100円(5), 社会人(5), 1日(5), 骨伝導(5), 外国人(5), なんだろう(5), コンプライアンス(5), 毎日(5), はてブ(5), イケメン(5), DQN(5), E3(5), 10年(5), 昭和(5), プレイ(5), 2018年(5), 一般的(5), HTML(4), リテラシー(4), youtube(4), 日銀(4), 何度(4), 自分たち(4), エビデンス(4), 文化的(4), 沖縄(4), 親権停止(4), 自己肯定感(4), 1枚(4), 著作権(4), コンプ(4), 漫画家(4), ブクマカ(4), ID(4), 自分語り(4), 毒親(4), 責任感(4), 平成(4), 東大(4), ？？？(4), 娘(4), twitter(4), 1人(4), 一緒に(4), 私自身(4), 長期的(4), パワハラ(4), 仕方がない(4), バレンタイン(4), PHP(4), 支持層(4), コスパ(4), ちんこ(4), 2019年(4), リフレ(4), 専門学校(4), wiki(4), 最低賃金(4), 盗んだバイクで走り出す(4), リアル(4), 個人情報(4), JK(4), s(4), 自民党(4), 韓国(4), 短期的(4), アプリ(4), 従業員(4), 所謂(4), はてなー(4)
上念(9), 骨伝導(5), 親権停止(4), 所ジョージ(3), バイトテロ(8), リクライニング(3), スーパー戦隊(3), 明石(10), インフレ率(3), 尾崎(3), ロックンロール(3), FORTRAN(3), O(8), バズる(6), ないや(8), 一理(6), エビ(5), 昇進(5), ファミコン(4), 機嫌(12), コンプ(4), HTML(4), 死体(8), 免許(10), 安倍政権(7), 壊し(10), バンバン(6), 宣伝(15), バイク(6), 商業(7), 在住(5), 背景(11), 音楽(18), 政権(8), 才能(11), 労働者(7), 感動(9), 姿勢(8), 寿司(8), ワイ(37)
■音楽に興味のない人がいる事が信じられない /20180830212442(14), ■「盗んだバイクで走り出す」に熱狂していた若者 /20190211125224(12), ■三大「タイトルと同じセリフは出てこない作品」 /20190211015951(11), ■「猫の死体が落ちているので片付けてください」 /20190210210506(10), ■こういうおかしな日本語使う奴ってなんなの？ /20190211113616(9), ■例の商業漫画の宣伝手法にモヤっとする人は「情報を食っている客」と同じ /20190211202811(9), ■自分で自分の機嫌をとるってどういうこと？ /20190211155935(8), ■ゲイとかレズとか /20190209223617(8), ■運転免許持ってない人間は無理なの？ /20190211004721(8), ■ブーメランとかバーミヤンみたいな言葉 /20190211165151(8), ■増田でバズりたい /20190211154630(8), ■なに枠なのかよくわからないタレント /20190211114208(7), ■ /20190210150520(7), ■どうかしてる高校生バイトの話 /20190211003451(7), ■リクナビに求人出してる弊社 /20190211153558(6), ■はてなニュータウン案 /20190210145018(6), ■ /20190210080232(6), ■アニメ趣味って持たざる者の趣味だよな /20190211173734(6), ■睡眠時間が短い人ってどう思う？ /20190211213900(5), ■ /20190211131826(5), (タイトル不明) /20190211174732(5), ■最近の映画は女が死んでばかりなのか検証してみた。 /20190202160657(5)
勝手にジョークぶちあげて揚げ足取られたら話の筋道をそらすのは如何な論法かと思うけどね、ジョークならジョークで完結させろよと言いたいが、「それはジョークだじゃあ話を元に戻そう」、これでいいのでは？それとも子供に対してCPUのことを計算してくれる装置ですよと語りかけるが如く丁寧懇切に連立方程式の解き方からBLASの存在まで説明しろとおっしゃるのかな？
それは筋が通らない話だと思うし議論する気があるなら最低限・・そうだな大学がならう数値計算とか並列計算機の授業のレジュメをさらっと目を通すぐらいはしたらどうでしょうか？
https://www.cspp.cc.u-tokyo.ac.jp/hanawa/class/sp20180925.pdf
うーむHPCに対するアプローチは二通りあって情報工学的に計算機科学の一環（つまりスパコンを作る側）として見るか、1科学者としてのシミュレーションを行う場、仮想実験場（スパコンを使う側）としてる見る場合の2つのアプローチがあると思うのだけど・・・PEZY-SCを搭載したシステムに関しては前者、計算機科学の成果としてみるべきシステムだと思うのよ、これの成果としては「非GPUで超メニーコアシステムを実現すると共に高効率なシステムを構築することに成功した」って言う一つの事実に集約されると思う。
でここで高効率なシステムの基準はなんなのかとというと「HPL」と言うベンチマークですわな、HPL=LINPACKと言う認識で話を進行させるけど、HPLは本来連立方程式の求解を行う速度を競うベンチマークであって、これを皆が手放しで賞賛してるのはおかしいと言う批判が存在する。
これは一理あってすべての科学技術計算の性能向上に寄与する指標とは言いがたいからだ。
じゃあなんでこれが推されている居るかというと理由は何個かあるけど連立方程式の解を求める必要のある技術計算はとても多いから、昔からやっててデーターが揃ってるから
ここまででHPLが重要視されている理由がご理解いただけると幸いなんだけど・・じゃあ具体的に連立方程式を使用する場面を示せよと言われると腐るほどあってどれを示せばいいのかわあらんのですが・・
http://www.cs.kyoto-u.ac.jp/wp-content/uploads/2012/07/05hori.pdf
まああんまり人様の研究をあれこれ紹介して間違った説明しても申し訳ないので中身には触れないでおくけど実際に連立方程式は最もシェア率が高い問題であると言う認識は持ってくれると
話が早い
まあさっきのXeonでいいじゃんって話も一理あって性能が低くてもx86_64時代のコードそのまま使いまわせるし、さっきあげたユーザー側から見た時楽ちんであるのは事実だ。
なによりintel C++/Fortranコンパイラと言うクソ便利なものがあってライセンス料払うとある程度勝手に高速化してくれたりするし使いまわせるコードも多い
まあPEZY-SCよりXeonのほうが計算機を研究してるわけじゃない物理学者とかの各種研究者エンジニアからすれば魅力的な点が多いのは事実だと思う
だからと言って計算機科学としての計算機の純粋な性能向上を主とする研究・開発成果を邪険にしていいわけないしまた別の問題、確かに商業ベースで考えたとき
これらの問題をどうにかしないといけないのは事実だし改善して行かねばならないのはPEZYやエクサスケーラーの各位に残された課題であるのは間違いない。
だが少なくともまだこの世に銀の弾丸となりうる万能システムは存在しない。
もしあるなら俺にくれ あといい加減なこと言ってたらゴメン、強いひとに殴ってもらうと筋トレになる
プログラマやってるけど、昔話を聞くに、本当に隔世の感があると思わされる。
だって昔のプログラマの仕事って、入念に机上デバッグされたフローチャートを、ただひたすらCOBOLかFortranかアセンブラに翻訳して、コーディングシートに書くだけの仕事だったんでしょ？
フローチャートで書ける程度のロジックなんて全然難しくないので、シートを書き終わった時点で事実上プログラムは完成したに等しいと。
あとはパンチしてもらって、テストは大抵一回動かすだけで全部問題なく通って一丁上がりと。
そりゃ月残業300とか働くのも決して不可能じゃないし、それだってハイになった勢いでガシガシ書けるだろう。
そうやってカネがっぽり稼いで、日々のモヤモヤは酒タバコ麻雀パチンコ風俗でスッキリさせて、そんでまた思いっきり働く。それが男だろ！ってノリだよな。
仕事で懇意になってるパンチャーのお姉ちゃんと裏で仲良くなって、そのまま付き合って…なんてのも普通にアリだろう。
今はもう、あらゆることが複雑になりすぎて、設計だってUMLとER図で対処できるかすら怪しくなっている。
言語だってJavaだけじゃなく、SQLやら、HTMLにCSSにJavaScriptと心得てないと仕事にならない。
そして何より、動かして試して、都度直していかないと分からないことだらけになっている。
プログラマの脳にかかる負荷は昔と比べ物にならない。当然あまりに長時間の労働は事実上不可能。
俺は残業100まで行った所で帯状疱疹が出て、シャワーで腰をさすりながらココらへんが限界と思い知らされた。それが10年前。
勿論今はもっと無理が利かない状況。
でも、残業300可能な時代を、色んな会社で現役として駆け抜け出世した幹部オヤジ達に、今のプログラマが抱えているアレやコレやらは、多分理解できない。
それくらい、時代が変わりすぎたのだろう。見えている世界が違いすぎる。
だから今の若い奴らを根性無しとして完全に見下しているし、本音では「なんだよ急に辞めやがって使えねーなー」とか「アイツ死にやがった、ざまあwww」と思ってる、人でなしの老害ばっかり。
勿論Fortran→C/C++→Javaみたくスキルを身につけてきた人は例外だけど、本当に例外中の例外でめったにいない。
それで「昔のままのノリじゃ、今の開発は絶対に稼げない」ということに思い至らない。
他の時間は読まないです。
2. 「ごめん」という代わりに「バカヤロー」と言ってみる。
謝る必要がないのに、毎回謝ってしまい、謝りすぎてしまうという問題を抱えていました。今でもそうです。そうなってしまうと、何をするのも謝ってしまい、受け身になってしまいます。自信がなくなって他の人から受ける評価も下がってしまいます。だって、すべてのことに謝っているんですから。
なので、意識的に「ごめん」の代わりに「バカヤロー」というようにしてみたんです。
3. タグを置くのではなく、片づける。
鍋から直接食べるのはそろそろやめましょう。
5. 2分で済むのであれば、やめてしまう。
2分もかかるのなら諦める。
一貫性をもたせるのは、認知行動療法（CBT-I）でもとても大事とされています。
確実に人生が変わる。
8. 丸々1年間、小銭はすべてレジで出す。
そして起きたときには忘れる。
増田。
13. できるだけ長く眠る。次の日も続ける。そしてその次の日も。
できれば二度と起きない。
14. 家を出る前に毎朝布団にもう一度入る。
そして二度寝をする
15. 何かをやめるのではなく、新たに買う。
そして部屋がジャンクであふれる。
野菜350gも。
大企業や銀行で、昔から動いている基幹システムは、大抵メインフレームにCOBOLの組み合わせである。
それをここ十年くらい、リプレースでx86系サーバにJavaという構成に変更することが多い。
しかし、ハードが汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。
ぶっちゃけCOBOLはCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは？と思うのだ。
その理由はこうだ。
COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。
勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOLの文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである。
そういうモノが既にある企業や銀行の文化において、当然発注側は担当者からお偉いさんまでCOBOLer系フローチャート脳だし、新しいシステムの設計でもそれを踏襲しようとする。
というか踏襲すること前提じゃないと設計書をレビューできない。
UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。
というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法の設計書で処理を組み上げざるを得なくなる。
そうなると、実装もフローチャートの設計を基にコードを書くわけだが、こういう設計はハッカー文化で発展してきた言語(Fortran→C/C++→Javaという流れと、PerlからPython・PHPというインタプリタ系の諸言語)との相性が最悪である。
設計とは実装を楽にするために書くのに、これらの言語において、フローチャートの設計は役に立たないどころか、邪魔でしかない。
だからFortranしかなかった頃から、本物のプログラマ達はフローチャートをdisってきたわけである。
ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である。
しかし、「普通の人達の普通の思考」からはかけ離れ過ぎているという意味で、「普通の人達の普通の仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。
…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLかアセンブラを選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。
というわけで、自分はCOBOLからのリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。
プログラミングって、これから始めてみようっていうとき、なんだか「得体のしれない行為」っていう感覚がありませんか？
ぼく自身は、プログラムを書いてる側の人間で、いまでこそ少しはプログラミングの本質的な難しさをわかってる気になってます。でもつい数年前までは、プログラミングは難しくはないけど得体がわからない、という感じでした。
そのへんのコードを組み合わせて動くものはできるけど、何がどうなっているのかは知らんし、ググって分からないものはできない、という方向で、「プログラミングは難しい」と思ってました。
最近になって、プログラミングの義務教育必修化の話題とか、コピペプログラマーの話題とかを目にするたびに、かつて自分がプログラミングに対して抱いていた「得体のしれない行為」という感覚が思い出されてしまい、少しざわざわした気持ちになったので、ちょっとここに書きなぐらせてください。
だいたいが個人的な話なので、そういうのがうっとうしい人は無視してください。
ぼくが世の中にパソコンという道具があることを知ったのは、たぶん中学生のときです。30年くらい前。当時、電気屋の売り場ではけっこうな床面積を使ってワープロ（文章を入力する専用マシン）が陳列されてました。文章を書くのは好きだったけど、字を書くのが死ぬほどめんどくさかった自分は、ワープロさえあれば自分も小説とか書くのになあと思いながら指をくわえて電気屋の店内をうろうろしてました。しかし、ファミコンすら買ってもらえなかった家計ではワープロなんぞ買ってもらえるわけもありません。そのうち巡回してた電気屋からはワープロが消え、それに代わってパソコンのコーナーが広がっていきました。このパソコンというのは、よくわからないけどワープロとして使えるっぽいし、どうやらファミコンを持っていない僕にもゲームができるらしい、おれに必要なのはこれだ、というわけで、中学生だった自分はパソコンという存在に興味を抱くようになったのでした。
とはいえ、だからといってパソコンを買ってもらえるような家計ではなかったわけなので、カタログを熱心に眺めるだけの毎日が続きました。その当時の自分にとって、パソコンが欲しいといったら、それはNECを買うかエプソンを買うかという選択でした。冨士通からパソコンが出ていることは知りませんでした。マッキントッシュっていうやつもあって、このPerformaっていうやつはなぜか安いとか、よくわからないけどシャープとかソニーも独自にパソコンを作っているぞとか、そういう情報がパソコンに対する認識のすべてでした。当時の自分にとってのパソコンは、電気メーカーから発売されている商品の一種であり、ラジカセとかテレビと同列の存在でした。
なんでこんな話がプログラミングにつながるかというと、ひょっとして自分がプログラミングにずっと感じていた「得体のしれなさ」の源泉の一つは、こんなふうにパソコンを電化製品として見ていた当時の感覚の延長だったのかもなあと思ってるからです。
ラジカセなら、CDだのテープだのを入れて再生ポタンを押せば、そのハードウェアの機能を物理的に体感できます。それに対してパソコンは、プログラミングをちょっとやってみても、その行為と、そのハードウェアとが、感覚的に結びつきません。もちろん、プログラミングというのは、物理的なデバイスに結びつけて考えなければできない行為ではありません。しかし、パソコンを「カタログの商品」として見るところから入ってるばかりに、そこでやるプログラミングという行為とハードウェアとの結びつきが見えにくい状態に、なんとなく居心地の悪さを感じていたように思うのです。
もし自分のスタート地点が、パソコンを使って文筆やゲームをするところだったら、パソコンは文筆やゲームのための箱だったでしょう。その後でプログラミングを始めていたなら、プログラミングという行為を、文筆やゲームに関連した創造的な活動として学べたかもしれません。
ところが実際には、自分はつい数年前まで、パソコンという電化製品に対する漠然とした行為としてプログラミングを捉えてた気がします。
プログラミングを始めたのは、高校生になって誰も使わないFM77が部室に置いてあったので立ち上げてみたらF-BASICのインタプリタが起動したからでした。とくに何をプログラミングすればいいかもわからなかったので、教科書や雑誌のコードを転記したり、ループで線画を書いたりして遊んでいました。大学に入ってからも、授業でFORTRANとかLispをやらされたけど、基本的に自分で目的をもってプログラミングするのは数値計算くらいのものでした。そのころになると、本で情報を探して（まだインターネット検索は使い物にならなかった）適当にコードをつなぎ合わせるのがプログラミングだと思ってました。そんなん面白くないなあ、とも思ってました。
この感覚、完全に、いま揶揄されているコピペプログラマーのそれだったと思います。ちょっと話はそれますが、ブロック遊びとか砂場遊びって、ほとんどの人はわりとコピペプログラミングと似たような感覚でやってるんじゃないでしょうか。パーツを勘で組み合わせたり、とにかく砂を盛っていったりすれば、家みたいなのができるよね、という感覚。プログラミングは、自分にとってそれに近い作業でした。学生のころは、内心、自分にもパソコンとサンプルコードさえあれば何かすごいものを作れるかもなあ、くらいに思っていたふしもあります。
自分はバカでした。パソコンがあるとかないとか、関係ないのです。パソコンさえあれば、なんて思う者に、本当のプログラミングがわかるはずがありません。
そんなこんなで、自分はまともにプログラミングを経験しないまま社会人になったわけですが、幸いにもプログラミングに対するこの感覚は、仕事でパソコンを日々使うようになってから徐々に変わっていきました。
具体的には、パソコンが、自分の中で「カタログの商品」から「武器」へと変わりました。それと同時に、プログラミングという行為が、武器開発という位置づけになりました。
武器というのは言い過ぎだとしても、ちょっとしたプログラミングは確かに業務上の課題を打開しました。それなりに計算機科学の教科書を読んで勉強をしたこともあって、いつのまにかプログラミングに対する「得体のしれなさ」も解消してました。
結局のところ、自分にとっては、プログラミングという行為の「得体のしれなさ」から解放されるまでにずいぶん長い時間が必要だったことになります。自分がそうだったからといって他人もそうだとは限らないですが、たとえば小学校で形だけプログラミングを教わっても、分かるとかわからないとか、好きとか嫌いとか以前に、なんかモヤモヤした気持ちになるだけの子どもも少なくないんだろうなあ。それは不憫だなあ。
かといって、自分がいまプログラミングで少しは戦えてるのは、そのむかしパソコンに憧れがあって、得体がしれないなりにプログラミングをする機会が若いときにたまたまあったからでもあるので、そういう機会になるなら小学校で形だけでも教えるほうがいいのかなあとも思います。
オチがないので、このへんで。
好きに表記すればいいと思いつつも見ると内心もやもやしてしまう。
やっぱりJavaと表記してほしい。Java……かっこいいじゃん！
※ Javaだけだと馴染みのない人もいると思うので似たような例を挙げる。
× SKYPEアプリ ○ Skype × PHOTOSHOPソフト ○ Photoshop × YOUTUBEサービス ○ YouTube
大まかには次の二点だと思っている。
COBOL、LISP、ALGOL、FORTRAN、PL/I、APL、BASIC……
今はFORTRANも新しいFORTRANはFortranと名乗っているし、BASICもBASICの派生はVisual Basicなどと名乗っていたりする。
時代に逆行してJavaをJAVAと表記してしまうとJavaがあたかも古い言語であるかのような印象を与えることになる。
× JAVA ← 1960年代の言語ですか？ ○ Java ← 今時の言語っぽい！
「言語」という接尾辞をつけてしまうと二重敬語のようなまわりくどい印象を与えることになる。
Cのようにググラビリティが低いため止むを得ずC言語と表記するという場合もあるが、Javaならそういった問題は無い。
コンピュータ関係で他のJavaと衝突していないか？それは大丈夫だ。
https://ja.wikipedia.org/wiki/%e3%82%b8%e3%83%a3%e3%83%90
Scalaちゃんは今日も「余裕でした(´･_･`)ﾄﾞﾔｯ」とツイートするんだろうか。
原子核の分野やFORTRANの分野で技術の継承の何が失われているのかはわからないんだけれでも、
私が考えるに、現在の「原子炉の設計（利権込）の技術」が失われることで、
今まで切り捨てられていた別のタイプの原子炉にスポットが当たるということはないのだろうか？
自然環境の変化で、恐竜のような大型生物がほろんで、小型の哺乳類や小型の爬虫類がいきのびたような。
FORTRANはどうするかね。「動いているものは変えるな」の原則からすると、絶滅を待つしかないのか。
いくつかまとめて反論したい
まず最初に言っておきたいけれども、僕自身はHaskellが大好きな関数型言語大好き人間である、ということを先に述べておきたい、それを踏まえた上で以下をお読みいただきたい
最初の「オブジェクト指向 v.s. 関数型プログラミング」や「ふたつのアプローチの比較」はまあ問題ないかなぁという感じ、問題があれば他の誰かに任せます
問題は「関数型プログラミングの利点」と「関数型プログラミングの得意分野はなにか」
まず「関数型プログラミングの利点」だけれども、ファンクタが云々、モナドが云々、これは「関数型言語の話」ではなく「Haskellの話」である
そこを引いてあくまでHaskellの話だと割りきって見たとしても、「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」？ モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリの設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう、パーサの理解にモナドの知識はあまり関係がないと言っても差し支えないのではないか
「書きやすい」に関してはこれはもう「主観の問題だよね」以上の言い様がない、僕自身はC++とHaskellの両方を書く人間で、確かにC++Hakellの方が「短く書ける」と「感じる」ことは多い、がしかしそれはあくまで個人の主観であり、更にはなにか明確な基準を取ったとして、やはりこれは「関数型言語」ではなく「Haskell」の話である、わかりやすく言えば「関数型言語であるLispを僕は読み書きできない」、特定言語の、主観に大きく左右される特徴を関数型言語一般の話であるかのように敷衍して話すのは感心できない
「静的型付け」云々もこれはもう完全にHaskellやOCamlの話である、LispやErlangとは何だったのか
多くの数値計算アルゴリズムは逐次的に定義されている、関数型言語で扱いやすいものではない、簡単にいえば「それFortranの前でも言えるの？」である
遅延評価はこれまたHaskellの特徴であり関数型言語一般の特徴ではないし、別に他の非関数型言語でエミュレートできないものでもない、更に言えばこれが何か数値計算に対して有利な何かをもたらすかといえばそういうわけでもない
「分数や虚数が扱えます」、に至ってはむしろ近頃の言語で扱えない言語何かあるんですか、である、大抵の言語にはその手のライブラリはある、関数型言語に限った話ではない
お前それShellやPerl、RubyやPythonの前でも言えるの？
この手の話は「ライブラリ」の話になり、言語パラダイムにより議論されるべき問題ではない、もちろん自動並列化などの問題で数学モデルに基づいていることが多いHaskellなどは有利かもしれない、が、やはりそれは特定言語や特定のライブラリの話になり、関数型言語一般の話ではない、並行処理の扱いにくい関数型言語の設計など容易だろう
言語の話でも言語パラダイムの話でもライブラリの話でもない、個人の技量の話だろう、関数型言語でも下手にしか書けない人は上手には書けない
GUIライブラリの設計にもよるけど、GUIってOOPの強い分野だと認識していたのだけれど、さてはて
最後に要点をまとめると
